text:
0 connections now, but I had been using Bitcoin QT for a while without problems
I had been using my Bitcoin client for months on my Windows computer running XP.
One day, I have trouble connecting to anything else on the internet, but my Bitcoin client seems to be running okay. When I restart my computer, my internet eventually comes back, but I've had "0 connections" to the Bitcoin network for the past 2 weeks since.
I tried sending a test payment, and that payment was deducted from my wallet, but it never got broadcast. I figure it will get out once I finally figure out my connection issues.
I have my wallet backed up on a flash drive, but loading up that wallet data did nothing to help me establish network connections.
I am NOT stuck syncing. I'm just not connected or syncing at all. Everything else on my computer is otherwise running fine.

What is the best address and port to connect to? Are there good backup options?
If all of my addresses are correct, how do I figure out why I have 0 connections to the Bitcoin network, and how can I either reset those connections or otherwise get up and running again?

By using process of elimination , I would do something like this.
First, I would reinstall your Bitcoin wallet and see if it works. If it works properly, there was probably a Bitcoind configuration file that was messed around with in your original installation or you were using an outdated version.
If it still doesn't work, install a Bitcoin wallet on another computer on your network and see if it works. If it works, than probably there was something wrong with the Windows configuration (maybe firewall or antivirus program is blocking access). If it doesn't work, there is something wrong with your network (may be problem in your router, or internet provider)
On a side note, I wouldn't recommend running a wallet on Windows XP if you plan to keep any Bitcoins on it, due to it being incredibly insecure since Windows stopped supporting it.

You can set the addnode=IP-OF-A-NODE in the bitcoin.conf file, you can get nodes from https://blockchain.info/hub-nodes .
To solve your issue first make sure that you firewall and pc config is correct to be sure that the issue is related to the bitcoin client.

link leads to an empty page.

The page is not empty. It seems the database connection on this page is temporarily down,

If you choose to define empty as 404 or zero bytes, yes you are correct it is not actually empty. However, I was trying to solve a problem, and from that perspective the semantic difference is entirely irrelevant. Given that the table is still empty days later, It's looking very much like it's a dead page (the stealthy evil twin of a "dead link").

May i hint you the post was from february 2014, thx for downvoting anyways. My guess is blockchain.com disabled the page for security concerns. May contact them directly for clarification.

I did not downvote.

This is a weird problem. I have seen it cut you off if you don't have IPv6 and the IPv4 to IPv6 virtual bridge (a service) running in the background, even if you don't have an IPv6 router nor IP and subnet address listed in your modem.
Also, if you're using Bitcoin-Qt, make sure you have the most recent version of the wallet and Pooler's CPU miner (minerd) installed, that can cause a problem too.
What I suggest doing is contacting the pool owner and find out if there is a problem with a said port and protcol, many people use Scrypt algorithm and not SHA256D anymore (unless you use ASICs) and they don't use the GETWORK protocol and port, they use the Stratum+TCP, which is default by many sites now.
This might be your problem.
Turn off or unplug your router and modem.
Drop to DOS and key this in at the prompt and hit ENTER.
ipconfig /flushdns
Plug in your modem first and wait for it to initialize and connect to the Internet.
Plug in your router and let it do it's thing and when it's up and running, type this at the command prompt and hit ENTER when done.
ipconfig /renew
After that's done type in the following and hit ENTER.
ipconfig /all
That will give you all your connection related data for a renewed adapter and cleared DNS cache.
Sometimes the cache can get old and not have the correct routing information in it which can load to "Destination is not reachable" or similar messages, like the JSON errors in the minerd.exe and ultimately Bitcoin Qt wallet with integrated mining option.
There are quite a few things that can trip this up, perhaps this will solve it for you.


text:
What percentage of bitcoins are being traded/used on a regular basis?
Clearly a lot of BTC are being hoarded by either early adopters, or small scale speculators like myself, holding out to see what it's value is in 10 or so years.
What percentage of bitcoins are actually changing hands of a regular basis?

As of October 2012, it was determined that around 78% of all bitcoins minted (as of May 13 2012) were being hoarded "in user accounts that have never participated in outgoing transactions", meaning that all other trading and commerce was actually being transacted with a "float" of the remaining 22% (i.e. less than 1 in 4); and there is really no way of knowing how much of THAT might simply be faux-"trades" between accounts owned by the same entity.
Certainly very little of the total float (and thus even less of the total "coinage") is actually being used as a "currency" to make purchases.

There's no real way to know but in the last 30 days, about 5,000,000 BTC were traded among all the exchanges that are reporting. You can also see how that breaks down by exchange according to this chart: http://bitcoincharts.com/charts/volumepie/

source: Stack Exchange

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

sort: votes


text:
Are Ripple IOUs e-Money under European law?
It has been confirmed by multiple sources that Bitcoin is not electronic money according to EU Directive 2009/110/EC, mainly because it does not represent "a claim on the issuer" and does not have a "face value". Ripple IOUs however do seem to fit the definition, especially if they are denominated in government currencies. According to many national implementations of the directive, only licensed institutions are allowed to issue electronic money.
Is there any legal investigation on that matter or some expert opinion regarding whether Ripple IOUs are in fact bound by electronic money regulations in the EU?

Another interesting aspect to this is that not all IOUs are for government currencies. Some are for Bitcoin, and some are for even more obscure "currencies" like Goodwill: https://ripple.com/forum/viewtopic.php?t=2895.

This all depends on what asset the IOU represents and by extension what it can be used for.
If in the case of USD or EUR etc they are accepted for payment of goods or services by a third party who is not the issuer then they are e-money.
In this case the issuer has to be either authorized or registered as an Electronic Money Institution (EMI).
The key difference between this and a deposit account is that no benefit can be given for holding on to the e-money over time such as interest.
They are redeemable for face value minus any reasonable charges.
Ripple IOUs can also be for bitcoins for example. However since they are not considered legal tender - you cannot pay your taxes in bitcoins for example, they are considered barter or the same as gold. These IOUs are not e-money.
If I were to issue Ripple beer IOUs which could be exchanged in any pub worldwide for a beer these would still not be e-money if they were only exchanged for beer since this is a closed market. I could not use my $50 worth of beer IOUs to buy a book for example. If book stores and other establishments started accepting them at face value then they would become e-money USD.
The UK FCS does a good job of explaining
http://www.fca.org.uk/firms/firm-types/emoney-institutions

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


text:
What is the meaning of the Bitcoin address version?
Bitcoin address versions are described on the Address wiki page:

Normal addresses currently always start with 1, though this might change in a future version. Testnet addresses usually start with m or n.

The Protocol specification gives a bit more technical detail:

Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111

Aside from distinguishing real and testnet addresses, what is the meaning and purpose of the address version? How and why will it change in future?

Last time I heard of it, the future of version bytes was still unsettled.
Currently, they are used to force incompatibilities between several base58-encoded data structures:

addresses / private keys
testnet / realnet
alternative-chains variants (namecoin etc…)

This way, you cannot misuse one for the other.
Someday, it might also be used as a real version number (the current SHA-256 + RIPEMD-160 + base58-encoding for keys could become obsolete).


text:
Which bitcoin client distribution to use on a secure pen drive?
I have just purchased an Ironkey. Which version of bitcoin client can run without needing installation or download of the blockchain? One which may connect to a server to access blockchain info?
So essentially I can plug it in anywhere and send money direct from the secure drive.

You can run MultiBit on a pen drive in a portable manner if you include Java runtime environments (JREs) for the operating systems you are interested in.  By including a JRE on the pen drive you can be sure it will run on the target computer.  MultiBit runs on Windows, Mac and Linux.
There is some help on how to set up MultiBit on a pen drive here : http://multibit.org/help_runFromUSBDrive.html
You can create a shell script / bat file with the single line: 'local-path-to-jre/java -jar multibit-exe.jar' to start it up using your included JRE.  (Note that Macs are guaranteed to have Java installed so you do not need to supply a JRE for that platform.)
There is a detailed tutorial on how to install a JRE here: http://www.dreamincode.net/forums/topic/42544-putting-java-on-your-flash-drive/
You can store your MultiBit wallets on your pen drive.   By default the path to the wallets is stored in the MultiBit config file multibit.properties as an absolute path (i.e. with a drive letter/ name).   I think you can tweak this to put in a relative path which would then open automatically on any computer.   Alternatively you can just go to the 'Your Wallets' screen and press the 'Open Wallet' button to open it manually.
Strictly speaking MultiBit does keep a local copy of the blockchain but it is the bitcoinj block chain so is less than 20 megabytes.

For now, there two lightweight client that can possibly solve your problem - Electrum and MultiBit.
You can always try an eWallet for holding small amount of coins, and run a normal Bitcoin client at home.


text:
Is an exchange a good substitute for a mixing service?
Isn't an exchange such as MtGox essentially a mixing service? I might be wrong, but can somebody trace coins when they are paid to one address, possibly exchanged, and another amount is paid back from another exchange address back to you? As long as you don't pay back the coins to the same address, and amount is not exactly the same, can this even be traced through blockchain?

And when Mt. Gox is subpoena'd for its logs, what might those logs reveal?

Of course, you're right, we don't know how long are logs kept. And obviously if you're verified with MtGox you're not anonymous. But I'm interested in how a blockchain and mixing services work, and want to verify if I'm right in conclusion that they essentially do the same thing.

Well, "mixing" can be seen as different things. At it simplest, every transaction mixes up your coins a little, especially when you split or combine them. However, what makes a "mixing service" is somehow more specialised.
So, there are several differences with exchanges:

Mixing services usually have a static pile of coins, distributed over a big web of addresses. When you want to mix your coins, the mixing service can do it instantly by distributing your coins into his web transferring them to both new and existing addresses and meanwhile transfer an equal amount of coins to a new address for you by combining small parts from his web. The difference here is that you do not rely on another 3th party that also wants to mix/trade, as you do with an exchange.
Most mixing services have a fixed fee that you pay in Bitcoin. Exchanges may as well have fixed trading fees, there is another cost to consider. You will have to both make a sell order and a buy order to "mix" your coins using an exchange. Even if you make both orders instantly after each other, you will probably lose more than twice the trading fee. This is because there is always a price difference between the lowest buying price and the highest selling price. Furthermore, if you make the trades while the price is raising, it will probably cost you even more.
As Stephen Gornick already mentioned, exchanges keep logs. They usually also require you to verify your identity and this information will be bound to the logs, making the mix all but anonymous. Most mixing services do not require you to have an account at all, they just give you a sending address and ask for a receiving address to which you want your funds back.

