This is worrisome, but we could still do BTC signatures on custom hardware entirely and not rely on normal computers.

Maybe there's a future in mini-computer-banks that can print small slips of addr/key pairs, entirely offline, secure and open source hardware to software.

The Bitcoin nodes could still run on normal computers as everything there is public anyway.

So other than some "maybes", no one has seemed that interested or contacted me with anything serious. In the meantime I think I am close to solving this myself so I am taking down the task.

If you were working on this despite not telling me clearly, as I instructed, we can talk about a smaller compensation for your work if you have something to show.

@Dare
I read your last post as "you not having time", let me know if that's wrong.

Answer: The correct syntax for importprivkey is
importprivkey("keykeykeeykeykekykeykekyekkey")

All commands seem to require the quotes.

Since you seem genuinely interested there are 3 major safe guards:

1. The card does not know, however it tracks your average spending and will block amounts too much over that normal.

2. The card will convert the charge to say "0004e00" or 4 BTC. It will then substitute the characters like so: "AKGAePO" and send this to the terminal. Since the first and last parts of this are usually the same it will be faily easy for the user to remember that AKG=000 and PO=00. If the terminal were to cheat however the result would be say AKHBePO and by looking at only the first 3 chars the user can tell he is being over charged.
This is called the Vignere cipher and it is faily easy to break - but impossible without some amount of data and a random untrusted terminal only gets to try once.

... or he can just put his PIN and rely on the charge maximum to protect him.

3. If the terminal immediately attempts to charge the card again after having received the PIN it will fail because the card locks itself for a few seconds after each spending. It cannot tell time so the locking works by the terminal polling the card say 1000 times.

I agree this proposal is honestly not that good:

Sure sign addresses and sure have signed receipts - brilliant - but keep it away from the blockhain.

http://www.zdnet.com/has-the-nsa-broken-ssl-tls-aes-7000020312/

We don't need arcane CAs from the 90's, Bitcoin works BETTER.


The example given with the paycheck is really weak and doesn't even BEGIN to justify this: Just send your own money around a bit, say you paid using an online wallet or use coin-mixing TOR and the whole shebang.

With Bitcoin it is SOO easy to hide.

EDIT:
And when buying: If the buyer doesn't send, give him a bad review and crush his business.

Just saying things don't make them true and you clearly have no idea what you are talking about.

Its all about protocol, if it is secure it doesn't matter if the terminal is trusted or not - much like Bitcoin client communication.

If by "everyone" you mean half or less than half the world's population sure:
http://www.go-gulf.com/blog/smartphone/
Of those only 29% have mobile internet:
http://en.wikipedia.org/wiki/List_of_countries_by_number_of_broadband_Internet_subscriptions

The mental arithmetic is not required, you can just put your PIN. There are also other safe guards so the 10 BTC charge can not happen.

My grandmother has trouble enabling her phone's USB storage device connection type - so good luck with a complex app that requires constant internet connection to function and will crash her phone if she installs the wrong non-light app.

I consider my potential market share very decent

I solved that ages ago. The card encrypts the amount with a "passphrase" the card owner knows and sends this to the terminal, hence the terminal cannot fake the amount actually sent to the card.

As for the cards programmability both Java cards and BasicCards can be programmed at will and bought by largely anyone.

Everyone on this forum needs to read up on rapidly-adjusted-payment transactions as I did a few days back. Entirely eliminates the need for off chain solutions:
https://en.bitcoin.it/wiki/Contracts

As for why fees will go up:
Its an economic equilibrium - if mining goes to zero anyone can mess with the blockchain and the BTC users stand to loose much value. If mining fees go to the moon the BTC economy will be inefficient and just waste CPU.
So basically => mining fees=risk-of-attack*damage-from-attack => Fee=Risk*Cost.

Since it will not take that much mining to make most attacks near impossible future total costs of the Bitcoin system will likely be extremely low. Keep in mind that mining can effectively be ZERO until you come under attack at which point you can scale it up, thus minimizing average cost.
The current block reward is largely an encouragement to waste resources and is only justified in its necessity to create Bitcoin in the first place.

It would have been more economically sound if Satoshi had simply distributed the 21 million BTC, but that has other issues and would not have incentivised the construction of the Bitcoin system in the same way.

It seems to want 2 args for the importprivkey function, functions are given as func(arg0,arg1...) and the old import command is gone.
I think the 2 args are wallet-name and the key in some format in that order... but where do I find the wallet name?

A card chip can do it.

The card I use however uses a cryptographic co-processor to do the signatures so the cheapest cards usually cant do it.

It takes less than a second, though I did not time it more exactly than that.

Hmm so simple.. but thanks a lot.

Will that be put automatically into an exe? Otherwise it doesnt really answer my question to post the same link as the op..

If the Danish Bitcoin Foundation wants to make a danish version available for download how can we do that?
-Does electrum use a localization file?
-Is there a list with available translations? (to see if its already done, I did not see danish in the link)

Nothing will change in short. There will be less mining though and Bitcoin will be supported only with tx fees, however BTC will continue to function and be used.
The mining machines will still be useful for getting these fees and securing the network however. Mining will likely be very professional and centralized by then.

Some very clear similarities yes:
Sounds like proof of work to me, though some of the rest is more like proof of stake... the document is very unclear on specifics though.
Signing of transactions is the same and escrow possibilities are mentioned.

Funny it uses the names Alice and Bob too, are those normally used in money transmit examples? Saw that with Bitcoin too.

I have no idea if the doc is legit though.

1.2 billion is not a lot of money... lots of companies are worth that, Bitcoin is not just another company its a new paradigme.

Just drugs? From that alone the value could soar to 100 billion, (though the money trail is likely not the hardest part of distributing drugs and drug users are likely not very technical).

Here's the docs for anyone interested. I have started digging into it myself, but the offer still stands.

http://www.4shared.com/zip/Y4DE2gKZ/BasicCardJavaLibDocs.html

I think Satoshi might be fine with the ruthlessness of the protocol as in: "If you can't type a number right, maybe someone else should get the power your money represents".

That said typing wrong  is my nr. 1 fear with BTC...

Theres a Danish bitcoin foundation now:
http://www.danskbitcoinforening.dk/