text:
Exported wallet.dat from bitcoin-qt. Then uninstalled bitcoin-qt. Now the wallet is empty!
Some months ago, I installed bitcoin-qt on Ubuntu, created a wallet and address, then transferred funds to it from MtGox. I let it sync up for over 10 days, but it never fully synced. So I exported a wallet.dat file, then uninstalled bitcoin-qt.
Today, I installed MultiBit and imported the wallet.dat file. It is empty. It has one address which shows no transactions or balance on blockchain.info. The wallet in bitcoin-qt had several addresses.
What happened? Is there anything I can do to restore the files containing my bitcoin?

I had the same problem. What I had to do is delete the copy of the blockchain and let the newly installed bitcoin qt download and sync from scratch. All was good after that.

Can you re-install bitcoin-qt and open the wallet again? Maybe all the addresses are there.
What about your account at Mt. Gox? If you transferred the coins from Mt. Gox, you should be able to look up the transaction on blockchain.info. Either the sending address still has the coins, or the receiving address does.


text:
Does a wallet containing multiple addresses have a single private key?
Title says it all. Would one private key enable you to recover all the addresses in your wallet? Or does a wallet just contain a series of key-pairs?

There are three main types of wallets:

non-deterministic (random) wallets
sequential deterministic wallets
hierarchical deterministic wallets

With a non-deterministic (random) wallet, all the private/public keypairs are generated randomly. The wallet may generate 100 random private keys as soon as it is initialized, for example.
With a sequential deterministic wallet, a passphrase or sequence of characters is randomly generated to act as a seed. It is then repeatedly incremented and hashed to generate new private keys.
With a hierarchical deterministic wallet, a single keypair is created initially and is known as the master keypair. This master keypair is used to generate child keypairs (remarkably, new bitcoin addresses can be generated using just the public key).
Here's a more in-depth explanation: What is a deterministic wallet?
Also, here's my python implementation of a sequential deterministic wallet. And here's a good example of a hierarchical deterministic wallet.

There's two types of wallet. A conventional wallet is just a collection of random keys, Bitcoin-QT and Multibit fit into this category. A Hierarchical Deterministic like Electrum or Armory generate all the keys in the wallet from a single key, so that one backup is permanently associated with a wallet no mater how many new addresses and change addresses are used.
https://en.bitcoin.it/wiki/BIP_0032

Thanks for the reply. That article was over my head, but if I'm understanding this correctly--normal wallets will generate a number of key-pairs, but a HD wallet will generate a bunch of public keys for a given private key?

That's right, though a HD wallet will derive private keys from a master key using a specific standard method, rather than using it directly.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
Why doesn't BTC depreciate in value as its supply increases?
The popular intuition is that that greater supply = less demand. I've looked around and haven't found a counter-argument. Why is the BTC gaining value as its quantity increases?

I don't follow your intuition.  The usual rule is that greater supply leads to a lower price, if demand stays the same.  But clearly here demand is going up even faster.

I think that was the root of my confusion: the simple correlation != causation problem. I assumed that demand would decline because of increasing supply--which is false.

The popular intuition is typically correct in well-saturated markets, but Bitcoin is not yet a well-saturated market. Though the supply of Bitcoin is currently increasing the demand is increasing dramatically faster. This is because we are during the initial adoption curve of a new technology and new demand is created as individuals discover the new tech.
In short, there is absolutely some downward pressure on Bitcoin's price exerted by the inflating supply, but it has been completely overwhelmed by upward pressure from new adoption.

The rate of bitcoin growth is regulated by virtue of how it was built such that each block should be found on average every 10 minutes, and the difficulty of mining is adjusted up or down to keep that rate more or less in line. Since the rate of production cannot be increased by brute force (by adding more computing power to the network) over the long run, there will no doubt be an increase in demand which is growing at a faster rate than the increase in supply. Of course the supply is fixed but the last bitcoin won't be mined for 100 years, so that shouldn't really play a factor today but that the rate of production will regulate.
If the ultimate amount were the regulating factor, then natural resources such as oil, rare earth metals or even gold should shoot to the moon because we know they will be exhausted in the next few centuries.

It's the supply AND demand curves that determines the equilibrium price. If the supply increases but the price remains unchanged, that means demand has also increased.

The supply of Bitcoin is increasing at a decreasing rate. If the supply curve just went to infinity, Bitcoin would be less attractive over time.  But it doesn't: How many bitcoins will there eventually be?

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
If the supply of Bitcoin is regulated, how could it be said to be decentralized?
The minting of new bitcoins is deterministic, and there will eventually be a cap to the production of new bitcoins. Why do we say that bitcoins are a decentralized currency if they are created in such a "top down", regulatory way?

Bitcoin is decentralized because the authenticity of all transactions depends on the 'decentralized' network of miners who compute SHA-256 proof of works hashes. The Bitcoin cap is completely arbitrary and doesn't really matter since Bitcoins are divisible to multiple decimal places. Whether there will be 2,100 bitcoins or 21 trillion bitcoins, the cap doesn't really matter. Its all relative. I feel as though the 21 million number was picked with consideration to the number of potential users in correspondence to the size of ints, floats, etc.
Many people debate as to how 'decentralized' bitcoin really is. It seems as though those who create or own ASIC miners are the ones who really have the edge on the market. Some say that certain altcoins that cannot be mined with ASICs may be more decentralized, since CPUs and GPUs are more widespread.


text:
Possible to temporarily reduce the supply of a cryptocurrency?
Does a cryptocurrency that can have its supply be reduced based on some factor currently exist?
If not, is this possible?  If so, how?

This is possible through the use of a multiplier. For example, you could add it to Bitcoin as follows:

You add a "currency multiplier" and "next currency multiplier" to the block header.
All Bitcoin amounts presented are multiplied by this multiplier.
You have a set of rules for how the next currency multiplier changes. For example, miners could be permitted to change the "next currency multiplier" by a small amount in each block.
Periodically, say every time the difficulty is adjusted, the currency multiplier is also adjusted by up to 2% (or whatever) towards the next currency multiplier and the next currency multiplier is set to the new currency multiplier.

So if I want to pay you "1 Bitcoin", I actually have to pay you an internal amount that depends on the multiplier. Changes in the multiplier would change everyone's displayed balances. This way, if miners believed there were too many Bitcoins in circulation and the value was dropping, they could "vote" to reduce the multiplier. This could result in a more stable price and thus make it easier to price goods in Bitcoins. At least, those would be the arguments in favor of such a scheme.

One more to the trove of good ideas for new crypto-coins to try! Wish there were a site to list them all and check who's tried them before: using prime numbers as proof-of-work - done, proof-of-stack - done, proof-of-storage - pending. Multiplier - pending, variable time between blocks - pending...


text:
Purpose of difficulty?
Is the purpose of difficulty only to manage the rate of a cryptocurrency's creation, or should difficulty also increase over time to compensate for Moore's Law for a consistent level of security?
Would a cryptocurrency with an extremely short difficulty time of < 5 seconds, even 1 second, be secure?

The purpose of the difficulty is to maintain a 10 minutes average delay between each block and by the way to ensure the Bitcoin emission rate.
The difficulty is adjusted every 2016 Blocks (2 weeks) to compensate the increase or the decrease of the network calculation power.
If the difficulty is so low that the network generates blocks in less than 5 seconds this would be highly unsecure because this would not let time for the blocks to be shared on the network. The result would be a lot of orphan blocks.
Some altcoins were launched with 15 seconds blocks target. Many of them like smallChange failled and doesn't exists anymore.

Thank you!  Exactly what I was looking for.  Is there a compromise between Bitcoin's intended 10 minute time and a consumer's ideal of "instantaneously"?  In other words, what's the smallest time possible that still prevents the problems you outlined?  Thank you so much in advance!

As far as I know there is no altcoin with less than 15 seconds blocks target. Worldcoin is the only one that worked for some time using 15 seconds block target but they updated it to 30 seconds because of the orphan block problem.
But having fast block target doesn't mean that transactions will be much faster. Look at Litecoin they have 2.5 minutes block target but they need 6 confirmations (about 18minutes) before a transaction is valid. Bitcoin has a 10minutes block target but it only needs 3 confirmations (about 30 minutes).

Thank you for your knowledge!  Also, if the block size was limited to no more than 1 transaction, would the orphan problem still be an issue?  Thank you so much in advance!

I think that it wouldn't really help. Bitcoin is decentralized so every client is connected to about 8 other clients. If there are 8,000 clients it would still take some seconds independently on the block size before every body will get the new block.

Again, I very much appreciate you sharing your knowledge.  How could the orphan problem for "instantaneous" verification be solved?  Should I open up a new question?  Thank you so much in advance for helping me to understand this issue!

You can open a new question but I don't think "instantaneous" verification will ever be possible using a bitcoin like protocol.

Thank-you Jan.  You've helped me so much, and it is much appreciated!

Thank-you Jan. You've helped me so much, and it is much appreciated!  I've posted the new question here if you'd like to take a stab at it.  Thank you so much in advance!  http://bitcoin.stackexchange.com/questions/18692/instantaneous-transaction-verification

Joe Pineda asked the right question : how much safety do you need? 99%, 99.99% 99,99999...%?
If you are a bar selling beers you probably don't need to wait the payment to be included in any block.
Like blocks, transactions are also shared to all Bitcoin clients. The honest miners will only try to include the first transaction they received and reject any double spend attempt. So if you wait lets say 5 seconds and your client not received any double spend attempt you can be pretty sure that you'll get the coins because all the miners should already have received your transaction first.

