text:
How does Bitcoin keep track of account balances?
I downloaded the latest bitcoin client and am waiting for it to connect. How does it remember how much money a person has? Do I create an account and the balance is associated with the account each time I log in?
Another thing I don't get is how come there's ways to get free bitcoins, such as through mining or websites? Isn't it unfair that some have their money they worked for transferred to bitcoins where others depend on the strength of their computer to make them money? Is it that the free ways of getting bitcoins never give out that much it's not a problem?

Mining isn't free. Where I live electricity costs 13 cents a kilowatt hour. If a website wants to give you their bitcoins for nothing that's their right. As for how the bitcoin client figures out how much money everybody has, well, that's a bit complicated. See https://en.bitcoin.it/wiki/Block_chain

And how did the people who have strong computers obtain them, if not by working for them?

https://bitcoin.stackexchange.com/a/79563/87861 Here I tried to explain how balance is calculated in Bitcoin network, implementation wise.

Those are quite some widespread questions.
Tracking of account balances
There are two parts that keep track of an accounts balance:

each node keeps track of the transaction history
a node keeps track of the private keys for the accounts it owns

Bitcoin at its core is a distributed ledger that keeps track of every transaction ever executed. Every node in the network stores a copy of the complete transaction history and can therefore reconstruct the balance for each account. Catching up with the rest of the network will take quite some time exactly because you need to download and verify the whole transaction history.
The private keys come into play when bitcoins are transferred from one account to another. To spend bitcoins you have to create a transaction and the owner of the sending account has to authorize the transaction by signing it with the private key associated with the account. So anybody that knows the private key to an account may spend the bitcoins that are in that account. Bitcoin-QT (the client you downloaded) creates a file on the harddisk called wallet.dat, which contains all the private keys for your accounts, so don't lose it. Other clients use different methods of storing the private keys.
Mining (or "free" bitcoins)
Mining is Bitcoin's way of minting new currency. There is no central bank that prints bitcoins, instead nodes are rewarded for their help in the network. They help the network by verifying and confirming the validity of transactions in the network.
As others have pointed out mining is not free: the initial investment in mining equipment has to be amortized and electricity has to be paid. While initially it was easy to mine, the fact that you compete with all the other miners about a limited supply of new bitcoins mined has quickly driven the cost of mining up.
Mining nowadays requires such a high investment that some miners never break even.

The reason I ask is because what happens if I get a new computer, do I lose all my bitcoins? Or is it as simple as copying wallet.dat to the new computer?

That's absolutely right: the wallet.dat file has to be kept save. Do not lose it as it is the only way of accessing your bitcoins and under no circumstance share it with untrusted people as anyone who has it can transfer the bitcoins. If you get a new computer simply transfer the wallet.dat to the new computer.

@Celeritas notice you can also use an online wallet, such as https://blockchain.info/wallet/


text:
When I buy a Bitcoin with dollars, where does the money go to?
I understand the networking concept of the coin, but I am not sure I understand the purchase process.
Let's say I have 1000$ that I want to spend on Bitcoins, who do I give this money to?

You give the money to someone who has bitcoins available to sell to you.
This might happen via an exchange such as bitstamp.net which matches buyers and sellers.

source: Stack Exchange

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

sort: votes


text:
Bitcoin exchange language coding
I am looking at coding a Bitcoin trading exchange,  Would PHP be sufficient for an order matching engine?  The server would be load balanced with running MySQL.

Yes, I have built exchanges with PHP and MySQL. I would also recommend Redis for caching.

Cheers! appreciate it, will look into Redis.

does it support row locking like innodb?

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


text:
Verification progress decreasing when validating genesis block
I've been experimenting with the litecoin source and have decided to make my own token network for personal use. I've mined my own genesis block, and assigned unique identifiers for base58Prefix and pchMessageStart.
getblockchainInfo returns:
{
   "chain" : "main",
    "blocks" : 0,
    "headers" : 0,
    "bestblockhash" : "00000ee1064237cca4001f4707031d29c0253c09005c67f0ff9fdeb268591c26",
    "difficulty" : 0.00024414,
    "verificationprogress" : 0.00255052,
    "chainwork" : "0000000000000000000000000000000000000000000000000000000000100010"
}

verificationprogress has been steadily decreasing, but according to https://bitcoin.org/en/developer-reference#getblockchaininfo verification progress is supposed to start at 0 and increase to 1, is it validating correctly? If so will I receive the premine reward once the genesis block is fully verified?


text:
Why does Bitcoin Core not produce a Reject message for Conflict TXs?
From the perspective of a full node participant in the network, why is it a bad idea to convey to a peer that a transaction has been rejected because its either a conflict transaction/high fee transaction or a transaction which already known to it?
I noticed that in the Bitcoin Core source code that REJECT_CONFLICT is set at 0x102 which is greater than REJECT_INTERNAL.
if (state.GetRejectCode() < REJECT_INTERNAL) // Never send AcceptToMemoryPool's internal codes over P2P
    pfrom->PushMessage(NetMsgType::REJECT, strCommand, (unsigned char)state.GetRejectCode(),
                       state.GetRejectReason().substr(0, MAX_REJECT_MESSAGE_LENGTH), inv.hash);

Bitcoin Core code excerpt from src/main.cpp.

Because it is a waste of bandwidth to convey information that your peers should be calculating themselves anyways. It is also a bad idea to rely on peer's calculations of whether a transaction should be rejected or not because they could be lying to you.


text:
How can I view the current blockchain size?
How can I view the current size, preferably in bytes, of the blockchain? Is there a CLI command for bitcoind? Or a website that displays the size?

If you have the bitcoin client running in server mode, you can pass it the getblockchaininfo command. This is the current output:
{
  "chain": "main",
  "blocks": 525329,
  "headers": 525329,
  "bestblockhash": "000000000000000000192cf4d557fb2265855713b0fd208a6490bca81137bce4",
  "difficulty": 4306949573981.513,
  "mediantime": 1527792344,
  "verificationprogress": 0.9999976722383654,
  "chainwork": "000000000000000000000000000000000000000001e6cf0d64537cc800fc54f8",
  "pruned": false,
  "softforks": [
    {
      "id": "bip34",
      "version": 2,
      "reject": {
        "status": true
      }
    },
    {
      "id": "bip66",
      "version": 3,
      "reject": {
        "status": true
      }
    },
    {
      "id": "bip65",
      "version": 4,
      "reject": {
        "status": true
      }
    }
  ],
  "bip9_softforks": {
    "csv": {
      "status": "active",
      "startTime": 1462060800,
      "timeout": 1493596800,
      "since": 419328
    },
    "segwit": {
      "status": "active",
      "startTime": 1479168000,
      "timeout": 1510704000,
      "since": 481824
    }
  }
}

The blocks field is the current number of blocks in the block chain. You can also get this information from BlockExplorer or use the Direct Link to the block count.
If you want the size in bytes, look at the size of your blk0001.dat file, currently 528Mb.

Upvoted. Interesting file size though, mine is only 550MB.

Thanks for that correction. I was checking on a machine that had multiple copies of many blocks in it. (Don't ask.)

@David Schartz How did you know that there were multiple copies in the block database files?

It was due to a bug I introduced while working on the bitcoin client. I didn't realize they were still there. I figured when I fixed the bug, they'd go away. It's strange, the client still works perfectly fine with them there. (I'm cleaning them out now.)

Go to http://blockexplorer.com/q/getblockcount.
Other statistics are available at http://blockexplorer.com/q.

Is the block size in bytes always the same or is there something like an average block size?

It depends on how many transactions are in the block. You can find out the size of a block by looking at it on http://blockexplorer.com/. The average size for the last 1000 blocks (which will be not representative of the entire chain) is roughly 22Kb (http://blockexplorer.com/q/avgblocksize).

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


text:
How was the blockchain's "hard fork" automatically resolved?
As a result of an "official" change in back-end databases from BDB in v0.7 to LevelDB in v0.8, in addition to an increase (by some mining pools) to a higher block size limit, there was recent "hard fork" at blockchain height 225430.
Miners were originally told to switch back to v0.7, but then later informed that v0.8 was fine as long as they don't increase the default (256kb -- soft limit) block size.
So what happens to block 225430 for v0.8 miners? Are they required to reload the database from <225430 with new "max block size" limits? How did this problem supposedly just fix itself (as has been reported here), or is this still a problem as blockchain.info continues to "sequentially" report orphaned blocks here? My last question would be what happens to the transactions that were linked to block 225430 (and are now UTXO), won't v0.8 still consider them spendable?

I'm sure this all would make a lot more sense if I had a better
  understanding of Bitcoin's block reorg logic. Perhaps a pseudo-code
  walk-through of the process might help.

Edit: the 2 chains seemed to have merged here (after 32 sequentially orphaned blocks). So how exactly did v.0.8 clients handle the reorg for 32 blocks? Is there a maximum reorg that Bitcoin can handle? Was it easier to double-spend during the 5+ hour blockchain correction?

@Nicolai thanks for the answer, but I was really looking for a lot more detail as to WHY & HOW? blockchain.info shows the first non-forked block was http://blockchain.info/block-height/225462, 32 blocks after the "hard fork". So what happened to v0.8 clients and their 32 previously confirmed blocks (as in what happened "technically" in the v0.8 client when the chains merged at height 225462 and v0.8 now had the "wrong" chain)? Also, what's the longest "hard-fork" Bitcoin can withstand? I'm really looking for "technical" details. Thanks.

Maybe worth pointing out that BIP50, an effort to learn lessons from the event, had the term "hard fork" removed since the problem ultimately turned out not to be a new software version relaxing the rules.  For more "hard fork or not?" detail see https://bitcoin.stackexchange.com/q/36090.

