HeadHunter you still aren't getting it.  What Meni is saying is the PRICE is what matters.

Lets pretend there are two mining bonds (each are 1MH/s per share, neither has default risk, both have same liquidity).

MINE.A is 1 BTC per share.
MINE.B is 0.01 BTC per share.

You are saying both would be a net loss?

Obviously not.  Somewhere between 1.00 BTC per share and 0.01 BTC per share there is a price that for a given period of time and given future difficulty would break even.   If the security is priced below that you would profit if you bought it.  If the security is priced above that you lose if you bought it.    "Investors" on GBLSE buying mining bonds have been "stupid" to date massively overpaying for bonds and creating a scenario where even under optimistic conditions they are unlikely to be profitable.


And if before it aproaches zero the sum of dividends paid are > the the purchase price you would have a net gain.  Take one of those "losing" bonds and instead imagine it was offered at 50% of the price it was offered at.  Was it still a loser?  The securities were overpriced.  It is that simple.  They were overpriced and investors who poorly understood the risks and economics created enough demand that they sold out at these over inflated prices.  That led to other offerings at similar overinflated prices (I mean if you see a competitor sell out at 0.3 BTC per MH why would you offer your for less).  It is called price discovery.  Obviously (hindsight for some but foresight for many others) the offering prices were way way way too high and those investors were doomed to lose money.

Another way to look at it is NPV.  The sum of any periodic payments over any period of time can be expressed as net present value.  (i.e. $100 per month for the next 10 years is worth $x right now).  Calculating NPV for 1 MH/s of mining power is challenging because determining future difficulty is tough but all mining bonds have an NPV (even if unknown until after they stop trading).  If you buy it above NPV you lose.  If you buy it below NPV you win.


TL/DR simplified version:
There is nothing wrong with the concept of a mining bond.  However all mining bonds to date (and probably all mining stocks too) have been horribly horribly overpriced.  Many are probably still overpriced despite falling 30% to 50% since launch.  The mining bond market resembles the housing market.  If you just took asking price for a new home in 2007 you probably have lost money.  Does that mean the concept of owning a home is fundamentally flawed or does it simply mean you bought an asset at an overinflated price?

TL/DR even more simplifed version:
If you overpay for an investment you will lose money (or earn a lower return than you otherwise could have).  It isn't more complicated then that.

It isn't security:
You seem to keep skipping pass the point that it wouldn't provide security.  The reason for encrypting the keys is not to be an end-all protection against theft.  Ask someone infected with a keylogger, or trojan which replaces copied bitcoin addresses with one owned by the attacker how effective an encrypted wallet it.  It isn't.  So why do we encrypt private keys if funds can still be stolen?  Simple it requires the thief to have both the wallet and passphrase.  If the system/OS is compromised then the theif directly or indirectly will but there are many instances where  thief may only gain access to the wallet file such as accidentally left on a donated/junked computer, survives a format, poorly configured dropbox, stolen usb drive, sent to email as a backup, etc.  

User should know the fee
I don't use bitcoin-qt much but if it doesn't always show the user the fee (even if fee is the default amount) then I agree that is an issue.  Not just a security issue but also a poor UI issue.  Your banking example is good.  The user should know the fee for every tx.  Most users will probably ignore it but the fee should be displayed for every tx.  


Note: I suck at UI work (my field is in back end db development).   It probably can be expressed better, but even that would be better than no info.

About bitcoind
Adding validating to bitcoind "are you sure you wish to pay a fee of x" is counterproductive".   It is designed to be used for automation (hotwallets, merchant systems, service providers, mining, etc).  There should be no confirmations just request and response.   BTW if a thief has access to your bitcoind RPC well your wallet is going to be 0.0000000 BTC real quick.  When you execute unlock they will quickly spend out your entire wallet in a fraction of a second.  I wouldn't worry about a thief making you pay to much in fees is via a compromised RPC.  You won't have any coins to overpay fees with.

Why would it be a monopoly?  Monopoly tend not to survive in free markets and there are no real barriers to entry other than NRE costs.  While the NRE costs are substantial if there is enough money to be made mining competitors will jump in.  If there isn't enough money to support competitors than the chain is a economic dead end anyways and the monopolist is likely the one taking the biggest loss.

Selling shovels to gold miners has traditionally been more profitable and less risky then mining for gold.  BFL understands this and future players will too.  The turn around on capital is much faster and ROI% much higher.  The equipment seller offloads all the difficulty, future price, better competitor offering risks on the miner.  All that makes it much easier to project cashflow which makes it easier to get venture capital funding. 