If you are a ATM company it would not be an so great idea to not wait any confirmations because with so huge amounts in the game some people will may be try to mine their own block. They need just to create a block in which one they spend the money back to themselves letting the transaction to the ATM become invalid.  Other miners will continue to work on this 'fraudulent' block because of course it's still a valid block.
So the solution they implemented is to verify the identity of the customer. So if something goes wrong they can find him later to ask their money back.

Thank you Jan!  I'd prefer the ideal: ~100% confirmation ideally.  Just because it's not available now doesn't mean a bitgenius can't come along and contribute it to cryptonumismatics.  Imo, I think these types of criteria are necessary for total displacement by cryptocurrencies.  All costs must be compensated, so if only 17% confidence in a bitcoin transaction can be reached in 10 minutes, prices will need to be 6x what it would be otherwise for a seller who delivers after 1 confirmation.  It may not be quite so extreme, but whatever the true risk is must be added to the price or bust.

Hmmm 100% it is difficult to determine when you'll reach it. In 2010 a buffer overflow vulnerability allowed someone to create an unlimited amount of Bitcoins. To revert this a patch was published and the blocks of an entire day were reverted. So is one day really 100%?

Thank you very much Jan: you've helped me to understand this so much more!  Assuming that creation rates are not expressly linked to difficulty, is it feasible that this could be solved with user defined difficulty?  Thank you so much Jan!  http://bitcoin.stackexchange.com/questions/18816/sender-defined-difficulty