The highest blockchain containing only valid blocks is always the "correct" blockchain.
The first 225430-block was accepted by 0.8 clients/miners, but due to a flaw in 0.7 clients/miners couldn't accept the block.
The 0.7-fork was accepted by all client and miners, and the 0.8-fork was only accepted by 0.8 clients/miners. The core Bitcoin developers decided they wanted the 0.7-fork to be highest, however 0.8 had the most mining power, so the developers asked mining pools to switch back to the 0.7 client.
After some time, the 0.7 blockchain (which didn't have the "flawed" transaction) was highest, and 0.8 clients/miners would treat this as being the "real" blockchain (and stop mining on the blockchain with the transaction 0.7 clients didn't accept).
The 0.8 fork is simply treat as many orphaned blocks and is not worth anything (it can't be spend, etc).

that is unfortunate, how can we ensure against something like this again, just curious

@CQM, what's unfortunate? This behaviour is by design, and meant the problem was quickly resolved

@HighlyIrregular no, the design is that bad blocks are solved by the network without human intervention. The whole point of bitcoin is so that there is no central authority to decide the fate of the currency, as the 0.8 miners found out was not such an absolute

@CQM, the 0.8 miners could have continued as they were if they chose, but that would have caused problems for the minority of the network running an older version. Enough of them preferred not to do this that the 0.7 version of the blockchain was intentionally chosen by the majority. Essentially, it was a vote with hashpower, which is by design. I agree it wasn't intentional for the fork to occur, but the way it was resolved was actually quite elegant, which is probably why the exchange rate is still strong.

@HighlyIrregular I too was pleased with the outcome, but this does raise concerns, especially for a solo miner that would prefer a hands off approach. Miners and merchants alike would need an automated alert

@CQM, I agree, and you're right to ask how this can be prevented from recurring.

It was not a vote of hashpower choosing one chain over another. It was hashpower choosing to either continue as two chains or as one. The 0.7 chain was the only one compatible with all software out there, so it was the only possible choice if they didn't want to have a permanent fork.


text:
What is a soft fork? What is a hard fork? What are their differences?
When people talk about possible changes to how Bitcoin works they sometimes say a particular change can be implemented as a soft fork. What does that mean? How does this compare to a hard fork?

related: What is a hard fork?

What is a Project Fork?
A fork in software development refers to the event of an independent project spinning off from a software project. Such forks sometimes occur in the opensource sphere, when there are irreconcilable plans/goals within a project's community, then often leading to a split in the community and two distinct projects thereafter.  In practice this takes form in the sourcecode being copied and henceforth being developed in a different direction independently by the forkers. For example in this conventional sense of fork, Litecoin is a fork of Bitcoin: Litecoin started as a copy of Bitcoin's code-base, but developed into an independent project (although still closely related).
Softfork and Hardfork in Bitcoin terminology
The terms softfork and hardfork in Bitcoin describe compatibility breaking changes in the Bitcoin protocol: Should the community be irreconcilably divided about such an issue, the old version and the new version of Bitcoin could emerge as distinct projects thereafter. While both versions of the Bitcoin protocol are in use, the differences in acceptance may cause a lasting blockchain-fork, i.e. two distinct longest chains which are both considered valid by part of the network.
Softforks are forward compatible
Softforks restrict block acceptance rules in comparison to earlier versions.

The new rules allow a subset of the previous valid blocks, therefore  all blocks considered valid by the newer version are also valid in the old version. If at least 51% of the mining power shifts to the new version, the system self-corrects:
Blocks created by old versions of Bitcoin Core that are invalid under the new paradigm might commence a short-term "old-only blockchain-fork", but eventually, they would be overtaken by the chain fork created under the new paradigm, as the hashing power working on the old paradigm would be smaller ("only old versions") than on the new paradigm ("accepted by all versions").
However, if less than 51% of the hashing power switches to the new version,  the blockchain-fork will not mend automatically as the chain created under the old rules has more hashing power and is incompatible to the new rules. This can either be remedied by the adopters of the softfork giving up their chain, or more hashing power switching to the softfork chain. The latter would cause the softfork chain to eventually overtake and reorganize the other chaintip.
Hardforks are not forward compatible

Hardforks ease block acceptance rules making previously invalid blocks valid in the new version. Obviously, this is not forward compatible as older versions will not accept the new blocks, causing the users of the old paradigm to remain on their own blockchain-fork indefinitely. To implement a hardfork, without a blockchain-fork, all users must switch to the new protocol consensually.
HF != blockchain-forks
Lately, I've seen "hardfork" being used interchangeably with "chain split". They refer to different things. A chain split is the state of the network when mining is based on more than one chaintip at the same time. This can happen for various reasons, including hardforks, softforks, buggy node software, and simply two miners discovering a block at the same height.

Would be great if "fork" was defined. This question and answer seems to be about "software forks", which are completely different than "blockchain forks", correct?  I was under the impression blockchain forks happen on the daily, whenever two miners mine blocks nearly-simultaneously. http://bitcoin.stackexchange.com/questions/3343/what-is-the-longest-blockchain-fork-that-has-been-orphaned-to-date

@AlexMillar: Great point, I hadn't even thought about needing to define that. :)

Great answer. One thing I'm still confused on: if a soft fork can actually become a hard fork if it doesn't get 51% of hashing power, as you state - then what actually is a soft fork? It seems like there is no such thing as a soft fork and everything is a hard fork. What am I missing?

@BrianArmstrong: Successful soft forks auto correct: users that still run the old version are still on the valid chain. Just when the soft fork fails, it behaves like a hard fork: the ones running the new version are on a shorter chain,  but can't process the longer chain unless they switch to the old version.

What I meant there when I wrote this two years ago was that a soft fork with minority hash support would lead to a persistent chain split. However, it can still self-mend if more hashrate converges on the soft fork chain. It is still distinctly different from a hard fork as the software is forwards compatible.

Where can I find a list of cryptocurrency that support soft fork?

why only Bitcoin knows the term hard vs. soft fork? I never saw it for other open source projects.

@FyodorGlebov: Other projects usually don't rely on the whole network running exactly the same protocol rules.

In a soft fork the old nodes can accept a tx that is now invalid, and they will split off the main chain, so I don't see why it's much better than a hard fork.

@relG: I cover that in my answer. The relevant section is "However, if less than 51% of the hashing power switches to the new version, the blockchain-fork will not mend automatically as the chain created under the old rules has more hashing power and is incompatible to the new rules." If more than 50% of the hashrate does switch to the new rules, all nods will converge on the new rules, though.

Currently miners do always mine both ty-types(segwit and non-segwit) right? Is this intended to continue to be like that forever or will miners at some point stop lets say mining non-segwit txs? Because if they stop at some point, non-segwit funds are in danger.

@Invader: Most funds are still stored in non-segwit UTXOs. Hopefully, this will slowly diminish. However, even if a few miners may eventually stop to mine non-segwit transactions, others could continue to do so. It would then merely take longer for non-segwit transactions to be included. As long as non-segwit transactions pay competitive fee rates, miners have an economic incentive to include them.

@Much: My question was the result of lack of knowledge. It may sounded a little bit confusing...

Softforks are forwards-compatible
Old nodes will accept blocks created by new nodes.
With a softfork, only miners will have to upgrade, or else they will end up on the losing fork. Users and merchants can keep running older nodes, which will accept the newer blocks.
Hardforks are not forwards-compatible
Old nodes may not accept blocks created by new nodes.
With a hardfork, everyone (miners, users, and merchants) will need to upgrade to the new code.

Currently miners do always mine both ty-types(segwit and non-segwit) right? Is this intended to continue to be like that forever or will miners at some point stop lets say mining non-segwit txs? Because if they stop at some point, non-segwit funds are in danger.

I found the best exact definition in the First three paragraphs here: gavinandresen / BitcoinVersioning

We recently rolled out two changes to the Bitcoin block acceptance
  rules (BIP16 and BIP30); this document records the lessons learned and
  makes recommendations for handling future blockchain rule changes.
Note: there are "soft" rule changes and "hard" rule changes. "Soft"
  changes tighten up the rules-- old software will accept all the blocks
  and transactions created by new software, but the opposite may not be
  true. "Soft" changes do not require the entire network of miners and
  merchants and users to upgrade or be left behind.
"Hard" changes modify the rules in a way that old, un-upgraded
  software consider illegal. At this point it is much, much more
  difficult (some might say impossible) to roll out "hard" changes,
  because they require every miner and merchant and user to upgrade.

To quote Andreas Antonopulous:
you run a vegetarian only restaurant and if you change it to be an only-vegan restaurant then you are soft forking it, if you change it to include meat you are hard forking it
https://www.youtube.com/watch?v=rpeceXY1QBM

On a fork new nodes are introduced into the network, creating a 'dirty' network. I like to imagine green(old) and red(new) nodes maintaining a single blockchain at the launch time.
In a soft fork:

If a new red block is mined it is accepted by all nodes, the network bchain grows normally.
If an old green block is mined it is rejected by the new nodes, creating a do-or-die chain split. Unlike a normal chain split the new nodes will never accept the version with the old block.

As with each chain split the miners decide where they put their hashes. Since the hash difficulty doesn't change immediately the chain backed with most hashpower will grow the fastest.
If the 'redblock' chain has enough mining support they win the race and old nodes adopt their chain, and the process repeats every time an old block gets mined.
Eventually one of the following happens:

green blocks are no longer mined and the chain continues red. The fork was a successful upgrade.
two different chains stabilize, the green-red chain has become too long to be rejected by a longer all-red one.

In the case of the latter, brand confusion may ensue, two chains means one is an altcoin. When this happens good quality wallet software should be able to make transactions on one particular chain. Each user, exchange and wallet maker will decide on which chain gets the original brand name (if any), typically this is related to philosophical or political choices. E.g. the chain with the most nodes and users vs. the chain with the most hashpower.
If the original brand is agreed (~consensus) to be the red chain it is expected much of the hold-out hashpower will migrate to that chain, as the market value is strongly correlated to the name and not the underlying technology. The altcoin technology would have to be significantly better to avoid this brand-drain. When a fork does not include replay protection it promotes confusion and prevents separating transactions; this is seen as a hostile brand-takeover attempt.
The backwards-compatible nature of soft forks means they can succeed on hashpower alone. A single node producing enough blocks (51%) can dominate an older network. To avoid hash-domination the older network must separate. This can be done by introducing an unpatchable incompatibility (i.e. a new software version) turning the SF into a hardfork.
Note that the opposite does not follow: just because a SF with enough hashpower is guaranteed success, it doesn't mean a SF with little hashpower is doomed to fail. This is the theory behind the user activated soft fork (UASF) concept. The success of the UASF theory merely depends on:

a minimum threshold of miners to keep the transactions reasonably usable until the difficulty adjusts.
the original brand being transferred based on the (perceived) 'user support'.

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

authors: Алексей Санкович


text:
How can i print out my bitcoin address that resides on my android phone?
I run a repair shop and im thinking of taking bitcoins, but I want to get the QR image of my wallet address onto my site. The wallet address is on my phone, but I'm not sure how or where I can go to print out the QR image of my address. I did a google search, but everyone has a wallet generator. I just want to print out an existing address i have.

Here's a quick way to do it:
<img src="http://qrfree.kaywa.com/?l=1&s=8&d=$yourAddressHere" alt="QRCode"/>


text:
What happens to transactions in the mempool when their parent transaction expires?
I was just reading the Coin Metrics Newsletter #53, and it included a section about the recent mempool congestion. After mentioning transactions that got evicted due to the network's queue of unconfirmed transactions exceeding the default mempool limit, it mentions about transactions expiring due to the 14 day limit:

Secondly, transactions residing in the mempool for over two weeks expired. By default, Bitcoin Core nodes remove transactions from their mempool if no miner found transaction fees to be attractive enough to include them in a block over the last 336 hours (two weeks).
In total 1,627 transactions expired between May 25th, and May 30th. Only 35% of these resided in the mempool for two weeks. The remaining 65% likely spent unconfirmed parent transactions and became invalid as their parents expired.

In the last sentence (highlight added), the newsletter describes that transactions chained from expired transactions would get dropped from the mempool as well. Is that an accurate description of the mempool behavior?
If yes, let's say txA was in the mempool for two weeks and got dropped, and txB was a CPFP transaction spending an output of txA which therefore got invalidated and dropped as well.
What would happen if the original sender rebroadcast txB? Given that txB inputs would appear to not exist without the context of txA, would the peers of the sender request the preceding transaction txA or just reject txB? Would then the two transactions repropagate as a unit?

Yes, this is an accurate description of the mempool behaviour. When a transaction is expired from the mempool, its descendants are as well.
When txA gets dropped, so does txB. If we later re-broadcast txB (and it's not too large) our peers will add it to a (small) cache of orphaned transaction they keep for us. If we broadcast txA in the next 20 minutes (timeout for orphan tx cache eviction), and it passes policy checks on its own txA would be added back to the mempool.
Note that the peers would only request it if we send them an inv for txA.
However, there are no such thing as "propagation as a unit" on the P2P network currently (package relay design is being discussed here). This is the reason why in your example txA must pass the policy checks on its own.
This has implications on L2 protocols with pre-signed transactions, for example in the Lightning Network where the transaction relay is critical. A pre-signed txA which happens to be below most of the network mempool minimum feerate at the time of broadcast won't be accepted even with a high fee-paying txB (1)(2).

(1) This is the reason why the Lightning protocol kept the update_fee message even post anchor outputs.
(2) This has implication in other L2 protocols too. For example in Revault it could prevent one to unvault a vault until the mempool backlog is processed.

Such Transactions cannot be proceeded without output from their parents. Hence they are  also removed from the mempool


text:
Using bitcoin for international travel
Bitcoin as a meta currency seems very useful if travelling through multiple places using currencies. I had this very intention for when I travel around asia.
What is the best method people have discovered for having the most flexible use of bitcoin when switching back to native currencies in such a manner?
Obviously, keeping fees as low as possible would be excellent.

You should be wary when trying to travel only on Bitcoins, some people have failed in the past.
At the current stage of development, Bitcoin is not ready to be used to finance your local spending across multiple countries, as getting money to and from an exchange takes a long while. Moreover, you can't withdraw money easily this way into a foreign currency, so the model would work like holding all your money in your local bank and using a debit card to withdraw money at an ATM.
You could potentially have your fellow Bitcoin enthusiasts offer to sell you local cash for Bitcoins on the spot, but that would require a lot of preparation, contacting people, and trusting them to show up on time when you need the cash. Generally, not an ideal situation.
All in all, it can't really be done at the moment. Maybe in a couple years...
Update: BitInstant has announced that they will be releasing an international MasterCard funded by Bitcoins in a couple months.

+1 for the suggestion of getting local people to act as on the spot exchangers, and for difficulty of actually making that happen reliably

link is dead :/

https://localbitcoins.com might be a good resource for finding bitcoin buyers for local cash.

Bitcoin is different from a Western Union, for instance.  Western Union has 500,000 agents located around the world but each is operating with explicit approval from Western Union.
Bitcoin has no such restriction.  Exchange can technically be performed by any individual working independently.  All that is needed is a supply of cash and a mobile smartphone to run a bitcoin wallet app and to see the current exchange rate.
This activity doesn't occur much yet, but when it does it will likely be found first where travelers and techies are found -- coffee shops, hotels, hostels, hackerspaces, etc.  If any of these accept bitcoin themselves, they might already use the service of a local exchanger to convert their bitcoins back into cash.  These places would know how an in-person exchange could be found or they may offer this service themselves as a courtesy to their customer (just as a hotel might cash a check for a guest.)
There are directories of local traders, maybe there are enough exchangers already where this approach would be used for at least some of the trip.

http://en.bitcoin.it/wiki/In_Person_Traders
http://en.bitcoin.it/wiki/Real_world_shops
http://en.bitcoin.it/wiki/Category:Local


text:
Is there any way to measure relative occurrences of wallet theft over time?
Soon after Bitcoins became valuable enough to be worth stealing, I started seeing news about viruses/malware that steal Bitcoin wallets. Presumably, wallet encryption has reduced the level of this, but is there any way of measuring it?
Given that there is probably growth in the number of users, I guess you'd have to compare it with that figure to get a comparative figure over time for the chance of having a wallet stolen. Is that figure measurable?

Can we prove that wallets were stolen even?   Was Alinvain lying?  Nobody knows.

Nothing personal, but I don't think this can be answered in any form, voting to close.

Is a "no" answer not constructive?

The only way you can measure something like that, is if users would first of all know if their wallets get stolen, and second of all, if they reported that problem. Besides that there is no real way to know if a wallet actually got stolen, nor are there any means of verifying that it did.
On the other hand, if one was to steal a wallet from some big Bitcoin website (say, a pool, an exchange, or an eWallet), one probably could notice a change of pattern of transactions, and we might hear some official statements from website owners about the theft. In this case though, it would probably be more of "quality over quantity" theft, as in we wouldn't see many cases like this appear.

We now have confirmation that if a wallet was stolen from a pool, we would know about it - https://bitcointalk.org/index.php?topic=66916.0. (a Linode security breach allowed theft from slush's pool, Gavin's faucet and others). This particular failure mode has little relevance for people keeping a wallet at home.

Of course, you might be left wondering as to whether a theft was real or staged, as with mybitcoin.com

@MeniRosenfeld, great example; thanks for the link. I don't believe it proves anything in a more general sense though. There's no guarantee that we would be told in every case that bitcoins are stolen.

It's worse than we thought, a huge amount has been stolen from Bitcoinica - https://bitcointalk.org/index.php?topic=66979


text:
What would be the technical, and wider, implications of a cryptocurrency that used proof-of-disk-space?
ShelbyMooreIII is promoting AnonyMint and/or AnonyCash as a concept* cryptocurrency based on a disk-space intensive algorithm. Some details are given here: http://anonymint.org/#Proof-of-Work_Designs
What would be the positive or negative impact of this kind of software on:

The disk you're running it on
The CPU/GPU of the PC
The HDD market
The environmental effects of increased disk manufacture (I'm assuming here that such a currency would cause an increase in production)
Anything else substantially affected

*I don't know what stage of development AnonyMint is at.

I'm speculating here, because I'm not going to test anything out.

The IOPS would like shoot through the roof. The potentially large amount of writes and reads will likely affect disk life, especially if the disk is an SSD. It would generate excess heat. A magnetic disk would also generate constant vibration. Heat can be controlled easier than GPU or CPU heat because there's less of it, and vibration can be dampened using rubber mounts. The largest risk is simply drive failure due to above average activity.
The GPU would likely be idle. The CPU would only be necessary to drive the hardware operations.
I think it may be difficult to get a 3 TB drive for that new gaming rig, because all of the miners would be trying to pack as much disk space into a device as possible.
I don't know enough about the manufacturing process to hypothesize accurately.
I could see a lot of need for drive recycling. HDDs burn out a lot quicker and take up a lot more waste weight than CPUs and GPUs.

What's interesting about the proof-of-storage-space concept is that it can really take advantage of unused space on consumer devices. I know I've got a 500 GB hard drive in my work computer that has never seen more than 50 GB on it. Amalgamate that across a corporate network, and there's probably PB of space available! I could see malicious types taking advantage of this in malware pretty easily, too: high CPU or GPU usage causes lots of heat and terrible performance, while high HDD usage can just make a program take a few seconds longer to start up.


text:
What are the pitfalls of repurposing the nLocktime field for backward compatability in eltoo?
In the eltoo proposal for paymentchannel management with less overhead proposed by Christian Decker et al. the update transactions need to be ordered. In chapter 4.1.2 of the proposal it is described for the sake of being backwards compatible that the nLocktime field can be repurposed within the update transactions.
Are there any other pitfalls of this solution besides the fact that it seams a little bit hacky?

I was hoping somebody else would answer this, since I am the author of eltoo, I would have preferred an independent answer.
To recap: the locktime is used in eltoo to enable a numeric comparison between an element on the stack (state number) and a value that the signature commits to. The reason we can't simply push a number on the stack ourselves is that this push would happen in the redeemScript, which cannot be committed in the signature, since it contains the signature. OP_CLTV combines the push, comparison and verification in one opcode:

Marks transaction as invalid if the top stack item is greater than the transaction's nLockTime field, otherwise script evaluation continues as though an OP_NOP was executed.

To your question about it being safe: OP_CLTV is the only opcode that ever touches the nLocktime (intended to be used in the scriptPubkey), and the only other use is to mark a transaction as invalid until a certain height. Both usecases only specify what happens with future blockheights and timestamps, and do not have any effect if the nLocktime is in the past.
Therefore eltoo's use of the nLocktime field and OP_CLTV is technically not a repurposing, rather it makes use of the existing semantics.
Of course I can't foresee if there is any future proposal that might want to repurpose past blockheights and timestamps, but I'm not aware of any, and searching the BIPs doesn't return any conflicting results. It'd also be very unsafe redefine its semantics for timestamps that were plausible in the blockchain, leaving us a few million unique timestamps even if we only consider 2009-01-03 - today.


text:
Unable to remotely access lightning-charge
My setup is a little bit complicated and I'm almost sure that my problem is port related.
So I'm running Mac OS X 10.13.4 with Parallels Desktop with a Ubuntu 14.04 VM. I managed to setup bitcoin core in the VM, on top of it I installed c-lightning and managed to fund it with btc (All is happening on the testnet) which I used to open one channel with some random other node. Everything is perfect for now.
Because I want to use the LApp for WordPress Lightning-Publisher I Installed lightning-charge and started an HTTP server running on the default port 9112. All of my ports are correctly forwarded and in my bitcoin.conf file I have allowed all ips. If I run Mozilla in my Ubuntu VM and go to http://api-token:mySecretToken@localhost:9112/info everything is fine, but when I try this on my Mac I get Can't open the page because the server unexpectedly dropped the connection. If I try using my external ip it's the same thing.
Using several sites to check if my ports are correctly forwarded I get that all corresponding ports are open (18332 for BTC core, 9735 for c-lightning and 9112 for lightning-charge).
Here is my bitcoin.conf

testnet=1
server=1
rpcallowip=0.0.0.0/0
rpcuser=someuser
rpcpassword=somepass

addnode=104.237.131.138
addnode=151.80.205.132
addnode=192.155.82.123
addnode=74.220.255.190
addnode=80.100.203.151

here is my lightning config

network=testnet
alias=IVCHOBIVCHO
port=9735
rgb=008000

Proof that 9112 is open:

Proof that lightning-charge opens from inside the VM:

And in Safari on my mac (using localhost:9112 returns the same error):

Neither Ubuntu, nor my Mac are under any kind of Firewall. My router is TP-Link

After a lot of research I found the solution to my problem.
I didn't know this, but in nodejs there's a huge difference if your server runs on 127.0.0.1 and on 0.0.0.0.
It isn't said in the lightning-charge docs, but except the --port attribute you also have --host which you can set.
Starting lightning-charge with this line charged --api-token mySecretToken --host 0.0.0.0 fixed all of my problems. Gosh was that an unpleasant journey!

127.0.0.1 is the loopback address (also known as localhost). ... If a host has two ip addresses, 192.168.1.1 and 10.1.2.1, and a server running on the host listens on 0.0.0.0, it will be reachable at both of those IPs.


text:
Lightning Payment failed (Could not find a route)
I tried to move funds between my two nodes. From A to B.
'A' node is
035ac00f3bfe7fd991ec7cd9b5fcad0bdaa338c343895e56f4ada7df181bc43622@46.101.114.3:9735

'B' node is
02b0de5dece2ae1c6cf62dba60e584268b8f27babb936a849e998c2170802efc9b@5.9.72.48:9735

First I made an invoice on 'B' node with the full amount available on 'A' node (150000 satoshi), but it didn't worked like the second time, when I calculate already the fees into the transaction, so I requested an invoice with 147900 satoshis.
The second invoice I made with the 'B' node:
root@Debian-94-stretch-64-minimal ~/lightning # cli/lightning-cli invoice 147900 1 movingfunds
{
  "payment_hash": "7d7f8720cfa3d745bc15698e7f5908ddf658fa6241cfeb51e3085d338140766a",
  "expiry_time": 1529652202,
  "expires_at": 1529652202,
  "bolt11": "lnbc1479n1pdje9w6pp504lcwgx050t5t0q4dx887kggmhm937nzg887k50rppwn8q2qwe4qdqjd4hhv6twvan82mnywvcqp25ajsmsdp9g9e9xcdwl26f6h37xusn4d2q30mde40lvekrhlcajxs9y6c70qzcmhxcu6kjm6wtm2f6u5dgutn4q3tsluzrmmtvuhw65gpg920uv"
}

I tried to pay with the 'A' node:
root@LightningN:~/c-lightning/lightning# cli/lightning-cli pay -k maxfeepercent=5 bolt11=lnbc1479n1pdje9w6pp504lcwgx050t5t0q4dx887kggmhm937nzg887k50rppwn8q2qwe4qdqjd4hhv6twvan82mnywvcqp25ajsmsdp9g9e9xcdwl26f6h37xusn4d2q30mde40lvekrhlcajxs9y6c70qzcmhxcu6kjm6wtm2f6u5dgutn4q3tsluzrmmtvuhw65gpg920uv
{ "code" : 205, "message" : "Could not find a route", "data" :
{
  "getroute_tries": 3,
  "sendpay_tries": 2,
  "failures": [
    {
      "message": "reply from remote",
      "type": "FAIL_PAYMENT_REPLY",
      "erring_index": 1,
      "failcode": 4103,
      "erring_node": "02f6725f9c1c40333b67faea92fd211c183050f28df32cac3f9d69685fe9665432",
      "erring_channel": "520051:68:0",
      "route": [
        {
          "id": "02f6725f9c1c40333b67faea92fd211c183050f28df32cac3f9d69685fe9665432",
          "channel": "527929:1112:1",
          "msatoshi": 155190,
          "delay": 326
        },
        {
          "id": "02e8334fcab092f496bce7421e8d711d41cbbfef0429bb30149784418df53dd1b1",
          "channel": "520051:68:0",
          "msatoshi": 154189,
          "delay": 312
        },
        {
          "id": "02ad6fb8d693dc1e4569bcedefadf5f72a931ae027dc0f0c544b34c1c6f3b9a02b",
          "channel": "520051:63:0",
          "msatoshi": 153188,
          "delay": 298
        },
        {
          "id": "025e77156e4c5e1ed62f9ad113ac2115a981ee99fa05d95be9e43add7f785a9b4d",
          "channel": "519778:1560:0",
          "msatoshi": 153187,
          "delay": 154
        },
        {
          "id": "02b0de5dece2ae1c6cf62dba60e584268b8f27babb936a849e998c2170802efc9b",
          "channel": "528515:2266:1",
          "msatoshi": 152188,
          "delay": 10
        }
      ]
    },
    {
      "message": "reply from remote",
      "type": "FAIL_PAYMENT_REPLY",
      "erring_index": 3,
      "failcode": 4103,
      "erring_node": "025e77156e4c5e1ed62f9ad113ac2115a981ee99fa05d95be9e43add7f785a9b4d",
      "erring_channel": "528515:2266:1",
      "channel_update": "b5bf64e0b15971ffb29e148080d717baac4aa707bd66214fd15585fdb1035af068de16ea66698a780814564733606ac8d1aa06ef9ddcce0d7b1b2e593f8734b06fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d61900000000000810830008da00015b2b7930000000900000000000000001000003e700000001",
      "route": [
        {
          "id": "02f6725f9c1c40333b67faea92fd211c183050f28df32cac3f9d69685fe9665432",
          "channel": "527929:1112:1",
          "msatoshi": 154711,
          "delay": 312
        },
        {
          "id": "02ad6fb8d693dc1e4569bcedefadf5f72a931ae027dc0f0c544b34c1c6f3b9a02b",
          "channel": "528371:1680:1",
          "msatoshi": 153710,
          "delay": 298
        },
        {
          "id": "025e77156e4c5e1ed62f9ad113ac2115a981ee99fa05d95be9e43add7f785a9b4d",
          "channel": "514137:241:0",
          "msatoshi": 153709,
          "delay": 154
        },
        {
          "id": "02b0de5dece2ae1c6cf62dba60e584268b8f27babb936a849e998c2170802efc9b",
          "channel": "528515:2266:1",
          "msatoshi": 152710,
          "delay": 10
        }
      ]
    }
  ]
} }

What's wrong? As I see the final ID is my second nodes ID so, they need to see each other.

Seems you are a bit unlucky here: the pay command tried two different routes which both failed, and then couldn't find a third route. The first one failed at node 02f6725f9c1 which I happen to have access to. So let's see what the error was. The path tried to route 147900 mSatoshi over that channel (plus some fees but let's ignore that for now). At the time of the attempt the channel looked like this from the node:
$ lightning-cli listpeers | jq '.peers[] | select(.id == "02e8334fcab092f496bce7421e8d711d41cbbfef0429bb30149784418df53dd1b1")'
{
  "id": "02e8334fcab092f496bce7421e8d711d41cbbfef0429bb30149784418df53dd1b1",
  "connected": false,
  "channels": [
    {
      "state": "CHANNELD_NORMAL",
      "short_channel_id": "520051:68:0",
      "channel_id": "8f48128e5be0d9f7c0d142388b22cd8eb7e624333c25ae0de9790486101c4579",
      "funding_txid": "79451c10860479e90dae253c3324e6b78ecd228b3842d1c0f7d9e05b8e12488f",
      "msatoshi_to_us": 0,
      "msatoshi_to_us_min": 0,
      "msatoshi_to_us_max": 0,
      "msatoshi_total": 50000000,
      "dust_limit_satoshis": 546,
      "max_htlc_value_in_flight_msat": 18446744073709552000,
      "their_channel_reserve_satoshis": 0,
      "our_channel_reserve_satoshis": 546,
      "channel_reserve_satoshis": 0,
      "spendable_msatoshi": 0,
      "htlc_minimum_msat": 0,
      "their_to_self_delay": 144,
      "our_to_self_delay": 144,
      "to_self_delay": 144,
      "max_accepted_htlcs": 483,
      "status": [
        "Loaded from database"
      ],
      "in_payments_offered": 0,
      "in_msatoshi_offered": 0,
      "in_payments_fulfilled": 0,
      "in_msatoshi_fulfilled": 0,
      "out_payments_offered": 0,
      "out_msatoshi_offered": 0,
      "out_payments_fulfilled": 0,
      "out_msatoshi_fulfilled": 0
    }
  ]
}

As you can see, all funds are owned by the remote side 02e8334fcab, so there is no way for us to send in that direction (if we have 10 bucks on the table and the other side owns all of it, I can't possibly pay them with the money). The pay command therefore saw the failure and attempted again.
For the second attempt, the payment still goes over 02f6725f9c1, but this time we have sufficient balance to forward it:
lightning-cli listpeers | jq '.peers[] | select(.id == "02ad6fb8d693dc1e4569bcedefadf5f72a931ae027dc0f0c544b34c1c6f3b9a02b")'
{
  "id": "02ad6fb8d693dc1e4569bcedefadf5f72a931ae027dc0f0c544b34c1c6f3b9a02b",
  "connected": true,
  "channels": [
    {
      "state": "CHANNELD_NORMAL",
      "short_channel_id": "528371:1680:1",
      "channel_id": "129a51f6055fb609e163c44ca10f060474348048d239ba66e3c0422a45b09b1f",
      "funding_txid": "1e9bb0452a42c0e366ba39d24880347404060fa14cc463e109b65f05f6519a12",
      "msatoshi_to_us": 501772528,
      "msatoshi_to_us_min": 0,
      "msatoshi_to_us_max": 502073023,
      "msatoshi_total": 2000000000,
      "dust_limit_satoshis": 546,
      "their_channel_reserve_satoshis": 0,
      "our_channel_reserve_satoshis": 20000,
      "channel_reserve_satoshis": 0,
      "spendable_msatoshi": 481772528,
      "htlc_minimum_msat": 0,
      "their_to_self_delay": 144,
      "our_to_self_delay": 240,
      "to_self_delay": 144,
      "max_accepted_htlcs": 483,
      "status": [
        "CHANNELD_NORMAL:Reconnected, and reestablished."
      ],
    }
  ]
}

But this time the last hop (025e77156e4c5) before reaching your node failed to forward. We can't inspect that last hop without access, but since you mention that you are the other side of the channel you use lightning-cli listpeers to see whether the other side has sufficient balance (msatoshi_to_us < msatoshi_total). My guess is that you opened the channel, and therefore own the entire balance (if you already own all of the money on the table how should they pay you?).
If you first try to transfer some funds somewhere else (just buy some pixels on satoshis.place or read an article on yalls), then you should be able to route to your node.

Thanks @cdecker for the advice, I tried it to buy some pixels on Satoshi's Place with Node 'A' but I got the following error: http://snippi.com/s/t22p5ow
If I type listpayments command I get the following result: http://snippi.com/s/oc4d8t6

Seems the payment took a bit longer than expected so the pay command decided to send it to the background. It should eventually resolve into either success or failure.

It gone to 'failure'. I tried even on the other Node, the same happened: http://snippi.com/s/d4406by

The majority of those fail with failcode=16394, which is the numeric code for unknown_next_peer. This means that the node that reported the failure does not (or more likely no longer has) a channel to the next hop. This should eventually be recognized by your node through gossiping. The other codes 4103 and 4108 are for temporary_channel_failure and fee_insufficient. All of these seem to be caused by stale network information. Is your node connected and processing gossip (logging about channels being updated)?

I see only the orriginal channels when I use 'listpeers' at both of my nodes.
Node 'A':
http://snippi.com/s/njz6yf9
Node 'B':
http://snippi.com/s/13itv67

That's how it's supposed to work, since only those are your direct peers. listnodes and listchannels will show all known nodes and channels.

what should I check, when I run those two commands? I got so much results, that I can't even see all of it, just the last 'X' amount.

If you see channel_update and channel_announcement lines  in the lightningd output, then it should be syncing alright.

If I run the 'listnodes' and 'listchannels', on both of my nodes, I don't see in the (partial) results any 'channel_update' or 'channel_announcement'. What should I do now? :(

I don't mean when you call lightning-cli, I mean the output of the lightningd process.

Finally I got what you needed. Here is the log: http://snippi.com/s/3jb5hy2


text:
`lnd` on Raspberry pi zeros?
Did somebody try to run the bitcoind full node on the Raspberry pi 3 and one or more lnd nodes on one or more Raspberry pi zeros?
My goal is to support multiple LN clients without having to run a full node for each client. Raspberry pi zeros are cheap, storage and bandwidth are not.

One node to rule them all and in the darkness bind them
Run a Raspiblitz (EUR120)
https://github.com/rootzoll/raspiblitz
Then run slave devices on ESP32 (EUR5)
https://github.com/musdom/sploony
https://github.com/arcbtc/1.21
121 would need to be ported with macroons

I saw this sploony thing on Twitter. Awesome.
sploony is just e representation layer for a lnd node.
I'd like to run multipe lnd wallet/nodes against the same bitcoin full node.


text:
Have a 0/unconfirmed transaction stuck over 12 hours
This is my first time using bitcoin and I've had a transaction stuck for over 12 hours.   Any help getting confirmed would be appreciated.
https://blockchain.info/tx/0b17a765b1f4a1a7e53a47b6da287b86211ea64126192ffc26a1d6d8920eab7a

Your transaction did not include a transaction fee. It will probably take days until it is confirmed or may never be. This can be fixed creating another transaction that spends the same money, but includes a transaction fee. Which wallet did you use?

Also see: http://bitcoin.stackexchange.com/questions/9046/why-is-my-transaction-not-getting-confirmed-and-what-can-i-do-about-it

bitcoin-core .  I thought it set recommended fees

Strange. What version was that?

Bitcoin Core version v0.12.0 (64-bit)

This was my 1st bitcoin transfer and I didn't realize anything about fees and such..  but  as ive been reading now for 13 hours different posts on 0 unconfirmed transactions I'm not sure how to proceed with either cancelling or waiting till it confirms

Depends on how urgently you wish to resolve the issue. If you have a few days, you could wait for the transaction to no longer be broadcasted, then run Bitcoin Core with -zapwallettxes to make it forget about the transaction. You could then send all your money to yourself, to overwrite the transaction.
Or you could try to doublespend, by running Bitcoin Core with -zapwallettxes now. However, other nodes would send you your first tx back, so you'd probably want to go offline until you've created the new transaction. As most nodes don't relay doublespends, it might still take a few days.

im trying to run the bitcoind with the -zapwallettxes flag.   I really dont know what im doing.  Probably  going to lose the coins.

If you don't feel comfortable trying to fix it by yourself, please find someone to help you. -zapwallettxes forgets the transactions you have sent and can find past ones by re-reading the blockchain. Since this was your first transaction and it is not confirmed yet, you shouldn't see any effect except for that one transaction disappearing. Bitcoind flags are explained more here: https://en.bitcoin.it/wiki/Running_Bitcoin

I ran bitcoind with the --zapwallettxes flag and recovered the coins.  Thankyou for the help


text:
What's the best Android wallet client for bitcoin?
There are many bitcoin wallet clients on android market. What is the best considering security, interoperability and usability?

If you want to keep your private keys secret (on your phone, that is), I'd recommend
Bitcoin Wallet for Android
The app also does not imply any trust in single servers, as it manages the block chain on-device.

so how much space does it take up when it has to download the bitcoin block chain data to get synchronized?

For future searchers: I installed the app, resynchronized and it didn't seem to take more than 200MB.  I think it's only downloading 6 weeks worth of transactions.

I've been using this wallet and it came as an unpleasant surprise that it can not export the keys in the now de-facto standard BIP39 format (sequence of English words). I wanted to move my funds to another wallet without paying $5 as a tx fee. I had to export an encrypted database from the app in its own format and use command line tools to extract the raw private key (see question). I'm not sure I can suggest an alternative though: I stopped storing coins on a phone altogether.

I consider the Blockchain.info Wallet Android App the best one on the market. It's no true client but an e-wallet but you can manage your own true wallets and addresses and your private keys are stored encrypted. The decryption happens on your phone.

There are various factors that matter.
If you wish to use the same EWallet account from both the web as well as from the mobile, then mobile-only wallets would be excluded.
Also, since an EWallet service requires service from a back-end, availability can be a concern as well.
Here's a list of options:

http://en.bitcoin.it/wiki/Mobile_Payment_Apps

I would suggest ImToken wallet as you owe your own privatekey. And also they have integrated few markets inside it.The best part is it's very easy to use and completely decentralized.Always write down your mnemonic phrase in piece of paper and keep it is safe.
Recently they have raised 35 billion dollars for the development and 20 billion of coinbase customer asset is in ImToken.


text:
Tax implications in Canada of buying and selling Bitcoins?
What taxes should be paid in Canada on Bitcoin transactions? Has anyone gotten official advice on this?
Is it relevant whether the Bitcoins were mined, received as payment for services, bought and then sold for a profit, or freely donated?
Is it relevant whether the Bitcoins are exchanged for CAD or exchanged directly for goods?
Is it relevant where geographically the buyer and seller are?

Here's a thread on the topic:

http://bitcointalk.org/index.php?topic=77186.0

Taxing authorities consider currencies or goods received in trade to be taxable income. Bitcoin would fall in the same category as foreign currency or barter, and would be taxable.
In Canada, barter is sometimes exempt from taxation:
"According to the Revenue Canada document T-490 (Barter Transactions): if the person(s) bartering is an employee, and not a business owner, they may exchange non-business-related services or goods "occasionally" without being subject to taxation. However, if the goods are business-related, or the exchange is "a regular habit" it falls under the category of taxable income, regardless of his employee status." source
Here's the Revenue Canada bulletin on barter and taxation:
http://www.cra-arc.gc.ca/E/pub/tp/it490/it490-e.txt

So I suppose mining is not taxable, until you sell (or trade) your coins to someone, at which point you'd have to pay income tax.

Yes that is correct.

Trading bitcoins for CDN$ is also non taxable if occasional and if your are not doing it as a business..

Could you please link a source for that information?

Yes, I doubt this is true at least at the federal level.


text:
Is there a historical timeseries of market depth & transactions available?
Has anyone stored the historical market depth & tick data from MtGox? Is it available publically? Would be useful if you were making a bot.

Related, there is a BitcoinCharts API which provides some timeseries information http://bitcoincharts.com/about/markets-api/

I have emailed MtGox and TradeHill about this, have not received a reply. Clark Moody doesn't store historic market depth information as there's too much data.

I think that's the main problem. It really is too much data.

I grabbed a simple script I had and I got it fetching market depth every 5 seconds and saving the differences (I should use websockets, but I didn't have a script ready). After 2 days I have ~5MB of data so maybe this is not that hard to do. The data could be even saved in a more compressed format (I am just dumping what MtGox gives me). It's just a matter of setting up a server running 24/7 with a script like this.

Current market depth available at

https://mtgox.com/api/0/data/getDepth.php?Currency=USD

All trades which happened in the last 24 hours available at

https://mtgox.com/code/data/getTrades.php

Retrieves 100 trades that happend after specified transaction

https://mtgox.com/code/data/getTrades.php?since="transaction tid"

A script is required to retrive all historical data, like the one posted by mizerydearia. The idea is to cycle download request while incrementing "transaction tid" aka "lasttrade" to download all data in steps.
#!/bin/bash
outputfile=data
lasttrade=0
while test -n "$lasttrade";do
    wget --quiet https://mtgox.com/code/data/getTrades.php?since=$lasttrade
    if test "`cat getTrades.php\?since\=$lasttrade`" != "[]";then
        cat getTrades.php\?since\=* >> $outputfile;
        echo >> $outputfile;
        lasttrade=`cat getTrades.php\?since\=$lasttrade|sed "s/,/\n/g"|grep tid|tail -n 1|cut -d ":" -f 2|cut -d "\"" -f 2`;
        lasttradets=`cat getTrades.php\?since\=*|sed "s/,/\n/g"|grep date|tail -n 1|cut -d ":" -f 2`;
        echo "$(date -d @$lasttradets)  tid $lasttrade"
    else
        echo Finished
    fi
    rm getTrades.php\?since\=*;
done

See MtGox - API for more http API calls.

Any idea how big this file is today? I'm at about 3.5 gb right now and still going.

@jordan.baucke what size did you get?

I'm running a similar script -- it's currently up to 10/20/2011 @ ~ 155 MB uncompressed -- I'll let you know when it completes, and see if I can dump it up online somewhere.

Well, I got to 3/11/2013 -- and it's only about ~670 MB so far.  So there must be a bug in the above script.  Probably related to the fact that it's parsing the JSON with Regex.  Maybe an error is being thrown every so often, and it's starting over at the error code (using it as a TID) or something?

I got up to date (1/14/2014) this morning -- completely uncompressed, the JSON is about 1.33 GB -- compressed in a regular .zip file, it's about 160 MB.  I used the URL and the approach described above (slightly different implementation), and although it does not mention USD in the URL, the results appear to be in USD only (maybe that happened when they changed the API? This could also be the reason for the much smaller file size).  At any rate, I've posted my dump here: http://bit.ly/1dMzqhJ

To get ALL mtgoxUSD trades since the start you can use the following url:
www.bitcoincharts.com/t/trades.csv?symbol=mtgoxUSD&start=0
WARNING. This generates a 49mb csv at the moment and can take some time, so please only follow the link if you actually need the data.
Visit http://bitcoincharts.com/about/markets-api/ for more information.

i think this is daily not tick data

Just noting here that MtGox tid's are not included in the data you get from bitcoincharts in that csv call API, and they switched from numerical indexing to microsecond timestamping a while back. In trying to maintain a db with integrity, you need the unique tid data... The history file is now over 100MB also.

Original MtGox Shared Dataset
Once upon a time there was a Google BigQuery dataset that was updated often with MtGox's official trade record. That's no longer being published because... ask someone who should explain it.
Data on Google BigQuery
The BigQuery shared MtGox Trades dataset is (@2014-04-20) available at
https://bigquery.cloud.google.com/dataset/931531665892:mtgox
The BitTorrent Version
If you'd rather not BigQuery, but you still want that data, there's a torrent, here's the full-metal-magnet.
magnet:?xt=urn:btih:c87cd62f9484993f0153a47fc51f06fb43ed71ee&dn=931531665892-mtgox-trades.csv&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.ccc.de%3A80&tr=udp%3A%2F%2Ftracker.istole.it%3A80
The MtGox Leak Database
In 2014 the Magic The Gathering Online eXchange (MtGox) server was compromised. Source code, user account details and trade data were made public.
For academic research the trade data is useful, here's a magnet to the original "public service release" file, MtGox2014Leak.zip. BEWARE: The TibanneBackOffice.zip file contains a trojan
magnet:?xt=urn:btih:b6545ecc7db8d44c8cbc4e93989edf8221af75f5&dn=2014+Mt.+Gox+Leak&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80&tr=udp%3A%2F%2Ftracker.istole.it%3A6969&tr=udp%3A%2F%2Ftracker.ccc.de%3A80&tr=udp%3A%2F%2Fopen.demonii.com%3A1337
Alternatively, cryptoanarchic.me have kindly provided an HTTP mirrored version of MtGox2014Leak.zip.
Those are the two data sources I'm using in my research.


text:
What are the safety guidelines for using the Sign Message feature?
bitcoin-qt's dialog box states, "Be careful not to sign anything vague, as phishing attacks may try to trick you into signing your identity over to them. Only sign fully-detailed statements you agree to."
What would this kind of attack look like?  What are some examples of statements that would be safe to sign agreement to?

The signing mechanism is a way of proving that a particular message was signed by the holder of an address' private key.  A merchant could ask that you sign a message stating where you want your order shipped to, using one of the addresses your payment originated from.
You should sign a statement saying "I, Jane Doe (jane.doe@email.com) sent 1.23 BTC to Acme Corp at 12:34pm, 1st Jan 2012 in payment for product XYZ for delivery to 456 High Street, Anytown, USA".
You shouldn't sign a vague statement saying "yes, I sent that money; send the product to the address I emailed you", because anyone seeing a copy of that signed message can then pass that on to the merchant with his own postal address and get the product you paid for, in the same way as you wouldn't put your signature to a piece of paper saying "I agree to the above" where the above was left blank.  The postal address part won't be signed, but perhaps the merchant won't care.

Additionally, it's a good idea to add: a) who you (the sender) are (name, customer id, email, ...), b) who it is intended for (business name, ...) c) time and date.

If you're really, really paranoid, you can include the transaction ID as well.

while this question is here, let me piggyback and ask for comments on signing one-time nonce values (as is currently implemented for #bitcoin-otc signmessage authentication). Any thoughts on that? it has been proposed by luke that even nonce values shouldn't be signed, without accompanying readable text stating what it is for and a timestamp. Is that a reasonable precaution to take, or are attacks on that pretty far-out in paranoia-land?

"Hi, I want to cancel <Joe's order> and get my refund sent to <nanotube's address>. Here is a token signed to prove I am Joe: <Joe's #bitcoin-otc auth>"
Even if we trust you specifically, it sets a bad precedent for people to sign/accept these.

luke: well, that can be done regardless of the content of the signed message. even if it is of the form "DATE, authenticating joe on #bitcoin-otc, NONCE", i can take it and say "hey here's a token signed to prove i'm joe".

You could really use any address for that matter, as long as whatever address you choose + the message itself + the verification signature are all the same.
So it doesn't prove that your the owner of the address, it just proves that message you sent is the one you expect the receiver to be able to verify. Seems a bit useless to be frank.

So it doesn't prove that your the owner of the address What? It definitely does. If not, I challenge you to prove that you own 1snowqqp5vmzgu47i5awwz9fsghqg94fa.

"You could really use any address for that matter" Nope, you can only use an address you have the private key for. i.e. an address you control/own.

You can't get the signing key from the verifying key, let alone the RIPEMD-160 hash of the SHA-256 hash of the verifying key. You absolutely need the private key to be able to sign a message.


text:
How to enable website users to transact with each other using bitcoins?
I have a website which enables users to trade information for a price.
The price is calculated based on an algorithm within the website.
The website charges a percentage per transaction for the service.
I would like to know how to go about enabling the users to perform the transaction using bitcoins as an alternative to credit card transactions.
The website is coded in Ruby on Rails, I am currently investigating bitcoind, and the bitcoin-ruby library but I'm feeling a little overwhelmed with new technology.
Could someone please explain how I might go this? I'm looking for an overview of the process.
For example: The website connects to a bitcoind server, and creates a unique wallet per user, then to provide transactions the users will need to transfer coins from somewhere to their personal website wallet. When the user wishes to purchase information from another user, the website then connects to the bitcoind and creates a transaction between the two wallets, and creates a second transaction to cover the website commision.
I've made up this example from my basic understanding of the system - but what security issues are involved in this. Will this approach work, or is there a better way?

It may help you to think about the problem a little differently. All you really need to do is process deposits and withdrawals. Then you can track bitcoin balances in your own database. When someone does a deposit, you bump their balance in your database (and the bitcoins go in your wallet). Moving coins from one user to another is just done in your database. When someone does a withdrawal, you pay them from your wallet to the withdrawal address they specify. (Whatever you do though, don't forget about security!)

OT: "enables users to trade information for a price. The price is calculated based on an algorithm within the website" <-- why don't you let the users set the price?

@Lohoris: That's probably what he does. For example, if he uses an auction, that's an algorithm within the website that lets the users set the price.

@DavidSchwartz If I understand you correctly, the website only has one wallet and the "portion" of the wallet owned by the user is stored in the database? Sounds interesting, and probably a simpler implementation - thanks!!

@Lohoris the value of information is based on users reputation - clearly I'm not going to allow users to directly set their own reputation.

@Globalkeith I don't understand, you let the users sell and buy stuff, but you set they price?

You need to set up bitcoind and look into accounts. If you want users to be able to pay each other in the system for anything, it is quite easy to move Bitcoins around without creating transactions simply by calling the move API. After that you just need to add the options for users to put money into their accounts and withdraw them, and you are set.
Can't really help you with Ruby-specific things though, as I don't know the language.

From the wiki: Account Weaknesses
...
Wallet backups are an issue; ...a backup must be done every time an address is associated with an account and every time the 'move' command is used.
..does not scale up to thousands of accounts with tens of thousands of transactions...
It is awkward at best to keep the bitcoin-maintained Berkely DB wallet database and the application database backed up and synchronized at all times.

The satoshi bitcoin client doesn't currently support multiple wallets.
The way that website backends typically interact with bitcoin is through the bitcoind daemon.
Here's a brief overview of how you can handle the interaction:
When a customer wants to deposit bitcoins with you, run bitcoind getaccountaddress <userid> to get a deposit address and associate it with their userid.
To see which users have sufficiently confirmed deposits, run bitcoind listaccounts <conf> where conf is the number of confirmations you require.  That will give you the balance of each user's account only considering deposits with enough confirmations.
For each deposit once it's confirmed enough, use bitcoind move <userid> admin <amount> to move the deposit from the user's bitcoin account to an account called admin and process the deposit (the same as you do once a credit card payment is received - send them the goods, or whatever).  The move will stop the deposit showing up again next time you run listaccounts.


text:
Why is a transaction with outputs of less than ฿0.00005460 rejected?
I'm trying to create a transaction via JSON-RPC API. It has low outputs, but not below "dust" threshold, yet it's still getting rejected by bitcoind with error code "-22". Transaction includes fee of ฿0.0001.
Transaction hex:
0100000001bbe7bfc7db0720cc0b66b55fc63b265e07554644ff18a79c07bb2e2b9bfb1666000000008c49304602210099c8d1376a735f3cfb79d19fdf6d196cdce60e5a3555aa5080b021b649b95d1a022100e5faf1deedd45f9666e77ae97a2e7618567abb03861f3756392a5ff2e35c9f54014104e171d9dee93d16be86a6489fb9dd06bcf42b2c19d869b6302ebc4e2cff93a8576dbf6c8c5372eca8c8ea69a1bd8107475916526377e8befd15ccaf91d9dd206cffffffff0236150000000000001976a9149bd0064acb814a139db73e049f04489dd9aec76b88ace91c0000000000001976a914a4d7331e96bf019411540cfc1d6e018d31c5329a88ac00000000

And human readable view:
{
    "txid" : "0c1b46a2cb0b2aef67c858503dc1cf365f2f792401ff6d2bcab9aa1fd0669702",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "6616fb9b2b2ebb079ca718ff444655075e263bc65fb5660bcc2007dbc7bfe7bb",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "304602210099c8d1376a735f3cfb79d19fdf6d196cdce60e5a3555aa5080b021b649b95d1a022100e5faf1deedd45f9666e77ae97a2e7618567abb03861f3756392a5ff2e35c9f5401 04e171d9dee93d16be86a6489fb9dd06bcf42b2c19d869b6302ebc4e2cff93a8576dbf6c8c5372eca8c8ea69a1bd8107475916526377e8befd15ccaf91d9dd206c",
                "hex" : "49304602210099c8d1376a735f3cfb79d19fdf6d196cdce60e5a3555aa5080b021b649b95d1a022100e5faf1deedd45f9666e77ae97a2e7618567abb03861f3756392a5ff2e35c9f54014104e171d9dee93d16be86a6489fb9dd06bcf42b2c19d869b6302ebc4e2cff93a8576dbf6c8c5372eca8c8ea69a1bd8107475916526377e8befd15ccaf91d9dd206c"
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 0.00005430,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 9bd0064acb814a139db73e049f04489dd9aec76b OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a9149bd0064acb814a139db73e049f04489dd9aec76b88ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "1FCrwY2CsLJgsmbogSunECwCa6WswBBrfz"
                ]
            }
        },
        {
            "value" : 0.00007401,
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 a4d7331e96bf019411540cfc1d6e018d31c5329a OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a914a4d7331e96bf019411540cfc1d6e018d31c5329a88ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "1G2bcoCKj8s9GYheqQgU5CHSLCtGjyP9Vz"
                ]
            }
        }
    ]
}

Why it's getting rejected?
Update:
Minimal output that is accepted is 5460 satoshis.

trying different thresholds I've found out that minimal accepted amount is ฿0.00005460. No idea why is that, but that's it.

Anything lower than 5460 satoshis is currently considered dust, that bloats the blockchain, while transferring a value that is lower than what it costs to store the resulting output on disk. From the bitcoinj source:

Any standard (ie pay-to-address) output smaller than this value (in
  satoshis) will most likely be rejected by the network. This is
  calculated by assuming a standard output will be 34 bytes, and then
  using the formula used in getMinNonDustValue(BigInteger). Currently
  it's 5460 satoshis.

Hmm, so dust value is not fixed to 5430 satoshis, but is calculated with some formula? What's the formula then and how do I calculate this myself? I really need to.

I took the liberty of copying the relevant code into a pastie: http://bitbin.it/iDVgHPnn there should be all the information you need.

Ok, but I don't speak Java. Is the formula coded there is:
min_nondust = (fee_per_kb*(148+33))/1024 ?

3 * (output size) + 444 (satoshis) for legacy outputs, 3 * (output size) + 201 (satoshis) for segwit outputs

This is because newly created outputs must be funded with amounts greater than or equal to minimum dust limit.
For legacy outputs the formula reduces to:

dust limit = 3 * (output size) + 444

For SegWit outputs, the formula reduces to:

dust limit = 3 * (output size) + 201

Actual C++ code first sets nSize to size of output:

size_t nSize = GetSerializeSize(txout);

Then increments it by constants:

In case of SegWit: nSize += (32 + 4 + 1 + (107 / WITNESS_SCALE_FACTOR) + 4);, where WITNESS_SCALE_FACTOR = 4.
In case of legacy: nSize += (32 + 4 + 1 + 107 + 4);

Finally, it multiplies the nSize by the fee rate:

return dustRelayFeeIn.GetFee(nSize);

which defaults to 3000 sat/kvB.


text:
What is meant by Bitcoin dust?
I've seen the term "dust" used to describe small transactions that might be considered as spam by the Bitcoin network. Is there is a generally accepted definition of this term?

I created this question while writing an answer and not finding a good link or definition for dust. I'll post my first attempt at an answer, but I'd love to see something more definitive.

Dust is often used colloquially to refer to any small amount UTXO. In contrast, Bitcoin Core’s precise definition of dust is used in mempool policy to define a minimum for output amounts in standard transactions.
Bitcoin Core considers a transaction output to be dust, when its value is lower than the cost of creating and spending it at the dustRelayFee rate. The default value for dustRelayFee is 3,000 sat/kvB¹, which results in the same dust values as the prior dust definition used before Bitcoin Core 0.15.0. The previous dust definition tied the dust limit to the minRelayTxFee rate and the spending cost of an output exceeding 1/3 of its value.
dust = (input_vsize + output_size) × 3 sat/vB

At the default dustRelayFee of 3,000 sat/kvB, given the size of a P2PKH input being 148 bytes and the size of a P2PKH output being 34 bytes, P2PKH outputs worth less than 546 satoshis are considered dust by Bitcoin Core (546 satoshi being the smallest non-dust value). For P2WPKH outputs, Bitcoin Core considers outputs worth less than 294 satoshis² dust. Since the input sizes of scripthash and taproot outputs are unknowable, Bitcoin Core combines their actual output sizes with the input sizes of the corresponding keyhash types for dust thresholds of 540 satoshis for P2SH, and 330 satoshis for P2WSH and P2TR.
The dustRelayFee can be set with the hidden command line option -dustrelayfee.
Additionally, Bitcoin Core 0.15.0 added a discard_rate. The discard_rate matches the longest target fee rate estimate (currently the 1,000 block fee rate estimate), but is bounded to at least dustRelayFee and at most 10,000 satoshi/kvB. Any change output that would be dust at the discard_rate, i.e. would cost more to spend than its value at the discard_rate, will automatically be dropped to the fee instead of being created as a change output.
Other uses of "dust"
Note that the term "dust" is also colloquially used to refer to a) any UTXOs of vanishingly low value and b) for UTXOs that are uneconomical to create or spend at the current feerate.

