For wallet security and security in general, perhaps a bitcoin operating system? Not a distribution with preinstalled bitcoin.

Let us not assume beforehand that Bitcoin is a ponzi scheme, neither that it will be the future currency. From other axioms I believe it is the latter:

As long as BTC rises drastically in value, people will hoard.
Let me call ambient rise in value the rise in value of humon society (all food, technology, music,... society finds better ways to do things everyday, society grows).
As long as there are enough newcomers to the "ponzi scheme" (some actually believe it is and consciously enter it realizing they are among the first, let me call these ponzi newcomers), the value will keep rising, however the difference between a future trader and a ponzi newcomer is not a thin line. At some point in time, the specular rise in value will diminish and start fluctuating about the ambient rise. Now that segment of BTC holders that were pure ponzi investors will get out of the game decreasing its value somewhat. It is a public secret that if a BTC bank run happens, your BTC could end up worthless. Why would a trader sell his BTC for nothing? At this point you have non ponzi mindset investors still owning BTC. But remember as the specular rise fell away, only an ambient rise is present (that a-rise from average real world work), so hoarding is no longer an issue, and trading WILL commence.

Your argument mathematically equates the claim that value is not a continuous function over time. This is true and false, it is true in that a specific trade of BTC vs USD has a spread as we all know. But there are average values, and these are most certainly continuous.

What you say amounts to: BTC value as a continuous function, is now rising (positive slope), and will -WITHOUT flat 0 slope- start falling (negative slope). The crucial magic of BTC trade will happen once the value starts stabilizing.

The ponzi mindset investors, (who do not actually value the crypto nature of the currency, but societies interest in it) will "step out"/keep their BTC in the new trade system that will really only materialize when nearly all ponzi mindset newcomers feel left out in the cold.

The unfair distribution feeling is a necessary part of BTC that tells your ponzi side of your (sub)consciousness that you wont be making money out of thin air after all.

You could claim that these feelings have been posted on the boards for a long time now, but still the value of BTC is rising like crazy. This just means that there still is a considerable part of newcomers who believe they can ponzi their way with Bitcoin. *some* day old news for some will also be old news for most.

Erm bitcoinexchange.com points to the bitcoin forum?

Is there any difference between the original post and simply sending the private key for an account? i.e. the blockchain does not know this account changed hands?

I was thinking about this a while ago, but it seemed to me that the sender could say buy a space pizza by sending his key to the pizzeria, and as long as the pizzeria doesnt spend the coins, the pizza customer could decide to keep his coins (since he still knows the private key).

I was thinking about a kind of mutual oblivious transfer preventing this? is this possible?

Perhaps the ecdsa signing code and private keys could reside on a smartcard?
How would a user be able to verify a transaction before signing it?
Can a setup be made that guarantees a transaction will be sent to the right person?
I am thinking about the small "calculator"format tokens. Could a custom 'token' display amount and target adress?

So like this: upon user attempt to send BTC a potentially infected pc proposes a transaction to the smartcard. The smart card stores the transaction and is ready to be switched off. The token restarts the smart card, and the smart card analyzes the transaction and outputs BTC amount and target adress to the token LCD. (the token has a button to accept or decline). Upon acceptance, the smarcard signs the transaction and stores it. Computer now starts up the smart card and can find the signed transaction only if user agreed.

Now that I think about it, perhaps the token should have a 2 row screen, one for amount and adress, and a full keypad. Create transactions on the smart card itself through the token.

Assuming the token is not programmable, it would be hard to hack, and since the token is never connected directly to PC, they would have to hack the smart card first...

Currently theres on the order of 10^8 $ worth of bitcoins circulating, and the value may keep increasing indefinitely (as society progresses and generates physical value, while the number of bitcoins asymptotically near the constant value of 21 million bitcoins...).

Since backups prevent data loss not data theft (and actually may promote data theft, as multiple copies are lingering on multiple computers/email accounts/....) and since encryption will need decryption when actually spending coins (at some point the private keys reside unencrypted in ram)

So running arbitrary code on a computer will probably eventually lead to wallet thefts. However as the value increases, the value of formal verification and overflow prevention will rise.

I believe Bitcoin will be more effective in eradicating viruses, and raising higher standards on widely accepted programming/scripting languages and file formats like Flash, since any avenue (not just potential flaws in Bitcoin) of injecting malicious code can be used to access the computer. Bitcoin will be more effective than all AV companies combined, it will force us to solve vulnerabilities at the design point, instead of having AV mobs racketeering individuals for their protection.

(compare the revenues received from malware/AV ads with the future value of cryptocurrencies)

cryptocurrency=>high valued private parts belonging to average joes=>userland tools will be required to be formally verified signed by an open community where everybody can speak up.

let me call cruftware vulnerable software of which one may assume backdoors are not purpousefully placed by their develloppers.