The way I see it, you'll never reach 100% confirmation. Chances are, tomorrow an E.T. comes with very advanced quantum super-computers (or a US gov agent gets them, after a secret scientific breakthru) and decides to re-do all blocks in all crypto-coins after genesis block, accounting themself all the rewards. Should their hash power be minimum 51% of the total hash power of rest of the network, there's nothing the rest of mortals could do to stop it :(

In fact there is a hardcoded checkpoint in the Bitcoin client see https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp
Line 42-52. But it isn't updated very often.
The checkpoints 'secure' it against 51% attacks even if you have huge computation power but you need to trust these developers who are setting the checkpoints.


text:
"Instantaneous" transaction verification?
Jan Moritz Lindemann graciously educated me that difficulty is used not only to regulate the creation rate of a cryptocurrency but also to allow for block propagation thus prevent orphaned blocks.
Since consumers of a cryptocurrency could be presumed to desire instantaneous transaction verification, is near instantaneous transaction verfication possible and secure?  If so, how?

If by "instantaneous" you mean "right at the moment of the transaction" - well, no. Not even with Visa et al. Even if you mean that, after waiting for a reasonable amount of time (say, less than 2 mins.) you receive a definite answer about your transaction's validity, it's not possible either.
The way cryptocurrencies work, all transactions are "waiting in line" to be picked up by a miner and included in a block. Meanwhile, you can always revert it or create another that conflicts with the first one. Once a transaction's in a block, though, you can still not claim victory for they're still not part of the official coin history: other miners need to accept the block and start constructing new blocks over it - and this is the critical part.
Another miner, somewhere else in the world, may have discovered another solution to the current block and broadcasted it onto the network. From that moment on, there will be 2 chains in competition, both of them valid, but eventually only one will become the official one. Which one? Whichever gets longer first, i.e. which is picked up by the most miners to create a new block after it - remember each block contains not just its hash but also a hash of the previous block, so in effect each block "points" to its predecessor, hence the term "chains".
It's also possible for a malicious part to do this on purpose - should that part have access to vast amounts of computing power it could convince you to give you something in exchange for their bitcoins. You see their transaction appearing in 2 blocks and give the stuff, they then take the last block before your transaction appeared and rapidly create 3 blocks without the transaction. Once they broadcast their 3 blocks to the network - voilá! Their chain takes over due to length, you end up with no item and no coins.
So you never get a definite yes or no answer - you just get degrees of certainty. The more blocks your transaction appears on, the more likely it is that it will be part of the official transaction history. That's why it's commonly said you should wait for 6 confirmations in Bitcoin or 12 in Litecoin to consider a transaction 99% valid - after that number, the probabilities of an attacker trying to out-run (so to say) the combined hash power of the whole network become almost negligible.

Thank you so much for answering!  OK, this is what I don't get: if multiple chains are possible with Bitcoin et al, how is that managed?  (Should that be in another question?)  So, for a crypto with only a 1s bst, there would need to be ~2,700 confirmations?  Thank you very much in advance!

One block per second! Puff... way too crazy! The point with lower times between blocks is that network speeds are not infinite, so it takes a finite time for a node to become aware of a block - and longer if such block was mined at the other side of the globe. Hence the possibility of orphaned blocks - with Litecoin you get more orphaned blocks, so you need to compensate by waiting for more blocks. How much should you wait in such a coin? Since it'd have massive orphaning, your number sounds reasonable... Meni Rosenfeld might now, he's done research on that.

As to "how are multiple chains managed in Bitcoin et al.?" Simple - they're not. The network accepts all chains of the same length, composed of valid blocks, as valid - and lets them compete. Eventually, one will get longer ahead of the others, at which time all nodes will stop accepting the other chains' blocks.

Thank you again for your knowledge!  It seems that no matter how short the initial verification is, to achieve >99% confidence, one must wait >30 minutes?  Thank you very much again in advance!

Again, thank you for your help!  Would you mind adding these pieces of information into the answer, so I can give checkmark?  It looks like you have presented the solution: less difficulty = more verifications per transaction for confidence.  Thank you so much in advance!

It's not exactly the lower difficulty which forces you to wait for more verifications, it's the time it takes for a newly generated block to propagate thru the network. With low time between blocks, more miners will keep working on a block, unknowing someone else has solved it. Also, the more possible it becomes for 2 or more solutions to arise independently, thus competing chains which eventually result in orphaned blocks. Meni Rosenfeld suggests a dynamic time as a better fit than a constant at https://bitcointalk.org/index.php?topic=79837.0

Thank you Joe Pineda for this valuable information!  In terms I can more readily understand, does this propagation thus competing chain/orphan block result add costs to miners or senders/receivers or both?  If both, who receives more?  Excluding the costs passed onto the receivers/senders by the miners, are the costs added to the receivers/senders low?  Thank you so much in advance, and I will surely read up on dynamic time!

In terms of costs, I believe it could be considered a kind of "cost to do business". I mean, all miners expect that, from time to time, a block they may have discovered ends up orphaned so they gain no coins. Since most of the time they gain no coins anyway, it simply adds up to the operational costs for them. Right now, miners' main monetary gain is in the mining rather than in the fees they collect, so costs are not directly passed on to end users. Nobody really knows what will happen when the prize for solving a block goes too low, though.

Thank you so very much again Joe Pineda!  That was what I was thinking.  If you had to guess, no matter how speculative, what percentage of a miner's work on average do you think would yield no return?  Thank you so very much in advance!

Now that is a very interesting question, which I believe deserves being asked by itself on this site!! Right off the top of my head I'd say it's normally the majority of the work. How much exactly? Don't know... 60%? 80%? 90%? I guess the answer depends on solo mining vs. part of a pool, how much % of hash power it has vs. rest of network, and the avg. % of orphaned blocks per day on the coin...


text:
What happen if there's no one mining bitcoin?
I read that miner are in a way contributed to the transaction progress of bitcoin. So, that means if there's no one mining anymore, the bitcoin can no longer be transacted?

This is true, that's exactly what would happen.
However the rewards for mining would increase proportionally so if there was any value in bitcoins at all then someone would be motivated to start mining to gather the rewards. That's why this won't happen, if 90% of people stopped mining then the rewards for mining would be 10 times higher.
Plus there are enough businesses involved financially in bitcoin now that I would expect them to invest in some mining capacity to keep the network going.

Effectively, yes, this is true.

If no-one mines a Bitcoin like crypto-currency it will stop to work, this mean that transaction can be created and shared on the network but that they are not confirmed anymore and that there will not be any new money supply.  This don't mean that the crypto-currency is 'dead', Bitcoin like crypto-currency will not die until someone owns it's block chain.
Note that this is what happened to an alt-coin called 'junkcoin'.
People had to mine blocks themselves to get their coins on exchanges.


text:
Is a low difficulty insecure?
Please ignore the connection between difficulty & creation rates for the purposes of this question.
Can a difficulty be set so low that the security of transactions is compromised?  In other words, if a difficulty is set too low, can malicious miners forge transactions?
If so, what number is "too low", and how is it determined?

A low difficulty is only insecure if the malicious miners have a combined hash power much greater than the difficulty level.  The difficulty level is adjusted up or down every 2 weeks so that a new block continues to be found approximately every 10 minutes.  So, to forge transactions, a large percentage of the current miners would need to stop mining in order to get the difficulty level to drop.  Then the malicious miners could jump in and create bogus transactions assuming they controlled enough hash power to make their blockchain the accepted one.

Thank you for your knowledge!  Something I don't grasp: are transactions in the blockchain tested to see if they were hashed properly?  If so, how do the transactions stand?  Thank you so much in advance!

Yes, the hash for each transaction is validated by each node in the network before accepting the block.  A block containing an invalid transaction will be rejected by the node and won't become part of the blockchain.

Thank you so much ScripterRon!  I think I'm putting words in your mouth for my understanding: when you say that malicious miners jumpt in and create bogus transactions, do you mean that they can only do it temporarily until others catch on thus deceiving people in the short run to potentially extract assets in exchange?  Thank you so much for helping me to understand this and in advance for your reply!

Once the deception is discovered, the honest miners can work together to fork the blockchain starting at the last honest block.  This would result in all subsequent transactions going back into the queue to be mined again.  Since that would include the dishonest transactions as well as the honest transactions, some sort of transaction cleanup would be required.  Perhaps just erasing all transactions after a point in time and then requiring people to do them again, which would surely cause havoc.

Again, thank you very much for instructing me!  Is that cleanup process not already included in Bitcoin or any other alt?  Thank you so much in advance!

Also, if difficulty were set to 0 or -, would there be any security at all?  Thank you so much in advance!

If the situation really occurred, I don't know what procedure would actually be used.  That was just my take on how to recover.  The network difficulty refers to the number of leading zeroes in the block hash, so it can't go negative.  At difficulty 1, I'm able to create a block in less than a minute using my GPU.  So it would be very easy to create a long block chain that way.


text:
Exhaustive technical explanation of signing & verification
I apologize for such a noobish question and am ashamed that I'm not getting this yet, but I can't seem to put together all of the pieces.  I've read every question I can find on the subject, the Satoshi paper, and bitcointalk.
How exactly is a transaction signed?
How exactly is a transaction verified?  I simply cannot understand how secure transactions signed with private keys that are presumably unknown to all else can be confirmed to be valid and correct without actually knowing the private key itself.  Please show me in detail how this works.
I know this looks like a dupe, but I've read every related question, and I just can't get to that "ah ha" moment that puts it all together.

Are you looking for an explanation that involves code?

@ColinDean Thank you for looking Colin Dean!  Code segments from Bitcoin or any other valid alt would be perfect!  Thank you so much in advance!

This should get you started on public key verification: **Digical signature
In essence, the bitcoin address is the public key.  A hash is created of the transaction and this value is then encrypted using the private key that is known only to the owner of the bitcoin address.  Anybody can then use the public key (the bitcoin address) to decrypt this hash value and determine that the transaction has not been modified by creating a hash of the transaction and then comparing it to the decrypted value.  This serves a two-fold purpose: it protects against transaction modification and it proves that the transaction creator has access to the private key for the bitcoin address.

Thank you ScripterRon!  I've seen that link, and I'm fairly comfortable with the various encryption schemes, but where I break down is the decryption, the verification of the transaction.  Isn't the private key required?  As best as I can ascertain for myself, transaction verification doesn't in fact fully decrypt but merely decrypts to some level of certainty based upon difficulty.  Is that correct?  If so or not, could you provide more detail on that?  Thank you so much for all of your help today!

You encrypt data with the public key and decrypt it with the private key.  The encrypted data is not readable and only the private key owner can view it.  You sign data using the private key and verify it using the public key.  The data itself is not encrypted and is still readable.  What is encrypted is a hash of the data.  The transactions in the block are not encrypted and can be viewed by anybody.  The network difficulty refers to the number of leading zeroes in the block hash and is not related to transaction signatures.

Thank you so much ScripterRon for putting it plainly!  I finally found the code, cleared my head, and reread your link and others on encryption.  Encrypt with the private key, decrypt with the public key.  DUH!


text:
Are transactions verified in chronological order?
I've seen that blocks include timestamps which are updated "Every few seconds", but who updates the timestamps, and are the timestamps used to verify transactions in chronological order?
If a block with a certain timestamp is added to the blockchain, will any block with an earlier timestamp be rejected?
How is the timestamp used by the protocol?

According to the wiki, there is some tolerance in the accepted timestamp for a new block:

A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you.

The reason, as explained in an answer to a related question, is that "without a central authority, it's impossible to know for sure what the current time is" (in the sense that, while there might be standards that set the "correct time", you can't prove that an operation that happened in a computer somewhere in the world actually happened the time it says it did).
So, answering your doubts:

Who updates the timestamps?
The miner that produced the block assigns the timestamp, and the other peers in the network endorse it.
Are the timestamps used to verify transactions in chronological order?
What matters is the order of blocks in the blockchain, not the order of the timestamps (since to produce a block you need a previous block "done", it follows that the transactions in that block happened after the transactions of the previous one).
If a block with a certain timestamp is added to the blockchain, will any block with an earlier timestamp be rejected?
Only if it falls outside the margin of tolerance mentioned above.
How is the timestamp used by the protocol?
I'm not sure of all the reasons it exists, but you can start by looking at this and this questions. My understanding is that it's unfeasible to know exactly when a transaction happened, but you still need a rough knowledge of the time at the very least, for several reasons.

authors: Сергей Токарев


text:
Must mining pools use the same address?
Must all members of a mining pool use the same address?  Is there ever an exception?
I know nothing of mining pools so can provide more information if possible, but what I mean in specifics is can a mining pool use every member's address in the blocks, or do all members have to use one address in the blocks and be repaid later on trust?

Your address is not in the blocks being mined.  All of the coins go to the pool operator.  He then takes his cut and divides the rest among the members of the pool.  The pool usually keeps the coins in your mining account until it reaches a payout threshold or you request a manual distribution.  This is done to reduce the number of very small transactions.
So, yes, you have to trust the pool operator.  But all blocks can be viewed on the blockchain, so you can audit the results if necessary.


text:
What if a country 100% denominated in a cryptocurrency loses internet connectivity to the rest of the world?
Please assume a small island nation becomes 100% denominated in a cryptocurrency.
Now please assume that for some reason the rest of the world manages to cut if off from the rest of the internet for some extended period of time, eg 1 year or more.
During the time that is isolated, it of course is able to continue using the cryptocurrency; however, what happens when connectivity to the outside world is restored?
Will all of this nation's transactions be lost forever and reset to the time before connectivity was lost?
If the transactions can be somehow recovered, what happens to all mining fees on the island during disconnection?
If anything is lost, how could a protocol be altered to manage this eventuality?

Hmmm interesting question. The 'island' would need to be running a few miners to keep things running. This question is basicly the partition tolerance of the bit-coin blockchain database.

@DarcyThomas Thank you for looking DarcyThomas!  Would you mind expounding on partition tolerance of the bit-coin blockchain database and how it relates to this question?  Can you answer any of the questions of this post?  If so, please add an official answer.  Thank you so much in advance!

Related: http://bitcoin.stackexchange.com/q/12207/5406 http://bitcoin.stackexchange.com/q/1738/5406 http://bitcoin.stackexchange.com/q/8554/5406

@Murch But none offer a solution.

@Gracchus: Questions that are linked in the comments or in answers will show up on the right side as "Linked". This is useful for people trying to learn more about the topic to find similar questions. - You will notice that I only posted them as "related" not as "possible duplicates".

I think that the "If anything is lost, how could a protocol be altered to manage this eventuality?" kind of got dropped in the end, it doesn't fit well in the picture with the other questions. Perhaps it would work better as its own question with a link to this question as reference.

@Murch The negative eventuality was uncertain to me at the time but is centrally important since it is hopeless for a potentially at risk population to simply accept it.  The last question was insurance.  The first half semi-duped because of the long time period vs the other questions.

I don't get the meaning of the first sentence: What is hopeless to accept?

@Murch Why would this hypothetical population use a crypto if they're at risk of a 1-year market shutdown?  Who there would exchange or mine if all transactions were to be wiped out once they are reconnected?  They could always play musical chairs, and some would, but it would eventually traded to 0 and abandoned.

let us continue this discussion in chat

@Gracchus, Mazacoin is a start.

I am just guessing here given the little I know about bitcoin and distributed databases.
This comes down to the how CAP theorem applies to the bitcoin blockchain DB.
CAP theorem states that it is impossible for a distributed computer system to simultaneously provide all three of the following guarantees:

Consistency (all nodes see the same data at the same time)
Availability (a guarantee that every request receives a response about whether it was successful or failed)
Partition tolerance (the system continues to operate despite arbitrary message loss or failure of part of the system)

As far as I can tell it is not consistent. And will handle partitions for a short period.
(and you could argue that long periods of partition will break availability of some transactions)
Details of what I think might happen:
(If every one plays nice and someone makes a few tweaks to the software it will come back online)
The bitcoin protocol has (in simple terms) two sets of data that it transmits/stores.
One is the block chain which is the authoritative order that transactions occur in.
The other is a gossip of the transactions.
First of all transactions would gossip around the islands network, but they would not get confirmed. Even if there were miner nodes on the network. This is because the difficulty would be very high.
The chance of the miners on the island of finding a block would be very low. So the confirmations of the transactions would probably not occur.
The difficultly is only adjusted every 2016 blocks. But as the miners on the island can not find a block the difficulty will not change. The confirmations would become stalled.
Basically if every one trusted 0 confirms and didn't double spend (hint: that is not going to happen) you could carry on as normal (assuming your software will let you spend 0 confirmed transactions)
This could lead to the network collapsing.
However if someone changed their mining software to mine at a much lower difficulty I think the network could start confirming again.
Normally this would not work as then bitcoin network would very quickly drop your block in favour of a longer more difficult one. But since you are in a partition you would win (for now)
Lets assume the miner who modded his software didn't try to make any double spends (which he would only be able to with the money he has before the partition, and there are enough miners so there are not any 51% atacks.
2016 blocks after that the network would readjust the difficulty (to the sum hashing power of the pool) and every thing would hopefully stabilise.
Ok all seems fine the partitioned island network would carry on.
That is until then partition is reconnected. (Dun dun dunnnnnnnn)
At that point two things would happen.

A longer more difficult block chain would replace the island block chain as the authoritative chain. This would wipe out all of the island confirmed transactions.
The island nodes would start gossiping the transactions that had occurred on to the other (newly connected) main partition.
This is assuming that, between all of the islands nodes, some of the software had a full copy of the gossiped transactions.

I think it would take the same number of blocks as the longest train of island transaction for all of the island transactions to be confirmed on the network.
Every thing back to normal???
Yes (insert Lost reference) as long as no one got off the island; with their bitcoin wallet.
If some one made a transaction from their wallet on both the island and on the main network,
then their transactions on the island would be seen as invalid (like a failed double spend).
But that would also mean that anyone the island who had made a transaction based on that failed transaction would find that their transactions would also be invalid etc etc. In other words that one double spend transaction would be poisoned.
Also any coins mined during the partition would also be poisoned.
Everyone's wallets along the poisoned branch(s) would revert to the balance they had just before that poisoned transaction.
You could check for those poisoned transactions with some offline copies of the block chain; before you reconnected the partitions.
This would make for an interesting set of norms, for your islands culture:
Your island's economy would depend on the (threat of the) death penalty being applied to anyone who tries to make offshore double spends (or spend coins mined on the island).
(Miners could still make money through transaction fees)
The import of mining rigs would fetch huge quantity of bananas and coconuts (as that would be the only thing you would have left to barter with internationally (Since you no longer have a national currency and can't trade internationally with bit-coins) :P

Thank you DarcyThomas!  That is a fascinating take on hashing power that I completely didn't anticipate.

Very nice answer. I think this might be your lost reference: http://bitcoin.stackexchange.com/a/12945/5406

@Murch Nice link. I however meant Lost the tv show. A bit subtle I know.

I see. Capitalization would have been important there. ;)

Since the accepted answer on this question is from 2013, I think this question is ripe for an up-to-date answer :)
DarcyThomas's answer still applies, if one would assume that the island nation is completely cut off from the Bitcoin network: mining would come to a standstill since the island nation's hashrate would likely not be able to find any blocks at the global difficulty, anyway a minority fork would get wiped out after reconnecting as DarcyThomas described.
In that unique situation, it would probably make sense to spin-off a low-difficulty forkcoin only for their island. Since the balances held by people outside of the island nation could wreak havoc when they eventually get reconnected to the world, it might make sense to require all balances to be moved once, and to decay any unmoved original balances in the forkcoin after that. The island should also implement replay protection, wipeout protection, and switch to a different PoW scheme, as mining power abroad will make their network vulnerable to majority attacks upon reconnection as well. It may make sense to make mining permissioned in some fashion to protect it against a mining take-over.
However, today, just cutting internet access will no longer suffice to achieve full isolation. In 2019, Rodolfo Novak and Elaine Ou demonstrated a Lightning transaction from Toronto to San Francisco via ham radio, and the Blockstream satellite serves the complete Bitcoin blockchain as well as Lightning Network gossip directly to large parts of the planet. Transaction by the islanders could be submitted to the network via satellite uplink or radio as well.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Cryptoissues? (stocks & bonds)
Are there any examples of cryptoequities or cryptoliabilities?
I've seen the cryptostocks site, but it doesn't look to be what I'm envisioning.
For simplicity's stake, please imagine a corporation that wants to issue stock that will never pay a dividend.
Could a fully integrated trading system be built off of the cryptocurrency concept?
Here are some of the criteria:

A corporation is the only issuer in a blockchain, so no mining rewards, only fees
The blockchain would probably need to be denominated in a single cryptocurrency
There would need to be some sort of automatically resolving escrow system where a buyer first deposits cash through into the blockchain before a trade can go through with automatic refunds if the trade fails
Buyer and seller would both have to sign the transaction, buyer pledging an amount of cryptocurrency, seller pledging an amount of cryptoequity
Orders would have to be able to be left in an "open" state to provide a limit book; in other words, buyers would need to be able to post how much cryptocurrency they would want to sell so to buy some amount of cryptoequity while whether the transaction will complete is uncertain, and sellers would need to be able to do the reverse while of course pre-depositing in the escrow
Open orders would need some mechanism to be canceled
Orders would need to be able to be partially filled, so an open bid could be partially filled by a seller leaving behind the remaining order and vice versa

How could this be accomplished?
(I will post any other necessary details)

There are a couple that may be what your looking for.....
Open Transactions - http://opentransactions.org/wiki/index.php?title=Main_Page
This is more general and not specifically targeted at Cryptocurrency, it seems pretty malleable and could be used for what you are describing.
https://counterparty.co/ - This is similar to above, and as I have only just recently found it cant say much, but also looks to do the job.


text:
Why are blocks hashed?
Am I correct that addresses are hashed to compress a huge text-represented coprime into something of manageable size?
Am I also correct that transactions are hashed for the same reason and also because:

To create RSA signature keys, generate an RSA key pair containing a modulus N
  that is the product of two large primes, along with integers e and d such that
  e d ≡ 1 (mod φ(N)), where φ is the Euler phi-function. The signer's public key
  consists of N and e, and the signer's secret key contains d.
To sign a message m, the signer computes σ ≡ md (mod N). To verify, the
  receiver checks that σe ≡ m (mod N).
As noted earlier, this basic scheme is not very secure. To prevent attacks,
  one can first apply a cryptographic hash function to the message m and then
  apply the RSA algorithm described above to the result.

?
I cannot find a reason for blocks being hashed except to slow the rate that transactions are verified thus new supply is mined.  Is this correct?  If not, why are blocks hashed?

I'd say "no" to all 3, which means you may want to read more about how Bitcoin works...

@MeniRosenfeld Thank you for looking Meni Rosenfeld!  Would you mind posting some links so that I can learn more?  I've tried to read everything I can, but I can't seem to find explicit motivations for each individual technology.  Thank you so very much in advance!

Bitcoin public key cryptography is not based on RSA, but on Elliptic Curves, so the key is not a huge coprime (in fact ECC manages to achive a similar level of security with much smaller keys).
About why blocks are hashed, the reason is not to slow down anything, quite the contrary: it's to speed up verification that a block "follows" the other blocks in the blockchain. One does not need the hash to verify the transactions (in either the current block or the past ones), but since each block contains the hash of all previous blocks (in a compact way known as a Merkle Tree), one can not simply create a block "isolated" from the blockchain (taking as much time as needed) and then just "insert" it in the blockchain to win the reward - it's necessary that a previous block is known before a new valid one is created.
The "hard" part is creating a hash that satisfies the difficulty criteria. A concise explanation of the process is given in this answer. But one does not need to "reverse the hash" or anything like that for any reason.


text:
Does a 51% attack depend upon difficulty?
Does increasing difficulty also serve to decrease the probability of a 51% attack?
It seems that since difficulty is the same for all, this is not the case.  Is that correct?
If difficulty were perpetually at minimum, would the probability of a 51% attack skyrocket?

The dependency goes as follows:

The difficulty depends on the total hashing power. As the hashing power goes up, so does the difficulty. This is intended to keep the block generation rate roughly constant at about one block every ten minutes.
As the total hashing power goes up, so does the amount of hashing power needed to accomplish a 51% attack. The total hashing power is the thing you need to accumulate 51% of.

So there is a direct relationship, but it's because they're both directly tied to total hashing power.

@DavidSchwartz' answer, covers most of the question, but to address the last point:

If difficulty were perpetually at minimum, would the probability of a 51% attack skyrocket?

A very low difficulty would increase the probability of a majority attack. This would not be a direct effect of the difficulty, but indirectly due to the time required for block-propagation. At a very low difficulty, the party with the highest hash-power would be able to churn out a lot of blocks quickly and could immediately start building on top of those again, while other miners would be hampered by the block propagation latency.


text:
Connecting bootstrap.dat to Bitcoin QT?
I have installed Bitcoin QT and I have also downloaded bootstrap.dat from a torrent. I am having trouble in adding bootstrap.dat to Bitcoin QT. Please guide me. Thanks.

Place bootstrap.dat in the bitcoin data directory and then start Bitcoin-Qt.  It will read the file to create the blockchain.  The file will be renamed to bootstrap.dat.old when this is completed to prevent reprocessing when Bitcoin-Qt is restarted.
You can locate the data directory by reading this.


text:
Simple GPU C++ mining
I'm trying to mine a genesis block for an experimental Peercoin clone.
I've already written one using boost threads, and it's been really fun since this is the most processor intensive program I've ever written, but I'm only getting 1M hashes per second, so I'm guessing it's going to take about 72 minutes based assuming initial difficulty 1 and this equation is correct.
Is there a relatively simple way to send the functions to the GPU?
All I'm doing so far is using a "silent" (returns false instead of writing the error to debug.log) CheckBlock() to verify if the nonce is valid or not.
Please show me a simple library that can use the GPU to verify the nonces.

This looks like a great lib that acts as a OpenCL wrapper, at least based upon the short example given on vector sorting.
All libraries seem to treat the GPU as if it's some foreign CPU, and while this is no exception, it seems to be the most direct and intuitive.
I haven't been able to test, but if it works as advertised, it looks perfect.
Note: I've tried to sort out CUDA and OpenCL by myself, and I'm just not good enough.  This appeals to my laziness.


text:
Why aren't blocks "zipped"?
Considering how large the total blockchain is relative to average download speeds, why were the blocks never data compressed before being sent?
Why could this not be implemented on a new alt?

Because the data is already serialized in a pretty compact way and large parts of that data are hashes which are effectively random numbers as far as compressability is concerned. (Random data is not compressable.)
Also when you search for for example a transaction id in an index, it will point you to the exact location in the blockchain. Having to read a whole bunch of data around that area and decompress it before being able to access the transaction that you wanted, adds disk I/O, CPU overhead and memory consumption. That severely limits the dictionary size any compression algorithm could use, and therefore the compression ratio.
Give it a try by zipping the whole blockchain file, but remember that any usable live compression would have a lower ratio than what you would find.

Thank you Jannes!  I definitely agree that they should not be stored compressed, and thank you especially for showing me the futility of compressing  hashes, but considering that the vast bulk of the data in a block is the transaction array, do you still think that that section can't be compressed?  Thank you so much in advance!

Nevermind.  Transactions are sent as signed hashes, not raw data.  You're right, there probably isn't too much benefit in compressing the json keys.  Thank you!


text:
I don't understand the "51% attack" problem. Why does a mining pool have power with a 51% share?
What gives a mining pool power to maliciously dominate the system if they're mining over the majority of the coins? Profits are disseminated to miners individually. I really don't understand how this enables a bunch of individuals to conspire to warp the market. I think I'm fundamentally misunderstanding the problem. Can someone explain how having a 51% share enables a pool to prevent, reverse, or double spend transactions?

possible duplicate: What can an attacker with 51% of hash power do?

Conceptually it isn't difficult to understand conflicts of interests (COI) principles.  If a pool has over 50% of the computing power required to demonstrate adequate "proof of work" to add entries to the Blockchain Ledger, this absolute centralized power will eventually "absolutely corrupt".
That centralized pool could be used to change the history of what constitutes the longest chain in the Blockchain by computationally orphaning blocks that were legitimately mined by other pools or solo miners. When a pool gets very large, do you honestly think it will not be tempted to modify the nominal Bitcoin transaction priority scheme?
If a pool has roughly a third of the computing power used to populate a Blockchain, they can start to statistically change the destiny of the Ledger, especially if all of its miners are using STM mining protocol. This is because miners are effectively slaved to the set of transactions the pool decides is important to mine, whether legitimate or not. When STM is used, the pool sets the mining block agenda, not the miners. Can you now see where the COI enters into the picture?
If miners use GBT, opposed to STM, they have more choice in the grouping of candidate transactions they bundle together for mining as long as they follow a template. As long as those miners are not colluding with the pool, this will help keep the large pools honest. The problem is GBT coordination sucks more network bandwidth, effectively ever so slightly lowering the profit margins miners can achieve. Most miners are interested in maximizing their profits, and are thus likely not to adopt GBT.
Knowing this information, and looking at the two big to fail pools is very disheartening. A barometer for when the big pools have gotten too large is when numerous small pools suddenly have higher orphan block rates, and their mining profits start to go south of what is expected for known difficulty factors for a protracted period of time.
To keep large pools honest, for the good of the public, the large pools that mine 25 to 30% or more of the Bitcoins need to support transparency with above the board full disclosure policy of what they are currently mining in advance of advertising their lucky block strikes. Such transparency, helps to ensure they are not violating the trust of good Internet netizen miners competitively mining at other pools.
This is a very hot topic.  From the flack that I received (i.e., negative Bitcoin Stack Exchange passive-aggressive votes) when asking a prior related question, I believe this is something that must be watched very closely...
FYI - I'm a security consultant and a guy that did wargaming for over 10 years.


text:
Why longpoll if sockets are available?
I've noticed that the bitcoin client uses sockets.
I've also seen that long polling is not only available but is also recommended.
Why?  Isn't long polling far less efficient than sockets?

Don't confuse the way bitcoin clients talk to each other (peer to peer, speaking the Bitcoin protocol) with the way the bitcoin client talks to RPC clients (server to client, with bitcoind acting as an HTTP server speaking JSON-RPC).
When the bitcoin client speaks RPC, it uses HTTP. Long polling is much more efficient than HTTP without long polling, which is why long polling was created and why it's recommended if you're using RPC.
However, using RPC for miners to talk to the systems that issue them work is rapidly becoming obsolete. Stratum replaces that, and it uses a native method that's more efficient than long polling.

Thank-you David Schwartz!  I still don't understand why sockets aren't used to push the data whenever it's available rather than inefficiently poll.  Since sockets are already set up, why poll?  Simply notify someone you want to subscribe to their feed.  If someone disconnects, feed over.  Why constantly bombard someone with polling?  Thank you so much in advance!

That's the argument for replacing RPC with stratum, which is basically what's happening.


text:
How does your account get credited when you send bitcoins(ex. Coinbase)
This question might have already been answered. If so, can someone send me the link to it.
Let's say I create a blockchain wallet. It gives me a bitcoin address to deposit coins. Once I send bitcoins to the address that is given how does the system know what account is associated with that bitcoin address.
I wanted to develop a site where you can deposit bitcoins into your account and I want to know how that is done.

I suggest you not to create any such site if you cannot figure that out (no sarcasm I swear but you should not)

There are no accounts as far as the block chain is conerned.  A transaction will show up in any wallet that contains a private key associated with one of the transaction outputs.  So if you create a wallet, export the private key and then import the private key into a different wallet, a transaction sending coins to the address associated with that private key will show up in both wallets.  Either wallet can spend the coins although this can lead to synchronization problems with the other wallet.
A wallet is responsible for scanning the block chain and recognizing relevant transactions.  If the wallet is online, it is notified when a new block is broadcast so that it can update its wallet transactions.  if the wallet is offline, it needs to scan the block chain when it comes online to pick up any blocks that it missed.
So the answer to your question is the private keys control which wallets contain a specified transaction.  In your case, you would need to create a different private key for each of your customers.

Thanks. could you send me a link to where I can find out how to write a script to create a private key for each account that registers.

The Bitcoin client (bitcoind or Bitcoin-Qt) will create a private key and assign it to an account using the getnewaddress RPC command.  If you are using some other means to connect to the Bitcoin network, you'll need to check out the provided API.


text:
Transactions are verified by miners. What happens when the last BTC has been mined?
Let's say we're X years in the future and we the last bitcoin has been minted. Since you can no longer incentivize mining new nodes of the blockchain, how will transactions continue to be verified?

possible duplicate of The End of Mining

You can still incentivize mining new blocks with transaction fees. So the premise of the question is false.

Are these transaction fees from some given pool? What if a pool decides to not have transaction fees?

@LeftoverSalad The transaction fees come from transactions. Each transaction can include a fee that goes to the miner who includes that transaction in a block and miners do not have to include transactions in blocks they mine if they don't want to.

Ah, that's what I wasn't getting! Marked as answered.

@LeftoverSalad There is, of course, a fair question about how well that will work. For example, right after someone finds a block, all the "juicy" transactions will be taken. There may be reduced incentive to mine until more high-fee transactions build up. This is especially true if people conserve electricity by shutting down mining equipment when the reward is too low.

That would lead to less than 1 block per 10 minutes and thus a decrease in difficulty. And/or it may lead to people paying a higher fee as to keep the incentive to mine high enough. It's a completely free market mechanism, very transparent and with low barrier to entry for new players (miners).


text:
What is the useful work done during the mining of Bitcoin?
What is the work that the computer performs while it does Bitcoin mining? Is it useful work in any case?

The work isn't useful outside the pursuit of bitcoins.

Mining secures the Bitcoin blockchain and confirms transactions, solving the double-spend problem without the need for a central authority.

It's not useful in any way other than maintaining mining in the bitcoin protocol. This is wasteful, but it is the easiest solution to the problem it's solving, you can quickly verify the correct sha256 hash. If an imaginary coin did computations for charity as it's "mining", how could people verify a node claiming to have done 100 computations correctly without also doing the same work?

Mining is useful in that it solves the double spending problem, provides the confirmation of transactions and security of the network. It also doubles as the mechanism to spread the currency without having a central dispensary, creates a positive reward for people to drive adoption, and makes it more attractive to spend computing power to benefit the network than to attack it.

All you are doing is computing sha256 hashs. You can read more about it here https://en.bitcoin.it/wiki/Mining. What do you mean by useful that is pretty ambiguous.


text:
Are transactions still tamper-proof if blocks are hashed without nonces?
If an alt were to forgo difficulty and timed release of new supply by removing the nonce from blocks therefore the whole difficulty/target system, is hashing without nonces still providing the same blockchain anti-tampering security?
If not, how could the blockchain's integrity be maintained without hashing difficulty?
As I understand it, blocks have nonces to satisfy difficulty so that the hashing process is slowed for the purposes of controlling the rate new crypto supply is produced.
Please assume that supply will be produced through a multiplier as described here instead of as a reward for mining.  In this case, block generation doesn't need to be slowed for the purposes of crypto supply inflation, but the blockchain does need to be made tamper-proof.
Is it correct that simply hashing in particular ways make the transactions tamper-proof, or is noncing a hash also necessary?

It's not clear what you're trying to do. What are you trying to accomplish?

Ripple is an example that works without proof of work nor proof of stake (so no nonce needed). This mechanism is more vulnerable to sybil attacks, so it needs strong peer identity knowledge (but not trust!) to be secure. See https://ripple.com/wiki/Consensus.


text:
What is the difference between deleting a private key and deleting an address?
On Blockchain.info, when deleting private keys from your wallet, it asks if you want to delete only the private key or if you want to delete both the private key and the address. If you choose to delete the address in addition to the private key, does this mean that unless the address is generated again, it doesn't exist anymore? If not, what does it do?

An address can be generated from a private key. But you need to have the private key from the address to be able to spend it's funds.
So, when deleting the address, it will just be completely removed from your wallet. (Note that there is no such notion of "whether or not an address exists". All addresses exist, but if nobody owns a private key for the address, the balance will be unspeakable.)
When deleting the private key only, the address will still be in your wallet, but it will be watch-only. This means that you will see the address's balance in your account, but you won't be able to spend the funds unless you enter the private key again. The main reason to do this is for security. If you write the private key down on a piece of paper, f.e., you could delete the private key from your wallet so that a person that hacks into your wallet will not be able to spend the funds.

It just removes the address from your wallet, so that you are no longer watching it. Any valid address can always have Bitcoins sent to it, and anyone who knows the corresponding private key can always spend them. Wallets are only needed to make spending or watching convenient. They aren't needed for funds to actually be received -- that takes place entirely on the blockchain.


text:
Block confirmation speed
Based upon any standard you think relevant, how quickly are current blocks being verified for rule-following such as correct balance tallies, true transactions, correct rewards & fees?
Is this an onerous process?  Would a database quicken this process?
Do you have any suggestions for improving block verification speed?

The bulk of the work lies in verifying each transaction within the block.  This means that the signatures need to be checked for each transaction input, which requires a lot of CPU processing.  So, one way to improve the verification speed would be to have a hardware-assist for the verification process (such as a specialized ASIC chip).  I don't know if a miner ASIC could be used, but it is an interesting thought.

That is not correct. See my answer.

Thank you ScripterRon!  What about searching for past transactions to make sure the new ones balance?  Is that not a terribly disk intensive process?  Thank you very much in advance!

The bitcoin client uses the LevelDB database to store the transaction outputs.  I'm using the H2 database in my own application to store both the block chain and the transaction outputs.  I'm not sure there is much more to be done other than performance tuning in high-usage areas (better SQL search arguments, indexes, caches, etc).

Thank you so much again ScripterRon!  Thank you for answering me many of my questions and giving me this crash course!  I was able to lazily hash at about 1M/sec, so I don't understand how simple block verification is so intensive.  Either something conforms or it doesn't, right?  Do you have any statistics on the average block verification time vs hash power?  I definitely can understand how a DDoS attack with bad blocks could bog one down, but I don't understand how verifying good actors' blocks is onerous except on the disk.  Thank you so much in advance!

Verifying the signature is CPU-intensive since you need to first derive the public key from the address and then use the public key to verify the signature.  The digital verification process uses very large numbers and complex mathematical formulas.  Check https://en.bitcoin.it/wiki/Transactions for more information.

I should add that transaction verification isn't a problem when you get a new block once every 10 minutes.  It only becomes a problem when you are downloading the initial block chain (either from bootstrap.dat or a peer node).  It then becomes a gating factor in how fast the new node can synchronize with the network.  And you are right, matching transaction inputs with unspent outputs is disk-intensive.  So it is a combination of checking signatures, matching inputs to outputs, and creating new database entries.

Thank you as usual ScripterRon!  You've helped me so much with my undestanding of bitcoin!  Isn't the public key merely concatted to the signature (or have I misread yet again?)?  Can't a single hash or "decryption" be performed very cheaply?  Thank you so much again and again in advance!

I am just getting into this area, so I can't tell you for sure.  But I think the public key is not in the input, so all they have is the address from the referenced output.  So the code has to first derive the public key using the address and the signed data.  Once it has the public key, it can then perform the signature verification.  I think it was done this way to reduce the size of the transaction (public keys are very long)

The transaction verification process is not particularly CPU or memory intensive. The CPU intensive part is the network protocol needed to get a global consensus on a single total order of transactions. That is called "mining" and that is what the specialized ASICs from various companies such as kncminer are designed to help with.

It depends on what part of the process you are looking at.  Definitely, if you are looking at the mining end, then finding the correct block hash is the most CPU intensive.  However, if you are looking at the peer nodes which receive blocks, then the transaction verification is the most CPU intensive.  This is one reason it takes so long for a new peer to process the block chain.

Thank you Neal Gafter!  Would you mind explaining why verification isn't expensive and why the network portion is?  It seems that every individual part could be fast but will become less so with higher verification frequency.  Thank you so much in advance!

I've downloaded the whole blockchain, copied it to an off-line, recently-formatted machine, and still had to wait (an hour? 2? can't remember now) before everything was ready - so clearly verifying takes a lot of time and CPU. I once read the process could be accelerated should the QT client use the GPU for verifying, just as it's used for mining, but so far I've not seen any implementation of this idea...


text:
How is network time enforced?
I've seen how nodes gather network time data, but how is it enforced in the blockchain?
Are all of the timestamps digitally signed and included in the block as proof?

First, where do these time samples come from: when your client connects to peers in the network it exchanges a version message with them. Among other things this message contains the current UTC timestamp at the peer. Your client then calculates an offset between the time at its peer and its own clock. The network time is simply the local timestamp + the median of all offsets of its peers. So you can see that we have a relatively simple attempt at synchronizing the clocks in the network, but depending on the sample of peers you connect to they can still vary wildly.
About enforcing the timestamps: there are very few places the timestamp appears in the communication between peers, likely the only place where it is actually enforced is in the block header. Should a peer receive a new block while being synched with the network, and the timestamp differs more than 2 hours from its local timestamp, it'll discard the block as invalid (source). The idea behind this check is that a client could attempt to skew the perceived difficulty seen by a node that is synchronizing with the rest of the network.

Thank you cdecker!  So it's only future blocks that are rejected for being too young not past blocks for being too old, the 2 hour failure?  Thank you so much in advance!

That seems to be correct, although I seem to remember that it was checked both ways, but I can't find proof of that :-)

Yes, you're right.  I found it but lost the link, lol.  Past blocks are governed in sequence while future blocks are governed in real time.  Thank you so much for your help!


text:
Can an old block be inserted into the blockchain?
I've been shown how network time is enforced, but I'm still having trouble understanding how a false old block cannot be inserted into the blockchain with the entire chain remined or how a powerful miner cannot remine the entire chain.
Does difficulty prevent this because it would take so long to remine the entire chain, or is there another way that "old blocks" are forbidden?
How are new blocks distinguished from old blocks or new transactions distinguished from old ones?
If blocks older than 2 hours are rejected, how are old blocks never rejected?

Every block refers to a specific parent, resulting in all blocks together forming a tree structure. Typically it's just a single very long branch, with very occasional short side branches (1 to 2 blocks long).
You cannot "insert" a block into the block chain, as no block refers to it as parent.

Thank you Pieter Wuille!  This is what I don't understand: if the entire chain can be rehashed with the merkle tree reconstructed, what is preventing  someone from doing just that?  Thank you so much in advance!

Each block contains the hash of the block before it. So if try to create a block to "insert" into the chain, every block after it would be invalid. So you would have to rebuild every single block after it. While you're doing that, the number of blocks after it is increasing. So you have to outcompute the rest of the world.

@DavidSchwartz Thank you David Schwartz!  Would you mind please expanding that to an answer?  Also, if a coin's blocks were not nonced, is it probable that multiple chains would exist simultaneously?  Thank you so much in advance!

@Gracchus Multiple chains always exist. The rule is that the "longest" valid chain (the one that would be expected to take the most computational effort to create) wins.

@DavidSchwartz Thank you again David Schwartz!  In the case of a nonceless coin with no other restriction to a miner's ability to mine like PoS, is it possible that a user would constantly switch between rapidly created longest chains or be deadlocked on simultaneous longest chains?  I don't have the experience to accurately & precisely answer that.  Thank you again so very much in advance!

@Gracchus It's hard to comment on the properties of an imaginary thing. The rule for what chain "wins" would have to be different since there would be no notion of computational effort to create a chain. Presumably, such a coin would have to have a sensible rule or it would fail precisely as you describe -- there would be no way for people to agree on which of two conflicting transactions are valid. Anyone can produce a chain that contains either transaction.

@DavidSchwartz Thank you immensely David Schwartz!  I have learned so much in the past few weeks from your expertise!


text:
How is the Merkle Tree sequentially propagated, and are the parts addressed?
When downloading the Merkle Tree, are all branches from the root downloaded in order?
Are the individual pieces of the tree cataloged in such a way so that the position of each piece is known?
In short, how does one know what piece of the tree goes where?

bitcoin wiki has some information on this. i have some notes elsewhere too that i can dig up.
https://en.bitcoin.it/wiki/Protocol_specification#Merkle_Trees

@JoeWhite Thank you for looking Joe White! I must be missing something because I don't understand how having the hashes in the tree allows one to know where they are in the tree unless if the program simply trials and errors until it is reconstructed. Please add your notes in an answer if it can explain how, per your link, d5 is co-branched with d6 and contains d1 concat d2 before trying every possible combination. Thank you very much in advance!

The Merkle tree isn't included in the download data.  Just the root hash is included in the block header.  The client has to reconstruct the tree in order to verify the root hash.  It does this by going through the transaction list as it appears in the block data.  Each transaction hash is a node at the top of the tree.  So, if you have 6 transactions, you have 6 nodes (the last transaction hash is repeated if you have an odd number of nodes).  Then the next level of the tree is computed where each node is formed by hashing the two nodes above it (again, the last node is duplicated if you have an odd number).  This process continues until you have just one node - the root node.  It is checked against the root in the header to make sure it matches.  If it does, you know the transactions have not been modified.  Note that the block hash is only over the block header and does not include the transactions themselves.
Here is an example with 6 transactions (Tx1-Tx6)
Tx1    Tx2    Tx3    Tx4    Tx5    Tx6
    \   /        \    /        \   /
     L2A -      -  L2B          L2C -     - L2C (repeated)
          \    /                     \   /
            L3A  ---            ----  L3B
                    \          /
                         Root

Thank you ScripterRon!  You've helped me so much to understand the intricacies of cryptos!


text:
How is bitcoin infinitely divisible?
I've read that bitcoins are infinitely divisible:

Bitcoins can be divided up and trade into as small of pieces as one wants

How is this possible programmatically?  The only thing that comes to mind are floating points which are inaccurate.
Are bitcoins truly infinitely divisible or merely practically?
A link to the relevant source code would be more than welcome.

Bitcoins are only divisible down to 8 decimal places (same FAQ you referenced).
Programmatically all calculations are performed in satoshis using integer arithmetic (1 satoshi = 0.00000001 BTC)

If there is a need for them, additional decimal places can be added with concensus of the network. This is why some refer to "infinite" divisibility, because we can select the level that we need as time goes on.

@CoinEnablers That should be an answer, because it is actually what is being asked.

If there is a need for them, additional decimal places can be added with concensus of the network. This is why some refer to "infinite" divisibility, because we can select the level that we need as time goes on.
The current level selected in the code (by Satoshi) is 8 decimal places (1 satoshi = 0.00000001 BTC) hence the nickname for the smallest unit currently possible for bitcoin today.
As a thought exercise, if a consensus of the network (miners, but also clients and server applications for compatibility reasons) decides to update to a version of the protocol that includes 16 decimal places inspired by your post, we could end up with a new base unit (1 satoshi = 100,000,000 gracchi) as well as nanobitcoins (nBTC), picobitcoins (pBTC), and even femtobitcoins (fBTC, 10 gracchi)
I have trouble imagining the need for such a thing, unless destroying bitcoin becomes a prevalent method of use. If it is needed the potential is there and will never dilute your held bitcoins, which actually makes it a problem some would love to see the need to solve.

Thank you CoinEnablers!  By that standard, why isn't every crypto infinitely divisible?  Thank you so much in advance!

The values in the bitcoin network are stored as the number of satoshis they are made-up from. I.e. if you add eight more decimals, you have to store that much more data in the blockchain.

@ Gracchus In theory, every cryptocurrency modeled after bitcoin could be retrofitted for more (or less) decimal places. Some altcoins have made changes  to these parameters already, but so far I have not seen anyone who has tried to alter one after issuance.
@Murch, that is an example of one of many technical details that would need to be solved. Check bitcointalk for more detailed discussions, there are several threads along this topic IIRC (with actual core developers commenting.)

Tadge Dryja explains why 8 decimal places is not enough: https://www.youtube.com/watch?v=-lgYYz3y_hY&t=13m43s

Note that a protocol change to add further divisibility would be a very invasive hardfork that would additionally require updates to almost every piece of Bitcoin software.


text:
Why is a double hash of the previous transaction included in Txin?
In Txin, there is a double hash of the previous transaction.
Why?  What purpose does that serve?  How is this data used later?

I believe it is one of the principles of Bitcoin, to make transactions you first have to have a valid transaction it stems from. If the previous transaction is not valid than the first transaction isn't valid as well.

It's hashed as to provide a summary of the entire transaction, sort of like an id. The hash can be used to verify that whatever transaction in plaintext you have is indeed the hash the person claims. You could put the full transaction in but that's not efficient.

Referenced by id? The txid of a transaction is the double hash.

@Gracchus It's due to efficiency and ease of checking. The Bitcoin network would get slowed down by massive transactions that had thousands of addresses linked to it whenever one node simply wanted to check if another node had the transaction if there where no hashed txid.

There can be thousands of addresses in a transaction, a txid hash will always be 64 characters.


text:
How explicitly can the blockchain be pruned?
How can the blockchain be pruned?
If the blockchain is tamper-proof thus cannot be changed, how can the data be removed?
Please be as explicit as possible.

related: Will old accepted blocks ever be removed?

The blockchain itself cannot be pruned.
Each block is verified through hashing all its data and a random nonce to find a hash that has a certain number of leading zeroes. If you even removed a single little bit of data from a block, the resulting hash would be changed. As most likely the new hash would not fulfill the difficulty requirement, the proof of work would have been destroyed. You'd have to create a new block to take its place. Then however, you would also have to recreate all subsequent block, as the parent's hash (think of it as a fingerprint) is included in its children block, i.e. if you change the parent, the whole blockchain succeeding from it becomes invalid as well.
What can happen is that the database of verified transactions that Bitcoin-Qt clients store is pruned. So far, after verifying each block, full clients keep every transaction that has ever happened locally. Instead, you could only keep the transactions in your database of which the outputs have not been spent yet.

Thank you Murch!  So is that what happens with lightweight clients that only balances are sent to them not the entire blockchain/transaction database?  Thank you so much in advance!

It is similar, but not the same. In the pruned client you would still verify all blocks, but you would not keep all data. AFAIK lightweight clients actually don't verify blocks themselves.

A block has two parts: a short header (metadata) and a (possibly large) payload containing the actual transactions. Header contains all the necessary data to validate the PoW and chain of headers since the genesis block header. Additionally, each header contains an authenticating value of its payload. SPV wallets sync very fast because they validate only headers and not the payload.
If a block contains transactions whose outputs have not been spent, then nodes must store that block to prove to another bootstrapping node that the UTXO set indeed contains a certain element. On the other hand, if all outputs generated in a block (say X) have been spent, than a node can discard block X and say to another bootstrapping node "all UTXO of block X have been spent, just validate header and move on".
This is a conservative approach. While a bootstrapping node cannot be fooled into accepting invalid UTXOs, we also cannot prove to that node that "all UTXO of block X have been spent" without exhibiting the actual payload.
Now the question may be: How do SPV nodes obtain and maintain an untampered UTXO set? See this answer for details.

SPV nodes do not maintain a UTXO set at all. That's impossible without seeing the full blocks. They only maintain a chain of headers.

@PieterWuille They maintain a UTXO set with outputs that are relevant to them. That's what the linked answer discusses; how a node obtains blocks relevant to it.

Ok, yes, I don't consider that part of the node, but part of the wallet connected to it (a wallet connected to a full node also has its own UTXO set in that sense), but agree.

It's been a few years, but I figured I'd add this, since it doesn't seem to be talked about a lot.
First, its important to note that block headers are sacrosanct; they are essential to verifying the blockchain.
However, much of the payload is no longer relevant, since the outputs they generated have already been spent.
It would be nice of they could be removed from the database, wouldn't it?
The issue with that, though, is verifying the integrity of the block. If we lose a few transactions, how can we verify that the header's payload hash is right?
To solve this problem, the original Bitcoin paper proposes a solution based on the Merkle Tree.
This tree is constructed by taking a series, hashing every pair of elements, and then repeating the process to that new series.
As the original paper states, this can allow us to remove old transactions, and still be capable of verifying the leftover ones:

This answer doesn't seem useful to me. Pruning to reduce the full node disk footprint has been available for years, however, the on-chain pruning proposal as described in the Whitepaper is infeasible and thus was never implemented.


text:
Do transactions reference the containing block of the previous transaction?
According to the wiki, it appears as if the previous transaction's index is referenced but not the block in which it's in.  Why?
How are transactions stored in the database that doesn't make referencing the previous transaction's block index necessary for performance?

If it were not this way, transaction generation would be slow and fragile. First, you couldn't form a transaction unless you knew which block all its outputs were in, which would mean you'd have to wait until they get in a block. Worse, if there were a blockchain reorganization, it would be impossible to recover many transactions because recovering their parents would change what block they're in, invalidating their children.
This means that nodes generally keep an efficient table of all unspent outputs, indexed by transaction ID.


text:
Earliest bitcoin forex & product purchases
How did bitcoin trade for conventional currency in the earliest days?
Was there much demand to exchange it for conventional currencies, or were those who sold goods & services content with holding the currency in the hopes of using it to buy goods & services from someone else?

The same way gold or any commodity did, the person buying bitcoins valued the idea or thought it had potential and payed someone money for their bitcoins. Price is what people are willing to pay anyways. Mining is the same concept, miners are paying with their hashing power (it isn't worthless!) to the bitcoin network.
It was as shabby and undocumented as possible I'd assume, see the infamous btc pizza, some guy posted a thread on bitcointalk (you can get records of this transaction and others by going through histories) saying he wanted to pay for pizza with btc. A guy in England agreed and paid with CC for the pizza to be delivered while the other guy sent btc in exchange.


text:
Blockchain length by number of blocks or transactions?
It is my understanding that the longest blockchain is the one that should be used.
Is "longest" measured by the number of blocks or the number of transactions?

The longest blockchain is measured by the number of blocks, not the number of transactions. This is because the proof-of-work is linked to the creation of blocks, not transactions.

Actually it's the sum of the difficulty of all blocks, but that usually doesn't make a difference when comparing different chains.

The best chain-tip is picked by the total difficulty of its blocks. This usually corresponds to the chain with the most blocks unless the chain-tips differ in difficulty.


text:
How accurate is Bitcoin network time?
Have any observations been made to conclude the accuracy of Bitcoin network time?
It would be interesting to know if NIST or any other authority has tracked the phenomenon.

You could track it yourself via bitcoind's -blocknotify. Seems easy to setup, fun and interesting!

From this blog post describing the timejacking attack:

Each node internally maintains a counter that represents the network time. This is based on the median time of a node's peers which is sent in the version message when peers connect. The network time counter reverts to the system time however if the median time differs by more than 70 minutes from the system time. A very reasonable way to estimate the median network time.

So block timestamps are based on "network time" which is in turn one of:

The median time advertised by peers (if between ±70 minutes from system time)
System time

The network time is used to validate new blocks. As a precaution, nodes reject any block timestamp that is greater than 2 hours from the current network time. Block timestamps that are earlier than the median time of the past 11 blocks are also rejected. This validation puts upper and lower bounds on the acceptable range of block timestamps.

So block timestamps are:

< 2 hours from "network time".
> median of last 11 blocks.

I have to refresh my error propagation lessons, but I guess this leads to an accuracy at around ±3 hours.
Of course this is just an upper bound on error, but the actual question remains: what is the real blockchain accuracy? (which is a very interesting question.) The only way to be sure is actually tracking it and comparing with a known perfect timestamp. I don't know if anyone has ever done that before and couldn't find any references.

It is not accurate, times in bitcoin's network are medians of other nodes.

But there must be some margin of error, right? The question is not "is it accurate?" but "how accurate is it?". It'd be interesting to track abs(real_stamp - block_stamp) over time.

Essentially when a node finds a block, it broadcasts it with whatever timestamp it wants, so it doesn't mean it's accurate at all. Of course nodes are programmed not to do this, but it doesn't mean they can't. Other nodes are programmed to accept blocks with timestamps that make sense: for example if I receive a block with a timestamp set to a period way into the future I'll probably dismiss it.
So it's not completely accurate but it's accurate enough because the majority of nodes are using the bitcoind node, which is programmed with a specific timestamp logic in mind to generate the timestamp based upon the median time of a node's peers which is sent in the version message when peers connect.

But how accurate is "accurate enough"?

Well since a block is more or less broadcast every 10 mins I would give it worst case a 10 minute margin error.


text:
How does Nextcoin convert 256-bit Curve25519 public keys into ~20 arabic numerals?
Nextcoin seems to convert 256-bit Curve25519 256-bit public keys into "account numbers" that have only arabic numbers and seem to only have a length of 20.
How is that done?
Examples
In the Nextcoin forum, users leave their account numbers.

References? I'm having a hard time even finding one of those account numbers.

According to these lines an accountId seems to be...
int(sha256(publicKey(sha256(passphrase)))[7:0], 256)

...which translates to 256^8 accounts or roughly 2 * 10^19, which fits the idea of around 20 arabic numerals.
Given there are only 2^64 unique accountId and the birthday paradox, you can check this collision probability table (the 16 bytes/64 bits row). If each person in the world had a single Nextcoin account, the collision probability is greater than 75%! I'm sure this is the least of their problems.
This looks really amateurish. Really amateurish. Really, REALLY, REALLY amateurish. Stay away from this coin!

@Gracchus you're welcome! I guess they used Curve instead of Ed because they couldn't find a suitable Ed implementation for Java. I guess (don't want to look at the code anymore! it's awful) they're just computing signature = shared_secret(32_byte_private_key, generate_public_key(32_byte_hash(data))), but I don't really have the theoretical knowledge to understand the drawbacks.

@Gracchus notice the [7:0] (Pythonic syntax) or just line 4973. They hash the first eight bytes of your public key (in reverse order) which gives us 256^8 = (2^8)^8 = 2^64 combinations. This means each account has 2^256/2^64 = 2^192 suitable public keys!

@Gracchus Bitcoin "suffers" the same fate since it maps 2^256 public keys to 2^160 addresses (2^96 keys per address), but 2^192 public keys per address is just awful! And only 2^64 accounts is even worse. I guess they just wanted short accounts, but they're never going to fix that without breaking their current accounts.

When I first saw Nxt, I thought its concept of pure PoS was intriguing, and its approach of "new code from scratch, in Java" was fresh air. Didn't give a thought about their addresses, I now see I should've. But, what else is wrong with NXT that you say the high collission probability "is the least of their problems"???

@Gracchus: user12480's answer clarifies the situation; it's apparently not as  bad as you were thinking.

Public keys are 256 bits. Account numbers (for brevity) are 64-bits. However, the person who sends first outgoing transaction with that account, controls the account with 256-bit public key.
You cannot take over an account by collision as it's protected by 256-bit public key.

I'm not sure I understand. Are you saying that in order to spend coins, your key has to not only have the right hash bits, but also to match a previously announced key? Could you point to the part of the code where this is enforced?

Step 1: User chooses a Password. Must have a strong 128 bit entropy, or clients should generate it  (the newer clients do, must safer for newbies).
PrivateKey (256 bits)  = Hash (Password) --
PublicKey (256 bits) = Curve25519 (private key) --
Account ID == first 64 bits Hash (Public key) --
You can send Nxt to that new account, but the network doesn't yet know the public key of that account. Once you send outgoing transaction from that account, your public key is known and you control that account with a 256-bit public key.

If there is collision with another password that results in the same account number, they cannot steal money, as your public key is permanently linked to the account once there is outgoing transaction.  The client should warn the second user if it happens.
The account ID can be changed to 80 bits once this becomes a problem, but I doubt it's a problem right now with only 30,000 accounts.

Ok, that helps.  But suppose I want to receive some coins.  I generate a brand new account, give the account number N to the sender, and she sends the coins.  Now isn't there a window for Mallory to find another private key for which the account number is also N?  If Mallory finds such a key before I make an outgoing transaction from my new account (and I might wait indefinitely to do so), he can spend them first.  Do I have that right?

Yes, there is a "window" but it would be a very small window. 64-bits isn't easy to crack (even 4 billion tries per second would take 50 years an average). All you have to do is transfer 1 nxt to the new account, do something, like create an "alias" for that account (useful thing to do anyway, as people can use the alias instead of account ID to send money), and that will propagate your public key to the blockchain

I see.  But I do have to remember to do that.  If I didn't plan on spending those coins, and left them in the fresh account for years and years without making another transaction or propagating the public key in any way, I could start to be vulnerable.   If the amount were very large, an attacker could be motivated.

The user must have one outgoing transaction (this isn't bitcoin clone, different system, different idea) The newer client warns the user if there is no public key. Try this client running on testNet  http://nxtra.org/nxt-client/
it will say "Warning!: Your account does not have a public key .."
You can ask for testnxt here:  https://nxtforum.org/general-discussion/some-testnxt-to-test-asset-exchange/

This got discussed in this thread https://bitcointalk.org/index.php?topic=366105.0 For what I understood, a freshly created NXT account is indeed vulnerable to hijacking (empty or with coins) until such account "sends" some coins to somewhere else - from that point on, the public key gets associated with the 20 digits address, and no other can use it. An account which received thousands of NXT whence no coin has ever exited, though, would be very vulnerable. I guess the most secure method is: open an account, receive 1 NXT from the faucet, send back such coin to the faucet - now you're secure.

That also means that you can't have cold storage, right ? See http://bitcoin.stackexchange.com/questions/24517/is-it-possible-to-have-complete-cold-storage-in-nxt

authors: Есютин Сергеевич Ростислав


text:
Can I mine Quark on Linux?
Are there any Linux applications for mining Quark coin? I am running CPU Coin Miner and I have the Quark Wallet, both on Windows, but I would like to install these on Ubuntu or some Linux distro. Is this possible?

What I've yearned for a long time is for a comparison of mining profitbility becoming available for CPU-only coins as quark, prime, protoshares and their kin...

Yes, there are multiple open source mining clients stated in the Quarkcoin thread. See "standalone miners".


text:
How are colored coins enforced?
How are colored coins enforced?
A signature can easily be rejected, and so can a block.
How does the blockchain enforce that a particular asset is tied to the colored coin or has been delivered?
I can see how another cryptosecurity could be tied to a cryptocurrency, but does the blockchain physically manifest itself, kick down the door of 31uEbMgunupShBVTewXjtqbBv5MndwfXhb, and collect the asset if 31... doesn't deliver?

They are not enforced.
Colored coins aware clients transfer them using some colored coins rules. If the rules are violated the coins get "uncolored". But if implemented properly, your client shouldn't cause your CC to get uncolored.
The main problem with colors not being enforced by miners is not this potential uncoloring though, it's scalability.
For example, a commited utxo (http://utxo.tumblr.com/) softfork could highly reduce the trust that SPV nodes require. Without enforcing colors, this won't work for CCs.
There's other hardfork proposals for colored coins that don't have these problems. For example, Freimarkets (https://bitcointalk.org/index.php?topic=280292.0) uses tags in outputs to indicate the color and miners enforce the rules.
The main disadvantage of this approach? You need a hardfork.
But if this hardfork doesn't happen on bitcoin, it can be deployed in a merged mined chain like namecoin. The Freicoin community is willing to accept this hardfork on Freicoin and Merged Mining with Bitcoin is also planned.
But once developed, these extensions could be deployed in any bitcoin-based chain.

There's no other way to implement colored coins than using rules. If you don't follow those rules, there's no way you can tell which color each output is.

You could imagine that you're selling a car to someone. The key to open the car is tied to your bitcoin address. So only you, owner of the private key for that address, can open and turn on the car.
Once you sell the car you make a symbolical transaction to the buyer and you configure the car key with the buyer's address, so only s/he can open the car.
The symbolical transaction is actually a colored coin. It's proof that you've sold the car. That proof is also attached to the physical key itself. That proof will forever exist (or at least until bitcoin exists) in the blockchain.
If then they decide to sell the car once more, they can use that same colored coin and make another symbolical transaction. Now the third owner of the car can see the proof of ownership of his car just by looking at the blockchain.

it's just a way to legally prove, to a judge for example, that you've owned something at a specific time (if you have the key)


text:
Are Mastercoin addresses Bitcoin addresses?
I am reading up on Mastercoin, and I must say, it is quite confusing. Am I correct in saying that your Bitcoin address is your Mastercoin Address? If so, I have one private key that contains two cryptocurrencies?

Yeah, that's right - Mastercoin uses the same address space as Bitcoin.
You can store BTC, MSC, TMSC (Test MSC), and soon many other crypto-currencies on the same address using The Master Protocol.

Have a look here: www.youtube.com/watch?v=mAW-kuoZaHU and you'll probably understand how it works.
You download the blockchain with Bitcoin-QT and run my Mastercoins wallet through it.You label the addresses in your QT wallet and you can now send BTC and MSC to these addresses.

link not working.. :(


text:
Could the bitcoin protocol be used to defeat logins and passwords?
Could the bitcoin protocol be used to defeat logins and passwords of websites?

Sure.
The website could give you a random string that you would use to sign a symbolical transaction to the blockchain. Once the transaction is done, the website can assign your bitcoin address with that initial random string and allow you to log into their site.
In fact it could replace systems like OpenID where you'd just make a single symbolical transactions that various other sites would understand and can log you in.

Can you imagine how big the blockchain would become if it contained a permanent record of every Facebook login ever?