¹ The transaction size was measured in bytes before segwit. Since segwit, the relevant measure is transaction weight which is either given in virtualbytes (vbyte, vB) or weight units (wu) where 4 wu = 1 vB. For non-segwit transactions, their size is equal to their virtualsize: 1 B = 1 vB. For segwit transactions, their virtualsize is smaller or equal to their size. You can read more about these units on Is there a difference between bytes and virtual bytes (vbytes)?.
² The attentive reader might expect the dust limit for P2WPKH outputs to be 297 satoshis as P2WPKH outputs are 31 bytes and P2WPKH inputs are about 68 vbytes, but it appears that when the dust limit for P2WPKH outputs was implemented, the code contained a rounding error in the vsize of the input that caused it to be assumed one vbyte smaller than it actually is. (Hat tip to Crypt-iQ for pointing this out.)

EDIT: This answer still gets upvotes 10 years later, so I'm going to try and update the answer a bit as all of the links and numbers were horribly out of date.
Dust is any transaction that is considered too small to be worth carrying out. Dust is a theoretical problem in cryptocurrency because a bad actor could attempt to flood the processing network with an overload of tiny transactions: the equivalent of trying to shutdown a store by paying at the only register with one penny at a time. Therefore, there are some safeguards in the BTC network that prevents "dust" transactions from propagating. Minimum transaction fees are also a way of preventing dust from being a problem.
The exact size below which a transaction is considered "dust", however, has no hard definition. Different clients, software, and different nodes might all have different limits. And those limits might change over time as the value of BTC changes. Amusingly, when I originally wrote this answer BTC was around $20 and 0.01 BTC was considered dust by some clients as it was only worth $0.20. As I edit this article today, that same 0.01 BTC is worth about $170, so I don't think it would be classified as dust by anyone.
The Bitcoin Core currently defines dust here in this code. (Even if you can't read C code, the majority is just text describing the intent of the fucnction.):
    bool IsDust(int64_t nMinRelayTxFee) const
    {
        // "Dust" is defined in terms of CTransaction::nMinRelayTxFee,
        // which has units satoshis-per-kilobyte.
        // If you'd pay more than 1/3 in fees
        // to spend something, then we consider it dust.
        // A typical txout is 34 bytes big, and will
        // need a CTxIn of at least 148 bytes to spend,
        // so dust is a txout less than 54 uBTC
        // (5460 satoshis) with default nMinRelayTxFee
        return ((nValue*1000)/(3*((int)GetSerializeSize(SER_DISK,0)+148)) < nMinRelayTxFee);
    }

I'd consider this the lowest threshold of dust: 54 uBTC. If Bitcoin Core rejects a transaction as dust it's very unlikely for a transaction to be successful. But other software and/or markets might have higher thresholds for dust. And Bitcoin Core might change its threshold again if the prices and/or fees change significantly. The exact definition of dust, and the threshold for what is considered dust may change over time with the transaction volume (and therefore competition for space in the blockchain) and exchange rates.

Considering 0.01BTC as dust is probably outdated; it likely dates back to when bitcoins were worth less that US$10.

Worth noting that the minimum amount counts for all outputs, even change.  The satoshi client is set up to just include the extra small amount as a fee to miners instead of creating change for a small amount.

Just a note that I added a major update to this answer today, because it was still getting upvotes 10 years later. Comments above may no longer be valid.

Hey David, today, Bitcoin Core's dust threshold is 1/10th of what you describe (see my answer). I think the code you are citing is from 2014. Since you just updated your answer, I was wondering whether you might want to point that out about your code snippet.

To understand 'dust' you must understand a few things:
Firstly, a UTXO is an unspent transaction output. This is essentially a piece of bitcoin somewhere on the blockchain that is unspent.
To create a transaction, 1 or more UTXOs are used to form the inputs, and 1 or more UTXOs are "born" in the process. After the transactions are confirmed, the UTXOs that formed the inputs are now just "TXOs" (ie. they've been spent).
To ensure a transaction is confirmed, a fee must be added, that fee is proportional to the overall size of the transaction, which is the number of bytes the transaction takes up on the blockchain. The more UTXOs are used as inputs, the bigger the transaction will be, thus the higher the fee that needs to be paid.
If I have 1 BTC stored in 1 UTXO, it will cost me less to send that than 1 BTC spread across 10 UTXOs of 0.1 BTC, and it will cost me less to send that than 100 UTXOs of 0.01 BTC.
The fees are calculated as satoshis per byte, and the fees fluctuate depending on how busy the network is.
Every UTXO you want to use in a transaction will incur an increase in fee.
Every UTXO takes up a number of bytes in the transaction.
If you multiply fee per byte by the number of bytes taken by the UTXO and it exceeds the value held in the UTXO, then this UTXO is said to be 'dust'.
So a 'dust' UTXO is a UTXO that isn't worth including in a transaction because to do so would incur a fee increase higher than the value of the UTXO.

Comment definition of dust from the actual Bitcoin repo on Github found on file policy.cpp:
// "Dust" is defined in terms of dustRelayFee,
// which has units satoshis-per-kilobyte.
// If you'd pay more in fees than the value of the output
// to spend something, then we consider it dust.
// A typical spendable non-segwit txout is 34 bytes big, and will
// need a CTxIn of at least 148 bytes to spend:
// so dust is a spendable txout less than
// 182*dustRelayFee/1000 (in satoshis).
// 546 satoshis at the default rate of 3000 sat/kB.
// A typical spendable segwit txout is 31 bytes big, and will
// need a CTxIn of at least 67 bytes to spend:
// so dust is a spendable txout less than
// 98*dustRelayFee/1000 (in satoshis).
// 294 satoshis at the default rate of 3000 sat/kB.

Dusty outputs are really small sized outputs from a transaction.  Bitcoin transactions are 0 sum so what goes in must come out.  When you make a transaction to send some money from your address to another address, any remainder gets sent to a change address that you'll be in control of.  Now if that remainder is really small then it becomes "dusty."  Then if you try to make another transaction with that dusty unspent output (UTXOs) miners will reject the transaction and it won't get confirmed, ergo the bitcoin won't move.
The bitcoin network depending on the version a miner is running has different definitions of what is considered dusty UTXOs.  If this site is correct version of bitcoind running on nodes the bulk of the network is at 0.10 and 0.9.*.For 0.9.3 the dust limit is 546 satoshis.  For version .10 I believe it is 546 and earlier versions of 0.9 I believe was higher at 10x around 5k satoshis.

Bitcoin dust refers to the thousands and thousands of tiny transactions that some sites flood the network and thus the blockchain with.

I think usually it rather refers to the transaction outputs, not the transactions.


text:
Does an exchange of only virtual currencies fall under FinCEN regulations?
If a business only exchanges between say bitcoin, litecoin and namecoin. No fiat currencies. Does it still fall under finCEN's regulations?

I'm not sure, but can't the US only regulate anything concerning US dollars? So only exchanging anything for dollars?

Your guess is as good as anybody else's.   FinCEN's guidelines read:

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."

That's as broad as you can get.  Bottles of Tide detergent apparently serve as a form of value that substitutes for currency, so going by that FinCEN could go after your corner market for not registering as a money transmitter for delivering tide to your door without verifying that you were the person who paid for the order (and keeping records for five years, and ... etc., etc., etc.).  Now I know they probably wouldn't stoop to doing that ... just like how the IRS wouldn't treat non-profits differently based on the political aims of the non-profit.
That's called totalitarianism.  The laws get interpreted such that the government gets total control over everyone and everything.

A virtual currency exchange does count as a money transmitter, although there is some discretion for FinCEN here. The relevant passages are the following:

An exchanger is a person engaged as a business in the exchange of virtual currency for real currency, funds, or other virtual currency.

and

An administrator or exchanger that (1) accepts and transmits a convertible virtual currency or (2) buys or sells convertible virtual currency for any reason is a money transmitter under FinCEN's regulations, unless a limitation to or exemption from the definition applies to the person.

So the question is then, "is a broker of 'decentralized virtual currencies' who does not accept "real currency" eligible for an exemption?" Note that:

FinCEN's regulations provide that 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.

The Code of Federal Regulations (31 CFR § 1010.100(ff)(5)(ii)(A)-(F)) has those six exceptions:

(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 ...
(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 ...
(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.

None of these examples apply, so the FinCEN appears to have discretion in this area. The closest parallel to a BTC/LTC/etc. broker is a foreign exchange dealer, but FinCEN does explicitly say virtual currency exchangers cannot be treated as foreign exchange brokers. So they could definitely make the case that it is therefore appropriate to treat you as a money transmitter.


text:
Where do these coins gain their value?
I have been mining coins for a long time (started with BTC/LTC years ago, moved to altcoins recently) and have realized I am not clear on the actual source of the value.
Do the exchanges deem the value of these coins? With all of these new alt-coins, do they not actually have a BTC/USD value unless they are added to an exchange?
How do buy/sell orders affect the coin price? If someone bought X amount of , that would cause the value to increase correct? Wouldn't they then just be able to turn around and resell what they just bought plus any they already had for a higher value?

related: Where do bitcoins come from and what gives them their value?

This is really asking about basic trading economics: if I have some new product X, what price does it have? I can set a price and see if anyone buys it. If not, I might lower the price or auction it to see what someone might pay for it. That is the starting value, but it doesn't really mean much as it hasn't been field-tested (so to speak). If others think it is worth more, they will buy more; if others think it is worth less, they will not buy at the current price, so those trying to sell will lower their prices until they can agree on a price.
What you describe is a simple pump and dump operation, which could be done on any sort of traded commodity like stocks or cryptocurrencies (especially altcoins). If you can feign interest in something (in this case, an altcoin) so that the trade price goes up, then you might be able to turn a profit. Note, however, that this is a sort of fraud and can open you up to, at minimum, civil lawsuits.
Doing a "pump and dump" will be easier on small markets, like altcoins, than on larger markets, like Bitcoin and Litecoin, because you have to buy up enough of the coin to start an upward trend that people will notice and buy into. If the market is large, you'd need huge resources in order to make an impact in the market.

In the stocks and foreign currencies market I know this is indeed illegal (even though people keep trying and some manage to get off with it). For crypto-coin exchanges, though, I believe the regulations are way too nebulous as of now. And even if it were explicitely forbidden, I guess it will be very difficult to legally prove participation and intent into these schemes :(

If someone bought X amount of, that would cause the value to increase correct? Wouldn't they then just be able to turn around and resell what they just bought plus any they already had for a higher value?

No, because trying to sell the coins would push the value down for the same reason. The further away the price is from its "natural value", the harder it is to push it further away and the easier it is for it to slip back. So if the price is at its natural value, and you push it up, it gets harder and harder (costing you more and more money) to keep pushing it up. When you start to sell, it's very easy to push it down, so you don't make very much money as you return the price back to its natural price.
Worse, if you're trying to do this, to push the price really high, you have to keep buying even though the price is high. Well, that's a pretty dumb thing to do. When you finally do get the price high, everyone can sell at that higher price, not just you.
So not only is the profit less than the cost, but you have to pay the whole cost yourself and you have to let everyone else share in the profit. Many people have attempted this strategy and billions have been lost. That doesn't mean it's impossible to make it work, just that it's not nearly as easy as it sounds.

A pump'n'dumper doesn't need to do all the heavy-lifting by themself: they just need to start a trend and once it gathers enough momentum the market will keep it up, at which point the attacker can just wait until the price reaches the intended price (or seems to be falling down) and sell their coins in small chunks. As you said, the bad part is they have to share the profits, no other way around for this scheme to work.

@JoePineda Either additional person "helping" just makes the problem worse. The higher the price gets, the more it costs to keep moving and the quicker it will fall when the selling starts. The first person to panic kills the momentum and everyone is trying to catch the falling knife. Everyone thinks they can sell at the top, but that's impossible.

Right. Probably the most rational way to try to ride a way would be to set a profit target (say - 10% or 20%) and sell at that price no matter what happens next. As you said, it's basically impossible to know at which point someone will panic and invert the tendency.

Beware, young Alice! That rabbit-hole you see is waaaay too deep!! Your seemingly innocent question is indeed very profound and stays at the intersection of history, philosophy and economics.
Whence do anything get its value? According to the Austrian school of economics, there's no such a thing as an "inherent value" of stuff: all value is subjective, we as economic participants "imbue" value onto the things according
to both rational and irrational beliefs. Should we be in a desert island, would you rather have 3 gallons of water and a wooden raft or 100 kilograms of pure gold?
Bitcoin itself had imbued value way before there were exchanges set for it. People would give each other coins as a sign of appreciation, a kind of "membership key" into an über-exclusive (and ultra-geek) club or, as in an (in)famous example, in exchange for some pizza.
As for buy/sell orders moving the price of a coin: yes, that does happen when the market for that coin doesn't have too much volume. For instance, with millions of dollars in bitcoins changing hands daily, a single buy/sell order for 1 million USD at any exchange won't move the price up/down more than 5-10%, and that "hiccup" will rapidly correct itself. Try that with, say, Litecoin and the price would go up about 33-50%, and most probably such movement would start a rally where people and automated trading bots enter an irrational frenzy trading, trying to ride the wave.
For a very dramatic and recent example you can check the Protoshares market at cryptsy - look up the graphs for 17-Feb to 18-Feb. And the equally impressive dive (plus its damping up and down the new equilibrium price) about 12 hours later. Unobtanium, Feathercoin and other minor coins have recently experienced similar (induced?) rallies.


text:
My lightning node URI is not visible
I did set up a mainnet c-lightning node by following the guide.
https://medium.com/@dougvk/run-your-own-mainnet-lightning-node-2d2eab628a8b
I noticed my node is visible on https://lnmainnet.gaben.win/ but the URI is unknown. Is there some settings I need to check on my server?

I'm voting to close this question as off-topic because it's about a specific piece of software and is best asked on that software's developer mailing list.

@Alin: no, I think OP is about lightning network, which is integral part of bitcoin network.

when starting lightningd, you want to add the option:
--addr=[insert your IP address here]
so maybe when starting your lightning node, at your command line you would enter:
lightningd --alias DavideRivola --network bitcoin --log-level debug --port 9735 -ipaddr 192.168.1.1
Where 192.168.1.1 you would of course, put your own IP address.
Also, since you are probably unaware of this as well, in case you want to choose the port, use the --port=9735 option and just change the port to which you want to use. Everybody pretty much uses port 9735 though. Make sure that this port is forwarded on your internet router and is not blocked by your firewall either.
Also, if you want to choose the color that represents your LN Node on the #recksplorer site, you can use the following option --rgb 00cc00 where 00cc00 is the RGB code you would like to use. (In this case I have chosen green, because, well..look at my name :) )
Use this site to find the corresponding RGB Code for the color you want to use: http://www.color-hex.com/
use the command lightning-cli listconfigs to check what you have configured for your node to make sure everything is right after it is up and running.