There is no good way to do that in most operating systems.  It is a fundemantal security issue that goes far beyond Bitcoin.  How do you know the client is actually the client?  How do you know the legit client hasn't been modified in memory?  How do you know the attacker isn't intercepting and modifying any warnings or messages from the client?  How do you know the attacker isn't modifying your input (you send coins to 123... attacker modifies that so client sends them to 1456.... then attacker intercepts and modifies the GUI so you see coins sent to 123...)?How do you know no parameters in the client have been modified?  How do you know there is no other process watching the client? watching the I/O?  etc.

Those are all security jobs for the OS.  If the OS is compromised or has a flawed security model then trying to make it secure at the client level is just going to fail.

The real solution is a hardware wallet.  Essentially the "client" becomes computer, custom OS, and program all in one.  Since the developer can control all aspects of the software/hardware stack you can create a more secure solution.   If Bitcoin becomes large enough I see customer hardware clients being the direction things are headed.

I think you are still missing the point.  A passphrase in the client to change the setfee wouldn't be useful and only provide "feel good security".  If an attacker has compromised the system to where they can execute arbitrary code they could modify the bitcoin.conf, send tx using the bitcoind API, or even replace the client with a trojan client which uses a custom fee (and hides it from the user) or piggybacks off users unlock request, or sends a copy of the wallet.dat and passphrase to the attacker. 

It would be the job of the OS to ensure that unathorized users can modify programs and files.  If the OS fails in that duty a passphrase in the client isn't going to stop an attacker and adding a token passphrase to the client is just going to dupe a user into thinking they are still safe when they aren't.

What is the problem exactly?  You rambled on and on without actually stating a specific complaint.

http://en.wikipedia.org/wiki/Bitcoin#Bitcoin_Services_and_Clients

Multiple clients are listed.  The satoshi client is actually not listed first and is put in the middle of the pack.

Because an attacker could do that by modifying the client also (DLL injection for windows).   The purpose of the encrypted wallet (not to be confused with the client but the actual wallet database) is to prevent theft of private keys.  Nothing more.

Liquidity.  Especially during the growth phase.  Last time I check you can't eat a share certificate.

5 MH/s produces ~0.02 BTC per week and that is before electrical costs, before the reward is cut in half, before your profit, before equipment losses/fees/outages/etc, before difficulty rises.  How exactly are you going to pay 4% interest?

This isn't the CME.  200ms would be more than fine, you could probably get away with double that.  Hell in peak volume market orders can take 10 to 20 seconds to fulfil on MtGox.  Maybe in 20 years Bitcoin HFT will require ultra low latency links, but likely by then Bitcoin will simply be traded on Forex with all its fiat brothers.

Wires "usually" (nothing is guaranteed or simple in the fiat banking world) have flat rate fees.  $40 sounds about right (between what you bank charges, interim bank charges, and MtGox charges).  It may vary somewhat depending on the banks involved but $30 to $80 is normal.  $40 on $10,000 wire makes a lot more sense than $40 on $300 wire.   Really wires are intended for very large transfers that need to be funded rapidly.

Next time bump that $300 to $500 and use Bitcoins Direct; 1% below MtGox with no fees

Anything is possible but that is very unlikely.  To register a DBA it can't conflict with any other existing name.  Given a Trendon Shaver does exist in TX and had a criminal charge (I doubt a fictitious legal entity which only exists on paper was physically arrested by the Police) years ago the likelihood a DBA for that name would be approved is essentially nil.

For example you could form a company "556j enterprises, LLC" and get a DBA for "Bitcoin Traders" but you couldn't get a DBA for "Microsoft" as that would allow you to legally open bank accounts, send invoices, and advertise as Microsoft.   You could imagine the complete and utter chaos that would happen if anyone could just register any name as a DBA without limit.

Then again govts do screw up so it is possible.  

This can be partially mitigated by using an algorithm which is difficult to optimize.  bcrypt attempts to achieve this.   IMHO SHA-256 is  the worst possible choice.  The user is likely generating the private key on a personal computer ill suited for a high number of rounds.  Mining has created a great incentive in improving the hashing efficiency (MH/$ and MH/W) such that the multiple between a major hashing farm and the user is already huge.   The rise of ASIC hardware will increase the potential resources of an attacker by another order of magnitude.

Given the user can wait for some significant but not unreasonably long period of time the use of something like bcrypt would seem to be preferable.   GPU acceleration of bcrypt is generally poor (although FPGA acceleration is not as adversely affected).  Scrypt attempts to hinder acceleration on both GPU and FPGAs.

TL/DR version.  The attacker will always have more hashing power than the user.  The goal is to keep the attackers throughput as low as possible (while still keeping the algorithm functional for end user).  This can be achieved by:

a) more rounds.  If the user only needs <1 private key per second then make it take a full second to generate.
b) salt.  prevents parallel and precomputation attacks.
c) algorithm optimization.   Use algorithm which is fast for user but not much faster (or optimally no faster) for the attacker.