So everyday cruftware like flash (crammed chockfull with the latest newest gadgets and "enhanced user experiences") necessary for many sites, will have to choose between open source, and formal verification (think SPIN model checker), or closed source followed by a correlation of cruftware use and loss of digital savings ("what were you thinking running closed source software?").

I believe bitcoin will enhance the general computing experience.

If this happens having just one closed source service/software running could result in compromise. As more software gets formally verified for the public trust, less closed source software remain an avenue of attack, resulting in more attacks via such remaining software, resulting in thefts correlated with that piece of software.

Quickly the only used software will be open source.

Now all devellopers have a common interest (and have little motivation to develop closed source software that nobody will trust to run, i.e. the average programmer becomes politically awake). A large mass of developers will need to work out a global creativity reward system (Until they develop this, they see little use in coding at all)

Btw, has anybody ever set breakpoints and traced control flow of different official bitcoin client versions upon processing the strange transactions as seen on http://blockexplorer.com/ ?

http://ubitio.us/file/download/393
Click for bigger picture

let monitor the total volume of transactions for the adresses you serve, then suddenly refer all payments to your adresses.

lather rinse repeat

Of source big problem with wallat safty!
Copy "wallat.pasta" to use/steal there bitcoins from open sesame wallat!

assuming that you want to allow colliding accounts/passwords if the user is dumb enough to to use "sex" as his password...

why do you need x at all?

I think x is simply a kind of salt (which does need to be remembered, by you (really not a salt but second half of the password) or the computer (fixed location computer salt))

your prescription for finding x is deterministic as a function of password. In effect, you are just applying a croocked form of SHA256.
Occams razor, if it does not add security leave it behind, and simply use SHA256(password) if you really want the same passwords to generate the same accounts...

so you see this as a feature of the system? forcing people to use strong passwords on pain of losing/sharing money? its an interesting concept
I have never heard of a strong correlation between mutual interests and mutual passwords.... but I can imagine people using concepts of interest as their password (sex/...)

but then why bother with x at all? deriving the private keys from password alone would be just as well...

I completely agree if the nonce was deterministic (not exactly a nonce at all!)


Thus x is a direct function of password. Thus as Garrett pointed out, guess a password and the algorithm will create the account, moreover: lots of average users would accidentally end up sharing the same password/account.

The idea seems fine if x was a random secret number.

This requires to bruteforce 4 bytes = 32 bits ?

He could easily prove possession of 1000BTC by giving a current adress where it resides, and a new adress where it will reside. Post this information on the forum an hour before actually sending the 1000BTC to your new adress. Put your money where your mouth is.

I remember thinking about nonlinear reward factors, they have some interesting properties:

linear: reward derivative is constant per added effort (irrespective of identity)
nonlinear: small efforts can be rewarded (say reward=sqrt(effort)) more than big efforts or vice versa (reward=effort^2)

I will henceforth refer to Reward as R and Effort as E

However keep in mind that bitcoin is pseudonymous. Keep in mind also that there is a difference between verifying a user is human (say captcha) and verifying his identity (say identity smart card available in some nations).

Suppose no Turing Test nor identification is done:

R = sqrt(E): attempt to reward average joe for mining more than BitCoin city heating rigs.
Average joe: downloads miner and will follow R=sqrt(E) for sizeable but not huge E
Greedy bastards: sybil attack compute many small E's (smaller than average joes), the derivative is higher than average joes with a sizeable E.
Now we have given greedy bastards an even bigger edge, and computing power and bandwidth etc still determine how many sockpuppets you can have solve tiny efforts. (in effect being rewarded linearly, if we recombine the many very small efforts at higher tangent)
Note how rewarding many small people promotes rigs, and makes for many accounts for the same person. in theory a slight deviation from linear reward in this sense could have the power to break up megapools...

R = E^2: punish small cpus and reward big rigs compared to linear reward: Only rigs and pools are worthwile, people tend to group and enlist under the same identity. Having pseudonymous accounts is a lossy business, performing effort under one name is more rewarding.

Note how there is a tradeoff between [Grassroots vs Centralization] and [one or multiple accounts]

Requiring an identity card signature for mining efforts could very well be used to reward average joe to promote wide quick adoption of currency, but would allow the goverment to produce fake identity signatures (not of real people since supposedly the private keys are generated on smart cards and never leave the card aherm...)

I also thought about what would happen if the proof of work was purely human: a mass pictionary game or something... and verification of blocks is done by human inspection this would only be necessary during the introduction phase: we could organise a mass pictionary game during a few  hilarious weeks and then many different humans would have coins that will never be replenished after which it could function just as bitcoin with miners safeguarding the network. There is a distinction between mining as a concept to distribute money and mining as a concept to secure the blockchain, I think few would honestly doubt their effectiveness for the latter, but a lot of people would have liked to see the introduction of money differently... oh well perhaps we just jealous fucks...

Can anyone think up a game that would be hard for a computer to play (probably with recognition and creativity)?

