text:
Ethereum - contract
I'm not sure whether people answers question on Ethereum here as well but just in case...

Once my smart contract is active on the Ethereum, what prevents me from modifying the contract for my own benefit? Let's say I created a crowfunding dapp which users can use on my site www.crownfunding.com. Once users are using that dapp, as a malicious guy, I could link a new smart contract to that site sending investor's money to my own account instead of using that money for the crownfunded project?
It is true? If so, what are the safeguards?
Could you tell me, in very plain words please, whether once I have created my contract code and "sent" it to the Ethereum network, I can update it? or do I have to write a new program and send it to the network (the oldest one then "dying" out of gas).

There's really no such thing as "modifying a contract". If you modify it, it's a different contract entirely. You would need an unchanageable master contract that specifically supported the ability to take functionality from external contracts based on something that was changeable. And people would only trust such a contract, and send money to it, if what was changeable was acceptable to them.

Sorry but I don't understand what you mean by unchangeable master contract?

and I understand that if i modify a contract, this is a different contract entirely. BUT as a user of the website, I have no possibilities to verify whether a new smart contract was not maliciously modified for the benefit of the developer?

I think you're missing the point. You can't "maliciously modify a contract". You can just create a new contract that's malicious. You make things unnecessarily complex and hard to understand by talking about a "change". The question is just this -- how can people know that the contracts they're sending money to can be trusted? A contract can't be changed, so issues with changes and modifications simply don't exist.

Step back for a second and look at the big picture. You want my money. If I'm just willing to trust you to do the right thing with it, we don't need smart contracts. The case for smart contracts is where I'm not willing to send my money just anywhere -- I won't send it except under conditions where I am provided assurances that the money will be used as I expect it to be used.
If people trust you with their money, you can steal it. You don't need a smart contract for that. But if the sender doesn't trust you, he will insist on sending his money to a smart contract he trusts.

1 - Once my smart contract is active on the Ethereum, what prevents me from modifying the contract for my own benefit?

There is no such thing as "modifying the contract". You would just be creating some other new contract. Anyone can do that at any time, and you can do that. The trick is how you convince people to send money to the new contract.

Let's say I created a crowfunding dapp which users can use on my site www.crownfunding.com. Once users are using that dapp, as a malicious guy, I could link a new smart contract to that site sending investor's money to my own account instead of using that money for the crownfunded project? It is true? If so, what are the safeguards?

You can't send other people's money anywhere at all. Other people send their money where they want to send it. Of course if you could get people to send money anywhere you want then you can steal their money. But in that case, why use a smart contract? The whole point of a smart contract is that you can't just convince people to send money wherever you want them to, and they insist on using a smart contract to guarantee the money goes where they want.

2 - Could you tell me, in very plain words please, whether once I have created my contract code and "sent" it to the Ethereum network, I can update it? or do I have to write a new program and send it to the network (the oldest one then "dying" out of gas).

You can design a contract whose sole purpose is to decide what contract actually executes and it can use whatever rules you want make that decision. However, again, you are assuming that an attacker can get people to send money wherever he wants. If that's true, he doesn't need a smart contract to steal their money.
The whole point of smart contracts is that other people won't send money where you want them to, they'll send money only where they want to send it. And you need to provide a secure smart contract they trust for them to send money, otherwise they won't do it.

Thanks a lot for your answers David. This is much clearer to me now.
Well just one last question...all that means that I, as an investor in a crowfunding website (for instance https://medium.com/@WeiFund) has access to the underlying contract code?
I might repeat myself but under that website (https://medium.com/@WeiFund) there is a backend code (smart contract code) which is linked to the user interface. Is this true? If so, Weifund could design a new (malicious) smart contract code as the backend code?
Do you get my point? sorry i'm just a beginner...;)

The logic of a smart contract is that the user is not willing to send money wherever a site tells him to but instead demands assurances that the money is controlled by a smart contract they trust. Sure, if a user will send money wherever a site tells him to, then that user trusts the site, and there's little need for a smart contract. The point of smart contracts is to handle cases where that trust doesn't exist and the user won't just send money wherever the site tells them.

Thank you very much for your patience;) this has been of great help

Hi again.
If I as investor is ready to invest in Bob's crowfunding project, we have to agree on the smart contract's code. This means I need knowledge of programming codes I guess? or I need a developper who can designe the code with the other counterparty (Bob)? Is is right?

Most likely you would be using some client whose developers had already decided on what crowdfunding contracts they consider reliable. Your client program would know how to read the contract parameters and present them to you in human-readable form for your approval. The contract would, of course, be available for anyone to inspect and would have to be coded as clearly and simply as possible in order to gain broad support. Developers have to convince each other the contract can be trusted so that clients and crowdfunding systems support the same contract.

It's much the same thing you do when you download firefox and all of a sudden you can tell if you're connected to the real "amazon.com" or not. Certificate authorities have to convince browser vendors that they're reliable so that their certificates will work in the browsers people use.

Ok. much clearer again.
I'm now understanding that as for a "physical contract", you have to agree on the code first.
The main advantage of the blockchain being actually the prevention of malicious modifications once the contract is validated by the involved counterparties.

What do you mean by clients? This is clients software?

Yes, probably a wallet. And not just that the contract can't be modified, but that you're assured that the funds are dispersed as you expect.

are you ok with my following ideas:
• Crowfunding: launch a campaign for a new uber-like company. We should set up a smart contract between Youber and investors which would confirm shares (let’s create 100000 shares) in exchange for money (e.g. Ether). With the help of some developers, we could design the smart contract (its code) and a client software which could make it more readable to Youber and investors.

The investor would have his shares stored in its externally own account (via the client wallet). (Very useful as I now have the possibility to sell and settle that share to another wallet).
Client software would just take a commission on the amounts of equity/debt raised.

The client’s ambition/interest is therefore to get a maximum of credibility. At first, there might be malicious clients colluding with smart contract’s developers to deceive honest investors and entrepreneurs (even if people having access to the code minimizes that risk).

While @David's answer is correct, there is a caveat.
The likelihood is that anything other than a trivial DApp will be made of multiple co-operating contracts. Specifically, the logic and the data will live in separate contracts. This is to permit the logic contract to be logically updated (actually replaced as David explains) without losing the data. Any DAO architected this way, is effectively modifiable.

@david schwartz,
the following is an extract from stephan Tual article:
https://blog.slock.it/we-re-building-the-ethereum-computer-9133953c9f02#.pcpmb89or
This is perfectly suming up my fears about decentralized applications...
"If you’d rather use your own machine, you probably noticed current Dapps often require you to trust them with relaying your instructions correctly to the Ethereum network via their web interfaces. This is rather ironic (and dangerous!) considering Ethereum was designed with removing the need for trusted third parties in mind."
"

authors: Егор Чеботарев


text:
ubuntu usb drivers to run bfgminer
Been racking the brain forever, ubuntu noob, but wiped W7 for Ubuntu, updated and upgraded, checked out bfgminer and cgminer, both when running good .bat file with good pool, but they say no device?
Adding zus:all or just all or just auto wont add the X3 Thunder I attached via USB to the laptop? I have had issues another laptop like this and had to use a special driver.
Any ideas or directions are greatly appreciated. Also I'm not against either cgminer or bfgminer, but id like to get one working on this ubuntu laptop at this point, I have a device that should be hashing and i cannot get working.

Would be advantageous if you rephrase the question to the exact steps youve taken, use the "CODE" take to paste console output, for long console use pastebin with the correct synthax. First idea is chown -R USER:GROUP /dev/device and try sudo apt-get install usbmount. PS pls include versions as well, which ubuntu do you use? Check synaptic -> search -> firmware, may you dont have the correct firmwre - without facts just guessing here :)

Are you running the miner as root? Do the devices show up when you run lsusb ?
In my experience, your user doesn't have access to the buses to talk to the devices, but putting sudo at the start (running as root) let me see and talk to my devices.
(I'm using cgminer compiled from source for LTC mining rather than BTC, but the principle should be the same.)

Yes, running as root, installed as sudo su, then installed and compiled, it opens to the pool, but wont connect the device, ill try the lsusb and report back later tonight when at cpu, thank you for your answer

BFGMiner has no such issues normally and should not require root.

source: Stack Exchange

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

sort: votes


text:
I have Blockchain.info wallet which i can't find
I opened up an account with a site called Blockchain.info got a username and password, got a Bitcoin wallet address. I then bought some bitcoins sent them to that address, the bitcoins left but now i cannot access any blockchain.info site that gives me access to my account. Does anyone know what is going on with Blockchain.info?

"now i cannot access any block chain site that gives me access to my account": This is extremely vague.  What exactly did you do, and what happened?

1) Blockchain.info was down for a few moments in recent days - please re-check it's availability.
2) Blockchain.info sends an email confirmation with your wallet's "Identifier". This is your login/username. Try searching your email for "blockchain" and see if you have that email.
Subject: Welcome To My Wallet
Body:

This email contains important information about your new bitcoin
  wallet. Be sure to keep this safe and stored separately from your
  password.
Login Link:
  https://blockchain.info/wallet/9c......
Notifications: Notifications Are Disabled Confirmation Code: D9028
Verification Link:
  https://blockchain.info/wallet/verify-email?data=xxxxxxxxxx

Clicking the first link to your wallet will pre-fill your identifier (login), and just need the password you set when you started. That will get you into your account.

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