As a final note, I want to add that with a good implemented mixing service, the user base of the mixers does not really matter. A good mixer will always have a static web that can be used for each new mix by adding your coins into it and at the same time, picking some random others to combine to an equal output. As long as this static web is big enough, the mixing will be very hard to trace.
There is one thing that could make you vulnerable for trackers. If the mixing service works instantly, the trackers could search for a new address receiving just the same amount as the amount you just spent. This is not hard to do. So, another feature that would make a good mixer, would be the option to give multiple receiving addresses and not executing mixes instantly, but taking a few minutes between funding the different addresses. Note that this can be in favor of an exchange, by which the actual mix is not logged in the block chain, so trackers need to have access to the logs of the exchange to track you.


text:
How do you know how much a product costs in Bitcoins?
When paying with Bitcoins how does that affect the price of the service or item? For example If I buy something that costs 20 CAD using Bitcoins and the exchange rate is 1 CAD = 0.01 BTC does that simply mean I pay 0.20 BTC? I'm not very knowledgeable about currency exchange to begin with. If the value of the Canadian dollar goes up and 1 CAD = 0.02 BTC then I would've lost money if I had did the exchange at the lower rate, is that right?
Take Privateinternetaccess for example. They have an option to pay in Bitcoins but doesn't say how much?

Most websites that accept bitcoins for goods or services work with a service that automatically exchanges the bitcoins they receive for dollars. For that reason, they also use the current exchange rate to calculate the price in Bitcoin.
So basically, when you want to buy a 10 CAD item for bitcoins, the website will calculate how much bitcoins that is and ask you to pay that amount of bitcoins.
And yes, when you hold bitcoins, the price you pay in CAD can vary as the CAD/BTC rate changes.


text:
How do payment processing companies work?
What is the rationale for existence of payment companies like BitPay? If I want to start accepting Bitcoin at my store I can simply set up my own Bitcoin wallet for free and then a simple script which counts Bitcoin price after checkout depending on current exchange rate. So what is the extra value these guys bring to the system?

Further to @StevenRoose's answer, if you price your goods or services in a non-Bitcoin currency (eg USD), then it's not necessarily a simple matter of looking at a single exchange's  best Buy offer to obtain the exchange rate for a transaction.
For example, let's say the customer wants to purchase a US$1000 item, and the best Buy offer on the MtGox exchange is $980 and the best Sell offer is $1010. If the customer became aware the retailer was using the $980 exchange rate, then they could put a $1000 Buy offer on MtGox to improve the exchange rate they get for the transaction, then (perhaps using an automated script to reduce time delay) make their Bitcoin payment to the retailer and immediately withdraw the Buy offer from MtGox, thus saving themselves $20.
BitPay uses a number of exchanges to calculate its exchange rate, and it's possible (I don't know) that they may also apply a safety factor to avoid manipulation, or factor in the cost of withdrawals (for exchanges that charge a fee).

Currently still, most companies want to receive in fiat currency. Most of these merchant payment companies function as a man-in-the-middle, so that you don't have to be concerned about anything Bitcoin-related.
They provide functionality with which your customers can purchase goods using Bitcoin and you will receive all payments in your fiat currency of choice (as long as it's supported by the merchant service).
Like with PayPal, when a users wants to pay with Bitcoin in your site, they will get forwarded to a page from, f.e., BitPay. The user will pay in Bitcoins to BitPay and be forwarded back to your site while you will be notified that the users did indeed pay. Meanwhile, BitPay adds the payment amount to your merchant account, in fiat currency, using the exchange rate of that moment.
Given the high volatility of the Bitcoin exchange rate, this is the best solution for most merchants for now. It's easy and safe.

So the companies basically carry the risk of volatility during the payment. Do we know how they handle it? In a bullish market this does not mind since you get more in the end, but bearish one is worse probably...

I guess most of them just sell the coins immediately at some exchange. I think I once read that BitPay keeps a large chunk of the Bitcoins they receive. If they did so the last few months, they were all millionaires by now. (Which I think they are anyway.)

Yes but are they able to sell coins fast? They'd have to run their own exchange to be able to do this. Maybe they have an agreement with one of the big exchanges so they do not need many confirmations when transfering funds there for selling. Of course they could use an exchange as a wallet directly too.

I think they might have special agreements with exchanges indeed. Otherwise it would be unfeasible. They will probably also always have a bitcoin balance at the exchange, trading instantly while the new coins are being transferred into the exchange.

Also, they are free to charge their clients just the trading fee they can get at their exchange partners.


text:
Is there a command I can type into Bitcoin-Qt to see the total number of bitcoins that have been created?
I know how to obtain this information from other means, I specifically want to know if it's possible for me to obtain this information using the Bitcoin-Qt client alone.
I am running it on Windows Vista and I don't have a miner set up.
Thanks.

The amount of bitcoins created is a simple function of the amount of blocks times the bitcoins per block. It seems rather pointless to make a command for that, if we already have a command that shows the block count.

Well, if you want it really accurately, you need to take unclaimed fees and duplicate coinbase transactions into account. The actual total sum of values of all unspent transaction outputs is 11105964.80381183 (as of block 234244).

@PieterWuille He askes "that have been created", not "that are in circulation".

You can calculate the total amount of when you know the last block in the block chain. You can check the number of block by holding your mouse on the icon in the lower right corner of the Bitcoin-Qt client.
Then you will need to use this table to calculate the total amount of bitcoins there exist. This table just lists up the block rewards, which halves every 210,000 blocks and starts at 50 BTC.
Currently you can easily add the 10,500,000 BTC from the first 210,000 blocks with 25 times the current block count minus 210,000.
If you want to have an implementation that you can use forever, it would look like this (I used Python):
def total_bitcoins(current_block_count):
    count = current_block_count
    reward = 5000000000 # satoshi
    total = 0
    while count > 0:
        total += min(count, 210000) * reward
        count -= 210000
        reward /= 2
    return total / 100000000.0

Note that this process limits the total amount of bitcoins that will ever be created to 20,999,999.9769.

It gives an error here: prog.go:12: constant 5000000000 overflows int

Golang implementation, updated version (seems the cloud instances aren't always 64-bit) http://play.golang.org/p/NfkefjHLED

Thanks. Where do the values in the table that you linked to come from? Also, from where is the code that you pasted above?  Is it in the bitcoin core?


text:
Could a mining pool attack Satoshi Dice?
Is it possibile for a mining pool to attack Satoshi Dice? A strategy might be: bet on Satoshi Dice and if the bet wins, do nothing, if it looses, don't put the transaction in the block (try to double spend) and hope, that the pool find the block. If the hash rate of the pool is big enough this should beat the house edge of Satoshi? Did I miss something?

You're absolutely correct. The following would completely work:

Get ready to perform a Finney attack.
Gamble some coins.
If you lose, go through with the Finney attack. Otherwise, cancel your Finney attack, and collect your 1250 BTC from satoshidice.

Is anybody doing this? I don't know.

SatoshiDICE makes the returning transaction depend on the incoming one, so any attack which makes a transaction not be in the blockchain won't work. (The returning transaction can't be included until the one to SatoshiDice is)

@lurfjurv Which is precisely why you don't perform the Finney attack if your bet succeeds.

Oh! I thought you were talking about something totally different. My mistake. You're just cancelling the transaction to SatoshiDICE if the bet fails. Ok, that'll work.

Would doing this be profitable? http://bitcoin.stackexchange.com/questions/8402/can-a-finney-attack-make-satoshidice-betting-profitable

@lurfjurv I don't see how that question is different from the one asked on this page.

This is asking if it's possible. I'm asking if it would be profitable, or how much mining power would be needed for it to be profitable.

It could be profitable depending on how much it costs you to write the patch for double-spending SatoshiDice. 2) There isn't a critical mass of mining power.


text:
How can you operate a fractional reserve e-wallet?
There are topics about the possibility of e-wallet providers operating like fractional reserve  banking. How it can be done in theory and practice? Did it ever happen on any meaningful way in Bitcoin's short history?
Edit: does this practice involve any real lending of bitcoins just like the case with real banking:
Edit 2: is it a prerequisite for e-wallet operators that they store all clients' funds on a shared bitcoin address or is it only an added benefit for them?

Not sure why this was downvoted; this is a great question! I've voted it back up to 0.

It is pretty simple. Persons A, B, and C store 10 BTC each with you, so you have 30BTC. You figure on any day you need 10BTC handy for all of the transactions of ABC. That leaves you with 20BTC to spend, and assuming they all don't come asking for it at the same time, you are fine.
When doing this, you need them to send you the BTC, and you keep a record of their account in a database. Transactions between them just update their db records (not the blockchain). Only when they withdraw or pay out to someone not in your system do you need to spend the money in your reserves.
Looking at mtgox, they could easily do this; the record of the coins that are yours is not what is in some address, but just what is in their db. Since they hold a huge amount of coins for a huge amount of users, it is unlikely that all of their coins will ever be withdrawn. In fact, many users may be dead or no longer interested in bitcoin or simply forgot their login. All of the bitcoins belonging to those users in essence will never be withdrawn, and mtgox can get away with spending them without worry. Using login statistics (which I am sure they have) they can probably make a guesstimate about the amount of their reserves will never be collected, and so they can spend at will.
I am not saying that mtgox is engaging in this (heck they probably make more money off of fees), but it would be so simple and totally invisible to anyone who cares.
Frational reserve banking is super easy and it just relies on a lack of transparency in addresses assigned to users with actual btc in them.
Interestingly this can make it so there are in some ways more bitcoins in circulation than in existence, as trading with db bitcoins is basically equivalent to real ones.