Perhaps a captcha solving game? I think the best captcha is making a captcha?

The compiler should use ProPolice or /GS in case of M$

I wrote "suppose".
I am only clarifying that [advertising the design choice to encode the hash of the public key is a safety feature] corresponds to [claiming it is harder to generate enough collisions to find a weak key with same bitcoin adress than it is to crack ECDSA of the public key (requiring to crack a specific public key)].

I do not actually believe these are planted backdoors, but it is our duty to consider all angles of attack, that is what security is about.

How do you make money these days if you find a fundamental security flaw in any crypto system? The prizes like RSA-Challenge numbers are symbolic and often discontinued. Even if you had the ability to generate a false transfer to your account in the fiat system, how long would it be before things get noticed. It seems like one would prefer to attack an anonymous banking system.

To the extent that there are basically no security implications (i.e. mapping larger public keys to smaller adresses), this reduction in combinatorial space is not dangerous. If it is not dangerous (and I probably agree) we could have simply used smaller keys (why then use secp256k1?). It does complicate matters for a potential attacker but it is certainly not advertisable as a security feature (suppose NSA can easily generate SHA256 collisions, then inspect the "public keys" for weak public keys, I dont think the signature check algorithms feature a check on how safe the key is).

In my original post I described how I feel that the original developer should have posted more design considerations, more documentation.

I can read a part of the code and concoct a reason why something is done a certain way. I can ask on the forums, but Satoshi (if it even is a single individual) is not around.

Simply coming up with an explanation does not mean it was the motivation.

At first I could only think up: an added layer of security, to only publish the public key once after which you never intend to use it again.
This made some but not enough sense to me (it is basically a cryptographic claim that it must be easier to crack secp256k1 public key, than it is to collide sha256/RIPEMD combo to generate compatible public keys, of which one might be much easier to crack)

Then I get a reply which makes a lot more sense: adresses become shorter for usability...

Then somebody elaborates my first interpretation and advertises it as a security feature...

This shows my prediction that I would like to see more DESIGN CONSIDERATIONS (think S-boxes) instead of having to resort to speculation.

The person/group that created bitcoin originally, could still elaborate their design considerations, perhaps write a book about it.

Now we have 2 reasons. Perhaps if we can find enough different explanations/speculations for why the public keys are hashed into adresses, Satoshi might feel the need to explain some of his decisions?

How many bitcoins did it contain?
How many bitcoins would you offer for me to repair it? (only if succesfull)

Ah that makes complete sense, i completely forgot about the ergonomic considerations of the adress...
But the public key would take about 64 bytes * 8bit/byte=512 bits compared to 8+160+32=200 bits, thats only 2.5 times bigger, I think few people actually type over an adress, the future will probably have bitcoin adress mime types...
It still seems a bit strange to care about a factor 2.5 in adress size when the main focus is security?

If I understand correctly the bitcoin adresses are
Base58(Version+RIPEMD160(SHA256(PublicKey))+FirstFourBytes(SHA256(SHA256(Version+RIPEMD160(SHA256(PublicKey))))))

Since Base58 is easily invertible (just encoding and not encrytion) we can ignore the inner outer brackets.

Now if ECDSA is considered trusted, why hide public key with a hash?

Consider the following use case: a web shop owner decides to use a fixed Bitcoin adress. The first time he receives bitcoins nobody can determine the public key, let alone its private keys. Suppose the shopkeeper spends some Bitcoins, now the public key must be known publicly to verify the transaction. Now if the shopkeeper keeps making money on the same Bitcoin adress, the extra "layer of protection" is gone so that an entity if existant can crack ECDSA keys, can steal the money from this point on.

I try to understand bitcoin better, but from nearly all perspectives, it is just already implemented, without the design considerations being public.

Perhaps it was done for extra layer of protection for those who decide to never reuse the same adress (call them paranoids or just cautious netizens)
But that is still me speculating, a lot of bitcoins design decisions stay a complete mistery.

In the end nobody knows if backdoors were planted in any algorithms, or vulnerabilities are about to show up.

Among all the bitcoin doom scenarios, perhaps the most effective one from goverment standpoint would be to make sure to produce the first convincing p2p money system, only to pull the plug, buying time before the majority of citizens will ever try to trust such a system again.
If this theory is correct, they would pull the plug as soon as it has been the major mode of payment. This could generate a lifelong distrust with a lot of citizens.

Assuming this theory is correct what we actually have is a race: the goverment/organisation that built bitcoin to undermine or delay the arrival of real cryptocurrencies by undermining the credibility in this category of money, they want the bitcoin community to grow quickly (convince people of cryptocurrency) right in time before they pull the plug (cold shower of hard-knock reality lesson to crypto currency users). The people who actually believe in cryptocurrencies, must try to identify the built-in kill switch(es?) and adapt the code. How much time is left before the organisation decides to pull the plug?