Hypothetical numbers.  Using SHA-256 the user selects a strength which will take <1 second to generate.  That would be ~1 million iterations (assume implementation in code is roughly similar to throughput of CPU miners).

An attacker with a single GPU could attempt ~500 million to 1 billion passwords per second.
A major hashing farm (100 GH/s double bitcoin hashes) could attempt 200 billion passwords per second.
A 10TH/s (double bitcoin hashes) could attempt 10 trillion passwords per second.

Against that kind of brute force virtually all passphrase are going to fall.  The throughput of the attacker must be reduced.  We can use salt but if it is determined by user input it will have relatively low entropy.  We can use more rounds but the multiple of attackers throughput is so high that even having user wait 10 seconds per private key "only" keeps a major ASIC hashing farm at 1 trillion passwords per second.

An algorithm which prevents re-use of the massive optimization in bitcoin mining for attacking passphrase is essential.

While bcrypt can't protect painfully weak passwords the combination of deterministic salt derived from user responses and a passphrase requirement of at least 8 characters, and a large number of rounds can limit the attacker to an ineffective throughput (baring dedicated bcrypt processors) which makes brute force attacks infeasible or at least uneconomical.

Rainbow tables can be defeated if a derivitive of the salt is correctly introduced salt on each round.  It makes the output of the round dependent on round number.  

That being said I feel using a function specifically designed for multi-round hashing would be better (PBKDF2, bcrypt, scrypt).  It is far too easy to design a cryptographic systems which appear secure yet have hidden flaws.  Those kdf were specifically designed to hash passphrases over multiple rounds and prevent cryptographic attacks other than pure brute force.

If there is such high confidence that Pirate will repay everyone in full why are the PPT bonds trading at a huge discount to face value?

Bond                                                                        Bid            Ask
https://glbse.com/asset/view/BIB.PIRATE                0.342   0.449
https://glbse.com/asset/view/FOO.PPPPT                0.370   0.470
https://glbse.com/asset/view/TYGRR.BOND-P          0.457   0.615

The market is saying there is less than a 38% chance of repayment in full.  The actual number is probably lower because the market is discounting the possibility of repayment + interest and including the possibility of repayment less than full.

Well that is the question of the week.  If it is/was a Ponzi scheme the answer is he won't and investors will lose.  If the PPT bonds are any indication the market is anticipating a less than 50% chance of repayment in full.

Well there is some mixing up of terms in your post.

The KeyID is simply a way to identify the key.  
You encrypt using the public key of the recipient (and the recipient decrypts using their private key).
You sign using your private key (and verify using the public key of signer).

When encrypting or signing the output will always be the same.  The short or long key ID is simply a way to identify the key.  There is only one key.
Kinda first name or full legal name both identify the same person.

Are you just asking how to get the extender (16 digit) keyID for your keypair? If so I assume this is for Bitcoin-OTC?

If so this should help.  I don't believe GPA has an option to show 16 digit keyID so you will need the GPG CLI tool.   You can keep using GPA or any other client once you have the keyID because it won't change.

GPG command line tool:
http://ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32cli-1.4.11.exe

GPG clients find all keys from the same user store so  if you already created or imported a key using GPA (or another client) it can be "seen" from the CLI tool.

To get extended keyID

Example:

28BB715FC26C17CD is the 16 digit KeyID for our company master key.  You may or may not have "sub" keys listed.  Sub keys are linked to the master key.  You can google GPG subkey for more info but the simple version if the master KeyID is your full identity.  It was what you want to provide the counterparty.

True but it does provide a lower bound.  IF 100K* BTC of shares were issued we know the minimum amount deposited would have to be 100K BTC.  Even if every share was bought based on interest payments at least 100K would have had to be initially deposited to produce that much interest.

* Note: I have no idea the value of all PPT shares on GBLSE.  The 100K is simply an example.

Nobody knows.  BFL hasn't provided any data.

The cliff notes version of that last 20 threads (none of which can be proven or disproven):
a) It really does use 2.5W (W not V)
b) The USB "powered" is just marketing hype.  It gets some power from the usb port but also some from the wall. *
c) It requires two USB ports and thus ~5.0W
d) BFL made a mistake. **
e) BFL is a scam
f) It has no external power requirements because it is powered by a radioisotope thermal generator. ***

* BFL has done this before.  BFL claimed the original Single was a unique blend of FPGA and ASIC technology.  While they never explained that claim the only plausible theory (since we know none of the hashing is done by ASICs) is they were talking about the USB controller (which is indeed an ASIC chip).

** BFL has done this before.  They were off on the power consumption on the original single by a factor of 200%.

*** Ok I just made up theory "f" but that would be cool.

The passthrough which were issued as bonds on GBLSE are a good start.  Since the shares were sold on a third party platform you know that those are outside funds entered the scheme (not just paper profits).