I edited my question. Let's say no user died, forgot their passwords or not interested in bitcoin any more. So the operator is still owing BTC 30, even if he has on hand only 10. The question is did he really spend the other 20? Or perhaps lent it out like real bankers fractional reserve? Yeah, there are some bitcoin lending operations out there but I guess it's still minor or murky.

Edited my post again: is it a prerequisite for e-wallet operators that they store all clients' funds on a shared bitcoin address or is it only an added benefit for them?


text:
Implement website payment solution
I want to implement a bitcoin paying system to my website. I came up with this http://bitfreak.info/?page=tools&t=bitsci but I am unable to understand how it's working.
I looked up into the sourcecode but I don't get where I can get the bitcoins after the user has paid. The term WIF is used a lot; what is that?
Is there any simpler solution? I don't want to use a third-party service

If you want to create your own implementation using the Bitcoin Client, you ought to look into Accounts. This concept would allow you to have complete control over your users' payments, but it would also mean that you have to implement your own solution that would be communicating with Bitcoind.
There is also a more complete solution from StrongCoin in PHP, but I have no experience with it.

WIF stands for Wallet Import Format, which is a string of text that can be converted to a private key. More info here too.
You should be able to import the private key into your Bitcoin client, though I'm not 100% sure whether it accepts WIF format.

The MultiBit Merchant project provides a demonstration of how to use the BitCoinJ library to accept payments using Java. At the time of writing, the source code can be found here: https://github.com/gary-rowe/MultiBitMerchant
If you want more detail about how to get started let me know.


text:
View market depth/ orders on mtgox?
Excuse me if this is a stupid question, but does mtgox have an option to see market depth? The trading page allows me to set a price, but without know the current levels of bid/asks how can I make a judgement about what price to set?
Cryptoxchange seems to display this information on its trading page, but I can't seem to find it on mtgox.

Doesn't http://mtgoxlive.com/ show the market depth?

I can't seem to find it either, I'm pretty sure that they used to show it. The market depth is available in their API though and if you want something a bit more user friendly it is also available on Bitcoin Charts.

for the reports you have:
mtgoxlive.com/orders
bitcoincharts.com/markets/mtgoxUSD_depth.html
for the source data you have:
en.bitcoin.it/wiki/MtGox/API/HTTP/v0#0.2FgetDepth.php (truncated)
en.bitcoin.it/wiki/MtGox/API/HTTP/v1#Full_Depth (full)
Related thread on bitcointalk: https://bitcointalk.org/index.php?topic=194868.msg2023904#msg2023904

Try http://classic.mtgox.com   --> trade data  --> market depth
you do not have to log in

There is also mtgoxlive.com/orders, but they have had some trouble lately. I have also recently discovered http://bitcoin.clarkmoody.com/ which is nice, but lacks the nice display of order depth

authors: uı6ʎɹnɯ ꞁəıuɐp


text:
Support sending bitcoins using webpage URL?
Are there any Bitcoin clients or services that support sending bitcoins to a HTTP(S) URL instead of having to enter a Bitcoin address directly? (e.g. for donations)

Webmasters could include their Bitcoin address in a link element in each page (same for the whole site or different for each page, e.g. to account which page generated which donation):
<link rel="payment" href="bitcoin:…" title="Donate bitcoins, if my article was of help to you">

The href attribute should contain the Bitcoin address, using the bitcoin URI scheme.
The rel attribute should have the value payment. It’s defined as:

RelPayment is a microformat for making exchanges of support (be it financial or otherwise) possible. By adding rel="payment" to a hyperlink a page indicates that the destination of that hyperlink provides a way to show or give support for the current page. For example to give financial support to the owner of the current page.

The (optional) title attribute could contain a small note, e.g. what the donations are used for, or who exactly would be the receiver etc.

Tools (Bitcoin clients/services, browser add-ons etc.) could extract the Bitcoin address by looking for a link with the link type payment whose URI uses the scheme bitcoin.
If one enters a webpage URL that hasn’t linked a Bitcoin address, the tool should throw an error. For security reasons probably only link elements should be parsed (instead of a/area), otherwise e.g. commentators could include their own Bitcoin addresses.

These things should probably be implemented by browsers, not by clients.

You could create a browser extension yourself that allows you to donate to the current page (when it supports it).

@e-sushi: It’s not a duplicate. A Bitcoin URI scheme is for representing a Bitcoin address as URI, while this question is about using HTTP URIs to send Bitcoin (which could make use of a Bitcoin URI specified on the HTML page).

@unor Woops, my bad… didn’t notice that what you’ve asked about was looking for something going the other way around. Removed my “dupe” comment accordingly.

@asterisk: My reply to e-sushi’s comment above is about the same question: I don’t think it’s a duplicate.

The client Electrum seems to support something like that (using a different method): Aliases:

Aliases may be server names (e.g. ecdsa.org) or email-like addresses (e.g. john.doe@ecdsa.org)
The corresponding Bitcoin address is retrieved by the client, using a descriptor located at a canonical url.
Aliases may be entered in the Electrum client, or used in Bitcoin URIs […]

Armory already supports donating with a syntax like this.  The syntax is as follows:
bitcoin:1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv?amount=1.0&label=Armory%20Developers&message=Donation%20to%20Armory

See https://bitcoinarmory.com/ for the reference of where I got this from, it's at the bottom of the page before the QR code.
That's just an http link where it is using bitcoin: as a prefix similar to how email links are setup, it has the bitcoin amount, the label, and the the address all pretty clearly labeled here.

You haven't addressed the question, you've just re-stated http://bitcoin.stackexchange.com/questions/4987/bitcoin-url-scheme as already included and linked to in the question.

OP is looking for  services that support sending bitcoins to a HTTP(S) URL instead of having to enter a Bitcoin address directly, So, your answer is rather useless.


text:
What's the easiest way to someone to double-spend 0-confirmation transactions?
I heard there is a desktop app today that 'easily double spends 0-conf tx'. Which is it? Is anyone working on a mobile version of this app?

Peter Todd wrote [Replace-By-Fee Tools](https://github.com/petertodd/replace-by-fee-tools
)

Basic usage:
./double-spend.py <address> <amount>
Creates two transactions in succession. The first pays the specified
  amount to the specified address. The second double-spends that
  transaction with a transaction with higher fees, paying only the
  change address. In addition you can optionally specify that the first
  transaction additional OP-RETURN, multisig, and "blacklisted" address
  outputs. Some miners won't accept transactions with these output
  types; those miners will accept the second double-spend transaction,
  helping you achieve a succesful double-spend.

Just to clarify in case this is scaring anyone.. this isn't a tool to successfully make a double-spend. This is just a trick/hack that manages in some occasions to get 2 transactions mined that both use the same source coins. One of those transactions will ultimately fail as the miners and block chain come to a consensus. It's easy to detect that this is being attempted but it could fool a human user briefly so if you're buying coins for cash then just wait a couple of minutes!

@George AFAIK this fools the current Bitpay implementation / some other payment processors that accept 0-conf transactions.

It probably does, or at least temporarily. If you're buying downloadable content you might just get away with it if you're lucky enough for the trick to work in your favour, but if you're ordering a physical product I'm sure BitPay et al have a system in place to prevent fraud.

I strongly doubt if this would work at all. You say you "have heard", just rumours or did you ever see such a thing in action?
Remember, quite some people benefit from spreading FUD like this about Bitcoin.
Many merchants and point of sale Bitcoin acceptants use zero confirmation payments, I've never ever seen or heard of a single case of double-spending.
I guess what such a hypothetical app would do, is send a payment to the node of the receiver, send a conflicting payment to a lot of other nodes almost at the same time, and hope the 2nd one ends up in the blockchain in favor of the 1st.
This is very easily taken care of with various 'payment probability' algorithms, e.g. by checking on several other nodes throughout the Bitcoin network if a conflicting tx appears. If not, then within 2-3 sec the payment propagation will be virtually 100% and any conflicting tx (to perform the double-spend) won't stand a chance. At least not through default nodes, which is like >95% of the network and probably >99.999% of the miners (where it counts).

Nonsense. You need the private key to send coins from an address, only the owner of that key can attempt to spend the same coins twice.

Oh, I assumed with a supposed 'double spend app' he meant something that can setup, sign and broadcast transactions itself, thus having the private key. But yes, of course, an app to just double spend any 0-conf transaction is utter nonsense.

Reading it again you might be right. Either way it doesn't exist because almost instantly the double-spend will be detected and within a few blocks all but one of the transactions will be rejected.

You mean within a few seconds, right? ;)


text:
What are the different prefixes of Bitcoin addresses?
Until today, I thought all addresses must start with 1.
Well, behold 3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk, which is a multi-sig escrow address created to hold the bounty for the development of CoinJoin. This is both the first address I observed that doesn't start with 1, and the first multi-sig address that I've seen in the wild.
Are there other possible prefixes? What characterizes the different prefixes? (E.g. are all addresses that start with a 3 multisig addresses? Are there multisig addresses that do not start with a 3?)

According to the glossary
the possible prefixes for bitcoin addresses are 1,3 or 5:
I'm quoting here:

Address
Bitcoin address is a Base58Check representation of a Hash160 of a
  public key with a version byte 0x00 which maps to a prefix "1".
  Typically represented as text (ex. 1CBtcGivXmHQ8ZqdPgeMfcpQNJrqTrSAcG)
  or as a QR code.
A variant of an address is P2SH address: a hash of a spending script
  with a version byte 0x05 which maps to a prefix "3" (ex.
  3NukJ6fYZJ5Kk8bPjycAnruZkE5Q7UW7i8).
Another variant of an address is not a hash, but a raw private key
  representation (e.g.
  5KQntKuhYWSRXNqp2yhdXzjekYAR7US3MT1715Mbv5CyUKV6hVe). It is rarely
  used, only for importing/exporting private keys or printing them on
  paper wallets.

1 and 3 are currently the only defined prefixes for an base58 encoded address.
1 is most common and denotes a simple "pay-to-PubKey" transaction. This transaction shows an actual recipient address.
3 indicates a "pay-to-script-hash" address that contains a hash (one way fingerprint) of a script that can be used for multiple things including address obfuscation and multi-signature requirements. This script is required to be a valid bitcoin transaction script, but the full script behind the scenes is not public, just the hash.
More information here:
https://en.bitcoin.it/wiki/BIP_0016
More info on the base58 implementation used:
https://en.bitcoin.it/wiki/Base58Check_encoding