text:
Will a paper wallet ever have format issues?
I found a paper wallet in my drawer, created in 2011 and with quite a lot of money on it. The private key says 'wallet import format'. I'm pretty confident that I will have no problem with importing it into blockchain.info or bitcoin-qt right now.
But let's imagine you find a paper wallet in many years from now. Who can still read audio tapes today? Will there EVER be an import format change? Or is this 'wallet import format' so future proof that my (future) grandchild could claim the funds? If Bitcoin still exists, of course.
I guess the safest paper wallet would include code or instruction on the bottom how to convert ;-)

Short answer: no, there will probably never be format issues.
Paper wallets are in a better spot than audio tapes because they degrade less over time and there is no specialised hardware required to read them.  It's not that the method of how audio was stored on audio tapes has been lost to history, it's just that finding a machine which implements that method is getting more difficult.  Since the method of storage in a paper wallet is just text, it would take a pretty fantastic catastrophe to wipe that knowledge from the planet. You're right that it's important to note the specific format in which private keys have been stored.  But as long as you know that, you will always be able to recover the private keys, which are the fundamental method of bitcoin ownership.  Since the "import format" is just a method of recording these private keys, that makes your paper wallets as good as any digital one.
Long answer:  a fundamental break in the current methods of cryptography wouldn't cause any format issues, but it might cause other issues (assuming the Bitcoin network at large had enough warning to survive the problem itself.  If it happened faster than that the world would have much bigger problems than Bitcoin failure).  If this happened, it would be major news and any reasonably attentive person could ensure that your paper bitcoins are at least as safe as anyone else's.  Left ignored in this unlikely scenario, it might be possible for someone else to steal your bitcoins.  Otherwise they could be invalidated by a protocol upgrade if the network considered that preferable to mass theft (old digital wallets would be just as vulnerable as paper ones, leaving a lot of bitcoins up for grabs by motivated adversaries).
Cryptographic protocols are often eventually weakened.  But this tends to happen at least somewhat slowly (which is the main reason we use cryptography for anything important at all).  A weakening of the cryptographic protocols at the heart of the Bitcoin algorithm would have far-reaching consequences for the entire computing industry:  banks, governments, corporations, etc. would all be scrambling to respond.  You would hear about it.  As long as you followed the convention Bitcoiners eventually settled on for responding to the threat, your bitcoins would be fine.  Or the world would end.  One of those two.
Paper wallets are also vulnerable to burning in the event of nuclear holocaust or a large asteroid collision.
tl;dr: to be paranoia-level safe you would want to ensure that someone is at least generally keeping abreast of Bitcoin news.

Good analysis indeed! The problem is not to find on the internet how to convert the 'wallet import format' then, but changes in the cryptography. Like the v0.7-0.8 issue showed: the network could decide to move on, eventually invalidating old wallets. Although such decision should be the last resort, better not forget a wallet in a hidden place :)


text:
What happens if I don't "pick up" bitcoins with a Bitcoin client?
Say I want to save ten bitcoins could I send them to myself and just not 'pick them up' with my client? In a way would I be storing the bitcoins in the blockchain and when I want them just start up the client? Or would it be possible for someone else to 'pick them up'? Or are the private keys already in the wallet file as soon as the payment is 'sent'?

I think this is a useful potential misconception to explain, and have edited the title to focus in on it more acutely.

Everything is already stored in the blockchain, and there is nothing to "pick up".
The blockchain stores: "A generate a block (25 btc now)" and "A sends 2 btc to B".
When you want to send bitcoins, you proof that you are "B" and sign a message saying "I own these coins (A->B) and want to send all of them (2 btc) to C".
Now "C" owns 2 bitcoins.
(This of ofc simplified alot, e.g. I am missing confirms/etc but you really need to understand the basics before you start learning the advanced)

Exactly. Your client doesn't do anything to your Bitcoins, other than report that they are in the blockchain, until you spend them.

Bitcoins themselves are not stored anywhere. The only things stored are (1) the blockchain, basically a record of all transactions, and (2) your wallet which most importantly contains your private key(s).
I think what you are talking about is to send Bitcoins to another wallet of yours but not update the new wallet yet. Meaning: not letting the client realize that a certain transaction in the blockchain belongs to its wallet. This is possible if you feel like it; you can keep the wallet disconnected from the network for example. You can always update your wallet later by connecting it or importing the blockchain and using bitcoind -rescan.
However in theory this would not matter at all until you send the coins to another address again. This then will put a new transaction record in the blockchain which you sign using your private key. At this point you publicly state that the coins are yours.

Say you generate a new Bitcoin address using a tool like bitaddress.org, you can immediately receive a payment on that address. Once you have received the payment, you already "own" the amount, because you have the private key to unlock those funds. The fact that the address is not in your wallet.dat doesn't matter. In that sense, there's nothing to "pick up" here.
You could of course import your private key into the client software so you can actually spend the funds at some point.
With real cash (dollar bills), possession is ownership. With Bitcoin, knowledge of the private key is ownership. If you have the private key, the money is yours.
See also: Brainwallet

Your client doesn't actually "store" anything; it's the blockchain that records how many bitcoins belong to a given address. If your client is not online when coins are sent to your address, this doesn't matter at all: the network will still acknowledge that those coins now belong to your address, and your client will report this as soon as you fire it up and connect it to the network. If this doesn't happen, then the coins will be lost and unusable by anyone.

I just downloaded bitaddress.org java file and experimented with sending a small amount to an address for which the private key has yet to be loaded. That money unfortunately disappeared. (i.e. when I loaded the corresponding private key nothing showed up)
On the other hand, sending money to an address with the corresponding private loaded in a client showns up quickly no problem.
hope this helps.
OH Wait! I spoke too soon. I did not see the transaction or look carefully but here it is:
Status: 39 confirmations, broadcast through 27 nodes
Date: 4/12/13 16:08
Debit: -0.000111 BTC
Credit: 0.000111 BTC
Transaction fee: -0.0005 BTC
Net amount: -0.0005 BTC
Transaction ID: 0bba0d308dcd8c8f8141bf95ba4...etc.
I am still confused though because the transaction summary in QT shows the amount as -0.000611 (instead of the net of 0.0005)

Mind linking to the transaction on blockchain.info or giving us a fill txid so we can look at it ourselves? Thanks.


text:
Is a private key used up when part of the bitcoins it controls are sent?
Here is my current understanding of Bitcoin:
I have 10 bitcoins in my wallet.
If I send 5 bitcoins to someone else, I am sending the private key from my wallet to somebody's public key address.
Those are combined into a new transaction that is later confirmed by miners. The miners confirm that I owned the bitcoins by checking my private key, and that the receiver's public key is valid.
Then, the miners create a new private key that is sent to the receiver's wallet.
On a simple True/False basis, is everything I have said right so far?
If so, what happens to the remaining 5 bitcoins in my wallet?  Do they magically get a new private key, or what? How does my wallet know how many I have left, and how do the remaining bitcoins get a new identity?

I edited the title to better reflect your question, hope that's okay.  I'll be posting an answer for you in a second.

possible duplicate of Understanding a transaction input and outputs

Related: http://bitcoin.stackexchange.com/q/1629/153

I don't think this is a duplicate of either of those, nor do I think it's a bad question.  I think it's a simple matter of needing to know how public and private keys work in Bitcoin.  Please don't downvote--it's hardly user4710's fault they aren't versed in the details of public key cryptography.  My answer will be up shortly.

-1 not voting to close, but the way it is worded is so confused that I don't think it's a good thing to have such a question, until it has been edited to something better (which may help future visitors, instead of confusing them).

@Lohoris what did you find confusing about it?

@eMansipater pretty much everything, it would need a complete re-word, from scratch, to become a good post, IMHO.

It's very readable for me.  Do you mean just because of all the wrong assumptions?  That, for me, is the question.

@Lohoris I've edited the question.  Does my edit take care of your concerns?  If not I feel like you are just saying it's a bad question because of the low level of understanding demonstrated.  Lack of understanding should never be considered a crime on Stack Exchange--only failure to express that lack of understanding as a useful, answerable question.  This one seems like a perfectly reasonable misconception, asked clearly.  Don't bite the newbs, people!  Users of this stack exchange shouldn't have to be cryptographers before they're allowed to ask questions.

@eMansipater ok now it's clearer. I guess it was the combination of bad writing + noob question that prevented me from understanding what he was asking. No problem with noob questions, I just wasn't able to understand what he was talking about.

