text:
What happens when an encrypted wallet runs out of keys?
Say someone wanted to be evil to the main client and set its wallet to contain one key, lock it, and then start mining. After the first block was generated, the client would traditionally create a new key to use for mining and store it in a wallet. However, as it doesn't have the password in memory, it can't encode the key. How would the client respond in this situation? Use an old key for generation, store the key unencrypted, or do something entirely different?

Why the close vote?

Not to mention a downvote. Everyone, please, if you do either, leave a comment, otherwise we can't improve ourselves.

If the key pool is empty and the wallet is locked it will use an old key instead of generating a new key. When wallet encryption was implemented the block creation code was changed to make sure different coinbase transactions are generated in that case.


text:
Script - OP_PUSHDATAs
When using OP_PUSHDATAs in different Scripts, how are the next bytes denoting the amount of bytes to be pushed encoded? Are they to be treated as unsigned integer, or signed (like the data that is taken from the stack?)? Are they big endian, or little endian?
OP_PUSHDATA1    76  0x4c    (special)   data    The next byte contains the number of bytes to be pushed onto the stack.
OP_PUSHDATA2    77  0x4d    (special)   data    The next two bytes contain the number of bytes to be pushed onto the stack.
OP_PUSHDATA4    78  0x4e    (special)   data    The next four bytes contain the number of bytes to be pushed onto the stack.

Little endian.
See, for example, the script_PushData unit test in the source tree that pushes one 0x5a byte onto the stack 4 different ways:
// Check that PUSHDATA1, PUSHDATA2, and PUSHDATA4 create the same value on
// the stack as the 1-75 opcodes do.
static const unsigned char direct[] = { 1, 0x5a };
static const unsigned char pushdata1[] = { OP_PUSHDATA1, 1, 0x5a };
static const unsigned char pushdata2[] = { OP_PUSHDATA2, 1, 0, 0x5a };
static const unsigned char pushdata4[] = { OP_PUSHDATA4, 1, 0, 0, 0, 0x5a };

source: Stack Exchange

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

sort: votes


text:
block hash and list since block?
I am writing transaction monitoring service but I am having some problems with listing since block hash. I have bitcoind daemon and when I execute listTransactions some transactions have same block hash so if I would try to listSinceBlock I would have problems. How this all works?

The block hash identifies a block. A block can contain multiple transactions, so listsinceblock lists all transactions in blocks newer than the given block hash.
So f.e., if you have this block structure:
block 5 hash: qwertyyuiop
|   tx100,tx101,tx102,tx103
v
block 6 hash: asdfghjklkl
|   tx104,tx105,tx106,tx107,tx108
v
block 7 hash: zxcvbnmnbvc
    tx109,tx110,tx111

When you would do listsinceblock qwertyyuiop, you would get all transactions in blocks older than block 5, so tx104 all the way up to tx111.

How long one block hash last? So how often is block hash changed?

The hash of a block does never change. It's its identifier, every block has a unique block hash.

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


text:
Safety of wallet setup
I just set up my Electrum wallet using live instance of Tails Linux distribution. I've written down the seed on the paper (and I remember it as well) and restarted laptop.  I plan to do all Bitcoin transactions only via Tails so I plan to recreate the wallet every time I am using it and then wipe everything out with no trace on the computer.
There is just one thing I don't get, can I have any "static" address tied to my private key and seed or do I have to get it through creating wallet every time? Because I would like to send some coins to my wallet without booting to live distro and generating the wallet again (therefore I need to have and store address somewhere), is this possible? Thanks a lot for explanation.
And is this approach reasonably secure (or even possible)?

Your approach sounds secure.
You can use any addresses generated from your deterministic wallet to receive BTC without the need to boot up and recover your wallet first.
For privacy reasons you should generate multiple addresses from your HD wallet and one use each for receiving payments once. As long as you have your mnemonic seed you will be able to recover your wallet and all of its addresses at any time.

Yes, that is a fairly secure way to do it.  A slightly more secure way would be to only use it on a computer that never goes online.
If your concern is primarily the safety of your private keys, you can export the Master Public Key and import it into Electrum on any computer.  This creates a "Watching-only" wallet (i.e. cold storage) that can see all the addresses/balances, but cannot spend them because it doesn't contain the private keys. As @Game Changer mentioned, do not reuse addresses for privacy reasons.
Reference the Electrum Cold Storage Documentation for a nice How-To of setting this up.


text:
What is the reason for other coins appearing like FTC and LTC?
Is it simply just trying to be faster and better in some aspects than bitcoins?

What do you mean "appearing like" them? You mean the graphical appearance of their clients? The structure of their addresses? Something else???

Must things have reasons? Someone felt like making them and now the exist.


text:
How much Bitcoin volume is for purchasing stuff versus trading/speculation/investment?
What percentage of Bitcoin transaction volume is due to people actually buying stuff ("goods") versus between traders, investors and speculators?
Of the "goods" volume, what percentage is for illicit purposes (drugs, etc.)?
Are these percentages relevant to the future success of Bitcoin?

The pseudonymous nature of Bitcoin is such that this question is very difficult to answer. How would you attempt to answer it?

I think this is a valid question, just hard to answer as I don't think it is possible to measure directly.

It's also hard to answer just because of the nature of money. I own BTC. I don't know whether I eventually use that to buy something, convert it back into my native fiat currency, convert it into a different crypto currency, or convert it into a different fiat. What would the transaction to buy those BTC be categorized as?

It's been estimated (with many assumptions) to be somewhere around 1-4% of the total trade volume. This seems bad until you learn that the speculation market for USD is $5 trillion a day.

Hello Garrik, welcome to Bitcoin.SE. Could you please provide a source for your figures? You speak of many assumptions, so I think that a longer explanation would be useful to substantiate your answer.


text:
Are smalltime block chains susceptible to brute force liars?
My understanding is that the integrity of the bitcoin block chain is dependent on the consensus of the masses - that no single actor can write entries at will unless they. controlled over 50% of the compute power focused on calculating proofs.
If this is true, wouldn’t small time coin with much less compute power working for it be susceptible to a bad actor, assuming this actor could focus enough resources? Specifically, slightly more than the current compute power dedicated to the coin such that the bad actor controlled greater than 50%?

Yes, many small coins are susceptible to such attacks. However, the value of the coins is so small that performing a 51% attack on the coin has almost no real use whatsoever. The coins that do actually have value where performing a 51% attack would actually result in non-negligible gains for the attacker are more difficult to attack because they are actually used.

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


text:
Why is the full blockchain required, effectively forever?
I do understand that every block is validated in terms of the blocks before it by way of the previous block's hash, all the way back to the genesis block. However, could the protocol be modified such that the blockchain is a sliding window over the most recent N number of blocks? How likely is it that some block from 1 year ago later turns out to be invalid?

How likely is it that some block from 1 year ago later turns out to be invalid?

Very unlikely, but I think that isn't the problem.
The problem is, how does a new user find out the current state (UTXO set or equivalent) without having to trust other parties? Any community has dishonest people preying on it.

You cannot ignore, expire or invalidate unspent UTXO from much earlier blocks. That is someone's savings and the community wont throw their savings away or  arbitrarily take away their peers savings. To do so would undermine the credibility of the currency. Any such change would be ignored and not be adopted by the majority.

Could everyone trust at least the UTXO represented within the sliding window? If so could it work if the concept of coin expiration be added to solve this (in theory I mean  - I realize this would probably be too large a change to be considered even if it might work).

@nocturna. I see no sound basis for that and expect it would open the way for fraud. We also need our money's value to persist and not evaporate.

How would it open the door to fraud? Whether dormant utxo evaporates or not is a value judgement and imho is better than persisting illegal and disgusting content on my computer by way of the blockchain.
But anyway I’m trying to understand whether such a scheme would work assuming that one doesn’t have a problem with old utxo expiring.

For future readers, a similar scheme is discussed here: https://bitcoincashresearch.org/t/prune-bitcoin-cash-network-every-7-years/273/5. Looks like the objections are value-based as opposed to technical/cryptological.

If your objection is specifically to the requirement to store old blocks (as you hinted in a comment), then you might consider pruning - see How can I run bitcoind in pruning mode?.

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


text:
Where does one obtain the most widely accepted Bitcoin/Euro exchange rate?
I want use Bitcoin to make a purchase from a private seller in another country. The good which I want to purchase is priced in Euros, so I need a Bitcoin/Euro conversion rate which both of us must accept for the moment when the Bitcoin is transferred.

Bitstamp is reputable and generally accepted in the context you've mentioned.

It would be reasonable to take a weighted average of all major exchanges, such as BitcoinAverage.com.


text:
What's the point of Bitcoin eaters?
I see some bitcoin documentation sites reference dummy addresses like "1bitcoinEaterAddressDontSend32425663" or something made up like that. I'd assume it's just so people reading the docs won't try to "tip" the writer and send to a foobar address that was made up for the sake of example.
That said, I find addresses under this schema that actually have quite a bit of bitcoins in them. Like hundreds of transactions+ and thousands of USD worth (circa 2016 for future readers).
Here is an example (1BitcoinEaterAddressDontSendf59kuE): https://blockchain.info/address/1BitcoinEaterAddressDontSendf59kuE
Who are these people sending money here, what's the point? Can anyone shed some light, lol.

I'd assume it's just so people reading the docs won't try to "tip" the writer and send to a foobar address that was made up for the sake of example

That is correct!
Other than that, there is no other real point at all. These bitcoins are gone forever and no one will ever be able to get them.
However there is some projects or new coins that does Proof-Of-Burning and by sending the bitcoin correctly to the bitcoin eater address you would get corresponding amount in the new cryptocurrency.

There are some occasions where burning bitcoin can have a purpose.

I remember OpenBazaar originally had some idea for bootstrapping your reputation by burning some coins. (You couldn't send your coins to someone else because the same person may be at both ends, you don't know with a permissionless system).

Man I bet that author wishes he had used a real address right about now

@user253751 There are over 13 BTC on the example address I gave........

@user253751 That was a claim you made.. I never said they were there for stupidity, no one did but you. All I said is "I bet the author wishes has had used a real address".

The point is that someone obviously made up the sentence and then adapted the last few places to make it adhere to the checksum test, i.e. it is a valid Bitcoin address. On the other hand, it's certain that it's not an address someone generated randomly (because vanity addresses of that length would take way too much effort to generate).
Thus, it's a "safe way" to burn bitcoins.

Yes I get that, but what's the point. Why would anyone do this?

That was already answered by Joe: a) To have a burner address where one can be reasonably sure that it's not held by someone. b) because they can.