The odd prefix comes from a different magic byte used to generate this address. 05 in this case for a script address. Magic bytes are used for different purposes, like indicating the network. Bitcoins private key byte is 0x80, or 128. (testnet is 6F, litecoin has 48, giving L..)
You can find a list here: https://en.bitcoin.it/wiki/List_of_address_prefixes
Usually they're defined in the chainparams.cpp  https://github.com/bitcoin/bitcoin/blob/2068f089c8b7b90eb4557d3f67ea0f0ed2059a23/src/chainparams.cpp#L129 for bitcoin and related networks, except in really old versions

Here is a comprehensive list of key formats: https://en.bitcoin.it/wiki/List_of_address_prefixes. Technically, most of these are not addresses, but this seems to be in line with @Assaf Shomer's answer, which mentions raw private keys.

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


text:
What is a block withholding attack?
How can a block withholding attack be performed, what would be its purpose and who is it a danger to?
Edit: when I posted this I was thinking about withholding a block you mined in a pool. But withholding blocks can form the basis for many different attacks. I think this is still useful as a broad question. It is a central concept in bitcoin security.

Related: http://bitcoin.stackexchange.com/q/1338/516 (duplicate?)

There are two types of block withholding attacks.  One, known as the Finney Attack, aims for financial gain when a double spend occurs.  The second is to cause financial harm to a pool operator.  A miner that solves a block can withhold a valid hash after finding one.  The cost to the miner is trivial (from not being awarded the share) but the cost to the pool is large as the pool loses a chance to earn the 50 BTC block award subsidy.

Unless the pool is PPS, the cost to the attacker is not trivial as he is one of the participants who would be given some of the block reward. Also there is a for-profit block withholding attack against mining pools, lie-in-wait.

If you're doing that attack why would you even have to do the hashing to begin with. Can't you just tell the pool you're doing work and hope you're assigned the correct value

Remember when 50btc was the reward...DAYUMMM

The simplest form of it called Finney attack, named for Hal Finney who first described it. The attack is variation of a double-spend attack involving accepting 0-confirmation transactions.
An attacker would generate a valid block but will not broadcast it, and then broadcast transaction A as a payment for a good or service. A merchant will see transaction A with nothing conflicting with it and accept the 0-confirmation transaction. Right after that the attacker would broadcast the generated block with transaction B which will conflict with transaction A, the Bitcoin network will accept his block and invalidate transaction A.
The attack is quite costly because there is a time gap between generation of the block by the attacker and completing transaction A, during which someone else on the network could generate a valid block and broadcast it, thus invalidating the valid block generated by attacker. Therefore it is practical only if the merchant sells the product online and it could be release immediately, e.g. a key for a software product.
A general form of this attack was described by Satoshi Nakamoto: White Paper, section 11. In theory, an attacker could pre-generate any number of blocks, e.g. if a merchant requires 1 confirmation before releasing a product an attacker would pre-generate 2 blocks ahead of the network and only then broadcast transaction A to double spend. But with each block the cost increases exponentially, and the practice of accepting 6 confirmations before releasing the purchase makes this attack possible only in case where the attacker has close to 50% of network hash rate or more.

“who first described it”… And what is section 11 of the white paper all about?

@Stéphane Gimenez, white paper described the general form of this attack, and Hal Finney described the specific case for 0-confirmation transaction, but I should probably include the link to the white paper


text:
How to transfer addresses from Satoshi client to MultiBit?
I'm trying to take an address from my Satoshi client and transfer it into my new MultiBit client. I have found several questions similar to this, and have tried all their solutions, but to no avail.
This is the basic process I go through: (Note: The address & private key I use in the example are empty; made for this example)

On the Satoshi client, I go to the console and type: dumpprivkey 16tTCqoguKk7ZvLXsUyUE5JKJQ2VMDpCQj
I get the private key
KzD6eDjxCwPf8YTGiGhNWAyg4HU4H6iWXYEqCyKGhH8Dy9ZKhdui
I confirm on bitaddress.org that the private key does indeed output the public key above.
I then export the private keys on MultiBit (Version 0.4.19 BTW), and add the private key listed above into the exported file.
Importing the private keys back, the public address 1GWqf362pUzGfrZ7K7Thazd27aRBsakGcX is imported, rather than 16tTCqoguKk7ZvLXsUyUE5JKJQ2VMDpCQj.

I'm not exactly sure if I'm doing something wrong, or the problem is some sort of bug in the software...
Please excuse me if I sound "Bitcoin-Illiterate", I'm kinda new to this stuff.

Welcome to Bitcoin.SE! Thanks for putting some effort into writing your question!

For the benefit of anyone who might not happen to know, never reveal private keys from your wallet as they can be used to spend any funds received at that key's corresponding Bitcoin address now or in the future.

Notice that your private key retrieved from the Satoshi client begins with a K. According to the List of Address Prefixes, that means the key is exported in compressed form.
MultiBit's export file saves private keys in uncompressed form. Private keys in uncompressed form begin with a 5.
You can divine the uncompressed key using Bitaddress's wallet details page. Just look for the private key that begins with a 5. It's the private key that has a QR code next to it.
Repeat the latter part of your steps, adding the uncompressed key to the export file and then importing that file.

Colin is correct. At the moment MultiBit only supports uncompressed keys for import (the ones beginning with 5). Compressed key support will be going into bitcoinj 0.7 so when that comes out I will improve this. For the moment do as Colin suggests and convert it to uncompressed.

Is there any way to uncompress the private key without sending it to an external service?

@kristianp: BitAddress runs entirely client-side in JavaScript. If you don't trust that, you could disconnect from the Internet while you uncompress it. Or, you can try using Sx.

@ColinDean thanks for that info, I didn't realise it was client-side.

Colin Dean, the javascript could be compromised. To trust that website, you should read and understand the source code before use and every time the web page is changed. Also, you'd have to do the same for the web browser that you're using.

Eyal, absolutely correct. Thus the recommendation of open source for just about everything interacting with private keys!


text:
Do private people mining or exchanging Bitcoin with Fiat fall under FINCEN's definition of "user"?
Fincen's March 2013 report defines:

A user is a person that obtains virtual currency to purchase goods or services.
An exchanger is a person engaged as a business in the exchange of virtual currency for real currency, funds, or other virtual currency.
An administrator is a person engaged as a business in issuing (putting into circulation) a virtual currency, and who has the authority to redeem (to withdraw from circulation) such virtual currency.

Note that to in order be considered an exchanger or administrator by the above definition, a person must be "engaged as a business".
So, is it true that a private person who mines at home, or a private person that sells Bitcoins in exchange for fiat, isn't in fact considered an exchanger or administrator, but rather a user (and is therefore not a Money Service Business and is exempt from regulation)?

The short answer is, it is complicated.  Below are some resources that may helpful.
As a disclaimer none of the below statements constitute legal advice and they should not be relied on.
I recently co-authored an article that contains some background information to your question. William B. Fleming and Joseph Evans, Bitcoiners in the Courtroom Part I: Government Oversight, Ford. Corp. L. Forum (Aug. 20, 2013).
TXT
PDF
The relevant portion is below.  Though, admittedly, it may not answer your question in full.  An argument can be made that the Guidance may have left room for a distinction between a miner who uses his Bitcoin for goods and services, and a miner who sells his Bitcoin for fiat.
"Notably, according to the Guidance, “users” are not subject to these registration requirements.   “A ‘user’ is a person that obtains virtual currency to purchase goods or services.”  Miners, too, are not subject to these registration requirements since “a person that creates units of this convertible virtual currency and uses it to purchase real or virtual goods and services is a user of the convertible virtual currency and not subject to regulation as a money transmitter.”
The most interesting part of your question really raises the issue of the scope of the definition for a "money transmitter."  Specifically: "are miners who sell their Bitcoin for fiat money transmitters?"
Page 5 of the Guidance offers an explanation that you may find helpful:
"A person that creates units of this convertible virtual currency and uses it to purchase real or virtual goods and services is a user of the convertible virtual currency and not subject to regulation as a money transmitter.  By contrast, a person that creates units of convertible virtual currency and sells those units to another person for real currency or its equivalent is engaged in transmission to another location and is a money transmitter."
Another helpful piece of information is located in footnote 10: "whether a person is a money transmitter is a matter of facts and circumstances.  The regulations identify six circumstances under which a person is not a money transmitter, despite accepting and transmitting currency, funds, or value that substitutes for currency."  31 CFR § 1010.100(ff)(5)(ii)(A)-(F).
This is the relevant portion of that statute:
(5) Money transmitter —(i) In general.
(A) A person that provides money transmission services. The term “money transmission services” means the acceptance of currency, funds, or other value that substitutes for currency from one person and the transmission of currency, funds, or other value that substitutes for currency to another location or person by any means. “Any means” includes, but is not limited to, through a financial agency or institution; a Federal Reserve Bank or other facility of one or more Federal Reserve Banks, the Board of Governors of the Federal Reserve System, or both; an electronic funds transfer network; or an informal value transfer system; or
(B) Any other person engaged in the transfer of funds.
(ii) Facts and circumstances; Limitations. Whether a person is a money transmitter as described in this section is a matter of facts and circumstances. The term “money transmitter” shall not include a person that only:
(A) Provides the delivery, communication, or network access services used by a money transmitter to support money transmission services;
(B) Acts as a payment processor to facilitate the purchase of, or payment of a bill for, a good or service through a clearance and settlement system by agreement with the creditor or seller;
(C) Operates a clearance and settlement system or otherwise acts as an intermediary solely between BSA regulated institutions. This includes but is not limited to the Fedwire system, electronic funds transfer networks, certain registered clearing agencies regulated by the Securities and Exchange Commission (“SEC”), and derivatives clearing organizations, or other clearinghouse arrangements established by a financial agency or institution;
(D) Physically transports currency, other monetary instruments, other commercial paper, or other value that substitutes for currency as a person primarily engaged in such business, such as an armored car, from one person to the same person at another location or to an account belonging to the same person at a financial institution, provided that the person engaged in physical transportation has no more than a custodial interest in the currency, other monetary instruments, other commercial paper, or other value at any point during the transportation;
(E) Provides prepaid access; or
(F) Accepts and transmits funds only integral to the sale of goods or the provision of services, other than money transmission services, by the person who is accepting and transmitting the funds.
These definitions can be found here: 31 CFR § 10.10.100
I hope that you find these resources helpful.
Joe