False, as you've described it here, because private and public keys work a little differently than that.  The underlying math is tricky, but I'll try and give a common sense explanation in everyday language instead.
Imagine that there was a special metal called Cryptonium, harder than anything else on earth and completely indestructible.  No one else knows it exists, much less how to make things out of it.  Let's also say you had a special machine which could make plaques out of Cryptonium, with raised letters on them saying whatever you wanted.  Obviously, you would keep the existence of this plaque-making machine a closely guarded secret.  You probably wouldn't even want anyone to know it was you that owned it.  But you still want to share this exciting discovery with the world, so you secretly produce a message that says "Behold, a new and indestructible metal!"  Then, late at night, you sneak into the middle of town and put the Cryptonium plaque up in the town square.
The next day, everyone gathers in the town square to wonder at this amazing new plaque.  They take turns bashing at it with the hardest, sharpest, heaviest things they can find, and the plaque remains perfectly unscratched.  "Sure enough," they figure, "it's indestructible."
You decide to use the secret machine to write more things, helping out the townspeople and gradually earning a reputation as a trustworthy and reliable source, even though nobody knows who you are.  But a few months later something terrible happens.  New plaques start showing up in town during the night, and they are fakes!!  Someone else is taking advantage of your reputation to spread false and misleading messages!  They don't have your special machine of course--they're making their plaques out of platinum, and it's only almost indestructible.  But the two metals look the same, and the townspeople don't know the difference.  What will you do?
You could announce yourself to the townspeople, show them the machine, and tell them the new plaques are fakes.  They might believe you, but your machine wouldn't be a secret anymore.  So instead you do something really clever.  You use the machine to make a small, square plaque in the shape of a hammer's head.  On the plaque, you put the message "This hammer will destroy all fake plaques." Then, you attach a handle to the hammer head you've made and leave it in the middle of town the next night.
Now, the townspeople can simply use the hammer to break all the fake platinum plaques.  Sure enough, the false and misleading messages are all easily destroyed, while the ones you've produced are able to withstand the hammer's force.  Your reputation is preserved, and your secret was never revealed.  Together the hammer, the secret machine, and the plaques form an unbeatable system that lets you send messages which could only have come from you--without revealing who you really are.  Not bad, hey?
In many ways public key cryptography works like our imaginary Cryptonium metal.  It's made up of three parts, and it gives other people a way to be certain a message came from you without you having to reveal your identity or your secret way of making messages.  Like the Cryptonium system, you need all three components to make the system work.  These three parts are your public key, your private key, and your signatures (which you can make as many of as you like, signing all different messages.)  In our story, the private key is like the secret machine, the public key is like the hammer, and the signatures are like the plaques.  In reality public key cryptography is more complex than I've described here, and if you want to learn more about it you can check out this course from Khan Academy.  However this example should be good enough to understand how private and public keys are used in Bitcoin.
First, nobody else ever sees your private key. Instead, like the secret machine, you use your private key to make signatures (like the plaques) that people can be certain came from you.  Each person (and each bitcoin address) has both a public and a private key, which share a special mathematical relationship, and the public key (like the hammer) is what other people can use to verify your signatures are real.  When you send a Bitcoin transaction, you don't give away your secret machine--you only use it to make a message saying who you're giving the bitcoins to.  This signed message, or signature, couldn't have come from anyone else except the owner of the address, so then everyone knows the transaction is real.
Second, private keys don't come from miners--they come from you.  You're the one who secretly chooses a random private key (the Bitcoin software does this for you), and that private key was used to figure out your address (which is basically a version of your public key) before anyone ever sent it some bitcoins.  Miners never have it to begin with.  They only see your transactions (signatures) and your receiving address (public key).
Finally, just to confuse things a little bit, you have to use up a whole transaction at one time.  So if someone sent you 10 bitcoins, and you want to send someone else 5 of them, you actually send out a transaction that takes all 10 that you received, sends 5 to the other person's address, and 5 to another address of your own (this is called the "change" from your transaction).  Bitcoin does this so that other people can't tell which part of the transaction is what you sent and which part is the change (nobody knows which addresses belong to the same person).  It helps protect your privacy.  But if you wanted to, you could send the change back to the same address, because your private keys are still safe.  You'd just have to use a different client than the default Bitcoin client, because it doesn't have a way to do that.  All of this happens behind the scenes, which is why your balance still shows as 5 bitcoins after you do this.  Bitcoin stores all your different addresses and private keys in something called a wallet, and the balance is the total bitcoins owned by the wallet.  So it keeps everything simple up front!
Make sense?  Hope it wasn't too long, but I wanted to try and make the public/private key thing more clear.

Really nice layman explanation!

