It sounds like PPoweredP wants a KickStarter-like system.  That way, investors are protected because a project will not fund unless it reaches the fundraising goals.

The level of trust for any website -- be it mtgox, blockchain.info or whatever -- is surely lower than a decentralized client or paper wallet.  blockchain.info seems as much a SPOF as the infamous MyBitcoin web wallet.  (note: not accusing the site owner, just noting its vulnerability and untested nature)

None of the other websites are as attack-hardened as mtgox, but even then, the recommendation for people storing large amounts of bitcoins (> 500 BTC) should be a decentralized solution.

Yes, websites are easier for Aunt Tillie right now, as we've seen with MyBitcoin and Bitcoinica, storing large amounts of bitcoins there for extended periods can lead to large thefts.

Be your own deposit insurance.

Blockchain data is validated by every P2P node, miner or not.

Thus, even a miner with 100% network power cannot rewrite basic rules that other users disagree with.

Miners choose which transactions to include in a block.

A valid choice is "no transactions" [besides the required coinbase transaction].

KickStarter has shown upfront financing can be highly effective.

Sure, there are flame-outs.  That does not detract from the successes.

Blatant guessing, based on:  number of claimed mtgox users, number of peer nodes on network, number of forum users, previous data posts around here, ...

Not a reliable number at all.  Just trying to find a number that we could say "probably over X"

Any chance of doing zlib-compressed JSON on the wire, rather than uncompressed text?

hmmm, it sounds like there may be an OSX-specific problem.

What is the previous known working version?

Was that an official OSX build from Gavin, your own build, or a third party build?

Thanks.

Correct.

And beyond that, the RPC API has never had the same ironclad backwards-compat guarantees that the blockchain and P2P network have.  From satoshi's time to present, RPC calls have been considered an internal control plane.  Compatibility with existing use cases is very important, even with RPC API, but sometimes there are exceptions:  deprecated, unused APIs; APIs where we've discussed and planned for changes ahead of time, etc.

For the main client it is low priority.

But in a blatant plug... https://github.com/jgarzik/pynode does support big + little endian out of the box.

Just for reference, last year's talk (warning: outdated) is available at
     http://gtf.org/garzik/bitcoin/2011/state-of-the-coin-2011.pdf

Astute readers noted that the table of contents jumped from slide 10 to slide 12.

The PDF in the OP has been updated to include a "Reality Check" slide, which was authored and intended to be presented... but due to an errant mouse click ("hide slide") was never shown.

Or...

When bitcoin value goes up, the incentive to mine increases.

Just had a big bitcoin conference, with interest spreading.

But most clearly, if BFL's ASICs are anything remotely to spec, mining with even 500 would be far more noticeable than the current hashpower increase.

It is highly unlikely that a merchant would ever see a double-spend until it's too late.  The favorite double-spend example involves secretly mining a block containing the second transaction, TX #2, the double spend.  The merchant sees TX #1, hands out the goodies with zero confirmations, and then the evil thief releases his block containing TX #2.

In the other double-spend case, where TX #1 races TX #2 across the network...  Presumably the merchant is well connected to the P2P network, receiving and broadcasting transactions normally.  Any double spend not sent in a block, but rather simply sent out to the network, would probably be rejected by all the merchant's peers.  The merchant would likely never see TX #2.  The moral of the story here is merchants should always be well-connected.

Zero-confirmation transactions are fraught with danger and possible mischief.  We recommend against zero-conf transactions.

It has been shown that even 1-confirmation transactions are within the realm of a determined attacker, so I would never go below 2 confirmations for anything remotely valuable.  But at that point...  if you can wait 20 minutes, surely you can wait 60 minutes for a full 6 confirmations.

The merchant must simply ask themselves about their risk level:  if the transaction is low value, then will an attack cost more than the price of the good being sold (coffee)?  That is a business decision and not a technical decision.  Can you afford the occasional double-spent coffee, in exchange for convenience of zero-confirmation?

Makes sense for new issues...  for existing issues, one presumes that a contract change -- even to add defaults -- requires shareholder agreement.

No.

A double-spend is not relayed by the network, nor accepted by miner.  That economic incentive does exist, though, you are correct.

Also, one a transaction has been placed inside a block ("confirmed"), all nodes will refuse to relay a double-spend transaction for those same funds.

Close.

Each node decides what to relay, or not.  Miners have no control over relaying.

As you say, the user does not have control over what nodes relay -- apart from knowing that "standard" transactions are likely to be relayed, and "non-standard" transactions are not likely to be relayed.

Miners do have control over what transactions are placed inside each block, but that is a separate issue from relaying.

That will always be a separate project, as far as I can forsee.

That is one distributed bond effort, yes.

There is no Official Blessed Distributed Bond effort; each developer just scratches their own itch.  In pybond's case, I am writing a basic distributed bond implementation, with no pay-to-policy stuff, just to prove the basics work.