https://en.bitcoin.it/wiki/Vanitygen
Theres no guarantee these addresses are made up ....
Of course, bitcoin eater addresses are around since the early days - but why not exploit it :)
Back then it came up as a joke, if you mined 100 btc a day wh not dump some for fun to an eater address to make the rest more valueable, then vanity addresses became mainstream ....

That's an interesting tidbit about past miners. Ironically some of these addresses are still getting deposits even this week! Kinda strange

Why not mine asic on such an address, may others think "omg how can anyone deposit there" oh well i sent a few cents :)


text:
Sent Bitcoins to an expired address - how do I get back?
I sent bitcoins to my CampBX address, and I was unaware that addresses expired, and it had.  So I sent them, they were taken out of my account, and now they are gone...
How do I get them back?
Bitchain says they were sent - but they are not in either account:
https://blockchain.info/address/1aPb2GVC3YVcaRce17EAjEZL9ZsT1Ssqi
Any help would be greatly appreciated.
Thank you!

I'm unsure why Camp BX began this practice.  Perhaps it helps to protect them by not retaining the link between the bitcoin deposited and the Camp BX exchange account that gets credited.  Or maybe there's some other reason.  I'm of the opinion thought that the funds should be recoverable for a longer period of time.   Maybe they allow it after filing a support ticket? https://campbx.kayako.com/Tickets/Submit

From Camp BX:
"Do not use this address after the expiry date, as your Bitcoin transfers will not be credited to your account. If you mistakenly make a deposit to an expired address, our system administrator has to expend several hours to track it down. We have to bill these hours out to customer if they wish to recover a lost deposit."

I submitted a ticket - and am just waiting for a response.  It is only about $100 worth, so I was going to just say that they can keep 30% or something.  Does anyone know a phone # for them?

CampBX are bound to keep the matching private keys somewhere. Otherwise they would lose quite some money as I'm sure you're not the only one who sends funds to an address that has "expired".
I believe the thing that expired was the binding between the funding address and your account. CampBX should be able to trace it though. A simple Support Ticket like Stephen suggested should resolve this situation.

Well, technically, they could have deleted those keys after expiring the address. It's not them that lost the money... Let's hope they still have them, though. Otherwise that's just irresponsible.

Yes, right. That "bound" in my answer is an opinion, but I assume that they are rational :-)


text:
MtGox api - keeping track of bids/asks that get cancelled
I'm getting started with the mtgox api. I'm primarily using this page to tell me how to use it.
What I've currently got, is I can fetch the depth and then put the bids and asks into 'buckets' (each being a range of price), and can tell you the volume at each bucket.
Now what I want to be able to is keep this updated every second or so.
So I'd need to be keeping track of:

Trades being made (ie Bids/Asks being met).
New Bids/Asks.
Bids/Asks being cancelled.

It appears as if the old version of the api could show the net change at each volume, but this doesn't appear to be the case for the new version.
How would I go about doing this?

There are two ways you can do this.
1) MtGox Polling API V2. You call the getFullDepth to download the full orderbook. Then you call getPartialDepth for updates, replacing all the orders in your master order book. This method is not very efficient and you can only poll at a throttled pace.
Here's a demo from the XChange open source project for simply polling for the partial order book and creating an orderbook chart.
2) MtGox Polling API V2 + streaming. You call the getFullDepth to download the full orderbook. Then you use the streaming API to receive depth events and update your master order book accordingly. Depth updates with an amount of zero mean that the orders were cancelled or filled, i.e. they don't exist anymore and you can remove them.
Here's a demo from the XChange open source project.

Your link to the "old version of the API" is actually going to the streaming API which is still available.  Only the http version was updated and from there it looks difficult to obtain accurate  depth info reliably for precise time periods.
So I'd stick with streaming. Updated much more in real-time for your requirements.
Now they deprecated the depth:volume field but they still have volume_int, which is volume change * 1E8, so you could obtain volume from that:
//js for example
var volume = volume_int * Math.pow(10,-8);

Check out the github samples at the bottom of the wiki page to help get started.  For example, this one


text:
When are private Keys created on Wallets?
I have just started mining and in another question of mine it came up, that there can be multiple private keys in a wallet because of defining a backup strategy.
I would like to understand when private keys are created in the wallet?
If it is specific of the coin / wallet, I am refering to dogecoin wallet application with currently 1 address created in it.

In the default Bitcoin client, and most clients based on it (including Dogecoin-QT), 100 private keys are pre-generated, so that the wallet you backup is useful both for existing and some future transactions (roughly 50 transactions, assuming you receive on a new address and send change to a new address each time). When you ask the client to generate an address for you, it pulls from a private key from this pool (and generates another to put the pool back up to 100 at some point), from which a public key and address can be calculated. This pool size is configurable in your .conf file:
 # Pre-generate this many public/private key pairs, so wallet backups will be valid for
 # both prior transactions and several dozen future transactions.
 #keypool=100

the other answer is just saying priv key is created when I create a new address. in your answer I find that there will be a private key needed for every transaction. at around 50 + 1 transactions (receiving and sending summed up) for every action i do a new prv key is created. what is correct?

When a private key is created is dependent on what wallet software you're using. I've described Bitcoin-QT; xenoky either described another wallet or described it incorrectly. When a private key is actually used is when you make a new address. You could send and receive everything from one address (in which case, you'll never need new private keys), but for anonymity (so people can't look at the blockchain and easily know all of your transactions) you should make them basically single-use. In this case, you might run through 100 in 50 transactions.


text:
Can I create a public address for Bitcoin without the private address appearing on the screen?
Is there JavaScript which will do this?
I would generate a 256 bit password using 99 dice throws, enter it into JavaScript on an offline computer (like using bitaddress.org) and get an address to send Bitcoin to, so that I can store them cold.
What I don’t want, as would be done in bitaddress.org, is for my private key to be shown on the screen in case there is screenshot malware on the computer. (N.B. I can defeat key-logging by scrambling the entry of the dice throws using a mouse).
When I wish to transfer the Bitcoin to, say, a Blockchain account, I can go to an offline computer, generate the private key from the password using bitaddress.org and then on another computer which is online carry out the transfer.
The procedure seems pretty safe to me.

If there is malware of any kind on that computer, you're probably screwed anyway.

If you're afraid of screen grabbing you should also be afraid of memory grabbing malware.
If however you make sure that such malware can never communicate anything to the outside world then you don't have to worry about either of those types of malware.
You can do that by booting from a write protected media (CD) and making sure there is no other writable media ( harddisk) connected. Also of course make sure the machine is offline (no network cable or WiFi etc).
After generating the private key write it down (error sensitive!) or print it (not on the big printer in the office, those often have harddisks in them). And after that turn off the computer to erase the memory.
Even in this setup you still don't want malware on the PC because it could influence the creation of the private key by making it predictable.

Thanks for that.
The error comes, not in writing down the private key because I can generate that from the input data when I need it, but in mistyping the input data and getting the wrong public address and end up sending funds to an account which I can’t unlock.
To counter that I type in the input data three times and when I have the same public address three times, I paste and copy it. (The input data is written on paper and stored safely).


text:
How to do mass payouts in my application to multiple addresses at once, or very quickly?
Let's say it's pay day--I've accumulated a lot of bitcoins, and sent them all to a single address. I now want to pay a lot of addresses from this "pool" of coins, say anywhere between 100 and 10,000 addresses. What is the best way to do this in a way I can use with PHP, and with which client would be the best fit? I'm currently familiar with bitcoind and electrum.
The problems I see happening is:

If I make them one after another, I would have to wait for a confirmation between each each transaction.
If I somehow send them all in one transaction, I would need to a) mess with raw transactions, and b) possibly hit a limit on the transaction size.

Is it possible to do this without using raw transactions? And how do I check to see how many addresses I can send to at once without hitting the max transaction size? If I DO have to deal with raw transactions, is there any library in PHP that helps me build them easily?
Thank you.

At least when you're using bitcoind, the best solution is using the sendmany RPC call, which allows you to create a single transaction that does many payouts. The transaction will be much smaller (in bytes) than the many single-payment transactions you had in mind (over 6 times, for 100 outputs), resulting in lower fees in total for the same effect.
Also, even if you'd use separate transactions for each (though I advise against that), there is no need to wait for confirmations between the different transactions, as the implementation allows sending 0-confirms transactions if they're from yourself.

In Electrum you can use the CSV import feature to make bulk payments. It can accept either a CSV file or CSV entered into a text box. The rough format is:
ADDRESS, 0.12345
ADDRESS, 0.12314

This feature has been merged into the 1.9 version that is not released yet, but you can use it already.
https://github.com/spesmilo/electrum/pull/282
Example:
1PkeTTctdh2CvhW3fQLs93PWP9qupWV68X, 5
3NujXLC3LxNsmk2wr69CLBuXGfhXeenUyu, 5
1CNAnSb7d1XCA4AXBH2gip3mi8dNTQxzeo, 1
1LSBFJ1An9orRMU6Bz3NS1y3jr1eH9AexE, 1
16qRyDVZVpptJb4HZzv5rWkjqtJWVRjDep, 1
1PkeTTctdh2CvhW3fQLs93PWP9qupWV68X, 5
1Nnad832Zyob64wGbju49CC5RFbACAfCNZ, 1
1J2gFYBnf8K2wHJDndgr3iN1nPoZumHXap, 5

The amount is in the unit your Electrum is configured. In my case, for example, it is in mBTC. Be careful with this!

Oh that is cool. How does it handle transactions that get too big for a single transaction--does it split them up? Any idea when this version is going to be released as stable? In the history panel, it looks like right clicking -> Details doesn't show the popup box anymore.

I've been looking for someone who would know about the big transactions handling, will be asking. The release is around the corner.

@user371699 Electrum's CSV import works the same as the Send function, so a bigger fee will be needed for a big single transaction.

I believe there is still a size limit for every transaction in the protocol, something like 10KB? I wonder if Electrum knows this limit and splits it into multiple transactions?

Quote: "It doesn't split txs. The limit is 100KB, so it shouldn't be an issue. Fee would probably be 1 BTC though"