No. Transactions work by ECDSA signing.
Basically, you write up a transaction and you sign it with your private key. Anyone who has your public key, the message, and the signature can easily verify that the owner of said public key is the one who signed the message (on the other hand, forging a signature is extremely difficult)
Transactions can have multiple inputs: In such a case a signature from each input key is required.
They also can have multiple outputs. Generally, a transaction depletes all the money in the inputs. All the change is fed back to the inputs, so a  transaction may have the inputs A(balance 10 BTC) and B(balance 15 BTC), with a 20 BTC output to C(owned by someone else), and a 5 BTC output back to A. Most clients by default create "change addresses" (or give you the option to do so). In such cases, a new address D is created to receive the change of the transaction, and the new address is added to your wallet (this keeps you a bit more anonymous. Your sender keys may be connected to your identity if there was some non-anonymous exchange involved in the transaction. The change key won't necessarily be connected with you)
Any bitcoins not accounted for in a transaction are considered as "transaction fees" and are an extra incentive for the miner to collect.
See also: Why are there two transaction outputs when sending to one address?

thats not right. by default, change is returned automatically to a new address.  you have to specifically direct change to an originating address.

@joe: That's in the official bitcoin client. The protocol specifies no such thing.

i'm not aware of any client that returns change to the originating address by default.

@joe: ..so? I never mentioned that in my answer. However, it is an option in some to turn off change addresses.

you said a "typical" tx will return the change originating from A back to A.  that's incorrect since by default all clients that i know of send change back to a new address D and most ppl don't bother or even know about returning change back to its originating address.

@joe: Fixed, happy? I was talking about the protocol, not the implementation. Change addresses are a feature of the client, not the protocol.

@joe AFAIK the android client "bitcoin spinner" returns change to the originating address.

@wump thats b/c in Spinner there is only one key pair so it's not possible to return change to a different address.

Short answer is No.
no new address is created. Bitcoin simply realizes that the balance of the former private key is deducted by 5 bitcoins.


text:
How much time does it take for the bitcoin-qt window to show up in OS X 10.4?
I have downloaded Bitcoin-Qt for Mac yesterday. I understand that it takes a while to "synchronise" but this site says one can access it whilst this process takes place. I have the Bitcoin in my applications folder but when I click on the icon nothing happens. A friend says he could monitor the progress of the synch, I can't see anything. What am I doing wrong?

What verison of the client are you installing? what version of OSX you running? Does the application load into memory? Im not familiar with debugging OSX but im sure these details will help someone else.

To closevoters--this seems like a valuable question to have on the site, though it might be able to use an edit.  The criteria for "too localised" is that a question is "unlikely to help any future visitors" and it seems perfectly reasonable that there will be OSX 10.4 visitors for a while yet.

Editted to include the most pertinent element--OS X version.

When you open the Mac client, it first displays the loading screen for a while :

After that it displays the main screen and starts synchronizing :

Note that the client is really slow and might take a while to load. If it's still not displaying the loading screen after a minute, try opening it again. As far as I know the Mac client doesn't have any requirements for installation.
To diagnose the issue, please perform these steps :

Go to Activity Monitor (it's in the Utilities folder) and see if Bitcoin-qt is running. It should be.
Open Console (also in Utilities) and see if there are any errors about Bitcoin-qt.
Restart your Mac. It may help.

Hi, thanks for your reply. Botcoin does not appear in the Activity Mon or the Console, so I downloaded again from Sourceforge (bitcoin-0.8.1-macoscx). My Downloads folder opens showing the orange "Bitcoin" icon and my Applications folder. I then drag the former into the latter. When I click on the icon nothing happens, I haven't seen the wallet image you show. My Mac is Intel OSX v10.4.11. Sorry if I sound dumb, I'm not very computer savvy. John

Ah, well, that explains it then. The earliest supported version of Mac OS X is 10.5. Either update your Mac, buy a new one, or use a different wallet.


text:
What is going to happen when it is totally infeasible to download the entire bitcoin transaction history?
As far as I know, the bitcoin system currently relies on the principle that all transactions are made by someone with access to the entire history of previous transactions. Since bitcoin's public debut 2.5ish years ago, these records have stayed small enough that it's still easy for one person to download and update it.
Once it gets large enough, though, it's going to be hard to do that. When I ask most people about this problem they just tell me that eventually we will start trusting our money to some bank-organization-type-thing (e.g. Coinbase) and we won't have to worry about the integrity of our records.
Imagine that in the distant future, the bitcoin system becomes widespread enough that the rate at which transactions history grows exceeds the rate of change in disk space technology. (far cry, I know, but let's just assume a worst-case scenario.) How would bitcoin account for this problem?
Is a better, more widely agreed on solution?

This is a topic that has been discussed to death, including questions on SE.

The default answer to scaling is SPV (lightweight) clients, which allow very good security and control of funds without the entire blockchain. Full nodes will still exist but the cost of running one will not be prohibitive.
In practice many people will use some sort of bank service. If the funds are in full control of the bank it has some disadvantages, but yes - in this case of course the banks will settle intra- and inter-bank transfers with internal records and reciprocity agreements, not with the blockchain.
There are some schemes which allow making a payment without it being recorded as a transaction in the blockchain, and without having to trust a bank with your money. This will greatly reduce the total size of the blockchain.

Certain clients like MultiBit don't download the block history. The chain for them is stored in the cloud. That is one solution.
Also, with interest from companies in things like Google Fiber, once we get to this point most people's internet speed will hopefully be fast enough to download it.

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


text:
Will forks and alternative block chains cause hyper-inflation of decentralized digital money?
Great effort has been put into Bitcoin's concept of money supply and that there will never be more than 21 million units.
However, it's relatively easy to fork it and create alternate block chains. SolidCoin, IXCoin, IOCoin etc are much less worth, but they can easily be traded against Bitcoin. Does this increase the over-all supply of Bitcoin-like money to well beyond 21 million units? Some believe yes, and that this is one reason already for the recent price drop.
Also, the concept of open and decentralized P2P money is still young. Chances are that a lot of other such currencies will pop up in time. Is there a risk that Bitcoin will be thwarted by an inflation of other currencies, rendering it and all other open, "free", decentralized money worthless and useless?
EDIT: One thing to consider in this context is that the number of traditional currencies will always be limited as there are only so many nation states on this planet (and they are consolidating, e.g. Euro), but the number of decentralized digital currencies is potentially unlimited.

I worry about what happens when one digital currency is obsoleted by another. Nobody is going to want to trade units of the new future system for units of the old system if the old one is being discontinued or abandoned by the market, and since there's no convertability built into the digital currencies, if the new ones are too different to be backward compatible, I fear that every time this happens, everyone holding the old currency will be stuck with useless bits.

It depends entirely how much those alternate block-chains get utilized. In the recent examples of ixcoin and i0coin, a small portion of btc miners and users switched over, sold their stash and went right back to bitcoin. It's essentially a case of network effect - whichever block-chain has the most users will be the most attractive to new users, and those new users themselves contribute to that effect. Bitcoin is by no means beyond the "tipping point" where forks can no longer threaten it, but short of a fork with some superior feature or another it remains the preferred fork and probably will for some time. Even namecoin hasn't touched bitcoin's user-base much despite having a definitive use built into the protocol.

I also think most people forget that "fork" doesn't mean "permanently branched away from" - for example, if enough people decide that SolidCoin is better because of the more frequent retargets, that's a change that can be rolled into the official client at some point. Forking the block chain is permanent, forking the project to experiment with new features isn't.

that's a change that can be rolled into the official client at some point -- theoretically, yes, but the logistics of convincing everybody to change their client are nightmarish.  The non-upgraded clients will reject blocks from the upgraded clients and automatically fork the blockchain without any human intervention.

It is likely that blockchain-based currencies like Bitcoin are a natural monopoly.  It is most beneficial for users to own and accept in trade the most popular currency, as they will have the greatest number of opportunities to do business with it.  This is referred to as a network effect.
There are also additional costs and risks associated with owning and accepting less popular currencies, so most people are unlikely to do so.  This makes it unlikely that alternative blockchains will gain much traction.  Few people will deal in both simultaneously, and even fewer will abandon the more popular blockchain entirely for a less popular one.
In order to overcome these obstacles, an alternative blockchain currency would have to have significantly valuable features that the incumbent lacked.  Even this might not be enough to compel large numbers of users to switch, and it becomes more unlikely as the incumbent grows larger.  If the alternative did gain enough popularity, it would probably displace the incumbent entirely.
The most recent batch of alternative blockchains are just clones of Bitcoin with tweaked paramaters and no additional features.  It's unlikely that they played a role in the recent price drop, though one could further investigate this by comparing the changes in the market cap of each currency.

In order to overcome these obstacles, an alternative blockchain currency would have to have significantly valuable features that the incumbent lacked -- FWIW the only example I know of is NameCoin, since BitCoin can't be used as a DNS or PGP-key registry.

A competing digital currency will have to convince people that it is better and worth more than bitcoin.  That's unlikely to happen if it shares all the properties of bitcoin since bitcoin would have a lead in terms of adoption and infrastructure (but with enough marketing muscle might happen).  Should the value of the competing currency rise high enough relative to mining difficulty, then miners can make more money by mining the new coins and then selling them in exchange for bitcoin.  This caps the upside potential of the new coin to the same potential that bitcoin itself has.  And there is a high downside risk of your investment going to zero.  For speculators, this is not likely to be very appealing and if it's not appealing to speculators, it's not likely that a new coin could get very far off the ground before being abandoned.  However, if the new coin offers some new innovation or is perceived to have some other advantage that will cause it to surpass bitcoin, then this dynamic could be inverted.

All other things being equal, the value offered by a currency to a user increases as its user-base grows due to the network effect. Therefore, it is reasonable to assume that unless another P2P currency possesses significant technological advantages over Bitcoin, Bitcoin's first-mover advantage likely makes alternate block chains uncompetitive in the main p2p currency space.
It's impossible to determine whether Bitcoin will become the de facto digital currency, and if the network effect is a significant competitive factor, multiple digital currencies existing does not preclude it from happening.

No.
Either alternate block chains are successful, or not. If they are not successful, the point is moot. If they are successful, then Bitcoin holders will diversify into these alternative crypto currencies. The total number of "coins" throughout the chains doesn't really matter, it's their combined monatary worth ... say in dollars.
It's not important whether Bitcoin itself is successful, or some mix of its clones. An easy an interoperable way to trade with the set of successful crypto currencies will emerge.

I think it is important to those who own a large number of Bitcoins whether or not Bitcoin itself is successful...

@Michael - I believe most Bitcoin holders should/will eventually diversify their investment over other coins, proportionally to the "market share" of these coins, thus making this point moot.

You could probably make the same diversification argument about traditional currency, but most Americans I know own exactly 0 Euros, Great British pounds, etc.

@Michael McGowan - that's a shame. See also http://bitcoin.stackexchange.com/questions/115/is-there-an-easy-way-to-diversify-your-bitcoin-holding-among-the-other-popular-fo

@Michael McGowan: But is that because they don't appreciate the benefits of doing so or because it's too difficult? With crypto-currencies, it's not difficult at all.

Alternate block chains are as different to bitcoins as the Yen is to the Dollar. These other currencies do not influence the liquidity of bitcoins.  They affect the bitcoin market only in so far as people begin using them.  As low as it is merchant uptake of bitcoin is far greater then any other block chain currency, and it is likely to continue to lead since that is where most of the infrastructure effort is focused.
Bitcoin's value as a tool online is it's features.  Unless other currencies provide different features that are compelling it is unlikely they will compete.  If a new currency does show new features that are compelling then perhaps people will buy units of that currency, but that still does not dilute bitcoin in any way.  Bitcoin is inflationary now due to the introduction of new coins being added to supply per design, this will slow and eventually stop, nothing outside of bitcoin effects this, so bitcoin will never be in danger of hyper inflation.


text:
Is "Reclaiming Disk Space" already implemented? How effective will it be?
Some people are concerned about the scalability of Bitcoin. The blockchain already has reached nearly 1 GB to download and store, which is not exactly in the spirit of a modern thin client, especially in regards to mobile devices.
Now when consulting the Satoshi Paper, it seems they already came up with a solution:

7. Reclaiming Disk Space
Once the latest transaction in a coin is buried under enough blocks,
  the spent transactions before it can be discarded to save disk space.
  To facilitate this without breaking the block's hash, transactions are
  hashed in a Merkle Tree [...], with only the root included in the
  block's hash. Old blocks can then be compacted by stubbing off
  branches of the tree. The interior hashes do not need to be stored.
A block header with no transactions would be about 80 bytes. If we
  suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365
  = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of
  1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.

Is this already implemented for the current version? "4.2 MB per year" suggests that no. Is it already on the roadmap? Have the developers met any unforeseen obstacles? Will the solution be as effective as promised?

Satoshi believes that Moores Law predicts a linear growth?

Also, the blockchain is growing exponentially not linear.

@Roo, Satoshi did say "current", which could be interpreted to mean that (s)he was explicitly referring to the linearized approximation.

The blockchain already has reached nearly 1 GB to download and store,
The proposal in Satoshi's paper does not reduce the download requirements, only the storage requirements (see this post to the bitcoin-dev mailing list).  Unless you are able to rely on some trusted third party, you still need to download at least all of the block headers.
If you download only the headers and not the full blocks and treat "buried X blocks deep" as proof that a transaction is valid you are open to a new class of attacks that would not affect a normal full-chain client.  The normal client treats "buried X blocks deep" as proof that a transaction will not be reversed later on -- the check to ensure that the transaction's inputs are unspent is completely separate from this.  A thin client cannot check that a transaction's inputs are unspent because it has only the block headers -- it does not have a copy of the transactions themselves.
The most worrisome of these new attacks have to come from your ISP, but in this day of wi-fi cafes that isn't such a far-fetched scenario.  So, use at your own risk.
I've been picking away at a wiki page dealing with all these issues.

Links in your answer are broken.

Currently there are no official lighweight clients like that available, nor are they in the making as far as I know. There are, however, a couple unofficial clients, like StrongCoin or Electrum, that hold even less data. Those are, however, working in a server-client mode, not peer-to-peer as the client described by Satoshi.
It is quite possible that such a client will never be created, as storing just the block headers is a bit pointless in itself. You have to rely on the network providing you a valid block chain anyway, you don't get much out of storing the headers, and if lightweight Bitcoin clients relying on servers would become widely available and accepted, you could do with even less data.

thanks, I know there can be architectures that rely on distributed servers, but the more Bitcoin can be decentralized to self-sufficient clients, the better

@herzmeister You can always get a virtual server or use a computer with static IP, install full Bitcoin on it and control it through JSON-RPC from basically anywhere. It's not too hard, and you sort of get the best of both worlds. Although after my own experience with redownloading the entire blockchain, I switched to an online wallet.

yes of course you and probably even me can do it, but I'm really speaking of the masses

Masses will use client-server not knowing about it ;).

@ThePiachu, you mean "Masses will get their coins stolen because they trusted a server they shouldn't have".  All of the existing "light client" proposals have hidden and dangerous trust relationships that are completely undocumented.  Please do not confuse these security-disasters-waiting-to-happen with the Simplified Payment Verification section in Satoshi's paper.

@eldentyrell Same could happen if you use an operating system you don't trust, or exchange, hacked client, etc. Trusting someone to develop a simplified client is just like trusting someone to develop a lightweight client. It's all about trusting to keep the wallet.dat secure, which can be accomplished in both approaches. The only difference would be, that in the latter version the server could trick you into showing you wrong data about your transaction history, which you can verify in a block explorer. All in all, everything about Bitcoin is trust to the developers, core or otherwise.

@ThePiachu, you write "trusting someone to develop a simplified client" indicating that you have clearly confused developing the client software with operating the server component.  Software can be digitally signed for integrity and inspected by multiple parties, as the bitcoin client currently is.  Servers upon which you rely to handle queries ("the cloud") cannot be easily audited like this.

@eldentyrell - I believe Stratum Server is open source, and is architected in a way that a malicious server would not be able to do a lot of damage. It's not even alpha yet, but it's a direction I'd like to see developed.

@ripper234, regarding "and is architected in a way that a malicious server would not be able to do a lot of damage", nope you're incorrect.  The server can perform attacks against the client that a thick client is immune to.  The people promoting this "stratum" just do a good job of obscuring the security problems.

@eldentyrell - I'm promoting Startum, and I don't believe it to be a major security risk. It's "less secure" than a full client, almost by definition, but I honestly don't believe it is significant for "not huge" amounts of money.

@ripper234, vague "it iz sekure trust us!!!" comments like yours are the sort of obfuscation I'm referring to.  I'm sorry to hear that you are unaware of the security problems and trust issues.  Unfortunately the fact that you are unaware of them does not mean they do not exist.  Lots of people believed that mybitcoin was safe for "not huge" amounts of money and look what happened...

@eldentyrell From what I understand, you will be able to copy the Electrum server, run it yourself and connect your light client only to it, which would be like using standard client and json-rpc. As for "loving the protocol" - same can be said about Bitcoin protocol. It takes a long while for someone to understand how it works, then they figure out they were wrong a couple times in understanding it. Unless you have written your own client from scratch, you don't fully understand the Bitcoin protocol, it has that many nuances to it (it still amazes me half a year later).

@eldentyrell - you're spreading FUD. If you have some specific claim why it is not secure, do share (not here - either in the forum, or perhaps in http://chat.stackexchange.com/). If you'd like me to explain why I think it's safe, ask a question and I'll answer it.

@ripper234, you're spreading misinformation.  I laid out my concerns multiple times in the "stratum" thread, starting here: https://bitcointalk.org/index.php?topic=55842.msg665443#msg665443  I am not going to try to repeat it within the 600-character limits of this comment mechanism.

@ThePiachu, nobody's worried about individuals who run their own copy of the server.  As herzmeister pointed out, the vast majority of the users aren't going to do this.

@ripper234, by the way, you've already demonstrated that you have no idea how bitcoin works when you posted this (which I and the site admins had to edit in order to fix): http://bitcoin.stackexchange.com/questions/2598/when-did-mtgox-lose-many-thousands-of-bitcoins  ... I don't think that makes you a very credible source for advice on what is or isn't secure!

@eldentyrell - thanks for the flame. I have reverted your edit on that question. As I wrote above, I will gladly post an answer as to why I think Stratum is secure, if you post a question about it. It should not matter how well I know the intricate low level of Bitcoin protocol - just whether the specific claims I make are right or wrong. If there is a fault, feel free to comment about my answer to the question that I'd like you to ask. Let's stop this thread, and move to Chat if you want.

@eldentyrell, see my analysis of Stratum here: http://bitcoin.stackexchange.com/a/2615/78

fyi I created a new question : http://bitcoin.stackexchange.com/questions/3199/read-only-blochain-in-bitcoind-patch-ideas and linked it to this one


text:
What is the average size of a bitcoin transaction?
I'm curious, since the inception of bitcoin, what is the average size (in bytes) of a bitcoin transaction?
To be clear, the easiest way to find this is not to take the size of the block-chain and divide it by the total number of transactions.  This is because there is a little overhead associated with block headers.  Transactions need to be accounted for one at a time for this averaging operation.
Has anyone taken the time to analyze this information and, if so, what were the results?  To be clear, I am interested in this answer as the data is stored in uncompressed-bytes.  I'm not interested in any textual (i.e. JSON) variation which might be used for network communication.

I wonder if there's much point in trying to be accurate. You could simply count them sure. Be 100% accurate. But what does that number tell you? I'm pretty sure the average size has changed over the years. Compressed addresses. Multi sig addresses. P2SH. OP_RETURN. More spam? Less spam? Any average you determine now will be different next year. Maybe you don't want one number but a graph of the the average per month? Per week? What's your purpose for this?

I don't need to know it perfectly, but +98% accurate would be great.

98% sounds pretty random again. But total  blockchain size / number transactions would probably get you there already. Especially if you correct that using a minus constant blockheader size. (Yeah I know it's not really constant)

Obviously, the correct way to get this answer to to calculate the size of these transactions and divide by the number of transactions executed and processed thus far.  My margin of error, however, is because I'd be willing to accept this metric, even if it was calculated 2 years ago. The immediate average is certainly different than what is was a year or two ago.  However, that difference is within my personal margin of error, thus the 2%.

I doubt that. I wouldn't be surprised if transactions are getting bigger. Because of growing use of mulitisig and op_return and more. How can you want something almost 100% accurate but then say you don't mind a difference because you estimate that diff to be max 2% ? I

If you want a current answer take the avg size in the last 3 months. If you want more insight into what that number would even mean, make a graph of the avg size for each month since genesis (that will show you if your 2% is realistic). If you don't care about that much detail, look at a few random samples of what you think are typical transactions (not too many txins or txouts, not too many signatures) and just go with that.

Yes, I understand how to do this but I don't have a client installed for me to run this operation against.  I ask in case someone else has the answer and they could provide the answer.  If I get around to it (could take a while) I'll figure this out on my own and update the question with an appropriate answer.

I understand, that's why I'm making comments, not answers. Also: I'm a bit surprised existing statistics and graphing sites don't include a graph for this. It is an fun/interesting statistic. For example when thinking about the scalability of the blockchain in 10 years, it's not just the number of transactions that's important, but also the change in their avg size. (For that purpose you probably do want to include the header overhead into the avg size.)

I think an economically more meaningful estimate is the average value of transactions (in BTC denomination, less tx fees).

Not if you're trying to calculate the growth in disk space used, year-over-year.

You can always find (not the average, but the) median transaction size from the last 24 hours on the bitcointfees.21.co page. Scroll down a bit to the "Which fees should I use" section.

Quote from Gavin Andresen:

the average Bitcoin transaction is about 250 bytes big

https://bitcointalk.org/index.php?topic=813324.0 (2nd post, last sentence)

I'm going to give you the answer mark because if there is anyone who's side comments on the issue are mostly correct, it's Gavin's or a couple other BTC core-devs.  If someone posts something a little more empirical, however, you might lose the check.  Otherwise, this was what I was looking for.  Thank you!

Just to give a few exact numbers, the current average transaction size (of all existing transactions until block height 498920) is 522.45 bytes.
If we take into account just the first 100000 blocks, then the average transaction size was indeed 238.51 bytes.
This is a plot of the average transaction size (aggregated monthly):

The peak on mid 2015 is produced by this 999657-bytes transaction.
These values can be computed using BlockSci.

According to tradeblock.com the average transaction size is about 500-530 bytes


text:
What is wrong with using hmac_sha512(block_hash, trans_id) as the resulting hash for a provably fair game?
Let's assume someone wants to make their own version of Satoshi Dice.  Satoshi Dice states that the winning output of the game is determined in the following manner.

The lucky number used to determine the winner of games is simple. It
  is simply the first bytes of hmac_sha512(secret,txid:out_idx). That
  would be the secret string as the key and the transaction ID of your
  bet transaction as the data.

I've done a little bit of research, and most provably fair gaming sites use a secret key for their result hashing.
My question is, what is wrong with using the block hash as the the key for the hashing algorithm when determining the win results, instead of a secret key that's periodically updated?
I cannot see how this method could benefit the player since he has no way of knowing what the hash of the block will be until after they've submitted the transaction and the containing block is confirmed at least once.
What is the exploit that prevents sites from using such a simple means of calculating the win/loss conditions?

I think you bring up an excellent point, the only down side is the payout will have to wait for the following block, delaying the payment slightly. no?

Miners could cheat this game, by withholding blocks that would cause them to lose.
For simplicity, let's assume the game is designed for approximately 50/50 odds (say, players are betting on the first bit of hmac_sha512(block_hash, trans_id)).
A mining cartel could do the following.  The cartel members pool their coins and place a single large bet at your casino (say BTC 1000).  If they solve the next block before anyone else on the network, they compute the hash of the block hash and transaction id, and determine whether this block hash would win their bet.  If it would, they post it, and collect their winnings (and their BTC 25 block reward).  If it wouldn't, they throw it away and keep mining (and forfeit BTC 25).  This cuts their effective hashing rate in half, but means that every time they do find a good block, they have a guaranteed win of BTC 1000.
This introduces a bias into the game, proportional to the fraction of the network's hashing power that the cartel controls.  But even a slight bias, over large bets and a long time, could let the cartel clean up at the casino's expense.
Worse, since the cartel's activities are profitable for all its members, there'd be an incentive for more miners to join the cartel, which makes the bias stronger.  In the limit, every miner on the network joins the cartel, and the cartel wins 100% of its bets.
A solo miner could mount a similar attack.  Alice creates a transaction that bets BTC 1000 at the casino, but doesn't publish it to the p2p network.  Instead, she includes it in the blocks that she hashes.  When she solves a block, she checks its hash to determine if it would win her bet.  If so, she publishes it.  (Maybe, to be a little less obvious, she will post her bet transaction on the p2p network and wait a few seconds before publishing the block, and hope that nobody solves another block in the meantime.)  If the block doesn't win her bet, she discards it.  As in the previous case, her effective hashing rate drops by half, but she wins every single bet that she makes.
"Provably fair" can be counterintuitive.  The way to make a provably fair game is not to bet on some external phenomenon that you think neither party can predict or influence; often the parties will surprise you, and in any case it's not usually easy to prove that they can't.  Provably fair systems instead bet on something that's determined by the inputs of both parties (with no external input), but determined in such a way that either party can assure a fair result by choosing their input to be truly random.

Thanks Nate.  I had considered this a possibility.  Truth be told, I don't see this being an issue with bitcoin.  However, with alts this is quite plausible.

As long as the bet is lower than the block reward, wouldn't that be enough to deter them from throwing away a valid block?

@bvpx: Yes.  I'm assuming that their bet is substantially larger than the block reward.

Sorry, I deleted my previous comment. What would be the issue with designing the game to limit maximum bets to current block reward minus one BTC, or something like that? Would there be any way to game that system? Mining cartels would lose in the long run.

@bvpx: First, you'd have to limit the total bets (among all players) to 24 BTC every 10 minutes (otherwise one player or cartel could just make lots of small bets from separate accounts).  That would drastically limit the size of your casino.

@bvpx: Or, a cartel could decide that they will not throw away all losing blocks, but only some fraction.  They will lose less in rewards, and still get to play a game biased in their favor.  And of course, if most of the network is participating in the cartel, then difficulties will drop to reflect the effective halving of the hash rate.

@bvpx: My point is that there is certainly a way to introduce bias into this game, and if that's possible (wherever the incentives might lie), it's not a provably fair game.  Maybe there's a cartel that really hates you, and is willing to take a big hit in rewards to ensure that you lose your bets.

I was thinking about this question last night, and I think I may have discerned the problem with using the block hash as the key to SHA operation.  I'm answering my own question so that some of the more knowledgeable experts can either verify my assumptions or correct me if this is wrong.
The problem with this method relies with orphaned blocks and the subsequent transactions that are added back into the mempool for reprocessing.
As an example, if player X sends a few coins to the gaming engine and it responds in the following block with a micro, loss condition payment, my payment, and the players payment, could be contained in child  blocks of a small orphan chain.  If the block containing the transaction for the game round becomes orphaned, all transactions within the orphan AND it's child blocks are posted back to the mempool to be reprocessed.
If the block of the original players transaction is rehashed, the win/loss conditions could be different.  This would be a big problem if the player originally lost, but within the new block hash, they win.
Theoretically, one could rewrite their engine so that it would double-check whether a previous block had been orphaned.  For each transaction in an orphan block, re-check the win/loss state.  If, and only if, the player had previously lost, but has now one with the new hash, a second winning payment could be posted to the primary block chain.
I don't believe this is exploitable but this would be a big headache.  Developing such a system would be easy, but supporting the user's could be annoying if orphaning ever became prevalent.
Also, as Ryan pointed out, this also means that you have to wait one block before you can calculate the win/loss state.  This would be a rather annoying feature for a game that is intended to be fast, such as Dice.

I don't think this is the most serious problem with this game; you can fix it by just waiting for several additional blocks to be mined, making it unlikely that the original block will be orphaned.  You probably want to do this anyway before paying off the bet, to ensure that the bet itself wasn't a double-spend.


text:
Decentralized escrow functionality built into Bitcoin?
AFAIK there are a few websites out there that offer escrow services for Bitcoin. Those however are central, i.e. I have to "trust" them.
Is it being discussed, is it theoretically possible, or does the blockchain technology already enable to implement a decentralized escrow service?
After all, it is easy to imagine that an escrow holder could be nothing more than a "virtual" party or a "bot", with its own wallet or private keys, that two negotiating parties could cast into existence. After the transaction has completed (or cancelled), the software would release (or revoke) the entrusted value to the respective party.
Update: If two parties cannot come to agreement, I can think of these solutions for now:

There could be a form of escrow option that will be chosen where at least one party is public facing and reputational, e.g. a (online) shop, that will be trusted by the other party not to deceive.
Two more "ordinarily" trading parties would choose an escrow option where the funds will never be released in the case of conflict at first. If they disclosed identity to each other, a court hearing could then be invoked which should usually come to a resolution, and the losing party will be enforced by law to provide value. Should Bitcoin never be accepted as negotiable matter by traditional jurisdiction, an alternative, equivalent infrastructure is thinkable, but let's leave that to another question for now.
This proposal by user Meni Rosenfeld:

How about this. There is a box in which there are two types of coins,
  "deposit" and "payment". Both parties have permission to open the box.
  When the box is opened, the deposits go to whoever put them, and the
  payment goes to the party other than the one who opened it.
So first the buyer and seller both put a small deposit in the box.
  This is safe since they can get it back. Then the buyer puts the
  entire sum of the payment in the box. Now:

If the seller sends the goods, the buyer will open the box and the
  seller will receive the funds. He is incentivized not to be lazy or
  spiteful because he wants his deposit back.
If the seller for any reason wants to back out of the deal, he can
  open the box and have the payment return to the buyer, and is
  incentivized to do so because he wants his deposit back.
If the seller goes with the "reimbursement" plot, the buyer knows
  he is scamming (since the seller should have just opened the box) and
  ignore the request. (There is a potential weakness in that the buyer
  can "defect" and open the box anyway, to get the deposit. This may be
  alleviated by having the buyer's deposit smaller than the seller's,
  giving him more bargaining power).
A fraudulent seller is not incentivized to try this on N people
  until it succeeds, since every failure costs him his deposit. Hence,
  scenario 3 in which the money is burned should very rarely happen.

In any case this isn't supposed to be bullet-proof, just a significant
  extra protection for sellers who already pass the sniff-test.
Additionally, the box can specify a charity address, agreed upon by
  both parties, to which the buyer has permission to send all funds,
  deposits and payment. So in the worst case the money will go to
  charity.
I'm not sure about the technical implementation details but all this
  should be very doable.

I don't think it's possible in principle. The escrow service is one that is inherently authorized to make a decision as to who ultimately gets the funds. In a decentralized escrow service, who or what would make that decision?
If I place some coins in escrow as part of a transaction to you, something must decide whether those funds ultimately go to me or you. Obviously, that decision can't be made by me or you.
I have heard proposals where the coins are "burned" (lost forever) if both parties don't agree on who should ultimately get them. I think that's a pretty useless service as it allows one party to blackmail the other. "Release the coins to me and I'll give half of them back to you. Otherwise, they're lost forever."

This "burn" model seems to be the only option for a decentralized escrow. Here is a thread at bitcointalk where this approach was discussed.

In an (a AND b) OR c signing model burning is still the main option between parties a and b but burning could be decreased by adding a trusted third party c. It would still require manually finding a third party to trust but it still allows a and b to settle their own transaction in the majority of cases, reduces the number of burned coins and allows the private industry of Bitcoin escrow to continue and thrive.

I updated the question addressing the unresolved conflict issue.

@nmat I also linked a proposal from the thread you specified.

I'm not sure what you mean by 'burned' but generally I would think they would go back to the block chain, as something like the tx fee, and the miners would pick it up.

By "burned" we mean that neither participant in the original transaction gets the money. Most escrow approaches "burn" the money if the parties can't agree. The problem with this is that it allows the receiver to blackmail the sender, "Give me the coins and I'll give you half of them back (maybe). Do nothing, and you get no coins back no matter what."

@DavidSchwartz someone who receives such a blackmail can be about 100% sure he will not receive the promised half. At worst he can be blackmailed out of his deposit, which should be fairly small, and I think it's safe to assume people will be vengeful enough to not want someone to get away with stealing their money (even more so if burned funds go to charity). Thus most blackmails will fail, and since the scammer needs to pay a deposit for each failed attempt, it will not be very profitable. Thus I think this is indeed useful.

@MeniRosenfeld The blackmailer could employ an automated escrow service ensuring the victim that he will do better if he releases the coins to the blackmailer than if he doesn't.

It may be possible to write escrow functionality into Bitcoin through the use of one or more scripts which I believe is how Namecoin implemented its DNS-like features on top of simply forking the block chain. Unfortunately the scripting abilities have been severely limited for security reasons. There is also discussion over whether this should be part of the main client at all or if it's better to be handled by third parties or perhaps additional plugins or applications.
If you'd like to stay up to date on this potential feature, there is a discussion on github about a fork by groffer which is still awaiting approval and could potentially be pulled into the main client. Groffer's mod allows for multi-signature Bitcoin transactions, which essentially means that coins can be placed under the control of multiple accounts at once such that both accounts must agree to (sign) any outgoing transactions. In such a system one party cannot claim the funds without the approval of the other party.
Edit: I also believe that groffer's mod allows for more complex multi-signed transactions such as (a AND b) OR c type transactions where either the two involved parties (a and b) must both sign or a transaction to complete it or it may be completed by a chosen trusted third party (c).

Gavin Andresen, the Bitcoin client technical lead, has said that M-of-N transactions are a priority for the next major release of the Bitcoin client.

Any link to where he said this? I'd love to include it in my answer but I'm kind of a stickler for sources.

He asked about the methods to do this here. I'll try to track down the announcement as well.

I think he backed off a bit and is now working harder to obtain consensus. See here and here. Also, here.

Perhaps we'd best leave this to the comments for the time being now, since we're not really sure if it's a priority for the next release. If he ever obtains consensus we can come back and modify answers then.

Anything is possible. David Zimbeck, created this concept for bitcoin back in 2014
BitHalo.org does this and has been running since 2014. It's an automated two party escrow service. Both parties put a deposit, if either one cheats the deal they lose their funds. Since there is no escrow agent then it's completely impossible to break the contracts and gain from it.
David, is now the lead developer for BitBay.Market you can download the BitBay Client to see for yourself the most advanced version of Halo.
He is nearly complete with his decentralized dynamic peg as well. This will be the most decentralized stablecoin in the industry and it provides the highest potential ROI because it's a soft peg not a hard peg.
Daniel Larimer said it best back in 2014, "All attempts at creating a “stable currency” that neither grows nor falls in value are fundamentally flawed regardless of design because they are built to on a flawed requirement. "
BitBay's dynamic peg is due to be released in Sept/Oct 2018.
This will make BitBay the only cryptocurrency in the industry that has solved both Crypto 1.0 and Crypto 2.0. The former being the ability to remove the middleman from any form of transaction, not just crypto, but goods and services as well. The latter being the ability to stabilize the price of a cryptocurrency so that it can actually be used as a 'currency'.
Whitepapers:
Halo
https://forum.bitbay.market/uploads/default/original/1X/a60c8a2bd0fac863ae0b112be1cd47fea32ff664.pdf
Dynamic Peg
https://bitbay.market/downloads/whitepapers/bitbay-dynamic-peg.pdf

I think multisignature transactions are a good escrow model.
On the surface, this doesn't seem to provide any protection - the seller could just tell the buyer, "I'm taking 90% of the bitcoins. I'll give you 10%. If you refuse, neither of us will get anything." A perfectly rational actor would take that deal - but a human wouldn't, because they'd feel cheated.
So essentially, multisignature escrow will work because humans are vindictive.

It is possible to implement a decentralized Escrow algorithm (to exchange any cryptocurrencies; could be used for example for decentralized trading from wallet to wallet with the aid of escrow) which has the following simple rules:

Parties agree on i) deadline, ii) deposit amounts A and B required from both parties into escrow chain. The Escrow creates wallets for deposits A and B.

The Escrow holds the private keys (in a safe decentralized hacksafe manner) to the deposits until the transaction is completed (or cancelled).

If transfer is successful and Escrow receives full deposits of A and B before deadline, it will "forward" the contents the wallet to the recipient to the given transfer destination wallet addresses. Otherwise, if transfer is unsuccessful (or cancelled by either party), Escrow "returns" the funds back to each of the senders.

Additional features can be added such as "speed reputation statistics", "party A usually deposits in 5 seconds" etc.

After such atomic swaps are implemented, a framework needs to be built where swaps can be combined like on a trading platform and initiated directly from a wallet.


text:
Public mining pool account w private access
I have several systems available that i would like to use to mine to a pool account. The problem is that other people have access to these machines and i dont want them to get my password from the config file, log into my account on the pool server and be able to change the destination of the found coins to their wallet.
What is the best solution for this?
The two that i can think of are if there is a pool that does not require a password to contribute the hashes, or setting up my own pool server that does that but this sounds more complicated.

Update: i understand they could still change the config for each system to point to their pool, but that would be a loss of one system. If they change it at the pool, that would be a loss of all systems.

Pools either don't use a password for mining clients, or they use a password different than the one used to log into the website and change things like the cash out address.
So you don't really need to worry about this happening. Just don't choose the same password for mining and website access, if the pool asks you to choose two passwords.
What could happen though is that they change the mining client config to mine for their pool account instead of yours.
There is also the special case of a pool or two that accept the user name as the cash out address. In those cases someone could change where your coins go simply by changing the user name in the client setup, because the user name and cash out address are in this case the same thing.

To just continue a bit, there are pools like eligius and p2pool which require just the address you want your coins to go to. Most don't check your password, or as states set a unique password for miners versus your main account password What you could do is set up an auto email notification that alerts you whenever amything happens, a restart or highjacking. Simply add in a few lines that send out an email and you're good. Make sure to both encrypt and properly password protect the miner folder


text:
Motivation to run full nodes
I'm sorry if I ask a stupid question. Bitcoin network was conceived by Satoshi Nakamoto as a decentralized network, but now we are seeing the full centralization of nodes in the United States.
The user lacks motivation for hosting the full node as it requires financial costs but it does not pay off.
I have a question. Does the bitcoin network protocol display address when requesting a useragent. Now we can see only the version and ip address. To anyone could donate a certain amount of coins for those who start a full node in the network.
The ideal option proposed by the bitcoin core developer Jeff Garzik  would be to make a commission for that unit is now fully take miners to share with all the owners of the full nodes.
Sorry for my English.

A correction in your question: the article doesn't say it is Garzik who is proposing to reward people who run a full node, it just says it is "an idea that has been floated".

'now we are seeing the full centralization of nodes in the United States.' That's a huge exaggeration.

Incentivising nodes is an issue. But it depends on how that is handled. Are there other duties that a machine running a full node could perform, and, for example, benefit from by the inclusion of a small payment?

From a pragmatic standpoint nodes are an issue in the Bitcoin network. There is a lot of centralisation since CPU mining was traded for ASICs. Personally, I run a node because I want to learn how the network works. There is incentives to run nodes, nonfinancial incentives too, I'm sure.

I'm not sure I understand your question, but: No, Bitcoin nodes do not announce their own Bitcoin addresses as part of the network protocol.
One could imagine modifying the protocol so that they did, but it would raise anonymity concerns: currently, by design, it is difficult to match an address with its owner's IP address.  If you knew at least one address that belonged to a particular node, you  might be able to look at other transactions in the block chain and deduce other addresses belonging to that node.  And ISPs usually have records that determine the identity of a user from their IP address.


text:
bitcoind is not downloading blockchain
I have installed bitcoind on Ubuntu Server. It didn't download a single block
bitcoind getblockcount

This returns 0 everytime I run.
Here is bitcoind getinfo
{
    "version" : 80500,
    "protocolversion" : 70001,
    "walletversion" : 60000,
    "balance" : 0.00000000,
    "blocks" : 0,
    "timeoffset" : 0,
    "connections" : 0,
    "proxy" : "127.0.0.1:9050",
    "difficulty" : 1.00000000,
    "testnet" : false,
    "keypoololdest" : 1385148166,
    "keypoolsize" : 101,
    "paytxfee" : 0.00000000,
    "errors" : ""
}

have removed proxy its downloading now

have removed proxy its downloading now

You can accept your own answer; otherwise this keeps bouncing to the top of the list as "unanswered".


text:
What use are ripples?
In the Ripple system we have two types of currencies - ripples and all other currencies useful for transacting with people in your web of trust. Ripples are the only currency in the system that can be used for paying transaction fees and transactions between any two users even if they are not connected.
With the discrepancy between the supply of ripples and the size of the fees, spamming the system would be virtually free. This usefulness of ripples is thus moot. Trading between any two peers could be accomplished with Bitcoin, so this use is also limited.
So, with that in mind, what use are ripples really, asides being a way for the developers of the system to monetise?

Why do you say that the supply of ripples is so big that the fees can be ignored?

@PeterMichealLacey-Bordeaux With a base transaction fees being 0.00001 XRP (http://bitcoin.stackexchange.com/a/7575/323) and there being 10^11XRP, we have 10^16 units of transactions available. That would be like like charging a satoshi for a Bitcoin transaction. Also, if a bulk of XRP are to be handed out for free, well, you get the picture...

@ThePiachu: The goal is not to make transactions expensive normally. The goal is to have some way to auction off transaction slots if the network is overloaded and to make it impractical for someone to overload the network for long periods of time. The transaction price will increase if the network cannot accommodate the transaction volume. An attacker will have to put more XRP behind every spam transaction than legitimate users are willing to put behind their one legitimate transaction. It's like rationing only when rationing is needed.

As explained in this answer fees are not fixed so I don't think that your conclusion about them being useless for spam protection is true.
Other than that I would say that they can be used similar to how Bitcoin is used. They may be a future competitor to Bitcoin even though they are certainly not marketed that way. They are scarce, easy to transfer etc.

One possibility is that they may form a useful "bridge currency". If there are, say, 100 currencies in use on the system, there may not be enough liquidity between every random pair of currencies, all 4,950 of them. But there may be lots of liquidity from each 100 currencies to and from XRP (only 200 pairs). This makes it very easy to find a starting path that works and the pathfinding algorithm has an easier time finding a good path if it has a working path to start with. It also may make for a more reliable way to easily estimate exchange rates between arbitrary currency pairs.


text:
How does Ripple solve the double-spend problem?
How does the Ripple system solve the double-spend problem? Does it also use some block-chain-like entity that officially dictates which transactions are confirmed and which are not, or does it use some other clever mechanism?

The details are very complex, but the core concept is fairly simple. Ripple solves the double-spend problem by consensus.
The analogy I use is an "agreement room". To walk into the room, you have to agree with everyone who is already in there. If you want to disagree, you have to leave and form your own room. Everyone who is honest wants to get into the biggest room they can with the most people in it.
In the room, people constantly agree on the current state of the system. It's implemented as a hash tree, so that's just one 256-bit number.
To perform a transaction, you walk into the big room and read out the transaction. Everyone checks the transaction against their ledger. Assuming there's no conflicting transaction or other problem, everyone agrees that the transaction is valid and they include it in the set of transactions they believe should be applied.
They then work on any disagreements they have by an avalanche process. Essentially, if someone is voting yes on a transaction that doesn't have overwhelming majority support, they just change their vote to no. This ensures there's a quick agreement on a set of transactions.
Once a set of candidate transactions is agreed upon, those transaction are applied and everyone computes the next ledger according to a set of deterministic rules. They all sign it, publish those signatures, and now clients know which transactions have been accepted by the consensus process.
If a transaction doesn't get in for some reason, but it's still valid, every honest person in the room will say yes to that transaction in the next round.
So, back to the double spend problem. A double spend is essentially two transactions, each of which is valid if and only if it's applied before the other. Thus solving the double spend problem "merely" requires agreeing on an order for the two transactions. If everyone agrees which comes first, the problem is solved -- the one that comes first is applied and thus the other is invalid.
In the Ripple system, if two transactions are a double spend, one of three things can happen:

One transaction will get voted into a consensus set before the other. In this case, that transaction will be in a ledger signed by all the people in the room, forever invalidating the other.
Both get into the same consensus set (this should almost never happen). In this case, a deterministic rule when the consensus set is applied determines which gets into the ledger, forever blocking the other.
Neither gets into a consensus set because neither gets a majority and both transactions are at around 50%. In this case, every node that sees both transactions (which will quickly be the vast majority of nodes) will vote yes on the transaction that wins by a deterministic rule and no on the transaction that loses by that rule. The one that wins by that deterministic rule will get in the consensus set, be applied to the ledger, and forever block the other.

That's a gross oversimplification, but it's inherently fairly complex.

How is this different from Bitcoin, if it is different?

@ColinDean: Bitcoin uses proof of work. The methods are completely different.

Is there any 'cost' to having a vote?  Does each node on the network represent one vote?  If there is not a high cost, is there a risk that an attacker can spam nodes on the network to get more votes?  Thanks for the detailed writeup.

@BrianArmstrong: There is no cost to having a vote. Each server operator chooses who they want to give votes to. See UNL in the Ripple wiki. (Sorry, that entry is a bit out of date, but the concept is correct.)

What is the deterministic rule here?

@Manish: It's actually fairly complicated, but if there are no other complicating factors (such as prior transactions that have to get in before one of the conflicting transactions can or the transactions produce a suboptimal result on their first application), then the one with the lowest transaction ID will get in.

@DavidSchwartz So Ripple nodes also keep a history of all transactions? Btw, in Bitcoin PoW does not solve double-spending. The block chain does. PoW is just a way of securing the block chain from unfair parties.

@StevenRoose Ripple nodes don't need to keep a history of all transactions. They can keep as much or as little history as they like -- it's just needed to provide historical data to clients.

But how can a node vote against a double-spend without keeping a history?

@StevenRoose Ripple has accounts with balances. If I send you $10, that's a double spend if I don't have $10 but it's not a double spend if I have (another) $10. So what you need to prevent a double spend is the current balance, not historical transactions.

Wow, that sounds weird. Maybe I get the concept of making transactions in Ripple wrong. Is it like with Bitcoin, broadcasting a transaction to all nodes? Because if it is, what prevents the receiver of $10 from rebroadcasting that transaction (f.e. when your balance is $50)?

@StevenRoose Every account also has a sequence number. For a transaction to be legal, the sequence number in the transaction must equal the sequence number in the account that performed the transaction. As part of performing the transaction, the account's sequence number is incremented, forever preventing that transaction from being applied again. So, again, you only need the current state of the account and no historical transactions.

The sequence number is neat. Thanks for clearing out. I think it's hard to find good references of the technical workings of Ripple. I used to learn everything about Bitcoin from the paper and the wiki, but last time I checked the Ripple wiki, it was kind of empty and didn't contain technical information.
You guys at O̶p̶e̶n̶C̶o̶i̶n̶ RippleLabs should do a better job with that if you want the community to embrace Ripple!

@David's answer essentially doesn't talk about an attack scenario where the room is full of dishonest nodes. This is essentially what the proof-of-work was designed to fix.
If you get a hold of a lot of IPs (nodes in the Ripple network) you could become a majority in the room. The difference is that it's really easy to get an IP, but extremely hard to prove you work in a proof-of-work system (like Bitcoin's).
For my understanding, Ripple doesn't solve the double-spending problem mathematically, as Bitcoin does (assuming honest nodes are overpowering the network). It solves it using a distributed consensus system that can easily be overthrown if you can obtain the majority of the IPs and you act honestly for a while, making other nodes trust you.
In conclusion double-spending is possible with both Bitcoin and Ripple, but with Bitcoin it's much harder to double-spend because the system is based on a mathematical race against the proof-of-work system, whilst Ripple relies on consensus of a number of nodes that can be more easily reproduced by an attacker.

reason why i'm being downvoted?

IPs and nodes have nothing to do with anything. The algorithm doesn't care how many IPs or nodes you have or don't have. It's based on public keys that human beings have chosen to extend very small amounts of trust to. As for "it's really easy to get an IP, but extremely hard to prove you work in a proof-of-work system", that's basically false. They both take money. What's hard to do is convince other human beings that lots of keys have totally independent ownership when they actually don't.

Sorry but it's still not clear to me. The Ripple system requires trust to certain amount of nodes, right? How easily can trust be faked by a single entity, simply creating a variety of different nodes in the system (sybil attack). Essentially, what if the room is full of dishonest people, and how easy would it be to do this?

This forum isn't really suitable to conversation. If you like, you can post to the Bitcoin forums or the Ripple forums. A single entity can create as many nodes as they want, but they have to actually convince people that the nodes are independent for them to count. Human beings make the decision of which keys to count based on their conviction that the keys are independently administered. There's a discussion of this issue here.

Ok. But simply: why doesn't Bitcoin then use this sort of system if it prevents double-spending without all the electricity waste of mining?

For one thing, this system wasn't known until two years after Bitcoin was made public. Jed McCaleb proposed it as a response to what he perceived as mining's inefficiency.

Do you know of an alt-coin that uses this trust model instead of proof-of-work. I know Ripple is one of course, but I dislike the very corporate nature of it. I'll keep an eye on the "trust" topic as it's very interesting. Also my point was raised by other several members on that topic as well (https://bitcointalk.org/index.php?topic=10193.msg146301#msg146301) so I'm not completely out of the line here.

@LucaMatteis Ripple is based on openness and trust unlike bitcoin. You chose specifically which nodes you want to trust unlike bitcoin. This will be individuals, business etc who can prove who they are. Nobody is going to trust some random unknown bunch of nodes. A ripple node isn't an IP but more like a public key. So my impression is that this is more like how security works in PGP. In PGP you typically verify the identity of someone physically or through signatures by people you already trust.


text:
Authoritative list of Bitcoin resources?
Has any website compiled a reasonably authoritative and trustworthy list of Bitcoin resources? I'm building an appendix for my course and I'd like to see if I missed anything.
https://www.udemy.com/bitcoin-or-how-i-learned-to-stop-worrying-and-love-crypto/
Edit:
To address Nick's concerns, let me clarify the purpose of this question. I am not asking for your favorite Bitcoin links. I am asking for authoritative and trustworthy lists of Bitcoin resources. For example: https://www.spendbitcoins.com/places/ is a reasonably trustworthy list of bitcoin commerce sites.

Why is this downvoted? It's a legitimate question to ask if someone created a Bitcoin link bank? The Bitcoin wiki has a link bank. Should we downvote their efforts?

Because this essentially asking, 'What links do you thing are good' which will provoke discussion.

I'm asking for link banks. I.e. lists people have compiled containing links relevant to the Bitcoin

Okay, so you're asking for links to links. How is that better?

Links to websites that have taken the time to vet and organize links. And yes it is better because I'm building an appendix with them after I take the time to vet them myself.

And did you get that interview I sent you?

@CharlesHoskinson I changed the language a bit to make answers a matter of fact rather than opinion.  Personally I'm voting to leave this open--this is an important, factual question with value for future users based on a real-world need.

And thanks for the edit. I'll be offering a bounty on this one soon.

@CharlesHoskinson I'm sorry if you feel that  I have something against you personally. If you'd like to discuss a way I could moderate that'd be less abrasive, you can email me or open a chat room with me.

Oh Nick, you know I'm just giving you a hard time. I'm too lovable to hate :)

Mods should at least post a comment after downvoting instead of forcing users to ask why the downvote. This is the only SE site where people get randomly downvoted without having any clue why.

Nick and I have a unique relationship. It's ok. This community has lots of interesting and lovable personalities. And I will shamelessly promote my course: https://www.udemy.com/bitcoin-or-how-i-learned-to-stop-worrying-and-love-crypto/

There are four really authoritative places for Bitcoin-related information that I can think of.

The Bitcoin.org homepage, which is managed by the core Bitcoin developers. All names listed on that site and references made can be considered authoritative.
BitcoinTalk.org, this was the homepage for the Bitcoin community from the start. Most of the first ideas were created here and still this is the best place to get information from other authoritative people strongly related to Bitcoin.
The Bitcoin Wiki, were you can find all technical specifications of the protocol as well as more basic information about how to buy, sell or use bitcoins. The wiki is maintained by the developers as well as insiders that helped shaping the protocol.
Bitcoin on GitHub, were development of the main client happens and all changes to the protocol are implemented for the first time. You can also find a link to this place on the Bitcoin homepage.

The most comprehensive list I have come across is Stuff Exists. I have not personally checked each link but it will give a good basis on where to pull a list of sites from.

This one is a good resource, and trusted http://bitcoin.bitshare.cm

Your answer offers only one addition instead of creating an encompassing answer. It would be better if you created a complete up-to-date answer that also added the resources linked in older answers that are still relevant and any other new ones that have cropped up in the last half year. As it is, it looks like promotion of a specific service that you might be affiliated with.

I would suggest https://github.com/coinpride/CryptoList
It is the most advanced crypto links list because it is opensourced and thus contains only the freshest links.