text:
Is there a web service that does reverse FirstBits lookup?
Input: any old Bitcoin address e.g.
1BCNEPySL4gzzjg8NNyNsQYJWYmZwpgaPF
Output: the FirstBits, in this case 1BCN1u

can you please tell where I can read about old and new bitcoin addresses?

@SalvadorDali - I don't understand what you mean "old and new addresses"

Blockchain.info has APIs to generate and resolve firstbits.
Get firstbits,
http://blockchain.info/q/getfirstbits/1BCNEPySL4gzzjg8NNyNsQYJWYmZwpgaPF
Get address,
http://blockchain.info/q/resolvefirstbits/1paypal
http://blockchain.info/q/resolvefirstbits/1ebay
http://blockchain.info/q/resolvefirstbits/1google

What is the purpose of this?

@bvpx:        Https://en.bitcoin.it/wiki/Firstbits tells us that firstbits are basically a way for bitcoin users to type a few less key strokes (an address shortner for bitcoin addresses). However there are more than a few downsides to it. I hope the information is helpful.n Just start at the beginning and learn everything bitcoin wiki touches on. Feel reese to ask more questions. I always suggest using the search engine before posting so you keep good rep. You can always privately message me. But I am over on my altcoins pool mostly.

This service seems to be out of order currently.

Having seen that yes blockchain.info no longer offers this service I was able to find only one other Block explorer that do offer the FirstBit lookup on addresses:
https://www.walletexplorer.com
https://www.walletexplorer.com/address/1BCN1ugdKdWd9pQ8Am9hMhtHZfmbXzxE8a?from_firstbits=1BCN1u
Hope this helps :)


text:
How to use two-factor authentication at btc-e?
btc-e has a very confusing process of enabling 2-factor.
How should I use it?

Should I generate a one time password with a Yubikey?
Should I backup the private key / base32 ?
What does this auth process do?
(P.S. btc-e - you need to hire some better UX people)

it was easy to set up for me using an android phone ... just install the google auth, scan the code they give you on btc
new users should take a screen shot of the QR code and print it out and save in secure location.  You can't get back to that QR code, so save it from the beginning.
Here is a more general info on the topic:
http://cadince.com/3-ways-to-move-google-authenticator/

At first I didn't find this on Google, but I just saw this on their blog:

To protect your account from hacking you should:

Create a key in profile->security https://btc-e.com/profile#security/2fa
Scan the QR code using the Google Authenticator (or enter key to another application)
Confirm by entering the one-time password

Following these simple steps you can turn a one-time password to log
  into your account, withdrawals, or to change the security settings.
Install Google Authenticator: Android:
  https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2
  iOS: https://itunes.apple.com/ru/app/google-authenticator/id388497605

I still don't understand whether it can be used with a Yubikey, and if so how.

AFAIK Yubikey is its own thing, and unless it is explicitly supported it cannot be used.

@MeniRosenfeld - yeah, I think so too ... what a shame.


text:
What is the normalized transaction hash of a transaction?
With the recent commotion around transaction malleability, it seems like the Bitcoin developers have been working on a semi-fix for it, called the normalized transaction hash.
It's implemented here in this pull request by sipa.
What is this hash and how is it different from the regular transaction hash? How can it be constructed? How does it try to solve the malleability problem?

It is a hash of the transaction without the input scripts.  SIGHASH_ALL says all inputs and outputs are included in the hash.  These are the areas covered by the standard payment methods and they cannot be modified without invalidating the transaction.  One of the problems, though, is that there are other payment methods which do change the inputs and thus the normalized transaction ID would change in those cases.  But it does cover the common transactions.

It's the same hash value that is signed by ESDSA (i.e., it's the "e" value used in the calculation of the signature's s value  s=(e+dr)/k


text:
How can one know which money exchanges happen in Ripple?
In Ripple, money can be exchanged in two ways:

a payment is sent from a person to another person
2 satisfying offers fulfill each other

The Ripple wiki states

When an offer is placed it will immediately take any other offers that satisfy it.

Regular payments can be seen by the Ripple network by Payment transactions that are sent around. However, when two satisfying OfferCreate transactions occur, how can one know that they are being matched are will fulfill each other?
Also, for a Payment transaction, multiple possible "paths" can be defined. How do other nodes know which path is chosen and so which offers that the paths correspond to are fulfilled?

I'm currently monitoring the payments WebSocket stream, but I seem to need more than that to know what money exchanges happen in Ripple.

It's a lot more complex than I supposed it would be. Is there a script or explanation how you can determine all balance changes from a transaction? Also, I see a lot of Payment transactions that include the RippleState address rrrrrrrrrrrrrrrrrrrrBZbvji but I cannot make anything of these transactions.

That's "ACCOUNT_ONE", it's used in RippleState ledger entries. I found looking at the JSON dumps of transactions (with a little input from the wiki) was all pretty easy to decipher.


text:
Is the time value in transaction or block information the time it arrived at my client?
Both transactions and blocks have a time field when you use Bitcoin's getblock or gettransaction methods. The API method list defines the transaction time as " time the transaction occurred".
Is this the time the transaction or block arrived at my client? Or is this time defined by the sender of the transaction or block?
I tried to encode a transaction to a raw transaction and decode it again afterwards, but the lock_time property is set to 0 when I do this.
The reason for this question is that I want to make sure that when you check all transactions twice, all new ones of the second check have a time value higher than the highest one of the first check.

Blocks have timestamps, transactions don't. The time of a block creation is known, the time of the transaction can only be guessed. Most clients use the block's time for transactions, and if they're still in the transaction mempool (not in a block) they use the time the transaction was first seen by the client.

So you say that when a transaction gets confirmed, the time value changes to the block time value?

That's client specific behavior, as transaction times play no role in the bitcoin network. But yeah, in this case that seems likely. Test it yourself though: go to blockchain.info, pick a few transactions that are currently unconfirmed and get the time value for them. Then get them again in like an hour or so.

@TomvanderWoerdt, But doesn't that mean that every single node will have different timestamps because they receive the broadcast at different times?

@Pacerier Yes, it does

@TomvanderWoerdt, Please also see http://bitcoin.stackexchange.com/q/25542/1475


text:
How to setup a LAN network with only one bitcoind client downloading the blockchain?
I want to do the following:
I have one small server PC at home. I want to install bitcoind on that machine to download the blockchain information. Then I want this machine to accept RPC calls from my LAN network and setup all other bitcoin clients on my LAN network to use that server machine for blockchain info and transaction broadcasting.
I already setup a bitcoind client on the server with the following bitcoin.conf values:
server=1
rpcuser=MyRPCUser
rpcpassword=MyRPCPassword
rpcallowip=192.168.0.*
rpcssl=1
rpcsslciphers=TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!AH:!3DES:@STRENGTH
rpcsslcertificatechainfile=server.cert
rpcsslprivatekeyfile=server.pem

Note that I did follow the instruction for creating a SSL certificate.
What should I do on the client machines? I tried bitcoin-qt -rpcconnect=[server-ip] but it seemed to just start regularly continuing to download the blockchain from where it stopped last time.
Besides, is it possible to let Bitcoin Armory also use a bitcoin client via RPC instead of the one of the same machine? Or does it really require a remote bitcoind <-> local bitcoin client <-> armory setup?

You need to use connect in your configuration file, rpc_connect is something different, it means that your client delegates its commands to another bitcoind.
If one client connects normally and other clients connect to it using connect = ip.of.main.client it will work the way you want it to.
Conversely you can prevent a node from connecting to anything by using connect = 0.0.0.0.
EDIT : I understand better now. You need to use rpc_connect = ip.of.master.bitcoind on the 'slave' node, and connect = 0.0.0.0 to prevent it from loading the blockchain and you should be all set.

connect=<ip> : Connect only to the specified node(s) That option will just let the client bitcoin download the blockchain from the server bitcoin peer, which I don't want. I want it to use the server bitcoind to check the blockchain and to transmit transactions. I think that's what the rpcconnect parameter does...

No it is not. RPC stands for Remote Procedure Call, like I said, the rpc_connect option will simply mean that any JSON-RPC commands will be forward to the configured node. connect does exactly what I told you, it connects to one or a collection of nodes exclusively. These nodes will then be used to download the chain AND get transactions. This is exactly what you want. connect forces a connection to one or several nodes excluding all others, add_node will connect to the configured node without excluding any other one.

I know what you told me. But I don't want to download the blockchain on the other machines, I want them to just use the server one using RPC.
I don't know for sure what functionality is available over RPC, but I think it should be possible that a rpc-connected client can receive getinfo commands and accept transactions and just forward them to the server bitcoind over RPC.
The main reason I want to use this for is Armory, which needs a bitcoin client to be running on the same machine, so I want that bitcoin client to forward all commands it gets to the server daemon.

I see, edited the answer.

Thanks for the correction. What do you mean with a proxy-setup? Would a proxy not just let a client download the blockchain via a different node?

Thinking about it the proxy part doesn't actually make much sense, removed it. I believe your original question is now answered.