text:
What does this transaction data mean?
I'm new to Bitcoin development, and haven't been able to find a good resource for deciphering transaction data. Could you please explain what the following keys signify? For example, what do the "in" and "out" transactions represent, what "n":"x", "prev_out_hash" means, etc...
I'm trying to find the amount and date of incoming transactions to a given address. I'm using BlockExplorer for getting an address's transactions, but I don't know what to do with that data.
{
"result":"success",
"return":
{
 "hash":"4462c88079cc51972f1bdcb8a4240ee8757b0bb69df828ade051c95ced540fa0",
 "blocks":["000000000000076fa606a7b67c131afc87d24d34114be2863cf24ca3d48139e7"],
 "version":"1",
 "size":"1158",
  "in":
[{
  "n":"0",
  "prev_out_hash":"4578576f49418e69da6d7a1166168bb80a94682f21cca518b6c2451bc64bf858",
  "prev_out_n":"1",
  "coinbase":null,
  "scriptsig":"304402201d7eaf891bcda16ea2979694c02e590fea8fc43dc092ee60e5fb2dd756bcb19502205c5be31b772029700d0a43d499932e9c321af1cfbc8745fba6dbbe48fa79bbb501 043a264aac55e23f83b29ac7e7a914584d2aa6c2eb08ea05405f5efc38473183ca4fc075f8144bb78698df1a5be6f4057f1bccc9e1217a5658946bcc4d4f6972c3",
  "addr":"46f740cb9c737111ec91ec235f6877055be7175e"
 },
 {
  "n":"1",
  "prev_out_hash":"4feea511029896ff4c31132346a79594fcd0c4e60aab2fa4f527e1395d375488",
  "prev_out_n":"0",
  "coinbase":null,
  "scriptsig":"3046022100f3bc0445f629e4e896ced23013d89ba6e6488a6ec21c47df608aaf6d6d212fbb022100d321c4c7f5f33900b8c0efba8ff58a3541e621588f402e167f51968b6ee0bbf201 042157f97a8a78caf6315dbd6d9267b9edd9c1c37cdb211f2bc03703a28eeebaf274efdcff4ef3e3ef4a6b7ccb5d8c17acba941d1a5669c3299f22a0e78e702fdb","addr":"7b0a72820f6e92ccc384dbdecb5584d855ce9416"},

 {
"n":"2","prev_out_hash":"9adadb88c3075afdce1216b35d27fd5cac9736ce3977778999f9a85105d2ea8f","prev_out_n":"0","coinbase":null,"scriptsig":"3046022100d63237cca9bf2200c6aa255834e06f9dc5e4e20f1ea7e6678119bb0e4a5a109f022100db37ec795336509fb3a16d1acebfe08523d95e177284149614a6d3384286b27c01 04b16b41dab16cfbf59f1713559795440b98b384dc01656ebaceeec8f6d1463802cb474062b2b8c1de53ab1fe65be0f6213dd61519044e9c1f50291b915fc7fc6e","addr":"2ed7c49f080e9898737276ad802e2067a1d06ab7"},
  {
"n":"3","prev_out_hash":"0e2ed4e4db87ddc9cb54ab3cdcae59762293815d3093c238e42d33248b39e19d","prev_out_n":"1","coinbase":null,"scriptsig":"3045022100ab501414e7643cc1a78645f544cbcf6411e71e0c21953cd51f7f9933a50538a002201b4c9bac60aa19d659d0686d45bf06c4928c4446269692d88722f57624cdaf1401 048e1e4862c6fee7293f6c7be43a72a375e68395398e4d5da3db06199a35fc46cf51b87f3c6b87caeb81181d630706e23b5679ae8b96ca36701282ae5b49dd99c9","addr":"c74d2e95aeb037297c7b6a232d78c715fa1ab826"},
  {
"n":"4","prev_out_hash":"93c912462daa2a52e108e3424596d56fe2a136d6707a65b6423dee229e317ea1","prev_out_n":"1","coinbase":null,"scriptsig":"3045022100fe782441b8788ed9297c8fea735701ae0a77081fc748ceee8cde945107f64967022014d51d5bc8d8138b97a657eda6d03ba998810e3e941988da90b82f6d24d8471e01 045f53cf2dbdb3213084efa69ac1dfcd8d97be8073a8b8104feb000513aa048b653f400d23314fc090456078f46a0fc9daabdee57f1ef14c2111b9ddc35255189a","addr":"958bba83ac42ebf055c1724b25bfe5c698abbb51"},
  {
   "n":"5","prev_out_hash":"44a1b493ef6176cced4c02fb97a227b98e5bea0616d9cdd6005bcd6905d667f3","prev_out_n":"1","coinbase":null,"scriptsig":"30440220132484ad901567d2c52c0b4f3be5263d1d8ed6e76be1398d2bb7c2a1aec5f748022033b907afa05eb075dee9993b8a05c9e40c69e53d65a06cc8a975ff4c4407141e01 04bd5d7feb1884efdccbe8feb8fa9ff57d56272ac5f667bc59cb07a232fbbd9cbabdf54b6bb6ca4c77e0de22cb0f896fa6183e53381861641049f0edee2d64cfe5","addr":"3784c102bbfd34cc7fb6e12c51b5c6177592f267"}],
 "out":[{"n":"0",
 "value":
  {"value":"0.01000712","value_int":"1000712","display":"0.01000712\u00a0BTC","display_short":"0.01\u00a0BTC","currency":"BTC"},"script":"OP_DUP OP_HASH160 6427f36ed6e5a0cb526a0b0bef1335992326e9a9 OP_EQUALVERIFY OP_CHECKSIG","addr":"6427f36ed6e5a0cb526a0b0bef1335992326e9a9","claimed":"N"},{"n":"1","value":{"value":"3.31674208","value_int":"331674208","display":"3.31674208\u00a0BTC","display_short":"3.32\u00a0BTC","currency":"BTC"},"script":"OP_DUP OP_HASH160 1f27d1fc284143729944ab89823111d2bb63dc46 OP_EQUALVERIFY OP_CHECKSIG","addr":"1f27d1fc284143729944ab89823111d2bb63dc46","claimed":"N"}]
}

Did you read this page? https://en.bitcoin.it/wiki/Transactions

It looks the output you are using is generated using the Mt. Gox API.  That's not the right tool for looking at blockchain data.

Bitcoin is simply a ledger of value assignment transactions.
There is a special assignment when the coins are first issued to a miner.   But from there, the ledger is simply a compilation of all transactions, each of which is simply a value assignment.
Similar to how you don't rip a $10 bill in half to pay for a $5 purchase, spending funds received is an all or nothing action -- the entire transaction amount received is spent during a transaction.
In a bitcoin transaction the transaction whose funds are being spent is referenced as an INPUT and the entire amount of funds from that previous transaction's OUTPUT become available for spending to one or more of this transaction's OUTPUTs.
So a typical transaction will have one more INPUTs and one or more OUTPUTs.
So let's take a simple transaction.  Previously the bitcoin address 15P8RCnL8oMjRf1RFrAZHJyYtxypdGp6wY received a payment of 0.022 BTC.  The transaction ID in which that payment occurred is 4faa9d17c458afdf3ae928b51f1088fbe314b6866a35ad60fa7d861bc311be05.
Now to spend those funds, a new transaction must be composed.  So the value from the earlier transaction 4faa9d17c458afdf3ae928b51f1088fbe314b6866a35ad60fa7d861bc311be05 will be spent.  That transaction had multiple outputs however.  So this spend transaction must reference which output from the previous transaction is being spent.   In this case, the index is 0 (meaning the first output of that earlier transactoin) is the one being spent.  That output is for the 0.022 BTC to 15P8RCnL8oMjRf1RFrAZHJyYtxypdGp6wY.
So the combination of a transaction Id + index is how the current spend transaction references where the funds are coming from.


text:
Where can I find historical exchange rate data for BTC/USD?
I'm looking for historical exchange rate data for Bitcoins/USD beginning in 2010, but I haven't been successful. This is for academic research. I tried bitchart.org. I don't know how to access the MtGox API either.
Can you help me with a step-by-step procedure to download the data in CSV format (or any other format)? It would be awesome if you could just provide me with the actual data file.

I've used http://bitcoincharts.com/ in the past, though it seems to be down at the moment

http://www.coindesk.com/price
http://www.investing.com/currencies/btc-usd-historical-data
http://www.quandl.com/c/markets/bitcoin-data
https://bitcoinchain.com/markets

Also, there was a Bitcoin Time Series spreadsheet.  Scroll to the bottom to see the data sources.

Hey Stephen, the excel file you linked to appears not to be updated.Do you mind updating it to the latest history? thnx


text:
How many throws of a dice are necessary to defeat a brute force attack?
At bitaddress.org I have decided to use "Brain Wallet" and create my own physical randomness using dice. (I understand that dice are more effective than entering dozens of random keys on the keyboard.)
How many throws are necessary to create a passphrase which would defeat a brute force attack on my keys?

I hope you mean a paper wallet, not a brain wallet. Brain wallets don't use any randomness.

Rolling a single die has 6 possible results. A private key is a 256-bit number. But its address involves a 160-bit hash, so that's the most you need to use.  To know how many dice rolls you need to get this much entropy, you need to know when 6^n > 2^160 (because the probability of a certain sequence of n die rolls is 1/6^n). This is equal to ceil(log(2)*160/log(6)) or 62.
So if you roll a die 62 times (or a pair of dice 31 times, etc. - but be sure to count the die separately, and in a consistent way - e.g. do not always write the smaller of the two first, because you'd remove some entropy), and write down the numbers in order (e.g. "132415614..."), you can use that to seed a crypto random number generator that can give you a private key as secure as is possibly useful.
Electrum's seed is 128 bits, and is considered (by those who created and use it, at least) to be secure enough for not just one private key, but all of your private keys. To match that entropy, you need 50 die rolls.

Every five dice add 12.9 bits of entropy. Minimum: 30 dice for 64 bits. Better: 60 dice for 128 bits.
https://en.wikipedia.org/wiki/Diceware

You can already use bitaddress to directly convert 6-sided die rolls into a private key.  Go to "Wallet Details" and enter your die rolls in Base6 format (enter 0 for 6, 1 for 1, 2 for 2, 3 for 3, 4 for 4, 5 for 5).  This requires 99 die rolls and assures 256 bits of entropy.
If you choose to hash a lower number of die rolls, then 50 rolls should assure 128 bits of entropy and be quite secure.  You should not be satisfied with anything less than 80 bits of entropy, so 31 die rolls would be your bare minimum.


text:
Is it correct that more than 160 bits of input data for producing a private key are superfluous?
If this is true, when I make a 64 character hexadecimal private key I need only provide randomness for the first 40 characters (40 x 4 bits per character = 160). The remaining 24 characters can be zeros.

We'd have to know what algorithm you're using to produce the private key.

A deck of shuffled cards. There are four suits (hearts, clubs diamonds, spades) so two cards drawn from the top allow 16 permutations of suit combination; each one of the sixteen permutations corresponds to a hexadecimal digit. After eight hexadecimal characters have been determined, I reshuffle the pack before determining the next eight characters.
To date I have done this to produce all 64 characters, but need I only produce 40 in this way? The problem is more theoretical than practical as producing the remaining 12 characters by cards is not much work.

Oh, you mean actually putting zeroes in the private key?! No, that's completely unsafe.

No, that's not correct at all. If someone knew that your private key contained 96 zero bits, their search space would be drastically reduced. 256-bit private keys are used because they are the minimum considered sufficient to provide the level of ECDSA security required. 160-bits can be used in the hash function because hash functions get more security per bit than ECDSA does.
You could, however, use 160-bits as a seed to generate a 256-bit ECDSA private key. For example, you could use a SHA-256 hash of a 160-bit seed as your private key with no loss of security. You can even go down to 128-bits with no significant loss of security.

I don't understand why the two cases are different. In each case the search space is of size 2^160, isn't it? In your recommended algorithm the brute-force attacker has to know to perform an extra SHA256 on each trial, but if this is to provide more than security by obscurity, we must assume she does know that. What am I missing?

Are ecdsa keys containing lots of zeros vulnerable to some attack more efficient than brute force?

@NateEldredge You're missing that the attack would be deriving the private key from the combination of the public key and many bits of the private key. To provide comparable security to a 160-bit hash, an ECDSA private key must have about 256 unknown bits.

If I understand all this correctly then the data input, on which a 256 has is to be performed CAN be only 128-160 bits, but if I make a 64 character hexadecimal private key then I need all the 64 characters to be determined randomly.

@Peter Correct. You don't want to have any pattern to the data that might make it easier to brute force the private key from the public key. Patterns hidden behind cryptographically-secure hash functions can't be exploited, at least so far as we know.


text:
Encrypting Bitcoin private keys instead of printing out paper
I follow the procedure of making a cold storage wallet: downloaded copy of bitaddress.org using an off-line computer booted with Ubuntu from CD.
Instead of printing out the private keys and corresponding addresses for my bitcoin, I simply use a JavaScript file (http://prgomez.com/ursa/) to encrypt the private key, while I am using Ubuntu. I then keep together the address and encrypted bitcoin private key safely so I don’t lose it, but with no need for special security. All I need to keep in paper is my 80 bit plus password for the encryption of the key.
Logically, this seems to me safe, though I have so far only entrusted small sums of money to this procedure.
Is it safe?

It's challenging to answer this without a clear definition of what you mean by "safe." I'll assume your two main concerns are (A) loss by theft; and (B) loss by user error.
For (A) you're "safe." You followed offline cold storage wallet generation procedure and your private key was not exposed in an online-hackable way. You have the same level of theft protection as an offline-generated paper wallet -- with the added level of protection that your private key is encrypted. If your paper is lost or stolen, another party would have to know your method of encryption as well as your password. (Naturally, if your password is stored on the paper, then you effectively have the same security as a non-encrypted wallet in the case of theft or loss of the physical paper.)
For (B) there are a number of possibilities, but here's some scenarios to consider.

Are you entering the unencrypted or the encrypted private key into bitaddress.org? If the latter, then you gain no benefit from the encryption and might be confused when attempting to retrieve your funds.
How confident are you that you'll be able to recover the unencrypted private key when the need arises? Your use of a home-brewed step here makes it a good candidate for something to go wrong. Are you prepared to keep a working copy of the encryption/decryption software -- exactly as it was used at the time of wallet creation -- for the entire lifetime of the paper wallet? Did you test decryption at the time you generated the wallet to ensure the decrypted private key matches the original unencrypted key? Have you tested retrieving funds to ensure that your process works from end-to-end? Are you going to remember all the steps involved 10 years from now or do you need to keep written notes?  Etc.
Same with any password-protected item, how confident are you that you'll be able to remember the password when the time comes? People forget passwords so often that nearly every website with password-based authentication includes a recovery mechanism. Are you printing the password along with the paper wallet? If so, then what is the purpose of the encryption? Are you printing the password and keeping it elsewhere? If so, then will you be able to find it when the time comes? (How many times have you put something where you'll "never forget where it is" only to discover you can't find it later?)
Same with any paper wallet, how safe is yours from physical loss, disaster, etc.? Are you planning to keep a backup copy? How do the backup copies affect your risk of theft? How long will the paper and ink last?

Have a look into BIP0038. bitaddress.org can generate BIP0038-encrypted private keys. Three benefits of this are:

BIP0038 uses scrypt with parameters intentionally tuned to make brute-force password guessing attacks very slow. In this thread folks were getting 7 password guesses per second at the time, which is not very many for a brute-force attempt.
bitaddress.org generates the wallet in such a way that the actual private key never exists in the computer's memory while the wallet is being created. Counter-intuitive, but true -- it uses the "EC multiply" variation of BIP0038. (Of course your password exists in memory, so you will likely still want to do this offline.)
It is more of a standard than your home-brewed encryption step. BIP0038 is not officially an adopted standard as of this writing; but enough folks support it at this time that it may as well be a de facto standard. This means you have several options for retrieval, with less chance for human error or other issues presenting an obstacle to retrieving your funds.

Excellent practical points. The reason for the "home brewed" procedure is that I know what I am doing and why. My main worry is A i.e. hacker theft.  The javascript file (http://prgomez.com/ursa/) for encryption is stored in several places, and often used as I use it to encrypt sensitive emails. Will take a look at BIP0038, but don't understand it yet.


text:
Transaction I never made
I'm a newbie so this might be a stupid question, but on Blockchain, it says I have made two transactions however I only did one transaction and the overall thing does not make sense to me. Could someone please explain where this second transaction is from and what the 10 BTC on the right means?
This is the page: https://blockchain.info/address/12b6BMrGnqm5eHiLGejWuESurbVxwVU4gk
Thanks

It would help if you told us what sort of address this is (e.g. your private wallet, an address you received money at in an online wallet, etc.) and what the transaction you do understand means (e.g. were you part of a bet, did you buy coins to deposit in your account, etc.).

I'm going to make a wild stab in the dark, that you are probably moving bitcoins from an exchange, because if you are new to this you are probably not making multi-party payments.
The earlier of the two transactions (green) is showing several previous addresses, paying several others. This would occur for instance when you withdraw from an exchange: ie they will be paying many people who are all making withdrawals, from coins that were deposited at many addresses.
The second payment, I am going to assume is a consolidation payment. As you say you only made one transaction, I can only think that this is either an exchange consolidating your deposit (because your first transaction was from one exchange to another), or else you withdrew to an online wallet service which is doing the same thing - consolidating. (Beware)
There is a third alternative, and that is that your machine has been compromised and you have just lost some bitcoins. I hope not.

Note: I assume the linked address is your own.
The gray 10 BTC shows the total amount that was sent to the recipient address: The second, newer transaction associated with your address collected a total of 10 BTC from a number of different addresses in one transaction to the receiving address, including the 0.3645 BTC from your address shown in the red box.


text:
How do I get all the latest transactions from Bitcoin network using Python?
Is there a Python client to listen to all latest transaction from the Bitcoin network? How does blockchain.info doing it?

Blockchain.info uses a special system that doesn't involve Python (as far as we know), they're most likely using a modifed node that notifies them of transactions.
The easy way
Just use Blockchain.info's transaction notification service. Their websockets api lets anyone subscribe to any bitcoin address.
The hard way
If you want to listen to all latest transactions, and not to addresses you own, you're going to need more in depth control. Otherwise use Bitcoind and its walletnotify parameter. Check out PyNode, a Bitcoin node implementation in Python.

You could write python code that polls an instance of bitcoin-qt/bitcoind, the reference client. Here are the RPC calls, available via HTTP requests:
https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list
The getrawmempool can could be polled to return unconfirmed transactions that have been locally seen. (I believe -walletnotify will only notify about wallet-relevant transactions, but tailing the debug log could be another way to learn of new unconfirmed transactions.) By using the -blocknotify command-line option, your external scripts can receive notification when new blocks are discovered, which might also include transactions that were never in the local unconfirmed pool.
You'd have to run with the -txindex option, so that you could pull all new transaction details out of the local blockchain, rather than just those from your wallet.

It looks to me like chainsnort is just what you're looking for:
 https://bitcointalk.org/index.php?topic=373490.0
The publicly available version uses Python websockets and connects to blockchain.info to listen to all new transactions in real time. There is also an RPC version to get the same type of data straight from your own bitcoind node, without relying on blockchain.info, but it's still in private beta.


text:
Spend BTCs from a paper wallet
So, I want to create a cold storage bitcoin address to store incoming BTCs from donations and payments (I'm a freelance developer so I'm getting used being payed with BTC). Since this address has to be spread among lots of different people, I can't change it so frequently, it's like my gpg public key, it would be a pain to change this address.
This means that I need a way to spend the BTCs stored on my paper wallet in a safe but fast way. The most obvious solution is using the Blockchain.info app, scanning the private key when required (I do not care about privacy in that case, I know I can be traced and such, but I'm ok that change goes back to the same paper wallet).
My question is, how much should I be worried about my private key being compromised by scanning it with my phone? Are there any known reports about this happening? Are there same safe ROMs that could prevent this?
If this is a serious concern, how can I spend the BTCs on my paper wallet in a same way whitout changing the public address everytime?

The Blockchain.info Android Wallet app is open-source and has been heavily peer-reviewed by the community. Your private key is stored on the device once scanned, but it is encrypted with a password so even if you lose your phone they won't be able to access the key.
As for the using safe ROMs, Android is a very secure sandboxed virtual machine that has been rarely compromised. The encryption of your keys is based on powerful and heavily tested Java libraries which run on an open-source platform called Dalvik, which is based on the Java Virtual Machine (JVM).
In other words, you really couldn't ask for a more secure environment.

If it's a large amount of money, you could consider keeping a cold wallet and a hot wallet. This is what exchanges do, and Mt.Gox tried to do but failed spectacularly at.
So your paper wallet will be your cold wallet. You will need a computer which is virus-free and not connected to the Internet very often (e.g. take an old computer which you never use, wipe the hard drive, install Linux on it, and don't use it for anything other than running a Bitcoin wallet). Keep a hot wallet on your phone, which you use to pay people. When it runs out of funds, go to that computer, send money from your cold wallet to your hot wallet, and turn the computer off. (Technically, there is an even more secure way to do it. The computer will remain forever offline, even when creating the transaction. The idea is to form the transaction on another computer, sign it using your private key stored on the cold computer, and then broadcast the transaction it using the other computer. However, this is a bit annoying to do and I wouldn't worry about it unless you were operating a Bitcoin service dealing with thousands of customers' bitcoins.)


text:
CreateRawTransaction and SendRawTransaction how to specify transaction fee?
I am able to createrawtransaction and sendrawtransaction but how am I able to specify a transaction fee for the miners?
I am looking at possibly large transaction sizes due to multiple inputs (around 100) and I have had a few of them never show up to their destinations and some of them do show up. I am assuming this might be due to the lack of transaction fees since I am using the exact same code to send both raw transactions.
So again, how can I specify a transaction fee in Bitcoind with creating a raw transaction.
And by the way, I am spending the funds from a multisignature address, in which 2 of the private keys are not controlled locally, so settxfee will not suffice. I want to write it into the transaction itself.

The transaction fee is specified by the difference of the sum of inputs and the sum of outputs, i.e.
transaction fee = Σ(inputs) - Σ(outputs)

In other words, you set a transaction fee by sending more than you assign to the recipient.


text:
How to store Bitcoin values in a MySQL database? floats are bad.... right?
What should I be using to store the values of a wallet in a MySQL database?
Apparently floats are too imprecise to be storing Bitcoins, especially down to the satoshi.
So what should I be using? Decimal ?

There would be small expression errors. If you want to save as integers just multiply by 100000000 and save satoshis.
As @ypercube states MySQL BIGINT is a wise type choice for storing satoshis, MySQL INT does not have a sufficient maximum value.

I'm not entirely sure I understand your math.

@WannabeeBitcoinDev: Store the number of satoshis rather than the number of BTC, since satoshis can't be subdivided.  For example, for an amount of BTC 12.531, store the integer 1253100000.  For BTC 0.00031, store 31000.

This is not a good answer. INT datatype in MySQL is restricted up to 2^32-1 for UNSIGNED and from -2^31 to 2^31-1 in SIGNED. BIGINT or DECIMAL is a wiser choice.

@ypercube The answer says "integers" (versus floating point as in the question). INT, BIGINT and DECIMAL are all examples of integer types. If someone creating such a table from this answer can't figure out the appropriate integer type on their own, they shouldn't be creating database tables.

@dchapes: If someone knew, they wouldn't have asked a question in the first place. INT and BIGINT are integer datatypes, yes. DECIMAL is a fixed point but not integer. And someone who doesn't know the details, may confuse INTEGER with integer. I only meant this comment to notify the answerer, so he can improve the asnwer. I have not downvoted as I agree with the general notion of the answer.

What you want is a MySQL Decimal field.
Specifically you want a DECIMAL(16,8)
That will give you 8 digits before the decimal and 8 after the decimal
See http://dev.mysql.com/doc/refman/5.1/en/precision-math-decimal-changes.html for details.

What makes you believe the value won't rise above 10^8 USD? :)

since there can't be more than 21 millions BTC, (7,8) should be enough. but if there is a possibility of treating additive values, say volume exchanged over a year, then it can go way over.

storing ohlc base and quote volume in this format explodes the memory big time especially for 1m candles, perhaps keep ohlc float and volumes in double?

@Gili The question is about storing an amount of BTC, not how much BTC is worth in fiat. Since the max amount of bitcoin possible is 21,000,000 8 digits before the decimal is sufficient.

a float natively only goes up to 7 decimals in most cases. if you just roll with decimal you'll be safe. When you round a 7 digit number to 8 decimal places you'll run into rounding issues.

unusable. floats become very sparse at higher values. the 8 digits after the dot can't be retained after a few hundreds. it becomes integer between 8 and 16 million, and after that you have to jump 2 by 2 until the max 21 million of BTC. however it's possible to possess 19 million BTC and 5 satoshi. not that you would care at this point, but still people's asset can't be waived under the leg.


text:
Anyone able to run Bitcoin-Qt 0.8.6 on Mac OSX 10.9.2?
I ran the Mavericks update today, putting me at 10.9.2 and now my Bitcoin-Qt stops responding after it notifies me that it is "verifying blocks". I am using it for ongoing research and am in a bad spot now. I realize I should have thought about the possible ramifications of running the update.
At any rate, is anyone able to get it to run? I've tried running it from the .dmg via the gui and via command line. I get the same results in both cases. As soon as it goes to verify blocks, it stops responding.

Yes, it's running on my system, which is a 5 year old Macbook Pro running 10.9.2.  I have 4gb ram and a 2.4ghz Core 2 Duo.
I did have problems however trying to sync the blockchain initially.  I had a partial blockchain that I had on another computer, which I copied over.  Normally in this case the computer reindexes the block files on disk, figures out where it is, and then picks up downloading from the last point.
However, I got behaviour very similar to what you're describing.  It would go to "verifying blocks" and stay that way for a very long time.
In the end I fixed it by deleting all of my previous blockchain (I deleted everything but wallet.dat), and then let the app download the blockchain from the beginning.  It took about 4 days, but in the end it works as expected.
Didn't really test it out much, but I don't think I saw the same thing on my 20gb Mac Pro, so I think the MacBook was just too resource constrained.
Also, the new Bitcoin coming out, Bitcoin 0.90, is available as a 64 bit app for Mac OSX, so this will likely help. I'm running 0.90 on my Windows machine and it's fine.  Haven't put it on the Mac yet.


text:
Is the time a transaction was done recorded in the block chain?
Is there something like a timestamp of each transaction recorded in the block chain, or only the mere fact that the transaction was done?

There's a unix timestamp in the block message. https://en.bitcoin.it/wiki/Protocol_specification#block
So you would be able to get know the transaction hit the blockchain down to roughly a 10 minute resolution.

I think the timestamp in the block can be off my more than 10 minutes.It can be manipulated by the miner finding the block within certain limits. Blocks are considered valid if their time is greater than the median of the last 11 blocks and less than currentTime + 2 hours.

Also, the transaction could have happened quite some time before a miner decided to include it.


text:
I've sent a small low priority transaction with insufficient fee with blockchain.info wallet, what will happen next?
I've sent a transaction which has a <0.01 BTC output, with zero fee using blockchain.info Android client. It is not being relayed (violating memory pool rules of bitcoind). What can I do to recover the Bitcoins that participated this transaction?

You can do two things

Wait until the transaction gets relayed. Transactions without fees usually get relayed as well, but often a later than those with a fee.
Send a new transaction spending the same outputs, with a fee. It's possible that some miner will accept it eventually. This can be tricky when you use blockchain.info's wallet. It's called double spending, you can probably find some information on that elsewhere, like on bitcointalk. That article suggest that you import the private key from the address you send from to Bitcoin-Qt and try to do the same transaction again from there.

OK, the transaction just disappeared from blockchain.info after 48 hours, and now the Bitcoins spent in this transaction are back in Blockchain.info wallet balance, so I am free to spend them again.

Can you explain step by step how can we "send a new transaction spending the same outputs" using the Bitcoin.info?


text:
Is it legal to buy Litecoin and sell those within a few minutes?
In US, is it legal to buy and sell cyber currency within a few minutes?

I cannot think of any law it would violate.  But legal advice needs to come from a lawyer who you hire.
Note that if you sell it for more than you paid to buy it, regardless of how long you held it, you need to report it on your tax return as a capital gain, and pay the appropriate taxes.  (If you sell it for less, you may be able to deduct a capital loss, subject to a variety of restrictions.)


text:
How to report the tax if I trade BTC to LTC?
Assume I traded 100 times between BTC and LTC and I earned $100 IF I sell all coins at market price.
However, I don't want to sell my coins yet. How I can report to the US tax?

The IRS treats digital currencies as capital assets and are therefore subject to capital gains taxes. Any disposition of these digital currencies, including trading and spending, is a tax event and capital gains must be calculated in USD.

References:
https://en.bitcoin.it/wiki/Tax_compliance

What I should put for the USD price of the BTC and LTC if the platform does not have a BTC-USD market?

Use a price from another platform then, like coingecko

I'm not a tax accountant or lawyer, but usually capital gains tax is only payable when you convert your assets into fiat currency. I would expect that the BTC-LTC trades are not taxable - only the sale to USD would be a taxable event.
If during the trades, you sold your (for exampe BTC) tokens for USD, then used USD to buy more (for example LTC) tokens, then the sale to USD would be taxable.


text:
Blockchain is showing 2 incoming addresses for a transaction?
A transaction into one of my wallets is showing that it came from two addresses? How can I find out which one it came from?

It came from both.
Transactions can have multiple senders and multiple recipients.
Sometimes a single address can also be both a sender and a recipient.

But what if I want to send money back to the person that sent it to me - what address do I use?

@sprstr you don't: you should contact him to ask him an address.


text:
Is there any way to directly query the block chain for the body of a transaction given its hash?
Blockchain.info provides this functionality in a simple API like so:
https://blockchain.info/rawtx/fc15f762e8dbbdd407534047ef2a9211ca0e79c3625d5fe73cdacade4f9118d6
However, I would prefer to make this query directly against the network blockchain rather than to a third party like blockchain.info.

You can use JSON-RPC to achieve this. The only missing information will be the relayed_by field.
To use the JSON-RPC API of your client edit your bitcoin.conf file like this
rpcuser=user
rpcpassword=password
rpcport=8332
server=1

Then you can use a library to query the API like JSON-RPC for PHP
You can also do it on a much easier way by using the command line
./bitcoind getblock c15f762e8dbbdd407534047ef2a9211ca0e79c3625d5fe73cdacade4f9118d6


text:
Ripple: a strange send I don't quite understand
A few days ago I've sent Bitstamp through Ripple 0.3168 BTC.
I had 0.4168 Bitstamp BTC before, and 0 BTC balance with everyone else.
Now strangely I noticed that instead of Bitstamp owing me 0.1 BTC as expected, it owes me 0.2022 BTC, while I owe to a friend of mine 0.1022 BTC.
While it sums up, I wonder what's the deal:

why didn't it send entirely Bitstamp BTC to Bitstamp?
how are us supposed to settle that? i.e. should I explicitly send BTC through Ripple to my friend, or simply when he tries to spend them he'll tap from my pool (hence no explicit action is needed)?

The short answer: using the info you and your friend provided, Ripple did what was best for everyone.
I don't know how to pull up the details of the transaction number you link to (I have no affiliation with Ripple other than as a user). But using the Ripple Live Graph I can infer the account of your friend and I note that currently your friend has no trust line to Bitstamp.

why didn't it send entirely Bitstamp BTC to Bitstamp?

So I'm guessing that what happened was that your friend had 0.1022 BTC IOU from Bitstamp but had the trust set to zero indicating they don't want more and would like to get rid of what they have (i.e. your friend told Ripple they don't trust Bitstamp). Your friend had specified that they trust you to pay them back BTC by opening a trust line to you
It's in your friends best interests to hold an IOU from a trusted source (you) rather than an untrusted source (Bitstamp). It's in your interest to have Bitstamp get the funds you asked to send in the cheapest way possible.
The way Ripple found to achieve both those results at once was to route part of your payment through your friend. Both directly sending back Bitstamp's IOU and routing through your friend had no transfer fee, only the 0.000010 XRP transaction fee) so either should be equally good to you.

how are [we] supposed to settle that?

As with any loan between friends it's up to you. With some friends I've made my repayment policies very clear, with others I'm more informal. [As an asside, I'll note that previous ripple implementations like classic.ripplepay.com wouldn't let your friend trust you without you agreeing.]

i.e. should I explicitly send BTC through Ripple to my friend

No, that would add to the debt, giving your friend more of your IOUs.

or simply when he tries to spend them he'll tap from my pool (hence no explicit action is needed)?

That is most likely the best option, and certainly the simplest. When they next send a payment, Ripple will consider going through you. If the recipient trusts you then they may end up with your IOU (by the way your IOUs have no trasfer fee, Bitstamp IOUs have a 0.2% transfer fee).
If the recipient trusts Bitstamp (and you still hold the Bitstamp IOU) then the recipient may get Bitstamp IOUs and your IOU will decrease or zero.
If before this, you were to use your Bitstamp IOU in payments (e.g. to Bitstamp for withdraw) then you'd have a negative balance and your friend would be unable to use (spend) your IOU except to others that accept it (trust you).
If your friend wants to explicitly redeem your IOU (i.e. asks you to pay him back) you could send him actual bitcoin outside of Ripple and at the same time he'd pay you the matching amount in Ripple to zero/decrease your debt. If you hold Bitstamp IOUs (perhaps you get some more via a deposit just so you have enough to cover your debt because you were asked to) you can just tell your friend to simply pay himself via his Bitstamp account.

Whoa what a great and detailed post, thanks!

I pasted the transaction and metadata here for anyone who wants to look at the details. As it happens, the path it chose was equally good. In some cases, this logic will allow you to avoid all or part of a transfer fee, but in this case you were returning IOUs to their issuer, so there was no transfer fee to avoid.

Yes, we need more examples like this great explanation in ripple documentation.


text:
What is the algorithm for generating a Ripple address from a ecdsa public key?
I know it is some combination of sha256 and ripemd160 that is used on the public key component to obtain the Ripple wallet address, but what is the specific algorithm?

The process of going from a Ripple secret to a specific ECDSA private/public key (which you didn't ask about but I included it here anyway) is documented on the Account Family wiki page.
From a ECDSA public key, {X,Y}, you do ripemd160(sha256(CompressPoint(X,Y)).
That's then encoded in base58 (using the Ripple alphabet/dictionary).
You can also look at the rippled implementation or a Go implementation.


text:
BCC, BTC Private Keys
If you were to send BTC accidentally to a BCC address then would the funds have been sent to the same private key on the BTC blockchain?  Would the owner of the BCC key be able to retrieve those coins in a BTC wallet?

To answer your question, if the person whom you are sending the BTC/BCC have the private key of the wallet, then he can access the BTC as well as the BCC in the wallet.
Both are just different chains, but each wallet share the same private key in both network.
For more detailed answer about sending BTC to a BCC wallet, click here

Thanks, that's what I thought.  The accidental recipient is an exchange, so I sent a request to route the coins into the proper wallet.  Hopefully they'll help me out.

Yes, BTC and BCC share the same addresses and the same private keys.


text:
Is there a lightweight blockchain parser library/server?
I'm using bitcoin-qt and have a local copy of the blockchain, in which I'm running some analysis with the JSON-RPC API using mostly getblock and getrawtransaction. I have no need writing or sending transactions in this use case. It's overkill to run a full node just to read the blockchain, and it hurts my analysis performance, too.
Is there a (preferrably tested) library to parse the blockchain and return objects, JSON or not? Language doesn't matter much. If not, is there a node implementation that allow turning off network and wallet features?

It should be easy with bitcoin-qt to effectively disable networking with something like -connect=0.0.0.0.  And I don't think the wallet features should have much effect if you just don't use them.

Here is the lightweight blockchain parser https://github.com/normanvolt/blockchain-parser

There are a couple available:
https://github.com/znort987/blockparser
Which is c++ based and has some basic analysis functions already written.
http://codesuppository.blogspot.com/2014/01/how-to-parse-bitcoin-blockchain.html
describes the basics of parsing the block chain and links to code written by the author of the post.
It looks like most projects don't parse it directly and use the RPC interface of the main bitcoin client.

A good solution would be to use a trusted third-party that has already parsed the entire block chain for you. For example, the Blockchain.info API is quite well suited for your purpose.
Specifically what you want is the Block Explorer API which returns JSON objects.

Given that I have a local blockchain, I think it would be more efficient to reach my disk than the network. I've considered this option and the apparent lack of standalone tools bothers me.

https://github.com/alecalve/python-bitcoin-blockchain-parser just parses the blkXXXXX.dat directly for you into Python, no servers needed. Likely much slower than the C++ option from https://bitcoin.stackexchange.com/a/22621/21282 ,  but good at least for quick prototyping since in Python.


text:
How can I ensure that bitcoind does not use unspent outputs for a given address?
With RPC calls to bitcoind, from separate (python) scripts, I'm:

calling getnewaddress to set up a new key pair for a 'special' address, assigned to a distinct account (let's call this 'specialAccount')
building raw transactions (outside bitcoind) that spend outputs to this special address and then calling bitcoind to sign send

In addition to the above, it is possible that bitcoind is also called directly, to make payments, or whatever.
How can I be absolutely sure that bitcoind does not consume outputs to my special address outside of signing outputs to this address in signrawtransaction?
We can assume that there are no calls that explicitly spend from 'specialAccount', but the problem is that, as I understand it, it is possible for bitcoind to borrow arbitrary unspent outputs for the purpose of paying transaction fees. (See this issue, for example, and also this one.)
Is there any way for me to lock the special address, and prevent this being used to pay transaction fees for other accounts, or to otherwise be able to use bitcoind to sign raw transactions that use outputs to this address without making the public key for the address more generally available within bitcoind?


text:
ATI OpenCL V.S. NVidia Cuda Cores
First of all, i would like to say, i really don't want this thread to be some debate about your favorite video card manufacturer. So please just take that elsewhere.
I have heard from a lot of people that ATI & Open CL is much better for mining than NVidia with Cuda.
When i first heard this i was kind of shocked, because pretty much everything i have ever heard in the past was that Nvidia's Cuda was quite powerful at solving mathematical problems, and I even had a couple university professors that swore by Nvida cards over ATI for this very reason.
So what is it, about the Bitcoin and Litecoin algorithms that make it so much easier for ATI cards, or should i say harder for NVidia cards?  I want to understand the technical reason behind the common knowledge.
Thanks.

In many ways, it is just coincidental that GPUs are going at hashing. It doesn't surprise me that some GPU engines are a better fit than others. A particular GPU might be very good at some types of mathematical operations (or rendering, for that matter) but might not be particularly good for hashing.
This is discussed in some detail on the bitcoin.it wiki:

Firstly, AMD designs GPUs with many simple ALUs/shaders (VLIW design) that run at a relatively low frequency clock (typically 1120-3200 ALUs at 625-900 MHz), whereas Nvidia's microarchitecture consists of fewer more complex ALUs and tries to compensate with a higher shader clock (typically 448-1024 ALUs at 1150-1544 MHz). Because of this VLIW vs. non-VLIW difference, Nvidia uses up more square millimeters of die space per ALU, hence can pack fewer of them per chip, and they hit the frequency wall sooner than AMD which prevents them from increasing the clock high enough to match or surpass AMD's performance. This translates to a raw ALU performance advantage for AMD:

AMD Radeon HD 6990: 3072 ALUs x 830 MHz = 2550 billion 32-bit instruction per second
( Nvidia GTX 590: 1024 ALUs x 1214 MHz = 1243 billion 32-bit instruction per second

This approximate 2x-3x performance difference exists across the entire range of AMD and Nvidia GPUs. It is very visible in all ALU-bound GPGPU workloads such as Bitcoin, password bruteforcers, etc.
Secondly, another difference favoring Bitcoin mining on AMD GPUs instead of Nvidia's is that the mining algorithm is based on SHA-256, which makes heavy use of the 32-bit integer right rotate operation. This operation can be implemented as a single hardware instruction on AMD GPUs (BIT_ALIGN_INT), but requires three separate hardware instructions to be emulated on Nvidia GPUs (2 shifts + 1 add). ?This alone gives AMD another 1.7x performance advantage (~1900 instructions instead of ~3250 to execute the SHA-256 compression function).
Combined together, these 2 factors make AMD GPUs overall 3x-5x faster when mining Bitcoins.

This is also discussed in a bitcoin talk thread.

that is a nice theory, but the real reason seems to be a bit different, bit coin minning requires some special operations on integer (whole) numbers, when most computations today are done using floating point. Nvidia has been shifting the computational abilities of there cards along the generations to favor floating point. If you want to dive down into the details there is a very good article over here:
http://www.itproportal.com/2013/04/17/amd-thrashes-nvidia-at-bitcoin-mining--will-the-gap-ever-be-closed/

Nvidia focuses on larger way, how the solution is going to applied in real world. AMD focus on the core computing architecture and rest is left to the implementors.

What is meant by "larger way"? This answer doesn't make any sense, and makes claims that are not supported by citations to evidence.


text:
Solo mining litecoin on OSX
I would like to do some solo mining of litecoin on OSX.  I realize the probability is low that i will hit it. but i like the idea of the lottery.  I have a miner setup (cgminer) and i have successfully connected to a pool.  I have found lots of guides that explain how to do this on Windows like:
https://bitcointalk.org/index.php?PHPSESSID=3rq912e407g04cjq8ehdhnk457&topic=83371.0
But what all these guides tell you to do is edit litecoin.conf and then restart litecoin-qt.  But does this still apply to OSX? I don't see a litecoin.conf anywhere.  I have looked in
Library/Application Support/Litecoin
Is it still litecoin.conf in OSX? or is it a different file?

~/Library/Application Support/Litecoin is exactly where your litecoin.conf has to go. Just go ahead and create it.
Good Luck with the Lottery!

So, i have added that file, and restarted litecoin-qt.  But when i launch bfgminer with the settings: bfgminer --scrypt -o http://127.0.0.1:9332 -u username -p password  -w 64 -I 13 it just hangs and displays an empty terminal.

Oh, I'm dumb, i had a # in my password. So it works now. One more small question.  How does litecoin-qt know which public key to credit when winning the lottery (say i have a couple public keys).

Also, when it starts i see [2013-05-06 14:31:39] Probing for an alive pool  [2013-05-06 14:31:39] Network difficulty changed to 396 (2.839Gh/s)  [2013-05-06 14:31:39] No suitable long-poll found for http://127.0.0.1:9332
Does this mean i have not set it up correctly?

No suitable long-poll found means that your bfgminer could not find a server that will inform it of a new block appearing on the network. This is correct, since you are solo mining, and litecoin-qt doesn't supply this.
Don't worry, your setup is correct.
Not having LP only means that your miner will get informed a little bit slower by litecoin-qt about a new block a little later, and potentially doing work on a block that has just been solved for a few seconds at most.

Thank you!  I just ran bfgminer for a couple hours but it is still displaying 0Kh/s.  When i have used bfgminer in pools in the past it would always display a non-zero rate for kH/s. Is this an indication that something is wrong? or is there no kH/s reporting when solo mining?


text:
How is Bitcoin / Litecoin mining prize awarded when solo mining?
When solo mining and connecting to either the Bitcoin-QT server or Litecoin-QT server.  If I actually do find a solution to the block, how is that prize awarded? I have not shared my public key via bfgminer, eg:
bfgminer -o http://127.0.0.1:8336 -u bitcoinrpc -p ........
How does the bitcoin/litecoin network know which public key to credit? Or does the credit just appear in the bitcoin/litecoin wallet?

The first transaction in a block, "creates" an amount of new bitcoins. The miner of that block puts the address there, so it can make sure it's an address he has access to.
Most solo miners are connected to a bitcoind daemon. Whenever they find a block, the new address containing the block reward is added to their wallet.
When you run bfgminer, you give it access to bitcoind through your RPC login, so it will add the address to your wallet.


text:
Buying Bitcoins using Guyana Dollars
Does anyone know what is required to establish an exchange that accepts Guyana $ as payment for Bitcoins?

You want to make your own BTC exchange?
It looks like $1USD = $205.20GYD.

related: What would it take to create my own Bitcoin exchange?

You need a bank account in Guyana for people to deposit money. Then you need a server to run the exchange. For the software you can check the answer to this question: Is there an open source Bitcoin exchange?
If you don't want to run you own server you can look at this: http://www.buttercoin.com/#/


text:
How is the real world value of bitcoins generated?
I do not understand where the value of the bitcoin comes from.
In old times people were trading in gold or silver. They began to deposit the gold coins in banks and started to trade with these deposit certificates. The deposit certificates became paper money. Then the convertibility of paper money for gold was abandoned, but the paper money had its momentum so it remains in use today.
But how did bitcoin get its momentum? I understand that to get bitcoins, you need to compute some cryptographical puzzles, so the amount of bitcoins is proportional to the computational time spent. But is this computaitonal time spent usefully as in industry, or is it just spent for the sake of gathering the bitcoins?

Just spent for the sake of gathering bitcoins. Its value is given from simple market laws (bid/ask), and people started buying it because they thought it might have been useful and successful.

The purpose from the perspective of the miner is obviously to earn bitcoins, but the purpose of the mining process is to verify transactions in the network.

BTC works as any currency. As long as people see value in it, it has value.
The momentum was just the curiosity the users had... Also the whole "Make free money with your computer"- thing which was started.
A big influence was the famous "How does bitcoins work" video I saw on vimeo. That got ME started at least. (Link to updated version)
The algorithms your computer solves when "mining" isn't used for anything no.
There are also other kinds of crypto currencies on the rise. The most notable is Litecoin. It uses a different algorithm. (Scrypt, instead of BTC's double sha256). The point of Litecoin was to make users able to "mine" more efficiently on their CPU's.
I hope this somewhat answered your question.

Thank you! "The momentum was just the curiosity the users had" and "The algorithms your computer solves when "mining" isn't used for anything no" answered my question fully.

If the algorithms aren't used for anything then they must be useless by definition, no? Of course they are used for something :) If they are used by something else other than that? Not in the bitcoin system.

They are used for securing Bitcoin--they are in fact Bitcoin's central innovation, solving a problem that was previously unsolved in distributed systems.


text:
What happens when an attacker completely controlls your Internet connection?
Bitcoin assumes that everybody sees the same ledger. However, what if your ISP is evil, and modifies your view of the Bitcoin network? Is it possible for such an evil ISP to make your own transactions not go to the real Bitcoin network, while returning results that make you believe that everything is fine? Your local blockchain could end up extremely badly out of sync with the global blockchain.
Is this scenario possible? If so, what happens when you finally sync back with the real blockchain? As far as I understand, Bitcoin always chooses the longest blockchain, but couldn't your evil ISP simulate a really busy Bitcoin network to you so that your fake blockchain is even longer?
Does this mean that applications like Satoshi Proof and Namecoin aren't really secure if networks can be maliciously partitioned? In Namecoin, for example, wouldn't it be possible for a bad ISP to simulate a blockchain that contains wrong domain information?

possible duplicate of Can I trust the peers I am connected to?

Yes, the scenario is possible. The attacker has two possibilities: censoring data sent to the network (likely your transactions) and censoring what the nodes sees from the network.
In the first case the isolated node will attempt to resend transactions that belong to it until they get invalidated or committed into the blockchain.
In the second case the isolated node will not receive incoming transactions and eventually will not receive blocks (if these contain censored transactions). It is however not possible to fool the node into considering transactions as confirmed without the attacker also producing a valid proof-of-work.
The same argument is valid for Satoshi Proof and Namecoin, you can hide transactions, facts and domains, but you cannot inject wrong information.
Once reconnected the node will synchronize with the network (download blockchain & send its transactions) and eventually be up to date.

Why can't wrong information be injected? The censor can simulate a "micro-economy" of other nodes doing transactions, right? Censors aren't just limited to censoring traffic.

They cannot confirm them, since simulating a confirmation would require the transactions to be included in a block that has a matching difficulty with the real network. This is difficult if the node was only recently isolated.

The cost of launching an attack like this would be enormous (tens of thousands of dollars), so it would only be a risk for very high value targets.


text:
bitcoind sendfrom round amount error
I have problem with bitcoind with the command sendfrom
Example :
./bitcoind sendfrom test1  1.99990005
The value when command "listtransaction test1" is 1.99990004.
I'm using bitcoind in ubuntu 12:04 locale en_US.UTF-8
Thanks for help.

What version of bitcoin?

My version is 0.8.6

I've tried this on testnet and I've been unable to reproduce this with 0.8.6. 1.99990005 is always parsed as 1.99990005. What CPU architecture? Have you compiled from source or using the precompiled executable?

To avoid ambiguity by using doubles and floating point numbers, IMO we should switch to decimal strings instead of numbers for monetary amounts in the RPC interface. See https://github.com/bitcoin/bitcoin/pull/3759


text:
What is the database for?
I see the block chain is stored according to the block chain format specification.  But I also see there is a database, which is currently a leveldb database.  Why is the block chain stored in two different ways?  Seems redundant.

Thanks for asking this question.  From the answer provided I was able to update the Bitcoin wiki: http://en.bitcoin.it/wiki/Data_directory

There are basically four pieces of data that are maintained:

blocks/blk*.dat: the actual Bitcoin blocks, in network format, dumped in raw on disk. They are only needed for rescanning missing transactions in a wallet, reorganizing to a different part of the chain, and serving the block data to other nodes that are synchronizing.
blocks/index/*: this is a LevelDB database that contains metadata about all known blocks, and where to find them on disk. Without this, finding a block would be very slow.
chainstate/*: this is a LevelDB database with a compact representation of all currently unspent transaction outputs and some metadata about the transactions they are from. The data here is necessary for validating new incoming blocks and transactions. It can theoretically be rebuilt from the block data (see the -reindex command line option), but this takes a rather long time. Without it, you could still theoretically do validation indeed, but it would mean a full scan through the blocks (207 GB as of march 2019 - https://www.blockchain.com/charts/blocks-size) for every output being spent.
blocks/rev*.dat: these contain "undo" data. You can see blocks as 'patches' to the chain state (they consume some unspent outputs, and produce new ones), and see the undo data as reverse patches. They are necessary for rolling back the chainstate, which is necessary in case of reorganisations.

So yes, everything but the block data itself is indeed redundant, as it can be rebuilt from it. But validation and other operations would become intolerably slow without them.

Ok, thanks.  Does rev*.dat just keep data for rolling back the chainstate/* database?  (I imagine rolling back the blockchain is fairly simply, and just involves pruning off the end blocks and adding the new ones.)

Indeed, just the chainstate; the rest is trivial. In particular, it contains the amounts and output scripts that were consumed by a block.

Hi. Say I want to implement the entire DB in SQL. Is it possible? If so, what are the pros and cons??

http://bitcoin.stackexchange.com/questions/41388/mysql-instead-of-leveldb-for-bitcoin-core


text:
Bitcoin online game integration
I want to create a game where users can win Bitcoins playing my games I created or perhaps other online games. What APIs do similar applications use to achieve this? how do they host the Bitcoins? do they use their own hosted wallet, bitpay? Bitcoin escrow?

I imagine it would be nice to integrate it in some MMO with millions of players, like WoW for example, who play for months on no end :) Great idea, keep me posted!

If you can afford storing the ~20GiB of blockchain on your disk, then bitcoind is a good bet. Otherwise, check out electrum, it has a very similar API, though there are some quirks. For the most lightweight solution, check out blockchain.info API, this should be the same API as bitcoind's.

The bitcoin software has it's own API.
Simply put, they run the bitcoind software and use RPC-JSON as the API.
EDIT : changed according to comment. Other implementations of Bitcoin also have their own APIs

This is an arcane, arcane point, but protocols don't have APIs. Implementations of protocols have APIs.  Hence, bitcoind, an implementation of the Bitcoin protocol, exposes an API.  Other implementations of the bitcoin protocol publish their own APIs.


text:
How do you generate a Ripple address and secret using the ripple-lib javascript library?
The ripple client application can generate new accounts using the elliptic curve algorithm. Is there a high-level function to perform this task?

Yes, there's a nice script written by you.
https://github.com/stevenzeiler/ripple-wallet

You can use this script for it. It generates a secret and an address, and with using library ripple-keypairs you can get private and public keys too.
'use strict';
const RippleAPI = require('ripple-lib').RippleAPI;
var test_server = 'wss://s2.ripple.com';
var keypairs = require('ripple-keypairs');
const api = new RippleAPI({
    server: test_server // Public rippled server
});
api.connect().then(() => {
    /* begin custom code ------------------------------------ */
    return api.generateAddress();
}).then(address_info => {
    console.log("Secret: " + address_info.secret);
    console.log("Address: " + address_info.address);
    var keypair = keypairs.deriveKeypair(address_info.secret);
    var privateKey = keypair.privateKey;
    console.log("Private key: " + privateKey);
    var publicKey = keypair.publicKey;
    console.log("Public key: " + publicKey);
    var address = keypairs.deriveAddress(keypair.publicKey);
    console.log("Address: " + address);
    /* end custom code -------------------------------------- */
}).then(() => {
    return api.disconnect();
}).then(() => {
    console.log('done and disconnected.');
}).catch(console.error);

Good luck =)


text:
How does one work out hashrate based on number of submitted shares
We are running a pool and are trying to get a total hashrate estimate.  How can we figure out how many hashes are being submitted to the pool based on the shares submitted?

possible duplicate: http://bitcoin.stackexchange.com/questions/5299/what-is-the-correct-algorithm-to-calculate-worker-pool-hashrate

A share has more often than not the maximum Target value (as in Difficulty 1). To create a share one needs on average 2^32 tries, or hashes. Multiply the number of submitted shares by 2^32, divide over the period those shares were submitted in and you have your hashrate estimate.


text:
Ripple wallet name?
If I'm reading the website right, it's saying that both Wallet passphrase and name should be kept private.
I now have a conundrum of which name to choose. Should I put my default username (public, well-known by those who know me), or should I put something that is hard to guess (like a password)?
How are the wallet name and passphrase even used in the system? Will someone give me his Wallet name, so I will be able to transfer money to him?

As a rule of thumb, don't give an attacker any more information than you have to. I would say that you should use your normal username; put the effort of remembering an odd username into remembering a better password.

How are the wallet name and passphrase even used in the system? Will someone give me his Wallet name, so I will be able to transfer money to him?

Nope. The username + password is used to look up a wallet file from something called a 'blob vault'. That blob vault contains your private key and your addressbook.

More specifically the blob vault never sees either your username or your passphrase but only a cryptographic hash of them combined. This has been discussed a bunch on the Ripple forums.

@dchapes Ah. So if making your username 5 times harder to guess is as difficult as making your password 5 times harder to guess, then it doesn't matter which one you do?

The only concern would be if I had a wallet named "dchapes" and you knew that then you could attempt to guess my pass phrase by generating the hash(username+passphrase) locally and querying the blob vault repeatedly. Using something like "dchapes.blah" would make it marginally harder; but yeah, just use a strong passphrase and it shouldn't matter.


text:
In getrawtransaction, what is the vout integer in the vin list?
I'm working on trawling the bitcoin transactions coming in via getrawtransaction.
I haven't been able to find the neccessary documentation to describe the vout integer in the vin array:
{"txid"=>"0fbf9a6f2172251611a58028bf596c3ace98b19f6f08d2b6581326c58aecda8e",
    "vout"=>0,     <----- THIS
    "scriptSig"=>
     {"asm"=>
       "3045022100a9ba4f0b8ff86e91e622f43f9b76944643a807c0f6c8b43490087a169fe7542f0220258eaa36c96faaaeb41052e8d4aa41f74950df1b1c2835cb677f201c1ee0a33901 0393a2770ce81ddd9cd1e6ef71a282261ef8c03648373db209078f7850b9ab1ad1",
      "hex"=>
       "483045022100a9ba4f0b8ff86e91e622f43f9b76944643a807c0f6c8b43490087a169fe7542f0220258eaa36c96faaaeb41052e8d4aa41f74950df1b1c2835cb677f201c1ee0a33901210393a2770ce81ddd9cd1e6ef71a282261ef8c03648373db209078f7850b9ab1ad1"},
    "sequence"=>4294967295},
{"txid"=>"4983504e9727a5ea73c4a0915da475faba248d0d8da265e2d270563dc3eabbaf",
    "vout"=>1,     <----- THIS
    "scriptSig"=>
     {"asm"=>
       "3045022100ccc460cb0b8777d14f27acb821eacae0b5316de19db03ea707c59364f098d44f0220058a4f9df9a917944299b4c52efe500d50ab28c2fd29bb7b9ff8b75f38abcd4201 03244951ad9d146a635b321816d953e54986c62ce9c92502873335531dada0156c",
      "hex"=>
       "483045022100ccc460cb0b8777d14f27acb821eacae0b5316de19db03ea707c59364f098d44f0220058a4f9df9a917944299b4c52efe500d50ab28c2fd29bb7b9ff8b75f38abcd42012103244951ad9d146a635b321816d953e54986c62ce9c92502873335531dada0156c"},
    "sequence"=>4294967295}

In the transactions I'm seeing, it tends to vout 0 1 0 1 0 1 in the array. What does this represent in a transaction? Do I need to interpret it in a specific way? Thanks!

The input of every transaction refers to an output of a prior transaction.
An input can't be defined by only the transaction hash.  A transaction consists of 1 or more outputs if you only specify the transaction hash there is no way to know which output is being spent.**
Since these types of questions often come from a larger misunderstanding of how the network "really works" I am going to start with some "plain english" rules on transactions (tx):
1. A tx consists of one or more inputs and one or more outputs.
2. All tx inputs refer to an unspent output of a prior transaction.
3. The full value of an input is always spent; a tx can not spend part of the value.
4. Likewise all outputs are either spent or unspent, they can't be partially spent.
5. A tx "spends" the outputs which are referenced in the input portion of the tx.
6. A tx creates new spendable "unspent outputs" listed in the output portion of the tx.

Now that we got that out of the way, to define a tx input you need to refer to the hash of a prior transaction AND the output index.  The tx hash identifies the transaction, but the transaction may have more than one output so the index is used to identify which output is being "spent" here.
This may seem confusing because you will hear statements such as "I have 20 BTC stored at address 1XYZ..." or "My wallet had 100 BTC", but this is really an abstraction.  The client is merely showing you the sum of all the unspent outputs for an address or the entire wallet.
The Bitcoin network works on the concept of inputs and outputs
The Bitcoin network doesn't consider the "value" an address when validating txs.  When validating a tx, outputs are considered as independent entities.  Spending one output for a particular address has no effect on the other outputs (if any) for that address.  A transaction is valid (among other things)if all the inputs refer to valid unspent outputs of prior transactions (can't spend coins twice), the sum of the outputs is less than or equal to the sum of the inputs (can't counterfeit new coins), and the inputs are signed by the correct private key (only the "owner" of the private key can spend the coins).
Examples
To avoid a lot of excess detail we will look at a simplified version of the transactions used in the Bitcoin network.
Say an previous transaction exists (tx hash 1234567890).  In this transaction you have an input which referenced an unspent output of a previous transaction worth 100 BTC.  You send 50 BTC to one address, 10 BTC to another address, and the change (40 BTC) is sent to a new address in your wallet.  Remember we can't spend part of an unspent output so the change is necessary because we are spending a 100 BTC input but only need to "send" 60 BTC.
The simplified pseudo-transaction may look something like this.
In[0] <lets ignore the input for now but it does have a value of 100 BTC>
Out[0] Bitcoin address=1ABC... Value=50 BTC
Out[1] Bitcoin address=1DEF... Value=10 BTC
Out[2] Bitcoin address=1XYZ... Value=40 BTC

The tx has 1 input, 3 outputs, all in/out indexes are zero based, and the value of the outputs is equal to the value of the input.  If the output(s) are less than the input(s) then the difference is the fee paid to the miner.  If the outputs are more than the input(s) then the tx is invalid.
Now since the "change" address is 1XYZ is another address in our wallet we can use it in a new transactions. We will pay a merchant 1 BTC and give the miner a fee of 0.01 for fast inclusion in a block.  The change will be sent to yet another new address in the wallet (1ZZZ....). The resulting transaction may look like this:
In[0]  Tx hash=1234567890 OutputIndex=2
Out[0] Bitcoin Address=1HIJ... Value=1 BTC
Out[1] Bitcoin Address=1ZZZ... Value=38.99 BTC

The input refers to the 3rd (0 base array) output of the tx above.  Looking up the output index 2 of tx 123456789 we can see the value is 40.00 BTC.  The sum of the outputs are 39.99 meaning 0.01 BTC will be collected by the miner of the block.
Real txs deviate from the simplified version shown above
Note this isn't really important unless you want to dive deeper into the workings of the protocol.  The output of Bitcoin transactions are actually scripts instead of static addresses and values shown above.  Functionally for most outputs they work the same, although to save space the hash of the public key not the address is used in the output. All blocks have a required tx called the coinbase which has no input because the output is the block subsidy and the fees paid to miners.  All values in the Bitcoin network are integers in Satoshis (1E-8 BTC) so technically all the numbers in this post would be multiplied by 1E8.

A single Bitcoin transaction can have many outputs. The vout field lets you specify which output you want to spend.
Look at this transaction. Suppose you have the 1EZ5 key, but not the 199N key. You need to clarify to the Bitcoin network which output you want to spend.

I'm not sure I understand. Why would you not want to spend an output included in the transaction? Could you provide an example to demonstrate? Thanks!

It's not that you don't want to spend the output, it's that you don't have the key to it.

A quick and to-the-point explanation for those who already know about the basics of the protocol (in contrast to @DeathAndTaxes's answer). Thanks!

In summary, vout refers to the index of the output address in question. The index starts from 0. So for example, if a tx has 10 output addresses, the vouts for the addresses would be from 0-9.

In vin list vout lets you specify which output you want to spend to whom.
Every vout has its own tx_id.
and the sum of values of this vout is equal to total BTC which we have for the transaction; And if
if vout < vin then the difference of these amount fee is to be paid to the minor.
else vout > vin then tx_id is invalid.

In a nutshell vout could be considered as an identifiant of the output inside a previous transaction.
keep in mind that the input that you want to include in your transaction are the  outputs of a previous transaction so you go back to the received transaction and you choose which output to include as input in your new transaction. However, if you don't care bitcoin client will do that in your place .