rpcconnect only changes where RPC commands are sent. So, for example, bitcoind getbalance would be sent to the IP address you specified, but nothing in the GUI generates an RPC call.
Source: This is the only place the CallRPC function is referenced.
I assume that you want to keep the private keys for spending the bitcoins on the personal computers. In that case, the best approach would probably be to install the electrum server on one computer, and the electrum client on another.
EDIT:
Sorry, only saw the part about bitcoin-qt, and I thought that was what you were running. So, the armory client does talk to the bitcoin client, but the address it uses is hard-coded. (Fortunately, it's only hardcoded in the python files.) Also, the protocol it's speaking is not RPC, but the bitcoin protocol itself.

The point is that I want to use the Armory client. It needs a bitcoin client to be running. But I assumed that the commands it sends to the local client would be routed over RPC...

Whoops, missed that. Thought you were running stock bitcoind. Lemme have a look through armory's source code.

@StevenRoose, please check out my edit.


text:
How to use block and transaction hashes for generating simple stochastic chances?
Many online Bitcoin gambling websites use the block chain info to prove fairness. Most of them use rather complex algorithms for this with pre-published secrets.
What most of them basically achieve: Convert a block hash or a transaction hash to a number in a certain range.
What is the simplest way to do this in a fair way, verifiable by everyone? I would like to focus mostly on using block hashes, which are the least manipulable.
With a simple way I'm looking for either a very simple mathematic way to do so or either a library which can do it for you.
I understand that predefined secrets are required when transaction information is used, because these are easy for users to manipulate. Block information, on the other hand, is far less easy manipulable. If you want to generate a block with a hash that would make you win in the game, you would make the standard block generation problem even more difficult and you will have to do solo mining  which is already quite hard when doing regular mining.
So, are these secrets also required when using block information?
Note that I am an engineering student myself so I will probably understand much cryptographic and mathematical terms, but the purpose of this question is of course to receive an answer that everyone can understand.

Here's the way SatoshiDICE does it:
SatoshiDICE has "secret keys" for each day which they pre generated for the next 10 years. They published the hashes of those keys so you can verify they didn't change them. When a transaction comes in, they hash the transaction hash and the secret key for that day, then take the first two bytes of that. Then, a few days later, they publish the secret keys.


text:
How to check if the block chain is up to date using bitcoind or json-rpc?
I read the full api method list and did not seem to find one.
I suppose there is no command specifically for that purpose, so what is the general way of doing this?
I would consider checking the time stamp of the last generated block, but the getblock method is not really explained in much detail.
EDIT:
Some people answer that I should compare the block count with one of an online block chain monitor. That is not really a practical solution. The Bitcoin-Qt client has a way of knowing when syncing is done (the V-sign vs the syncing icon), so why doesn't bitcoind? How does the Bitcoin-Qt get this information?

possible duplicate of When downloading the blockchain for the first time, how do I know when it's done?

In short: run bitcoind getinfo, compare the number after 'block count:' to the number here.

@BinaryMage That question does not make clear that it is about the daemon in the headline. I would have ignored it if I had seen it when I was looking for an answer.

Check out my edit.

The getwork call will fail if you aren't up to date.

@StevenRoose Good point. I edited the other question to make clear that it applied to the headless client (bitcoind).

I use a python script that grabs http://blockchain.info/q/getblockcount and compares it to the output of bitcoind getblockcount.
As others have said, there is no absolute way of telling if your blockchain is up to date.
Anyway, here is my script:
    import httplib2
    from bitcoinrpc.authproxy import AuthServiceProxy
    access = AuthServiceProxy('#########')
    try:
            blockCount = access.getblockcount()
    except Exception as e:
            print "Problems connecting to bitcoin wallet:"
    else:
            try:
                    response, trueBlockCount = httplib2.Http().request("http://blockexplorer.com/q/getblockcount/")
            except Exception as e:
                    print "Unable to get true blockcount from blockexplorer:"+str(e)
            else:
                    if (int(trueBlockCount) - 5) > blockCount :
                            print "blockchain not up to date: true block count is: "+str(trueBlockCount)+", while bitcoind is at: "+str(blockCount)

pip install httplib2 and git clone https://github.com/jgarzik/python-bitcoinrpc.git and python setup.py install helped me run this code

rather than bitcoind getblockcount don't you mean bitcoin-cli getblockcount?

There is no way for checking whether syncing is done, simply because it isn't known.
Slightly abstractly, and probably not useful in your case, the client is always syncing: there is no real difference between "having all blocks" and "not having all blocks" - it always has all blocks that it knows about, and doesn't know whether there are blocks which it misses.
What the GUI shows you is a guess. It checks the age of the last known block, and if it is (IIRC) more than 90 minutes ago, it assumes it's out of sync. This is usually a good indicator, but it will rarely yet certainly randomly fail from time to time.
The core code has another heuristic built-in, which uses block heights reported by other nodes (without verifying that information in any way, so it's easily cheated). This information is used to determine whether it should optimize cache behaviour for many fast operations, or reliability. It's not exposed directly either, but the getwork() and getblocktemplate() RPCs will fail in this mode.

What is the benefit of the heuristic built-in over checking the age of the last known block?

Bitcoind no longer supports RPC calls. Try:
watch bitcoin-cli getblockchaininfo
When the displayed number of blocks equals the displayed number of headers, you're synced!

This doesn't seem to work in all cases.  I have a bitcoin-abc (BCH) testnet node which is synced, but headers is still significantly larger than blocks.  I think maybe it is getting header counts from BTC nodes.

@NateEldredge - how do you know it is synced?

@MaxVernon: The debug.log has an UpdateTip message showing a block with a recent timestamp, which agrees with the latest block shown by block explorers.

If you could include info about how to double check using the age of the last known block, I think this would be the best answer. You know you're not up to date until your latest verified block is the same as your number of headers, but you don't quite know you're up to date even when that happens until you check blocks timestamps vs network time (and your own time)

Considering that you are always somewhat out of sync, here is how you can get by how long in seconds, and then you can divide by 60 or 3600 to get it in minutes or hours.
If you want to do it manually:
# bitcoin-cli getblockcount
2345
# bitcoin-cli getblockhash 2345
000000007024f233aa44bc7784a78926fb1c325f9985c936ae57b94530505062
# bitcoin-cli getblock 000000007024f233aa44bc7784a78926fb1c325f9985c936ae57b94530505062 | grep "time"
    "time" : 1233313208,
# echo $((`date +%s`-1233313208))
<number of seconds>

Or the same in two steps
bitcoin-cli getblock `bitcoin-cli getblockhash \`bitcoin-cli getblockcount\`` | grep time
    "time" : 1233313208,
echo $((`date +%s`-1233313208))
<number of seconds>

I didn't find a way to do it in one call, so here is a script that does the whole thing, with no error checking as you can see:
#!/bin/bash
cnt=`bitcoin-cli getblockcount`
hash=`bitcoin-cli getblockhash ${cnt}`
timeline=`bitcoin-cli getblock $hash | grep '"time"'`
ltrimtime=${timeline#*time\" : }
newest=${ltrimtime%%,*}
echo $((`date +%s`-$newest))

Then you can replace
echo $((`date +%s`-$newest))

To get the number of minutes like this:
echo $(((`date +%s`-$newest)/60))

Or the number of hours like that:
echo $(((`date +%s`-$newest)/3600))

Or, assuming you have perl (which you probably have) and that you prefer to have the date of the last block:
perl -le "print scalar localtime $newest;"

The time that is in the block is the time that a miner reported, while it will probably be close to the correct time, it may not be correct. See this question.

I'm trying to use this method to determine the age of the newest block in my wallet's chain, to estimated up-to-date-ness. via RPC calls, I run getblockcount and it returns the block number. Then I run getblockhash $count to get the hash. Everything seems to be going well. But then when I run getblock $hash it throws a parse error, every time (-32700). Any thoughts on why? Despite my variables in this comment, I have confirmed the commands being sent are correct. For example:
getblock 000000000000000000114801309313f1fa84f8ce4e6f6e0bcc23eea91aeca343 throws a parse error :(

Update August 7 2015 ~ start
So after having an IP or two banned because of checking to often... so, I'll provide some options on how to avoid getting banned.
First don't use the script under this update; the variable expansion Bash preforms causes multiple calls to https://blockchain.info in to short of a time frame. You can try adding sleep 120 between the assignment and calls but that would be very slow.
Second the key things are; Checking local count $(bitcoin-cli getblockcount) and Checking a well known node $(wget -q -O - http://blockchain.info/q/getblockcount) and Checking local sync state $(bitcoin-cli getblocktemplate)
To combine the Blockchain from your node to another in one line
$($(wget -q -O - http://blockchain.info/q/getblockcount)-$(bitcoin-cli getblockcount))
# To print this with echo and date stamp
echo "    $(date) : $($(wget -q -O - http://blockchain.info/q/getblockcount)-$(bitcoin-cli getblockcount))"
# To redirect and exit with 0 : ie place in crontab
echo "$($(wget -q -O - http://blockchain.info/q/getblockcount)-$(bitcoin-cli getblockcount))" > /var/log/btc_blocks_left_to_sync.log 2>&1

The last one above is likely the best for scripting as the file it saves to can be read for just the number inside or the last time it was modifide.
Update August 7 2015 ~ end
Indeed the correct function call is shown there, @BinaryMage, thank you.

possible duplicate of When downloading the blockchain for the first time, how do I know when it's done? –  BinaryMage Apr 4 '13 at 0:50

The person to show the correct function was @LoHoris, however, the updates to Bitcoin node software now uses bitcoin-cli getblocktemplate and not bitcoind for these lookups.
Thanks to both of them it is possible to offer you all a combination of both answers wrapped into a checker script; ready for your customization and updated for the year 2015

    #!/bin/bash
    timed_wait=600
    vars_to_load(){
        ## Set vars to function such that they are set upon every call
        localCheck=$(bitcoin-cli getblockcount)
        crossCheck=$(wget -q -O - http://blockchain.info/q/getblockcount)
        diffBlocks=$(($crossCheck-$localCheck))
        localSize=$(ls -hal ~/.bitcoin/blocks | awk '/total/{print $2}')
    }
    check_sync(){
        while true
        do
            current_time=$(date)
            echo $current_time
            bitcoin-cli getblocktemplate
            if [ $? = 0 ]
            then
                echo "All synced up"
            else
                echo "Uh oh, running available checks"
                ## call function that runs it all on a timer
                networked_sync
                echo "Node has $localCheck of $crossCheck blocks available."
                echo "Size of local blockchain is $localSize"
            fi
            echo "Sleeping for $timed_wait seconds or $(($timed_wait/60)) minuets."
            sleep $timed_wait
        done
    }
    networked_sync(){
        vars_to_load
        ## Function to print difference in node sync
        if [ $diffBlocks -eq 0 ]
        then
            echo "Sync is good with $diffBlocks blocks off"
        else
            echo "Sync has $diffBlocks blocks left to download"
        fi
    }
    check_sync

This script first checks the exit status of bitcoin-cli getblocktemplate because anything other than 0 is usually an error it'll run the other parts only if bitcoin-cli getblocktemplate shows an error. Of course it is possible to check for specific error codes instead and do things for specific error codes... but this works fine as a template for me when setting up BTC nodes in a headless environment.
The other checks then compare local block count verses https://blockchain.info and prints out how many blocks your system is off. These only run when local check of sync status error out thus if you're on a slower like @Steven Roose mentioned then this script is ideal.
By default the wait time between checks is 600 seconds (10 minuets) to keep network checks and local checks to a minimum, however, for logging and better resource management it is easy enough to comment out the while, do, and done and sleep $timed_wait lines. And add one line to crontab to accomplish running on a schedule. Last modify the very end of the script to write output to a file.

The function modified;
    check_sync(){
    #   while true
    #   do
            current_time=$(date)
            echo $current_time
            bitcoin-cli getblocktemplate
            if [ $? = 0 ]
            then
                echo "All synced up"
            else
                echo "Uh oh, running available checks"
                ## call function that runs it all on a timer
                networked_sync
                echo "Node has $localCheck of $crossCheck blocks available."
                echo "Size of local blockchain is $localSize"
            fi
            echo "Sleeping for $timed_wait seconds or $(($timed_wait/60)) minuets."
    #       sleep $timed_wait
    #   done
    }

And to run every 10 minuets
    sudo nano /etc/crontab
        */10 *  * * *   root    /pathTo/script.sh 2>&1

Then to enable logging modify the call that starts every thing within the script;
    check_sync | tee -a /tmp/BTCsync_log.txt

Hopefully this is acceptable enough of an answer to mark this question as [Solved] such that future  web searchers can have an easier time of this.

Not seeing any trivial answers here. Here's what i did.
Use API CALL "getblockchaininfo"
Parameter "verificationprogress" will be ~= 1.0, if you are synced.
Warning: this appears to be based on time, your clock will need to be somewhat accurate.
I check that it is >= 0.999 to determine if i'm in sync.

This seems like a pretty simple, logical way to determine this. Any second or third opinions about using this method? Potential pitfalls?

A bit hacky, but the debug log shows your "progress" as far as bitcoind is concerned.
tail -n 1 ~/.bitcoin/debug.log

Gives you something like
2016-04-26 19:02:21 UpdateTip: new best=000000000000000002a9b8f81c231c99b86f79fae383fb1fc046974f7fdcf118  height=405098  log2_work=84.399379  tx=119389857  date=2016-03-31 10:06:53
progress=0.982752  cache=0.5MiB(0tx)

In this case, I'm 98 percent "done".

There are some neat solutions here, and maybe this is just overly simple but, if you're legitimately catching up to the blockchain and not basically at the end so only getting that new block once every ~ 10 minutes, look at your cpu usage.
If you're on linux, run "top".  bitcoind will be working its butt off calculating every hash of every block through the blockchain.  Once it's caught up, it's basically idle.

Does not work when your internet connection is having issues. Or when your connection is just slow. bitcoind iterates between downloading blocks and verifying them, so in a period of downloading and a slow connection, CPU usage will be low as well.

Yes that's true.  If you have a slow enough internet connection such that your CPU is only busy hashing every 10 minutes or so, you can't tell the difference between that problem and actually being caught up.  However you'll never catch up if you don't outrace the rate at which blocks are created.  Even if you're only seeing activity once a minute that's still a clear indiciation that you're catching up.  As once you're caught up you'll only have real activity once every 10 minutes.

just use the standard bitcoin-cli getblockchaininfo
then check the initialblockdownload field in the response, if this is true, then the node is still synchronizing:
{
  "chain": "main",
  "blocks": 813280,
  "headers": 814250,
  "bestblockhash": "0000000000000000000296fddea58647bc01598bf91f391d081c06ada148efce",
  "difficulty": 61030681983175.59,
  "time": 1697941840,
  "mediantime": 1697939028,
  "verificationprogress": 0.9981760872613284,
  "initialblockdownload": true,
  "chainwork": "000000000000000000000000000000000000000059f423ba44c0a97786f959b1",
  "size_on_disk": 590414048660,
  "pruned": false,
  "warnings": ""
}

I don't think this is correct. Not sure, I thought once the flag was set to false, it would never go back to zero. So if you start up a node that had been down for some time, it would no longer be an indicator.

Throw the script below into your /home/$USER/.bashrc file and restart your shell.

alias bitcoindSynced='
bitcoindSynced() {
blockCount=`bitcoind getblockcount`
blockChain=`wget -O - http://blockchain.info/q/getblockcount`
blockDiff=`expr $blockChain - $blockCount`
if [ $blockDiff = 0 ]
then
    echo "up to date"
else
    echo "$blockDiff blocks behind"
fi
}
bitcoindSynced 2>/dev/null'

Then when you run the command

bitcoindSynced

you will be provided with the number of blocks left to sync,
or if your client is up to date it will let you know.

Also, if you don't want to restart your shell you can just run the command

source /home/$USER/.bashrc

and it will do the same thing.

That's a really strange way of doing a bash function definition.

And I have problems to believe this is the way the Bitcoin-Qt client does it...

How would you do it?
It's alised because you need to call the function after with '2>/dev/null' after defining it and you can't do that inside the function or it will repeat forever when the shell starts. I'm no linux guru, if there is a correct way to do it then please teach me :)

Also this is not how the Bitcoin-Qt client does it, it's a hack for the bitcoind daemon.

More rudimentary but useful to know if the wallet is synchronized or not
By using the commands:

"getinfo" (give your current block height)
"getpeerinfo" (give the
block height with the "startingheight" field for each connection).

Then, you can easly compare values and find out how many percent you are for downloading the blockchain.

By getinfo I assume you mean getblockchaininfo. If that's true, this doesn't seem to work as the median number from peers right now is 637967 yet getblockchaininfo shows me as having 637974 blocks. So I'm magically ahead of all of my peers. Somethings not right with this method.


text:
Older Clients & Wallets
I have about 5 BTC stored in Wallets created under different versions of Bitcoin, all encrypted with multiple backups.
I downloaded latest Client and it doesn't work with the wallets, I've gone back to an earlier client and it works ok.
I assume there have been changes over the past year or so.
I don't have time to figure this all out and try out which Older client works with which backup wallet so I can send my few BTCs to a Brainwallet address and dump the old wallets.
Can I assume that because they are in wallets with backups, encrypted etc that the coins are safe and I just need to go through the trouble of recovering them.
I've heard about pywallet and have tried manually dumping the private keys so I can transfer the coins but so far no luck, it's all Greek to me.
Can I assume the coins are safe (providing the wallets are not iredeemably corrupted, and that one day soon, when I have time I should be able to recover them.

If a new client fails to open your older wallet, that is a bug and you should report it: http://github.com/bitcoin/bitcoin/issues

Your coins should be safe.
No need for a brainwallet:

open the new client and create a new address
backup this new wallet
open your old clients and send your coins to that new address

Never delete the old wallets anyway, just in case.

I think part of the problem is that the OP doesn't know which version each wallet was created with, so "open your old clients" may or may not work, depending on compatibility between versions.


text:
Uptime and other service performance levels
Other payment networks have scheduled maintenance periods as well as unscheduled outages but Bitcoin's network, being decentralized, can have varying service levels depending on:

which versions of the software and which nodes are used
the nature of the transactions (e.g., microtransactions or those originating from an eWallet sans fee, etc.)
several other factors.

What are key performance measurements that can be made for the Bitcoin network, and how can they be measured? If measurements are being made already, where are they available?

Here's an example of a metric that others are interested in as well.  http://bitcoin.stackexchange.com/questions/1557/speed-of-operations-in-the-bitcoin-network

You seem to conflate several issues in your question. If you are just talking about "uptime", which your question title implies, then speed of transaction propagation or confirmation is not relevant. As long as your node is can connect to other nodes and send/receive data, the network is "up". If you send transactions that require fees and they don't confirm for a long time, that's your problem, not the network's.
That said, the "gist" of your question, about network health, transaction processing speed, etc, is not unimportant. There is a bunch of useful data on this site, dedicated to monitoring the bitcoin network: http://bitcoinstatus.rowit.co.uk/ that would probably get you started in the right direction. :)

I've modified the title and question to also inquire about other metrics as well.

@StephenGornick I would remove uptime from your question title and simply indicate in question that "since uptime is 100% for a distributed network what OTHER metrics can be measured to calculate performance".  Since the genesis block bitcoin uptime has been absolutely 100%.  As long as their is a single node receiving and hashing transactions it will remain 100%.  In other word uptime will always be 100% until Bitcoin is no longer used.

Confirmation time of received transactions is a key service level measurement.
For someone processing transactions with their own custom client, it's mostly up to them as to when they consider a transaction confirmed, as there's a trade off between speed and risk.
Multi-node listening allows a reasonable level of confidence that a double spend hasn't been performed, but it doesn't protect against a Finney attack.
Because a Finney attack is difficult and risky to perform (the attacker risks losing the reward for a solved block), it would only be worth bothering with a particularly large transaction. This means the level of service differs by transaction.
A table indicating confirmation time (and thus service level) would go something like this (figures are educated guesses; perhaps someone can measure it an update the answer at some point):
Transaction size    Risk of Finney attack    Confirmation technique        Confirmation time
Small               Very Low                 Multi-node listening          <3 Seconds
Large               High                     2+ Block confirmations        20+ minutes, on average
Very large          Very High                Many (x) block confirmations  x*10 minutes

Obviously it's open to interpretation as to what is "small" and "large". As previously stated, the trade off between speed and risk will help determine a suitable balance for each scenario.


text:
In order to reduce fees, can I 'consolidate' my wallet by sending the entire balance to a new address in the same wallet?

My balance is currently made up of lots of small amounts
I know I'm not going to be using my bitcoin wallet for a while, so I don't care if the consolidation transaction is slow.

Would creating this transaction with no(or relatively low) fee achieve the aim of making subsequent transactions smaller and therefore less likely to attract higher fees in order to go through quickly?
Assuming this sort of 'consolidation' even works..
What would happen if a wallet program had a feature that allowed people to automatically 'consolidate' overnight depending on the makeup of the wallet's balance? Might it have a negative effect on the network?

This question doesn't ask how, so I've asked that question here: http://bitcoin.stackexchange.com/questions/5583/how-can-i-combine-all-the-tiny-amounts-ive-received-while-minimising-transactio

It depends which of two cases you are in:
If you have lots of decently-sized transactions to 'gather', it will likely have the reverse of the effect you want. Right now, you probably have lots of old transaction outputs that your future transactions can claim. That means you can form many transactions that use only old outputs, and thus get a higher base priority. If you consolidate your coins, you will have only one transaction output to claim. So in the future, you will only be able to create one high-priority transaction. Once you do that, you will have no more old coins.
But if you have lots of absurdly-small transactions to 'gather', it will likely help you. By not having to gather lots of small transaction outputs together in the future, your future transactions won't be as large and therefore won't require as high a fee (or as large a wait).

If fees are your only concern, yes it works. By ordering the smallest inputs (those of which you'd need lots in a future transaction) in ascending order and then build transactions to yourself just small enough to avoid paying fees you will end up with a few large inputs which can then be used in future transactions, without paying a fee.
This method has been discussed for mobile clients as it allows to discard spent inputs and reduces the amount of data to be stored/searched.
However as David pointed out your future transactions might get a lower priority for being confirmed:

Transactions within each fee tier are prioritized based on several
  factors. Most importantly, a transaction has more priority if the
  coins it is using have a lot of confirmations. Someone spamming the
  network will almost certainly be re-using the same coins, which will
  lower the priority of their transactions. Priority is also increased
  for transactions with more BTC, and reduced for transactions with more
  data.1

So there is in fact a tradeoff between renewing your old inputs and keeping them as they are to create higher priority transactions. I'd say just set yourself a limit like "inputs larger than 1 BTC should not be aggregated" and you'll be fine.


text:
Understanding trading history
On BTC-E, you can see the recent trade history for the different currency pairs. For example right now you see these recent trades:
14.05.13 01:27  Sell    112.75 USD  4.77859 BTC     538.7860225 USD
14.05.13 01:27  Sell    112.76 USD  0.359638 BTC    40.55278088 USD
14.05.13 01:27  Sell    112.76 USD  0.122198 BTC    13.77904648 USD
14.05.13 01:27  Sell    112.76 USD  0.022195 BTC    2.5027082 USD
14.05.13 01:27  Sell    112.76 USD  0.0100155 BTC   1.12934778 USD
14.05.13 01:27  Sell    112.76 USD  1.20736 BTC     136.1419136 USD
14.05.13 01:27  Sell    112.76 USD  0.360915 BTC    40.6967754 USD
14.05.13 01:26  Buy     112.9 USD   1 BTC           112.9 USD

Shouldn't every trade of type "sell" match a trade of type "buy"? Or at least the amount of all recent sell-trades should match more or less the amount of all recent buy-trades? If you look at the history of the last 15 minutes right now, the amount of BTC in sell-trades is much higher then the amount of buy-trades. How can this be?

Most exchanges work with an order book. In this method, the two parties involved in the trade are slightly different.
The order book lists prices at which people want to buy and prices at which people want to sell.
You can see btc-e's order book on their homepage. Let's assume the following simple order book:
SELL ORDERS:
    person 1 wants to sell 3 BTC for 101 EUR/BTC
    person 2 wants to sell 1 BTC for 100 EUR/BTC
BUY ORDERS:
    person 3 wants to buy  2 BTC for  95 EUR/BTC
    person 4 wants to buy  5 BTC for  90 EUR/BTC

Note the ordering of the orders, it's on purpose. In all order books, the highers buy price is always lower than the lowest sell price.
Now, these people are passive traders (this is afaik not an official term), meaning that they are waiting for the price to reach a certain value in order to trade. Mostly, they do not need to buy/sell fast, but want to have a good price.
Then, there are active traders, that want to do their trades immediately. So, when I want to buy 1 BTC immediately ("at market price"), I will have to pay 100 EUR for it, as this is the best sell offer I can buy from. If I wanted to fast sell 1 BTC, I would get only 95 EUR for it, meeting the best buy order to sell at.
So in fact, when an active trader wants to buy 1 BTC, he actually creates a buy order for 1 BTC ar 100 EUR/BTC. This order will match the order from person 2, so they will trade. This means that the trade is initiated by the buy order from the active trader. For this reason, this trade will be logged as a buy trade.
Rounding up: Trades are logged according to the type of trade the active trader did.
Some things that are useful to keep in mind:

The bid/ask prices that most exchanges advertise, are the highest buy and lowest sell prices from the order book, respectively.
A buy trade will raise the lowest ask price (or keep it the same), while a sell trade will lower the highest bid price.


text:
What does "Not yet redeemed" mean in a BlockExplorer transaction output?
Just digging around BitCoin Explorer and I came across a neat transaction. More so, curious, does the second output where it lists "Not yet redeemed" mean that someones BitCoin wallet didn't accept that transaction or something?
http://blockexplorer.com/tx/01ccb4aff48836c9ebe93caa83d7090eb2f76fa71275a9d6766cc8f32c82af39

Hint: blockexplorer is terrible, you might want to switch to blockchain.info https://blockchain.info/tx/01ccb4aff48836c9ebe93caa83d7090eb2f76fa71275a9d6766cc8f32c82af39

No, it means that those coins are not yet spent.
Bitcoin transactions work with inputs and outputs. Every transaction can have one or more inputs, and it may then create one or more outputs of which the total amount adds up to the sum of the inputs (minus the transaction fee).
Only coinbase transactions do not require inputs. Those are the first transaction in every block that gives the miner of the block his block reward and all the fees from the transactions in the block.
When you want to spend bitcoins from one of your addresses, you will have to find an "unspent transaction output" for that address, make a transaction with the output and assign new inputs.
What this means is that an address does not really have a balance stored in the block chain. There is just a list of unspent outputs, and those that are bound to some address add up to this address's balance.


text:
So... bitcoin is dying?
In the upcoming months the difficulty on the chain will cause GPUs to be non profitable (or so I hear).
So all we can do now is mine with ASICs - and even then see returns after a YEAR?
That will be the death of bitcoin .... If mining isn't profitable - no one mines - no one mines no coins generated and transactions fail ?
What are people thinking still trying to make rigs etc? Or am I completely mistaken?

Non profitable means there is too much processing power already.

which is there because it is profitable. Unless you plan to support it out of charity ?

If no one mines, mining will be profitable again. That's what the difficulty is about.

Besides, Bitcoin is more than only mining. Eventually, only a small part of the big Bitcoin community will mine, while the others use it for what it's meant to be used. As a payment option and a currency.

People are still building GPU rigs?   I suppose it happens -- especially if a person isn't aware of what ASICs bring to the table) but probably this isn't occurring in any significant number anymore.

Nobody goes to that restaurant, it's too crowded.

Bitcoin's difficulty adjusts itself automatically according to the amount of hashing power available. Since not every miner has the same profit margin, they may be shutting off and turning on at different times. Because of this in the end only the most efficient miners will be mining.
In case there is a sudden drop in mining profitability (like say after the 2011 bubble), a lot of miners might drop off the network. As long as some of them still mine (those that are in for the long run and the idealists that will mine no matter what at the very least), that won't harm the network. The block generation might slow down for 2 weeks, but after the amount of hashing power stabilizes, everything will go back to normal. Bitcoin is a self-correcting system.
So as long as the amount of hashing power that suddenly drop out of the network is not really big, Bitcoin will be unaffected in the long run.

Bitcoin automatically adjusts difficulty every so often so if mining is not profitable then people will stop mining and the difficulty will drop, making mining profitable again.  Unless there is a sudden crash in mining power Bitcoin will tick along happily.
Mining is never going to be wildly profitable, but the doomsday scenario you are suggesting is not going to happen.

Mining services are paid for using a subsidy.  Currently this subsidy pays out 3,600 BTC (worth about 400K USD) each day.
Some miners will save their proceeds, others will cash out to fiat (especially the GPU miners who have high electric bills) and a small minority of miners will spend their mined coins in the Bitcoin economy.
So it matters little to the Bitcoin economy that the GPU miners will no longer be receiving enough to cover their electricity costs (and will be forced to retire that hardware).


text:
Selling BTC from BitMinter
I have started mining with BitMinter.com and am nearing a complete bitcoin. I have searched for hours for my account/wallet address so I can move bitcoins from BitMinter to an exchange. I can't seem to find that, or any way to sell any bitcoins I have worked for. How do I get my bitcoin from BitMinter to somewhere like fastcash4bitcoins.com?

Bitminter has an auto cash out function. On the Account homepage, you can set a Bitcoin address to which your coins are deposited as soon as you reach a certain amount.
I assume you already have a Bitcoin wallet somewhere that can give you an address to enter in the auto cash out form. If you don't, visit this page on the Bitcoin website and create a wallet. (I recommend you for simplicity and security considerations to choose a web wallet or a fast wallet like Multibit or Electrum.)
Once you set up auto cash out, you will receive your bitcoins in your wallet. They you can create an account on an exchange that allows you to sell bitcoins. They will give you a deposit address to which you will need to send your bitcoins using your wallet. As soon as the deposit arrives, you can sell your coins and withdraw the cash from the exchange site.

Ah I see, I was under the assumption that the bitminter.com account was my wallet. Thank you very much for your explanation!


text:
How to verify ASICMiner share ownership through Bitcoin address / blockchain.info?
How do I verify ownership of ASICMiner shares through a Bitcoin address given that matches with a signed message I've been sent?

Hi Tom! I assume you mean blockchain.info so I will change the title.

Go to https://blockchain.info/address/16fuoinLFjBmiCYmCYDXPNfERJtdPB5ASe
Check if the same address as he has signed the message with is on that page. This will only tell you that he had the shares the moment the dividend was paid.
Or you can ask friedcat on bitcointalk.org to confirm the ownership of shares.