text:
Any single transaction has vin and vout values. How can I tell the address of the originator and receiver?
This is my very first dive into the actual transaction contents. I'm choosing a random transaction in the block chain to understand whats going on.
So, I see that this particular transaction has a single input, and a set of outputs.
What I really don't understand at this point is, how can I tell what the originating and ending addresses were, along with the transaction amount.
My confusion comes from not seeing the originating address (although I suspect that's me not understanding something fundamental) coupled with multiple recipients defined across a set of voutaddresses.
{
"hex" : "01000000024aa42a4453b3894a161dfc6701f8946b42fd98f231b53dc6b95e378edcc63da8000000008c4930460221009c8c0cf9664f8e97dc0d2379150dae9de743bd1ba9164c74da8728ac8bd33818022100ab74fba8f1219d2e5a79f9ec3bee7f9de6dd49edc66a667a8bd433692bd9ddb8014104c086981930501414c538310ab4014186fd2e9901fabcce97de24abd7f6b14ca5b319896ac482d00506e5f722da754f727015a51fb1ee8728089bc03c8b6adb37fffffffff126ce9e47f9ee8d2e6c26fb13f2daa4e052f6a5aaef77871f2f1cb6b93253a1010000008b483045022100b20a538bcb20fc8463bb698a4a07fced226aff193cddf5eb246564708e5193c702207c2b6fdbc1b90575be7ef5f7d7013bef357bab0d8bd6b57708df35c2aa03e56d014104f3234bbe0fcfb2091bd6ad64203fcb6f0a7ac08b3730f2b759f85aab5fb233adad9cde430938f6f303d98b1aa9c17a2a56fcca95982cf76bce9e13acfc6fab3dffffffff02404b4c00000000001976a91470f25592e7284f48ccddcc8ef9af83d48c47301a88ace2900400000000001976a9140495ef54c1276a4bf3e35e433d893857db344e7088ac00000000",
"txid" : "1a558999f1360e95406c39ada43121fc2441ca5600e39f5d5a3bd3c494b9aae9",
"version" : 1,
"locktime" : 0,
"vin" : [
    {
        "txid" : "a83dc6dc8e375eb9c63db531f298fd426b94f80167fc1d164a89b353442aa44a",
        "vout" : 0,
        "scriptSig" : {
            "asm" : "30460221009c8c0cf9664f8e97dc0d2379150dae9de743bd1ba9164c74da8728ac8bd33818022100ab74fba8f1219d2e5a79f9ec3bee7f9de6dd49edc66a667a8bd433692bd9ddb801 04c086981930501414c538310ab4014186fd2e9901fabcce97de24abd7f6b14ca5b319896ac482d00506e5f722da754f727015a51fb1ee8728089bc03c8b6adb37",
            "hex" : "4930460221009c8c0cf9664f8e97dc0d2379150dae9de743bd1ba9164c74da8728ac8bd33818022100ab74fba8f1219d2e5a79f9ec3bee7f9de6dd49edc66a667a8bd433692bd9ddb8014104c086981930501414c538310ab4014186fd2e9901fabcce97de24abd7f6b14ca5b319896ac482d00506e5f722da754f727015a51fb1ee8728089bc03c8b6adb37"
        },
        "sequence" : 4294967295
    },
    {
        "txid" : "a15332b9b61c2f1f8777efaaa5f652e0a4daf213fb266c2e8deef9479ece26f1",
        "vout" : 1,
        "scriptSig" : {
            "asm" : "3045022100b20a538bcb20fc8463bb698a4a07fced226aff193cddf5eb246564708e5193c702207c2b6fdbc1b90575be7ef5f7d7013bef357bab0d8bd6b57708df35c2aa03e56d01 04f3234bbe0fcfb2091bd6ad64203fcb6f0a7ac08b3730f2b759f85aab5fb233adad9cde430938f6f303d98b1aa9c17a2a56fcca95982cf76bce9e13acfc6fab3d",
            "hex" : "483045022100b20a538bcb20fc8463bb698a4a07fced226aff193cddf5eb246564708e5193c702207c2b6fdbc1b90575be7ef5f7d7013bef357bab0d8bd6b57708df35c2aa03e56d014104f3234bbe0fcfb2091bd6ad64203fcb6f0a7ac08b3730f2b759f85aab5fb233adad9cde430938f6f303d98b1aa9c17a2a56fcca95982cf76bce9e13acfc6fab3d"
        },
        "sequence" : 4294967295
    }
],
"vout" : [
    {
        "value" : 0.05000000,
        "n" : 0,
        "scriptPubKey" : {
            "asm" : "OP_DUP OP_HASH160 70f25592e7284f48ccddcc8ef9af83d48c47301a OP_EQUALVERIFY OP_CHECKSIG",
            "hex" : "76a91470f25592e7284f48ccddcc8ef9af83d48c47301a88ac",
            "reqSigs" : 1,
            "type" : "pubkeyhash",
            "addresses" : [
                "1BJCzAbdTe8cCSvd2Yr7RCAnHqfsixjVth"
            ]
        }
    },
    {
        "value" : 0.00299234,
        "n" : 1,
        "scriptPubKey" : {
            "asm" : "OP_DUP OP_HASH160 0495ef54c1276a4bf3e35e433d893857db344e70 OP_EQUALVERIFY OP_CHECKSIG",
            "hex" : "76a9140495ef54c1276a4bf3e35e433d893857db344e7088ac",
            "reqSigs" : 1,
            "type" : "pubkeyhash",
            "addresses" : [
                "1RFKRhk3nMhk7yyN687YtxKVfohtdm6Sc"
            ]
        }
    }
],
"blockhash" : "00000000000000007764778f17fc18d6051711507bbaeb503c2d4aba017f1445",
"confirmations" : 4,
"time" : 1393487217,
"blocktime" : 1393487217

}
Taking another transaction as an example, I had a look at its inputs to see if it would be possible to figure out the address from the previous transactions. What I ended up with was this:
Current Transaction: 3846c2c5de2d6a3ea44d0d26d52cef2b33c9f44f3da1305e33905aebd3ba5795

Input 1 to Current Transaction:     70413306b48d8a1ce9b4d9a3500477cea1e42888c07f69d9f45f4785fde0e551 [0]
    Output: 14sbkc8jwphWvDczoBMY812nvpT7T8pp3t
    Output: 15R7vh1r5nrTB7uGg89pmP8grJKzpRVeTr
    Output: 129w8zn65WqkVmUbTQGnLojg6qu5vaNnvQ

Input 2 to Current Transaction: a97685efbed249543f34c22480609ea1851b4d4c76f7207db3de64b65206d037 [6]
    Output: 1AdVciiT8VoJiCn5nevnVQnzQFeyHKtgzU
    Output: 1A2UXf1wK4G7g6NquQu5VJzAt2hwBvakwc
    Output: 1NT9GeNPK7jW33b61Xv8CpRhfTwXXHrbsh
    Output: 1DNWZmsURXXyNchhj3An4em3UkHb7ux39L
    Output: 18rt5YDpzL7CuBSsCxQPSWg6xPu7UR6Dks
    Output: 13aUL5mzLGLJKbfCBfJukRPmikau5aGHF3
    Output: 16ui1ZtnN1Ufgp9RHvp7jECbMPoMfEjLzW
    Output: 16ZgAzQZyvv6MWZALTUBcvNEiKARbjoMHZ

Input 3 to Current Transaction: dc4ba3a246a479f7747a05fa56658f2521a9456689103a2df0015b538edaa7d7 [2]
    Output: 1Pxh9sMK22d2QCU1quoFcgP2arxHgyaHeV
    Output: 1AxfD8QMrjbvD4SRWEBavYY1P6FfPhXpri
    Output: 14ZQsi7XWMBpXu8MRJdq23TJBymnsvMY4j

None of the previous inputs match. What am I missing?

I see that the vin part of this may already have been answered. I'll have a try of that.

To get the full picture of this transaction (1a55...), you must also get information on the input transactions, a83d... and a153....
The input for a83d has "vout" : 0, which means it's the first output that we'll be spending here. If you pull up the info on a83d, you'll find that its first output was for 0.05 BTC to address 1QKj... Similarly, a153 with a vout of 1 means we'll spend the second output. The second output there was 0.00319234 BTC to address 1PK5... These are our input amounts and addresses. The scriptSig contains the public keys corresponding to these addresses and the signed messages allowing the transaction. It's worth noting that from these public keys, you can calculate the input addresses, but not the amounts.
The outputs are a little more straightforward: value is the amount, and the address is under addresses. These show that 0.05 BTC goes to 1BJC... and 0.00299234 BTC goes to 1RFK... Note that the outputs contain only addresses (in the raw form, they are the hexadecimal numbers like 70f2...), not public keys. The sum of inputs is a little larger than the sum of outputs. The difference, 0.0002 BTC here, is the transaction fee, that goes to the miner that finds a block with the transaction.
A likely interpretation of this transaction is that one person owns addresses 1QKj and 1PK5; he sent 0.05 BTC to 1BJC, and received his change at 1RFK.
For more details and explanations on how Bitcoin transactions work, see How the Bitcoin protocol actually works by Michael Nielsen and the Transactions page on the wiki.

I am surprised this excellent answer not been even voted-up

For this particular transaction, there is NO SENDER. Notice the "coinbase" field in vin, it indicates this is newly generated coin, created via mining.

The addresses of Receiver is the one given in VOUT["scriptPubKey"]["addresses"] section.For the addresses of sender you need to get rawtransaction of VIN["txid"], and match the index of Vout with "n".
Here is Python 2.7 implementation of same, hope that helps


text:
How can I tell whether transactions were (not) made via BitPay / Coinbase?
Background
Recently, Rep. Steve Stockman posed for a photo op with his Bitcoin address on a big QR code, which got shared. He has a Bitcoin donation page which asks for identifying info and goes through BitPay, but of course anyone could send him Bitcoin anonymously, without using that page, if they know the address to send it to.
The Libertarian Party and CoinPAC have Bitcoin donation pages that don't outright list their addresses, but block chain analysis of a donation would probably reveal their main address(es), and those addresses might have received contributions that didn't go through the donation pages. (The LP's page doesn't even require giving your info for it to show you the donation address.)
Stockman & LP's donation pages use BitPay; CoinPAC's uses Bitcoin Builder (which in turn uses Coinbase).
The Livingston County Libertarian Party (addr) and Jim Fulner (addr) publish their Bitcoin addresses openly on their websites, and the Bitcoin Voters PAC published a list of their Bitcoin addresses in their official FEC registration filing‡. None of them even have Bitcoin donation pages that collect info, so of course anything sent to them presumably wasn't properly attributed.

Problem
The FEC requires PACs to know the identity of all contributors (especially for "in-kind" contributions, i.e. anything other than fiat currency). If any of the above received any Bitcoin contributions that didn't get attributed to a specific person (e.g. by going through a donation page that requires disclosing your ID before telling you the address to donate to), that'd probably be an unlawful unidentified in-kind contribution.
For our upcoming FEC advisory opinion request about how to handle Bitcoin, I'd like to have example(s) of how:

it's not possible to "refuse" a Bitcoin transaction (e.g. someone contributing to the above outside of their donation pages)
it's not possible to reliably refund a Bitcoin to the control of the person who sent it (e.g. a transaction that was laundered or came from an exchange)
some transactions are worth less than they cost to get rid of (e.g. dust or complex / intentionally large-byte-size transactions)

Our request proposes a framework for how to deal with these problems (e.g. one could donate unattributed Bitcoin contributions to a charity). I just want real-life examples I can point to that show it's not a purely theoretical issue.

Question
How can I show that Stockman, the Libertarian Party, and/or CoinPAC have received BTC contributions that did not come via their donation pages (and thus BitPay or Coinbase)?
Pointing to specific transactions they received and explaining how it is clear to a third party that those transaction(s) weren't made via BitPay/Coinbase would be extremely helpful.
Other examples of political committees that have published a Bitcoin address or are currently receiving Bitcoins in some way would also be much appreciated.
Thanks in advance!

More info
† See our bitcoin AOR page & my G+ post for some more background.
For the record, we are strictly non-partisan. Our intent here is not to make any particular candidate or party look bad, but rather support transparency in campaign finance.
We want to accept Bitcoin  (potential donors have requested it and we think it's a good idea), but we think it needs to be done carefully to be compatible with current law and good public policy.
Comments on our AOR are welcome, but not really on topic here; I'm just pointing to it for context. The question here is simply: how can I identify a transaction as being / not being made via BitPay or Coinbase, just looking at the block chain? (Let's assume there's no subpoena involved. :-P)
‡ So you needn't transcribe:

18kKJ15uz1nuMJ2kacuahLKLL9NwnsbRQi
1EsR4cdbgPvnD3Gk6wNkTotdzexiN56wXt
14jc8MtHxE6M6Xn7LarvZnXF6GgaaRy1PY
12QeAyDyXiMVn5uwpQUHwS8g2Z3SZf2Kvx
1GuHY98Bxf4mFw2CQEUXqwDUTRqnTRrCt8
113pdko8qQYsvkbV4r7H247oFPFNMnUYqY
1M9AfWnRFmgQgAuTsQssL523ANsxKzfygs
199JdcXMQ41eA9ZPTLUktR9kfAiQRhaErW
1AZxfdTXg5V3gRZMtMfQZrwgBeaQMAtKqN
1NyuGppGprR6uM2koN7hH8wGP8bk6wKh15

Send them yourself? Maybe a little risky, since it may be illegal, but it would get your point across. Just send them directly to their address, since you know it, and then be able to prove that you did it while bypassing BitPay/Coinbase. You can prove you bypassed them by showing the transaction was directly from A to B (A being your wallet and B being the candidate/PAC's) and showing A does in fact belong to you.
Explaining that it is impossible to refuse a transaction is purely theoretical, so there's no getting around that.
To explain that it isn't always possible to refund you just have to explain that it isn't uncommon for addresses to be used once and discarded.
To explain the third problem, you should just highlight that it is possible for malevolent actors purposely send donations that would cost more to refund/get rid of than to keep and thus a requirement to do so would be asinine. Then maybe go through the technical aspect of how said transactions can be created.
Edit: Seeing as sending them yourself would be illegal and that is the only way without knowledge of Bitpay's addresses, you're going to need BitPay's address. You're not going to get that. At best you could send coins to them and trace their path to a storage wallet. But there's no way to know that all coins pass through the same storage wallet, so you can't say that any coins sent to the candidate from an address other than the storage address you know are directly from a person.
As a concrete example, say BitPay has two storage wallets A and B and you want to send coins to a candidate. The have you send your coins to wallet A and then they send the amount of coins you want to give from wallet B.
Companies use schemes similar to the above example with arbitrarily many wallets. They do this because knowledge of all their storage wallets would give away competitive info like the total number of coins they have. There are just to many ways for BitPay to obfuscate their internal handling of coins for you to trace anything. So a subpoena is the only way I'm afraid.

Actually doing this myself, or encouraging someone else to, would be a Very Bad Idea and definitely illegal. Google "fec bitcoin". Make Your Laws PAC = my work.

See my edit. Sorry to disappoint.

Only way is if Coinbase/Bitpay publicly released their addresses, which they won't.

You can't. Transaction inputs are indistinguishable from each other.

source: Stack Exchange

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

sort: votes


text:
Will bitcoin's value be affected by other digital currencies?
There are many different digital currencies being released now, following in the footsteps of bitcoin and trying to improve upon it.  Will these currencies, by giving consumers more options, reduce demand for bitcoin and decrease or limit the increase in its value?
Stephen's answer made me realize that I'm not just talking about any crypto but the one's that will inevitably improve upon the already great bitcoin model.

Bitcoin is a "proof-of-work" based cryptocurrency.  Proof-of-work based cryptocurrencies are protected from a malicious 51% attack because of that coin's mining network.
Bitcoin is protected by 12,500 Th/s of mining capacity (using SHA hashes).  For an attacker to come in and attempt to commit "double spend" fraud (as the result of having 51% of the mining capacity), that attacker would need to spend perhaps a hundred million dollars to acquire the necessary mining hardware.  There is no way, today, that an attacker will be able to use this tactic to earn a profit because there's simply no way to withdraw even tens of millions of dollars worth of funds from exchanges (following the attack) -- due to exchanges employing KYC/AML policies such that an attempt would fail either due to withdrawal limits, access to cold-storage, etc.
Alt coins don't have this same threshold.
So in addition to Bitcoin having first-mover advantage and the strongest "brand" (thus that's why Overstock accepts Bitcoin and not Litecoin or anything else), it has the least risk of catastrophic loss due to a malicious 51% attack.
The difference between Dogecoin and a Bitcoin is like the difference between investing in a longshot penny stock issue of a nearly bankrupt company versus buying a blue chip NYSE which continues to deliver quarter-after-quarter.
So there is certainly a substitution effect.  Many of those speculating on Litecoin would otherwise have been holding bitcoins.  But there's not an easy way to know what the value of a bitcoin would be if the $500+ million valuation of all Litecoins in circulation were to grow by several billion dollars.  Since we haven't reached "saturation", perhaps many of those speculating on Litecoin might not have held Bitcoin regardless -- and thus if that were the case the existance of Litecoin didn't affect Bitcoin's exchange rate.
There's also the situation where an altcoin happened to be the "gateway drug" that caused a person to become interested in crypto currencies but then that person later embraced Bitcoin. In that instance, the greater the traction of that type of person to an alt currency eventually results in greater traction of Bitcoin.
There's also other altcoins that are not proof-of-work based.   For instance, PPCoin is a "proof-of-stake" crypto currency.  These are not vulnerable to a 51% mining attack (though they have other vulnerabilities).  So it is possible that those PoS coins could be seen as having an equal (or lesser) risk to that of Bitcoin and thus that coin could be seen as a substitute for Bitcoin by some.
To conclude, simply alt coins are not equivalent to bitcoin and thus a dollar spent on acquiring an altcoin doesn't mean there is one dollar less spent on acquiring or holding a bitcoin.

Good answer thank you.  That's about as good as "hard to say" can get.  I mean that in a nice joking way... Now I know that there are a lot of cryptos that aren't as secure as Bitcoin but isn't inevitable that eventually the bitcoin model is improved upon?  That's more of my concern than just any old digital currency.  I'll update the original to try make that clear.

The bitcoin proof-of-work isn't locked-in forever as it currently sits.  As long as the economic majority favors a change, the algorithm could be changed to accommodate an alternative method.  This has already happened several times (a few of the issues documented here are such instances https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures).

Any currency that innovates beyond bitcoin will take price out of bitcoin, people will see the other currency as a 'better alternative' if it doesn't have the many problems that still plague bitcoin and nearly every crypto-currency.

The only thing I can tell is that bitcoin isn't fast enough, compared to other cryptocurrencies. For example, a dogecoin transaction gets 3 confirmations in 1-3 minutes, while bitcoin can take up to 30.

Bitcoin's speed depends on network propagation time, a problem still unsolved by any other crypto-currency. Dogecoin and other coins are fast because they don't have massive networks to propagate blocks to, and their block times are a trade-off. Faster block time means a greater risk of orphaned blocks which mean your transactions will have false confirms, which is incredibly bad.

I think they may if they start off with an algorithm that's lighter than Bitcoin's.
However, one should remember that the value of money is based on the number of people that will accept it. Hence, new cryptocurrency will first have to reach a critical mass similar to that of Bitcoin's before challenging its dominance.
On a related note, you may question whether Bitcoin itself will ever outperform national legal tenders, for which users are mandated BY LAW to accept the tender in payment for services or goods provided.

Good points but it could also be said that bitcoin really broke the ice for future cryptos.

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


text:
How do I move my bitcoin from mycelium to another wallet?
I'd like to do this in a fee-less way.  This is the first step in claiming my BCH.  I've tried using this link
https://steemit.com/btc/@libert/step-by-step-guide-on-claiming-bitcoincash-from-mycellium-wallet-201783t112141477z
My bitcoins just never show up in the coinomi wallet.
I tried using this tutorial
How to sweep private extended key from mycellium into coinomi for bitcoin cash coins?
But the derived keys that are generated, and I've gone through at least 1000, are not for the "other addresses" that appear on my wallet.  The first in the list is my HD wallet but that has zero funds.  I have two "other addresses" with the BTC.  These don't appear. I only scanned the first 20 QR codes but searched 1000 for the prvt keys of the two addresses according to my backup.
Anyway I'll edit this if necessary I'm just trying to take this step by step.  Any help is greatly appreciated.

Have you tried this: https://blog.btc.com/how-to-recover-your-trapped-bitcoin-cash-from-other-wallets-24b929543f26

I have not tried that yet, thank you. Before I do that though, I'm under the impression it's important to change addresses with my btc for security reasons. Then after that's done use the private key of the old address to claim my BCH using the previous addresses' key in a new wallet.   Since I asked this question,  I managed to figure out how to export from mycelium to coinomi but I was shocked to see a 6$ fee in the coinomi wallet.  I figured this isn't a transaction it would be fee-less.  I'm looking at other wallets now and still trying to figure it out.

To move your bitcoins just send to a different bitcoin wallet using the send option in mycelium. To get access to your bitcoin cash just restore from your mycelium seed in electron cash. Electron cash is a bitcoin cash fork of electrum so the steps are the same as for electrum. Just make sure you select bip39 in step 4 and in step 5 choose legacy p2pkh as the derivation path.

there should be an export function on mycelium. select the other keys on the left pane and export them. in coinomi, import them (dont sweep, that makes a transaction).
in coinomi, the import functiln appears to be under settings -> restore wallet. make sure you dont have anything of value in coinomi before restoring this way.

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


text:
Do multi-signature transactions make a 'bitcoin kickstarter' possible? And what state are the bitcoins in, in the meantime?
This isn't a question about kickstarter really, just a way for me to phrase my question about the crypto in terms that I can understand.
My understanding, based on this article.. Stop Saying Bitcoin Transactions Aren’t Reversible is that multi-signature transactions would make something like a bitcoin KickStarter particularly easy.
That is the kickstarter-like bitcoin service would act as a third party to many contracts transferring btc to the second party?
Maybe this has already been done? Hmm @coinstarter.. Yay! Great to see but doesn't really answer my question about how the crypto works.
To make things easier I'll call the people that pledge to the campaign the 'first parties' and the recipients of the funds the 'second party'. Could multi-party signatures to ensure the second party only receives btc after the projects are funded? and at the same time be sure that the third party (eg coinstarter) technically can't abscond with the funds.
Also - and this is my real question - in such a case what state are the bitcoins in prior to the project being funded. That is, are they marked in the blockchain and thus impossible for first parties to 'double spend' btc they have pledged to a campaign or are they actually not in escrow so if a first party spends them on something else in the meantime (after pledging, before the project is funded) the transaction just fails?
Thanks so much in advance, hope this question makes sense, crypto wise.

While multi-signature transactions with a trusted party (e.g Kickstarter Inc.) would work, their disadvantage is requiring said trusted party...
The bitcoin wiki describes a different method that doesn't require any third party:

Each backer creates a transaction with the amount to be pledged (this is an immediate step and required since the method doesn't allow for change
That transaction is used as input signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY, and the output is the to-be-funded address with the funding goal. Due to the input being less than the output, this transaction is invalid and shall not be published but instead transmitted to the recipient.
Once the recipient received enough transactions summing up to the funding goal, they can publish the assembled transaction

Unfortunately, this method has other drawbacks:

The funding goal must be exactly met (or a multiple of it), i.e. there cannot be stretch goals or overfunding
Since the input transactions are not spent until the funding is complete, the backers might accidentally spend that very transaction in another transaction

Ideally, script would provide means to determine whether a given bitcoin address (or in this case, the script itself) currently has at least a given amount of bitcoins available...

Note to self: Check Zero Knowledge Contingent Payment


text:
Bitcoin as an investment?
I have a couple thousand dollars in a savings account. I am getting almost no return since the bank accounts interest rates are so very low.
I know nothing about the stock market, so investing there is not at the top of my list. If I put the money into a bitcoin wallet, theoretically, isn't it gaining value faster than the savings account? Even with any fees involved, it might be a good place to hold my money.
Also if things go bad here in the USA, I'd like to have some money safe.

Keep in mind that funds held in a Bitcoin wallet carry considerable financial risk (compared to a savings account). The value of bitcoin can increase rapidly, but it can also drop rapidly.
If you believe that long-term, the value of bitcoin will continue to increase, then bitcoin might be a good investment for you. However, the future is unknowable, and something could happen that causes the bottom to drop out of the bitcoin market and its value to plummet. Your choice.
Note also that in the US, you may be liable for taxes on realized capital gains through investment (this is not tax advice).

Is there some sort of chart of bitcoin value over time?  Thanks for the great info. I do think it will be a good investment. Maybe I'll start slow and buy 1 bitcoin first.

There's lots of charts available, an easy one is http://bitcointicker.co (click on the "6Mth" link in the top right for more history).

Thanks. I'll watch this and see how it goes over the next month or so before doing anything.

I THINK THERE IS NEVER A BAD TIME TO BUY BITCOIN
People who have missed out on the early days of Bitcoin may find it hard to justify investing at this point in time. That is understandable, as over $15,000 per Bitcoin is quite a steep price. The best time to invest in Bitcoin was yesterday. One should not contemplate whether or not to invest for too long. Opportunities will come and go with Bitcoin. Even if you would buy today and the value dropped by 20% overnight, there is still a good chance one will score a profit by just holding onto this Bitcoin balance for the foreseeable future.
If you have done your own research into Bitcoin and think it might be worth trying, there are few reasons to wait. It is important to keep in mind one does not necessarily need to buy a full Bitcoin either. Unlike most other currencies in the world, Bitcoin can be divided up to eight digits after the decimal. Even purchasing a fractional amount of a Bitcoin is a smart idea right now, as it will most likely appreciate in value if you have some patience.

I think this answer understates the risk involved. Bitcoin prospects look good now, but you won't know otherwise until it's too late. For someone who knows little about investment opportunities, like the OP, I think it'd be worthwhile to at least mention risk vs. reward and the benefits of diversification. You paint the appreciation of Bitcoin as an inevitability, when the reality is far from it.

Considering adoption of bitcoin seems to be increasing exponentially, as long as all other things stay the same, bitcoin's value is likely to increase proportionately (until market saturation). https://bitcointalk.org/index.php?topic=366214.0
The only worry I have is the coming regulation. If you look at the period from the middle of Nov to now, you can get an idea of what regulation can do to bitcoin. China made it illegal to sell BTC for their currency and the price dropped around 50% over a month or so and it's still pretty volatile. With larger companies like Overstock starting to accept them, the US is starting to feel some pressure to clarify their position on crypto. My biggest worry is that their decision, depending on how restrictive it is, has the possibility to make BTC almost worthless. The choke points like exchanges are currently vulnerable to being shut down by money laundering laws.

Bitcoin is not an "investment" it's a speculation. Purchasing (part of) a company and sharing in its profits is investing. I recommend reading Bogle's classic book in index fund investing. The best strategy is to grow rich slow and this easy to read and understand book will show you how.
If you must delve into Bitcoin, just put in 5% or an amount you are comfortable losing.
I'm nearing retirement and regret not saving 10-15% of every paycheck and putting it into the stock market. Had I done that I could have retired early.

Here is what I would do:

Take a "small" amount of USD, e.g. $100 ("small" = an amount that you can afford to lose)
Use those dollars to buy Bitcoin. (You do not have to buy integer values of Bitcoin)
When (or if) the value of your Bitcoin increases to some amount > $100, [i.e. $(100+x) where x > 0] withdraw $100 worth of Bitcoin back into your USD bank account.

Congratulations! You now have $x worth of Bitcoin that cost you nothing.
If the condition in step #3 does not become true soon enough for your liking, just convert all the Bitcoin back to USD. Your potential loss is limited to $100 (which should not matter to you) but your potential gains are unlimited.
Remember to pay taxes as required in your country. Most probably, you should only have to pay taxes on your profit in USD in the year that you sell any Bitcoin, but this is not professional tax advice.


text:
Are bitcoin wallets money service businesses (MSB)?
Do hosted wallet services located in the USA need to register with the fenCEN as a MSB?

If the business is based in the US, yes.
Edit: IANAL, but in my opinion a wallet service clearly falls into the category of money transmitter according to FinCEN's virtual currency regulations.

Please provide an argument or source of information that supports your answer.

@Murch, answer edited with FinCEN reference. I actually learned about it from a local bitcoin meetup where US regulation was heavily discussed. Of course, most regulations are normally open to different interpretations. A good lawyer can work miracles.


text:
My pool shows no evidence of block that my computer discovered
It appears that my computer discovered a block i.e. bfgminer printed an Accepted line, but in my BTC Guild account there is no evidence of this and in fact, their records of when my computer last took part in the pool are wrong.
Given the hex number of my block, is there any way for me to track down the block to find out what happened to it?
UPDATE: Turns out the Accepted share was a test share, used to detect botnet machines.
Thanks.

Are you mining at some absurdly low speed? If so, you're probably so close to zero as is considered effectively equal to it.

I thought you had solved a block. But if this is just a normal "accepted" message that just means you did a tiny bit of work that you will be paid for. Normally you see those every few seconds unless you have a very very low hashrate (CPU mining etc).

Pooled mining lowers the difficulty that it reports to miners and the results are submitted as proof of work to the pool, so they can pay you.  Only a small portion of submitted shares are valid solutions to an actual block.


text:
What are some good online Bitcoin wallets based on client-side security?
I just found Bitventory, which seems to be an online wallet service that requires a minimal amount of trust (it's the major design goal, at least).
Are there other services with similar goals or functionality?

Yes there is such a service which provides exactly what your looking for it is called StrongCoin

Bccapi (http://code.google.com/p/bccapi/) solves the same problem as  Bitinventory and in a surprisingly similar way. Two android clients are in the making on top if the Bccapi, however so far only one fully functional console UI exists.

BitcoinSpinner for Android phones is an amazingly simple yet secure Bitcoin wallet. It is built on top of the BCCAPI.
BitcoinSpinner announcement at bitcointalk.org

True client side security requires 2 party signed transactions which aren't currently implemented in the maineline client/protocol.
With a two party wallet both parties (the online wallet service provider and the owner) would need to sign the transaction with their independent private key in order for it to be accepted by the network.  The wallet provider never has access to user's private key and thus can never transfers users funds.
Any solutions that exist now are stopgap at best.

What flaw do you find in the approach implemented by Bitventory?

This way if the service provider goes out of business my coins are lost forever. Bccapi, StrongCoin & Bitinventory is the way to go.

@ripper234 I took a closer look and I think Bitventory could be a secure solution.  Most "secure" online wallets use javascript to convert passphrase into determistic private key.  The problem with that is DNS spoofing or javascript injection attack means you are giving your passphrase to an attacker.  Bitinventory uses strongly signed Java applet which could reduce the risk of code replacement.

Lumi Wallet is a client-side HD secure wallet for BTC, ETH and a load of ERC20 token.
it also has 2FA (strangely, many decent wallets doesn't have this)


text:
Where can I see the average transaction fee payed in the last 100 blocks?
Is there a site that shows what's the average transaction fee payed in the last X blocks? Or just raw data about this?
I checked BlockExplorer and Sytes and they don't seem to show this information.

Blockchain.info shows the amount of fees payed each day.


text:
Is Proof of Stake a hard-fork?
Proof of Stake is a proposed modification to the Bitcoin protocol.
maaku claimed that it doesn't require a hard fork / alt chain.
Is this true?

It depends on what PoS system is considered (or not, since I think the answer is the same either way).
Cunicula's system is completely different from what we have now. There's no way to "half" switch to it since a block which is valid in the current system means nothing in his system, and vice versa.
My system uses a skeleton which resembles the current system, so in theory you could solicit signatures in parallel and let anyone use them or not as he pleases. As theymos says a fork will still occur once there's a disagreement between the two systems about which is valid; and anyway, I think the process of collecting signatures and embedding them in the blockchain requires enough rethinking of the network that it is meaningless to regard it as anything but a hard fork.
Of course, even if you make an entirely new alt for it, you can always provide a built-in mechanism to allow bitcoin owners to import or copy their wealth, to make sure the early adopters of decentralized digital currencies at large don't suffer from the advent of a new and potentially better alternative to the original Bitcoin.

lol - A big "import wealth" button :)

If proof-of-stake is adopted and someone succeeds in attacking proof-of-work but doesn't meet the new proof-of-stake rules, the network will split: old clients will go with the attacker and new clients won't. So I would say that proof-of-stake is a hard-fork change. A fork might be avoided if no one tries this attack, but you can't rely on that.
This doesn't mean that you can't do the change without causing chaos, though. A totally backward-incompatible change occurred in February without much turbulence, for example, though this change required two years of planning in advance. A similar gradual roll-out could be done for something like proof-of-stake.
(I don't actually think proof-of-stake is a good idea.)

Thanks. Why don't you think it's a good idea?

Depending on the implementation, it might not require a hard-fork (which is defined as old clients not following the ongoing blockchain). If all POS-enabled blocks also have valid POWs, old clients will accept them too. This is similar to the BIP16 rollout last March.
I'm not sure proof-of-stake is a good idea, since it gives even more power to computer crackers who steal a lot of Bitcoins, and forces miners to keep their Bitcoins online for mining. It also could lock a lot of smaller miners out.

Why would it lock smaller miners out? The same computer crackers can hack into mining pools and abuse them to perform a double spend ... we can continue this discussion on the PoS thread: https://bitcointalk.org/index.php?topic=68213.0

I don't think POS requires to have the bitcoins online. If you design the protocol well, coins that are used for mining, will have two keys associated with them, and the one used for mining can't be used to spend them.


text:
How many Bitcoins existed when block 209,999 was mined?
This article claims there are now 10,499,925 bitcoin (at the time of the reward drop from 50 to 25).
Weren't there supposed to be exactly 21,000,000 / 2 = 10,500,000 BTC mined at this point? What am I missing?

I suppose this is the culprit. If we add the duplicate 50BTC that is missing and the first reward from block 21,000,000, we would have 10,500,000BTC in total.
However, my calculations would be: 21000000 blocks (ranging from Genesis Block 0, to block 20,999,999) multiplied by 50 BTC, that would give us 10,500,000
With the duplicate transaction, that would be 10,499,950 BTC total.

IIRC there's another duplicate as well. If the OP's number is actually for block #210,000, this accounts for it.

What is a duplicate transaction? How does it make some bitcoins invalid? Is there a thread that discusses this?

@ripper234 - This - http://bitcoin.stackexchange.com/questions/3030/two-blocks-two-transactions-same-hash

The output of the genesis block cannot be spent.

@PieterWuille Hmm, that's interesting. Any reason for that?

Nobody knows, and there is no explicit comment about it in Satoshi's source code. However, no full node to date would allow him to spend it. Perhaps it was deliberate.


text:
How does the pool know the share hashes are calculated and not cheated?
Miners calculate share hashes and submit them to the pool for their proof of work. And if the share hashes leads to a correct block hash in terms of difficulty, everybody in the pool gets paid according to their submitted work using different distribution methods.
Question:
Why can't a miner just submit random numbers as fake share hashes (little work) to the pool, instead of doing the actual hard work of hashing?
So for the pool: Is there a way to prevent this without recalculating the hash to find out its fake? Recalculation is hard work, and annihilates the sense of delegating it to miners.
And if there is no control it would only be visible with statistics as the pool is too unlucky on the long term. Ex.: a miner submitting 100THash/s and never finding a match might doesn't even calculated the hashes but just submits random stuff.
Edit: Clarified question to distinguish from similar sounding questions.

What makes you think the share hashes are not checked?  But one can check by just computing one hash, rather than the trillions needed to find one that makes a valid share.  That's the whole point of a proof of work - hard to find, easy to verify.

Possible duplicate of What is a share? Can I find it while mining solo, or only when pool mining?

@HighlyIrregular Thats what I read but don't understand. If I submit a trillion random numbers with a simple laptop I will get a large reward portion from the pool as soon somebody else in the pool submits the correct one using expensive ASICs. So I didn't do any work but still am contributed a large portion simply because my hashes were "unlucky" and for the pool it looks as if I contributed.

No. If you run through a trillion hashes and find, for example, 10 hashes that are good enough to submit as "shares" to the pool, and the ASIC miners submit 100,000,000 shares, then you'll receive a proportion of the reward equal to 10 out of 100,000,010. If the reward is 20BTC, then you'd receive about 200 satoshis, currently worth about $0.01. To earn that much without an ASIC device, you'd probably use $1 or more of electricity. Those numbers are only an example, but it gives you an idea of the situation.

@HighlyIrregular I meant you submit 100,000,000 shares, which in a extreme context is 100,000,000 times the same number to fake "hashing work". Or does the pool keep a "submitted hashes from all miners database" to prevent this?

Each share is verified to ensure it meets the target criteria, and yes submitting the same share multiple times would be detected. There isn't a requirement to keep more than a few minutes history of submitted hashes because the inputs used as part of the hash calculation change so frequently (trying to submit a hash of an old input would just fail to verify).

I had the exact same question and took me a while to find the answer.
TLDR: the pool simulates a smaller difficulty network and if you find a solution to it, the pool considered you did work and can check it in an instant. One of those solutions might be so good that it is the solution to the network.
As a background read:

I recommend this answer to the question what is a pool share vs. a network block.
And this article about Bitcoin Mining Pools, but applicable generally in my opinion.

In short, a share does not contain multiple calculations, but just a solution that is easy to verify because is just one.
For the argument, lets say you have 100MH hashing power. It would take you 100 minutes to find the block solution to the network in order to get the reward, because the network difficulty is 50.
A share given by a pool to work on has a difficulty you need to meet or exceed that is smaller than the network difficulty, lets say for example 20. With your computational power it would take you 1 minute to find the share the pool requests you. You submit your solution to the pool and it will calculate in a fraction of a second if what you calculated for a minute is valid. Now you have a valid share (hopefully, more details in the recommended links) and you took part in the work for that pool. A special and important thing about your computed solution is that the difficulty it meets is not necessarily exactly 20 (what the pool asked of you). It might meet a difficulty of 30, or even 50, case in which congrats you found a valid block (but can't steal it because the pool already inserted its information on what gave to you to calculate).

If the hashes are not recalculated/checked by the pool independently

The hashes would be checked by the pool, so you can't just submit random numbers. Pools would most likely ban miners which did that, for wasting their time.

But checking is the same amount of work as calculating the hash. They could never keep up with all the miners, if there isn't somewhere a shortcut for the pool, or a way to assign double work between miners to detect fraud (and loose hash power)

@Stefan: "But checking is the same amount of work as calculating the hash."  No, it's not!

@NateEldredge Calculate the hash is same as check the hash, but to find the valid hash (share) miner must check (calculate) trillions of hashes, and the pool server only has to check (calculate) the one submitted by the miner. But I see that by calculate you assume finding the correct hash.

The key is that a share is not just any (nounce, hash) pair, it is a (nounce, hash) pair which reach a given difficulty level, but a level which is much easier than the "network difficulty".


text:
dogecoind won't read conf
I'm having issues starting dogecoind after compiling in ubuntu 12.04 x64 running in VirtualBox on win 7 ultimate x64
here's what i've tried from inside dogecoin/src after make -f makefile.unix:
sudo su
./dogecoind -server -listen -daemon -rpcuser=dogerpc -rpcpassword=dogerpcpw -rpctimeout=30 -rpcport=8334 -rpcallowip=192.168.1.* -rpcallowip=127.0.0.1 -testnet

and i get:
Error: To use the "-server" option, you must set a secure rpcpassword in the configuration file:
/root/.dogecoin/dogecoin.conf

so i do:
cd ~/.dogecoin
emacs dogecoin.conf

i save the following parameters:
rpcuser=dogerpc
rpcpassword=dogerpcpw
rpcport=8334
rpcallowip=192.168.1.*
rpcallowip=127.0.0.1
server=1
daemon=1
listen=1
testnet=1

i even chmod 777 dogecoin.conf to be sure everyone on God's green earth could access it so that wouldn't be a problem, but still the same error when trying to start up dogecoind
would much appreciate any help/tips!

This is not Bitcoin related, and you shouldn't be running random daemons as root. It's likely a capitalization error, with this sort of crap it usually is case related.

although SUPER helpful, i'm running a secure dev env so i can run as whatever user i seem fit.  furthermore, the daemon is a derivative of the bitcoin daemon so the question is still relevant. not to mention that according to SO meta, bitcoin.se is for all cryptocurrency related qa. thanks for playing tho

"Secure dev environment" and "running every process as root" are incompatible statements, you have have one or the other. My comment is actually quite relevant, a lot of scamcoins have has issues with some systems being case sensitive and others not being.

@goatse: According to community discussion questions about altcoins are on topic.

I think the problem is with version 1.5  of dogecoin.I used
rpcpassword=DLKKWE93203909238dkkKKeowxmIOw0232lsakwL02k
to solve the problem. Change the password to whatever you want, just use lowercase, upper case and numbers, it should fix the problem

thanks for the suggestion! i won't be able to try this til i get home for the night, but do you think my issue is that the password i'm trying is too short (not 43 chars) or that what i was using for a password that included an underscore?

@JonBest: Dogecoin checks for a weak password (here's the code: https://github.com/dogecoin/dogecoin/commit/af853674bb7b275355d4ae847d4869e3f73cd246). It estimates the number of bits of entropy by taking the log base 2 of the number of unique characters, and multiplying that by the length of the password. If the number of entropy bits is less than 64, then the password is considered "weak" and is rejected.

@JonBest yes, your issue is that rpcpassword. its supposed to be a long mix of upper case, lowercase and numbers. It was just added in a latter release of dogecoin 1.5 which included checkpoints and stronger rpcpassword for much security wow. lol, anyways, i was also confused by it when I compiled it, but I understood it after I tried long password. What greg said is exactly true.

thanks for the specifics! makes sense now...can't wait to correct this this afternoon (;

wow! much thanks! i do a 42 character long [a-zA-Z0-9] password and it worked. thanks so much @GregHewgill and @ user2185284 !

It's unclear which version of dogecoind you are using. However, in the current 1.5 code on Github, there is a similar message:
if (mapArgs["-rpcuser"] == "" && mapArgs["-rpcpassword"] == "")
    throw runtime_error(strprintf(
        _("You must set rpcpassword=<password> in the configuration file:\n%s\n"
          "If the file does not exist, create it with owner-readable-only file permissions."),
            GetConfigFile().string().c_str()));

https://github.com/dogecoin/dogecoin/blob/master-1.5/src/bitcoinrpc.cpp#L1080
This indicates that your attempt at working around the problem with chmod 777 would not have had the desired effect. Instead, try chmod 600 dogecoin.conf.

i tried chmod 600 and that didn't work either...even when i give the parameters in the CLI i get the same thing

Dogecoin does not use port number 8334 the port for dogecoin is 22555 and if the above mentioned is really your password please change it to something more strong

def not my real pw lol i'm gonna try what you and greg said shortly

changing the port didn't work

change your conf file with the follwoing
server=1
daemon=1
rpcuser=yourusername
rpcpassword=yourpassword
after saving restart dogecoind

Dogecoin is pretty much a vanilla Bitcoin client with a few tweaks. I noticed I got this same error if there were any syntax errors in my config file. In my case, I had a "parameter-value" instead of "parameter=value".

Your password is too short, make it longer and it should work.

that's not the real pw, but i did try a much longer password that didn't work either


text:
Bitcoin/Dogecoin Daemon RPC authentication - 401 status error
I'm trying to connect to a local dogecoin server with jsonRPC.
The dogecoin daemon is launched with the following parameters:
dogecoin-qt -server -testnet -gen -debug -debugnet -printtoconsole -rpcuser=user -rpcpassword=user

The following Java code is used to connect to the server:
I'm using com.googlecode.jsonrpc4j.JsonRpcHttpClient
            JsonRpcHttpClient client = new JsonRpcHttpClient(new URL("http://user:user@localhost:22555"));

        String response = "";
        client.invoke("getinfo()", response);
        System.out.println(response);

It just won't accept any credentials at all, I've tried setting them on the conf file, command-line, etc.
Server returned HTTP response code: 401 for URL: http://user:user@localhost:22555

Any ideas ?

So... does it work now or what?

The authentication part yes. (I cannot answer it myself within 8 hours). However you should take a look at this post http://bitcoin.stackexchange.com/questions/7528/bitcoind-returning-invalid-json-rpc-2-0-response?rq=1

Ok, it seems that for some reason I didn't read this essential part:

The easiest way to tell Java to use HTTP Basic authentication is to set a default Authenticator:

    final String rpcuser ="...";
  final String rpcpassword ="...";

  Authenticator.setDefault(new Authenticator() {
      protected PasswordAuthentication getPasswordAuthentication() {
          return new PasswordAuthentication (rpcuser, rpcpassword.toCharArray());
      }
  });


text:
How can I search for transaction text on the blockchain?
Is there a google like search engine which can search for any text that is included with a bitcoin transaction? As I understand it each transaction includes 80 characters of text as well.
Update
It is not possible to search the blockchain for text in an easy way

It isn't true that every transaction contains 80 bytes of text; this is an optional feature and used only occasionally. If you are running a full node such as Bitcoin Core, you could simply grep the block files; then the harder part is identifying the start and end of the transaction and computing its id.

There are several methods of sending text in bitcoin transactions. It is not nescessarily 80 characters. One method most often used, is to have a multisig transaction, where some of the publickeys contain the text, instead of being a valid public key.

Would it be useful to make a search engine for all of this? Maybe I should do that

It is possible to make search engine. But i doubt that it would be useful for something.

What about for searching through all those Digital Contract type uses of the Blockchain? I would have thought that was the killer app for Bitcoin?

Thanks, that makes alot of sense. So where will the actual data be stored if only the hash is stored on the BlockChain?

@AussieCryptocurrency. Add that comment as an answer and I will accept it and award the bounty, as I assume you have got the closest and most correct answer, even if what I wanted to do by searching the blockchain is not possible

If we're talking about smart contracts and such (which we are) then there's no text to search from contracts and such. The digital contract functionality doesn't work like Blockchain.info comments.
If you're going to use the Blockchain to lodge a patent for example, you're not uploading the actual patent. A hash is being made of the time (ie perhaps the hash of block at that height) and a hash of the document, which is then concatenated and then hashed again. So at it's simplest it's:
hash( hash(Blockchain time data) + hash(Document))

Think of it like this: the patent is in an envelope. The envelope is sealed with wax and stamped with a stamp referencing:

proof of time and
proof of envelope's contents

The text inside the envelope isn't searchable, whilst Blockchain.info comments (analogous to post-it notes in an accounting ledger) might be, though the usefulness is not the same.

There is funny site http://bitcoinstrings.com/ I am not sure that it is what are you looking for but just in case...

Yes its funny. But it still doesn't let you search the blockchain

Are you interested in blockchain.info site messages? Try google advanced search like https://www.google.ru/search?q=clue+site:blockchain.info (this query for word "clue")

No, I am interested in blockchain transaction messages, not site messages

In fact, transactions do not have text fields. But there are some ways to include arbitrary data (text, images) in transaction. Read this article http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html

In fact that text is a blockchain.info extension not really present in the blockchain itself. I can't find any text search method in the query API.

I believe you are right, this is not possible right now to search the blockchain.

I found that smartbit.com.au allows you to search for text included in OP_RETURN outputs.
As an example, searching for "on brink" returns an Eternity Wall message that echos the coinbase of the genesis block.

While it is hard to give a more comprehensive answer to this question than what is given, I think it could be improved by providing an example for a successful search.


text:
How to pass password with special characters to RPC API via curl?
When I set a simple password in my .conf file
rpcuser=user
rpcpassword=password

I can contact my wallet using curl from the command line like so:
$ curl --verbose --user 'user:password' --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getbalance", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:18332/
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 18332 (#0)
* Server auth using Basic with user 'user'
> POST / HTTP/1.1
> Host: 127.0.0.1:18332
> Authorization: Basic dXNlcjpwYXNzd29yZA==
> User-Agent: curl/7.50.1
> Accept: */*
> content-type: text/plain;
> Content-Length: 74
>
* upload completely sent off: 74 out of 74 bytes
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Τετ, 21 Ιούν 2017 08:59:30 GMT
< Content-Length: 52
<
{"result":14.13139559,"error":null,"id":"curltest"}
* Connection #0 to host 127.0.0.1 left intact

But if I set a more complex password with special characters, such as
rpcuser=user
rpcpassword=!@#$%^&*()

then the call fails with 401 - Unauthorized
$ curl --verbose --user 'user:!@#$%^&*()' --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getbalance", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:18332/
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 18332 (#0)
* Server auth using Basic with user 'user'
> POST / HTTP/1.1
> Host: 127.0.0.1:18332
> Authorization: Basic dXNlcjohQCMkJV4mKigp
> User-Agent: curl/7.50.1
> Accept: */*
> content-type: text/plain;
> Content-Length: 74
>
* upload completely sent off: 74 out of 74 bytes
< HTTP/1.1 401 Unauthorized
* Authentication problem. Ignoring this.
< WWW-Authenticate: Basic realm="jsonrpc"
< Date: Τετ, 21 Ιούν 2017 09:03:05 GMT
< Content-Length: 0
< Content-Type: text/html; charset=ISO-8859-1
<
* Connection #0 to host 127.0.0.1 left intact

It doesn't seem like the password was mangled at the shell level. It was passed verbatim.
$ echo dXNlcjohQCMkJV4mKigp | base64 -d
user:!@#$%^&*()

There must be a way to do this, because bitcoin-cli works with the complex password just fine.
$ bitcoin-cli getbalance
14.13139559

Looking into bitcoin-cli.cpp it seems the client is using basic HTTP auth, which is consistent with what the wiki says.
strRPCUserColonPass = GetArg("-rpcuser", "") + ":" + GetArg("-rpcpassword", "");

...and later on...
evhttp_add_header(output_headers, "Authorization", (std::string("Basic ") + EncodeBase64(strRPCUserColonPass)).c_str());

Can someone please figure this out for me?
I want to know because I'm trying to pass complex passwords into EasyBitcoin-PHP and failing.
Thanks.

It seems that this is a bug in Bitcoin Core. I will take a look at it.
Edit:
I see the problem now. You have # in your password. The config file parse will interpret # as the beginning of a comment. So this means that it thinks the rest of your password is considered a comment by the config file. You cannot use # anywhere in the config file or everything after it will be interpreted as a comment.
In your example, the rpcpassword that Core is using is !@. To have # in your rpcpassword, I think you will actually need to use the rpcauth option which uses hashes instead of putting the password string in the config file.

Doh! This is so obvious in retrospect!


text:
How do exchanges decide on cryptocurrency trading pairs?
Cryptocurrency trading pairs for example ltc/btc, doge/btc should be paired using some criteria. I'd like to comprehend on what basis they are paired.

Exchanges generally choose a few base currencies and build trading pairs on top of them. It has multiple reasons:

The exchange needs to find a base currency where people can understand the value of X from X/base. BTC/USD is $1350 that gives you a clear idea of how much BTC is worth in USD. That is different from LTC/DRK = 0.98. What did that tell you? Not much. You are in need of a base currency you are familiar with. Most people have a good feeling for the value of USD. Therefore, it is a good denominator.
The exchange needs to find a base currency which people are most likely to deposit/withdraw for trading. After you are done with trading numerous altcoins with each other, you want to exit the trading platform in a currency that has a meaning to you. To make that easy, base pairs are usually BTC.
This is probably the most important, if an exchange has BTC LTC USD, they will most likely not create BTC/LTC pair because that will decrease the liquidity of LTC/USD pair. They will most likely only offer BTC/USD and LTC/USD. On top of that, the extra pair will have maintenance cost to the exchange.

I disagree on your last point. Why is the most important? And I trade on Kraken and btc-e, which both have BTC/LTC/USD (and EUR) and BOTH have all the market pairs with those currencies. I really like those to have all the options, and I will stop trading on an exchange without one of them. I think the other two options are far more important for the exchange to decide which pairs they offer. But I am not an exchange developer or something :)

BTC/LTC/USD is not a good example. But it's understandable. They are liquid pairs. Imagine less liquid pairs. PPC/NXT/DOGE then you understand what I'm saying.

Ahh, yes. Then BTC/LTC was the worst example you could choose. But I understand your point

The decision to open BTC/LTC would depend on the liquidity of the exchange. IF you don't have much, then you wouldn't open BTC/LTC. Imagine being a small exchange.


text:
Are There Abbreviations/Acronyms/Codes for Cryptocurrency Exchanges?
I wonder if there are any abbreviations/acronyms/codes for exchanges like Cryptsy, Kraken, and Ccex. Similar to abbreviations as seen for coins in Bitcoin = BTC and Litecoin = LTC.

No, there are not such codes for Exchanges, like there aren't any codes for different websites. The codes for the different currencies are just for shortening I believe. It's easier anyhow for trading pairs (NMC/BTC instead of Namecoin/Bitcoin)

Thanks, but this code i mentioned here is not source code, rather name code for exchanges.

Im not sure what you want then. Do you want a trading bot or something like that?

For instance Bitcoin is called as btc, Litecoin as ltc, they are cryptocoins. Crypty, Kraken are exchanges, so do they have any code to refer them ?

Ahh, on that bike. I will update my answer


text:
Bitcoin CreateMultiSig in PHP always returning FALSE
I am using bitcoind 0.8.5 with JSON to try and implement multisignature addresses locally on my server.
But when I try and create one from my code, it keeps returning FALSE.

$create_multisig = $bitcoin->createmultisig (2, '[ "02e280809f7a7e0fabb7404d68ef89b66e9cf63ecfffd37ef2c78d06c51d2247f6", "02f22be70ae35432c82e7b05846eeab1fec5b09ebe523bb98d6d6bbf1ff29d96c3"]');
var_dump($create_multisig);

I have tried variations of the quotes, I tried putting the public keys into variables, etc.. Can somebody tell me what I am doing wrong here? It won't create the multisignature address.
EDIT:

$pubkey_str = "";
$pubkey_str .= "\"02e280809f7a7e0fabb7404d68ef89b66e9cf63ecfffd37ef2c78d06c51d2247f6\",";
$pubkey_str .= "\"02f22be70ae35432c82e7b05846eeab1fec5b09ebe523bb98d6d6bbf1ff29d96c3\",";
$pubkey_str = substr($pubkey_str, 0, (strlen($pubkey_str)-1));
$pubkey_input = "'[$pubkey_str]'";
var_dump($pubkey_input);
$create_multisig = $bitcoin->addmultisigaddress (2, $pubkey_input);
var_dump($create_multisig);

And the resulting output

string(141) "'["02e280809f7a7e0fabb7404d68ef89b66e9cf63ecfffd37ef2c78d06c51d2247f6","02f22be70ae35432c82e7b05846eeab1fec5b09ebe523bb98d6d6bbf1ff29d96c3"]'"
bool(false)

I lost my guest session but I figured out the problem.
jsonRPCClient was not providing me any useful information as an output so serching Stack Exchange I was able to find somebody who changed the JSON library to output a useful error code.

    Add *'ignore_errors' => true* to the $opts array
    Change the error line that throws Request error to read throw new Exception('Request error: '.$response['error']['code'].' - '.$response['error']['message']);.

Then the output said that I was inputting a string and I should be inputting an array. So all I had to do, was put all the public keys into an array and plug it into the createmultisig function.

$pubkey_str = array();

$pubkey_str[] = "02e280809f7a7e0fabb7404d68ef89b66e9cf63ecfffd37ef2c78d06c51d2247f6";

$pubkey_str[] = "02f22be70ae35432c82e7b05846eeab1fec5b09ebe523bb98d6d6bbf1ff29d96c3";

$create_multisig = $bitcoin->createmultisig (2,$pubkey_str);
var_dump($create_multisig);

and this was the output

array(2) { ["address"]=> string(35) "2MtXTzX7pASPKr8VKmkyWKRNFt2o1oFxi9K" ["redeemScript"]=> string(142) "522102e280809f7a7e0fabb7404d68ef89b66e9cf63ecfffd37ef2c78d06c51d2247f62102f22be70ae35432c82e7b05846eeab1fec5b09ebe523bb98d6d6bbf1ff29d96c352ae"

Which is exactly what I expected. So maybe it was a stupid mistake on my behalf, but hopefully other people can benefit from it.


text:
cloning bitcoin how bitcoin find new nodes
I am studying blockchain, cpp and crypto so I cloned bitcoin and created a new altcoin.
everything it is working fine as I expected, but i have some questions which i could not find a answer.
the question it is about nodes,let me explain my case.
I have now 3 VM's running the bitcoin clone wallets which it is a new coin now.
vm 1 = it is connected to the node 100.00.00.0
coinname.conf
addnode=100.00.00.0
vm 2 = it is the server which provide the ip: 100.00.00.0 for the vm 1
vm 3 = random wallet as well connected to the ip 100.00.00.0 for the vm2.
coinname.conf
addnode=100.00.00.0
I removed the nodes and dns from net.cpp for do this experiment ok?
strMainNetDNSSeed[][2]
pnSeed[]
so I started do experiment, turning of the VM 2 which provides the ip for the wallets connect.
after this the VM1 and VM3 lost the connection, fine I expected that.
so my question is, how the wallet VM 1 and VM 3 will connect by themselves and keep the networking running if the VM 2 if the server it is offline? and as well if the 2 users don't know the ip it is sharing the nodes?
I searched this topics bellow but i could not find what I am looking for.
How does bitcoin find peers?
How do bitcoin nodes initially find peers?
https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery
EDIT:
the user bellow was right, after while the other wallets get the peers and nodes , so does not matter anymore if the VM2 it is offline, the network keeps on, amazing thing about bitcoin. :)


text:
Why are Bitcoin calculation "useless"?
The FAQ says:

Why don't we use calculations that are also useful for some other purpose?
To provide security for the Bitcoin network, the calculations involved
  need to have some very specific features. These features are
  incompatible with leveraging the computation for other purposes.

That's a rather generic explanation. What are these "very specific features" that Bitcoin calculations need?

I can see that you are talking about the mining process and the SHA hashing algorithm. From what I understand that function needs to be:

Scalable - one needs to be able to precisely adjust how much work needs to be put in for a desired amount. This is done through the use of Target/Difficulty and uniformity of the output of the SHA function (it produces more or less a smooth distribution of random numbers).
The function needs to be quick to verify and always verify the same way. Moreover, the function needs to be always verifiable and not rely on third party - generally, you need to process a lot of blocks in order to catch up to the network, so there is no point in it taking too long. Also, there is no ambiguity in determining whether a given hash fulfils the preconditions as would happen with some functions ("is this protean optimally folded?"). Morever, floating point calculations are not too good as different computers could have different rounding errors. As for being always verifiable and not relying on third party - Bitcoin is a decentralised currency and thus it cannot remain that way should it be dependant on some company or website operating it. Every peer needs to be able to independently verify the solution with minimal amount of software and hardware. Scientific simulations can rarely fulfil this goal.
The function needs to work one way and have no cryptographic weaknesses - generally, you don't want people to reach the result quicker than is fair. Hashing functions are the types of functions where one needs to perform the calculations in order to receive the results and can't get anywhere knowing the solution. SHA-256 is secure and for now doesn't have any weaknesses.
The output of the function should depend on every part of the input. Moreover, changing even one byte in the input should change the output completely. - Generally, the function needs to be very sensitive to tempering. Any change on the input must change the output so as to prevent malicious manipulation of data. Similarly to ensure that the function is scalable and nobody can "tinker" with the data a bit to produce another valid result from a previous solution, the output must appear to be pseudo random and any change of the input must change the entire output.

Don't you think some of the points I made in my answer are valid as well? I think yours is better, but a few things I mentioned are requirements too - add them to your answer and I'll accept.

@ripper234 I wrote the answer after having skimmed yours. I added a point about the input/output change. Lets see... Number 1 is mainly a feature of the blockchain, not really hashing function and is encompassed in my last point. Number 2 is covered with points 3 and 4. Number 3 I think I should add to point 2.

I think point 1 is not 'mainly a feature of the blockchain', but rather it helps explain why a simple list of useful problems can't be used as hash targets - because people might pre-calculate them (there might be work arounds to prevent this kind of pre-calc, but still I think it's an important requirement of the whole hashing scheme ... not just the hash function specifically).

The requirements of the Bitcoin calculation function:

Every calculation must depend on the previous calculation. This is what makes each block strengthen the security of previous blocks.
Every calculation should be impossible to know, or even make "partial progress" on, before the previous block is found and published. This is done to make sure to prevent pre-calculation of blocks (by satoshi or anyone else) - it makes sure the "lottery ticket" that is finding a block is split only between miners currently working on this problem (that there are no "hidden lottery tickets").
There should not be any central source that affects the types of calculations (e.g. a central server sending protein folding problems). The conditions for the calculation should be knowable from the peer to peer network (a central server is a single point of failure).

We do not know of any "useful" calculation (e.g. SETI@HOME, FOLDING@HOME) that abides by these criteria, so random "useless" hashes were chosen.

Bitcoin mining exists first and foremost to synchronize transactions; it does so by allowing miners to acknowledge that they consider some transactions valid, by provably doing a calculation which references these transactions somehow. This requires the calculation to have the following properties:

The most important requirement by far as that it is possible to take arbitrary data, and from it generate algorithmically a problem to be solved; the problem must depend on the data in such a way that without knowing the exact data, it is impossible to make any progress towards the solution to the problem.
If you could not derive a problem from arbitrary data, you could not take transaction data (which is arbitrary) and from it present a problem whose solution acknowledges the transactions; the derivation must be algorithmic, otherwise there would be need for some central entity to come up with the problem; and no work should be possible before knowing what the transactions are, otherwise the work cannot meaningfully acknowledge the particular set of transactions.

The problem must be much easier to verify than to solve. Otherwise, a lot of overhead will be created in operating the network after the problems are originally solved.

It should be possible to freely scale the difficulty of the problems. Otherwise, as the computational power of the network changes, the solutions could arrive too quickly (causing forking and overhead) or too slowly (delaying the confirmation of transactions).

We need to have sufficient confidence that the problems are indeed as difficult as we think they are. Otherwise, a party finding a significant shortcut could have an unexpected and unchallenged advantage.

Requirement 1 is the most important, and also the most unlikely to be satisfied by "useful" problems - real-world applications generally require a central domain expert to issue relevant problems.


text:
Is there a list of "hardforks that will never happen in Bitcoin"?
The Hardfork Wishlist lists some fork-causing changes that might actually get introduced (e.g. adding more decimal digits to allow units smaller than a satoshi).
Is there a similar list of forks that will definitelylikely never happen? (might happens in alts, but not in Bitcoin)
One such change is obviously changing the target limit of coin creation from 21,000,000 to something else. Another change might be changing the reward splitting to be continous - such a change is probably too complex without much concrete benefit to be ever implemented in core Bitcoin.

Here, I created a page about that: https://en.bitcoin.it/wiki/Prohibited_changes

Excellent, thanks. +tip $1 (too bad the reddit tip bot does't work here).

I took the liberty to slightly "fix" that page, assuming that the "21M" limit won't be changed at all (i.e. neither increased nor decreased)

@Lohoris The limit is currently slightly less than 21 million, so that doesn't make sense IMO.


text:
Who operates WeExchange, the first Ripple Gateway?
Is it operated by OpenCoin, the company behind Ripple?
https://weexchange.co/
https://ripple.com/wiki/Gateway_List

Nope.
The contact page lists

WeExchange Australia, Pty. Ltd.
WeExchange, Inc

Of course, I don't know that for a fact. The whois is registered to a privacy protection company, which doesn't really fill me with confidence.

+1 rule #1: never give your money to someone who doesn't even tell you his name...


text:
What do the "Fetch Wallet" options when opening a Ripple wallet mean?
When I open a Ripple account, I can choose to fetch my wallet from

Payward, Local Browser
Payward
Local Browser

What does this mean? Can someone elaborate on the differences, and when is each option appropriate?

Are there still 2 people voting to close ripple questions, despite being consensus on meta that they are in-topic? How childish they are?

@Lohoris - not just voting to close, but without identifying themselves...

we could vote to close too, to reveal them.

@Lohoris - nah, no point.

I voted to close on this and all other Ripple questions I see.  I feel the Ripple questions detract from this SE and will continue to use my "vote" in this manner.

@StephenGornick - why don't you come talk about it here? http://meta.bitcoin.stackexchange.com/questions/335/should-this-se-also-cover-questions-about-ripple

@StephenGornick - wait ... you have. Is this reply ironic? http://meta.bitcoin.stackexchange.com/a/345/78 I took it as a vote from you for including Ripple on Bitcoin SE?

@StephenGornick this is abusing the system: once it has been established that community thinks it is in-topic, you no longer have the right to vote to close.

@Lohoris - of course he has the right to vote to close, it's just childish and futile to insist on doing this if the vast majority will disregard it.

@ripper234 no, you have to provide a reason to close a question, and if the reason is "it's OT" when the FAQ says it is IT, he's abusing the system.

If others join me and Ripple questions continuously get closed then maybe the topic of what the community wants here gets revisited.   Incidentally, I want Ripple to succeed.  I just want the Bitcoin SE to remain the Bitcoin SE.

"Payward, Local Browser" tries to fetch your wallet from Payward and if an account has not been found or if the Payward is not available / you are offline, it tries to fetch the wallet from local storage.
"Payward" only looks in Payward.
"Local" only looks in local storage.

P. S. You've set where to save your wallet in https://ripple.com/client/#/register right after the "Create Wallet" button.

You can store your encrypted wallet in Payward server, and access it everywhere, not only from your local machine.


text:
Is Ripple.com scalable?
What is the Ripple equivalent to https://en.bitcoin.it/wiki/Scalability ?

Centralized banks which controls your money seemed to be able to scale throughout the world. So ripple can too im sure. But i only trust in decentralized bitcoin. Good luck to ripple tho. its probably "good" for the purpose its designed for.

Why the close vote?

See also http://bitcoin.stackexchange.com/questions/9701/is-ripples-distributed-exchange-scalable

The limitations on Ripple scalability are substantially the same as the limits of Bitcoin scalability. There are various minor differences, but they don't significantly change the picture.
Ripple already has some scalability features that Bitcoin doesn't have yet, but Bitcoin can easily add them when it needs them. For example:

Ripple nodes don't need to keep history to process transactions.
Ripple nodes can form "clusters" under common administration that divide the cryptographic work.
Ripple nodes can escalate the transaction fees they demand to forward transactions in response to load bursts.

One difference is that Ripple's confirmation time can increase with load. In a sense, Bitcoin's confirmation time can increase with load too as you may need to wait longer to get a transaction in a block. But Ripple's consensus process can take longer if more nodes are participating in it or if a higher transaction level creates more disagreements that must be resolved in the consensus process.
Right now, consensus consistently takes about 2 seconds (which is the minimum). In simulations, the consensus process increases with the log of the number of trusted validators. 100 validators brings it to about 3 seconds. 1,000 validators increases it to about 4 seconds. 10,000 increases it to about 5 seconds.
Consensus time also increases, though by much less, with the transaction rate. Note that consensus time is just one factor in the time it takes to confirm a transaction, though as the network grows it will likely be the dominant factor.

So are you saying that Ripple won't be "the better scaled network on top of Bitcoin", because it's fundamentally very similar to Bitcoin in terms of scaling?

Ripple has a bit of a head start on Bitcoin because we got to design it from scratch knowing about the specific scaling issues Bitcoin has. But Bitcoin can (and likely will, when it needs to) adopt solutions. The extent to which Ripple will, we hope, scale better than Bitcoin are just fixed multipliers. For example, a Ripple ledger will probably close 100 times more often than a Bitcoin block is found. If they could both handle 100 transactions per block/ledger, that would still be a huge advantage for Ripple. But both networks would find it approximately equally hard to double their capacity.


text:
Whats are "non-final transactions"?
Killerstorm mentioned "non-final transactions" as something Satoshi talked envisioned. Can anyone elaborate what this means?

These? http://bitcoin.stackexchange.com/questions/5783

Well, a very simple case is mentioned in "Providing a deposit" contract, but there are many other uses, and many contracts depend on such transactions.
I also provided a brief description in this comment:

Transaction with nLockTime in future cannot get into blockchain before that time.
Previously it was the case that it was stored in memory pool, but now they can't even get into mempool. And it is OK, actually.
  Basically, nLockTime gives you an ability to back off after some delay, and that delay penalizes abuse or gives some time for negotiations.
For example, suppose there is a service provider and a customer. They do not trust each other very much, so they will put money into 2-signature transaction, with nLockTime'd rollback in future. If customer is satisfied with service, he will release money to service provider. If service provider agrees that he screwed it up, he will release money back to customer. However, if they disagree (e.g. service provider think he did great job but customer thinks it's shit), money can be released by nLockTime'd transaction, say, year from now. In that case customer suffers because he cannot use money for a year, but service provider doesn't get money for shitty job he have done.

But, well, a complete answer will be a rather lengthy article...


text:
Does variability of block solution time change as difficulty increases?
We know that the expected average time to solve a block from any given point in time is 10 minutes when the network hash rate matches the current difficulty.
However, as difficulty increases are we going to see more or less variability, or does it stay the same?
ie If we compared a difficulty of 500,000,000 with 500,000, would we see more blocks taking over 60 minutes to be solved, or less blocks, or will there be no difference?

The variability is exactly the same no matter the difficulty. It is always an exponentially distributed random variable with mean 10 minutes (the mean could be slightly off if hashrate mismatches difficulty).
What we may see in the future however is a reduction in variance due to decrease of the block reward. As transaction fees become a more significant part of the reward, the profitability of mining will increase the more time has passed since the last block; just after a block is found, mining is unprofitable so the hardware may idle/switch to a different task. So the network hashrate will increase with time, meaning that few blocks will be solved quickly (hashrate is too low) and few will take a long time (the hashrate will be high so it won't last long), meaning less variance.


text:
Litecoin daemon is not responding to API calls
Just before few hour I have setup bitcoin daemon on my ubuntu server and tested it with API and it is responding very well. Now I have installed litecoin daemon on the same server and used copied the same php files with a little sytax changes like change in username and password and port number but it is not responding to any API calls.
Content of litecoin.conf are :
server=1
daemon=1
rpcuser=my_username
rpcpassword=mypassword
rpcport=9332

Content of litecoin.php
<?php
include_once('jsonRPCClient.php');
$variable = $_GET['variable'];
$litecoin = new jsonRPCClient('http://my_user:my_password@127.0.0.1:9332/');
if($variable=='getnewaddress')
{
echo $litecoin->getnewaddress();
}
else if($variable=='getinfo')
{
print_r($litecoin->getinfo());
}
else
{
echo "hello";
}
?>

Any help of what I am doing wrong here ?
I was trying to figure out why php file is not throwing any error if there is any then I discovered that error_reporting in php.ini file is turned off after turning it on I got following error while executing litecoin.php on the browser :
Warning: fopen(http://...@myserveraddress.com:9332/): failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden in /var/www/jsonRPCClient.php on line 132
Fatal error: Uncaught exception 'Exception' with message 'Unable to connect to http://myuser:mypassword@myserveraddress.com:9332/' in /var/www/jsonRPCClient.php:140 Stack trace: #0 /var/www/litecoin.php(12): jsonRPCClient->__call('getinfo', Array) #1 /var/www/litecoin.php(12): jsonRPCClient->getinfo() #2 {main} thrown in /var/www/jsonRPCClient.php on line 140

You are using HTTP, so you can use an IP packet sniffer to see what's going on. Is your connection accepted by the server? Does the server respond with any kind of HTTP response?

@GregHewgill I have used the same file with bitcoin daemon with different parameters and its working fine. But litecoin is not working

Yes, you already said it wasn't working, but you haven't given any information that would allow anybody to guess a reason. I am suggesting a method for you to do some diagnostics to find out why it is not working.

Sometimes this error is thrown because passing too many characters as rpcuser or rpcpassword in the config file I have sorted out this issue with reducing the length of the rpcuser and password and removing special characters

First add this line to litecoin.conf
rpcallowip=127.0.0.1

Then make sure you've added the litecoin command to your path
sudo cp litecoind /usr/bin/litecoind

and that your starting the litecoin daemon
litecoind -daemon

and test with
litecoind getinfo

if all that works then JSON RPC should work fine.
If none of that works try setting up the client by following this guide.
Also make sure your username and password are consistent across your PHP and litecoin.conf because they aren't in your example.

I have figured out that error_reporting was turned off in my php.ini file that is why it wasn't showing any error, now that I turned them on running litecoin.php on my server shows following error:


text:
How do I find out the reward value of a generated block
Using the bitcoin client's JSON API (or any other altcoin client) how do I find out the reward given for finding that block?

The information you get for a getblock call doesn't seem to include the block reward. You could find it with a gettransaction call for the first transaction, but bitcoind only allows lookup for transactions in your own wallet, so that won't work either.
So indeed, as Diego points out, the only option is to look at the block height. This wiki page lists the different reward values for the different block height intervals.

That should be fine for my need.  I only need to know the reward value for blocks I find.  So it's safe to assume that the first transaction will always be the block reward?

The first transaction is the coinbase transaction and the output of this transaction contains the block reward + the combined transaction fees of the other transactions.

All you need is the block number. The reward started at 50 and it halves every 210k blocks. Currently it's at 25, and as I write this the current block number is 286459. For other altcoins, you need to know the schedule.

so we can calculate block with your said matematic formula? we can use this table right?: https://en.bitcoin.it/wiki/Controlled_supply#Projected_Bitcoins_Long_Term

a bit old but maybe useful for people doing e2e tests in regtest
// from bitcoin-core implementation
// return in satoshis
function getBlockReward(height, halvingBlocks = 150) {
    const halvings = BigInt(height) / BigInt(halvingBlocks);
    if (halvings >= 64)
        return 0;

    let reward = BigInt(50 * 100000000);
    reward >>= halvings;
    return Number(reward);
}

and use it with bitcoin rpc client and getblockcount. Ex:
const blockNumber = await bitcoindClient.getBlockCount();
console.log(getBlockReward(blockNumber));

Pease notice that if you will use other network you must pass halvingBlocks params or change default value.


text:
Cannot get BITCOIND RPC connection working on Ubuntu 12.04 or Windows 7
OK, I recently posted trying to get help connecting to BITCOIND using Ubuntu or Windows 7.
In Ubuntu (Virtual Machine under Win7 64bit) 12.04 Desktop LTS I have the following written in my BITCOIN.CONF file located in $HOME/.bitcoin :
server=1
rpcuser=hello1
rpcpassword=12345
rpcallowip=*

I run BITCOIND with following command:
./bitcoind --server --rpcuser=hello1 --rpcpassword=12345

But when I try and connect with the Ruby script (see https://bitcointalk.org/index.php?topic=85495.msg3773215#msg3773215 ) it gives an error saying it can't connect.
Likewise, under Windows 7 I attempt the same procedure and using NIRSOFT cports app I see Bitcoin daemon is only opened under port 8333, not 833*2* as one would expect if RPC connection was active.
I've opened TCP/UDP port 8332-8333 in port forwarding of router.
What on Earth am I doing wrong here?
Why can't I connect to Bitcoin daemon via RPC?
==> BONUS QUESTION: I'm quite new to Ubuntu; how do you check open TCP ports at terminal in Ubuntu? (equivalent of netstat in windows)

I am not familiar about how to run it on windows but for Ubuntu 12.04 I can help you out first you should remove garbage from the conf file which should be located under ~/.bitcoin folder with the name bitcoin.conf with just following text :
server=1
daemon=1
rpcuser=whatever
rpcpassword=whatever

^^ is sufficient
now to make bitcoind to reply RPC calls you should have jsonRPCClient files in your computer I am not familiar with ruby but still https://github.com/Textalk/json-rpc-client-ruby this link can give you an idea on how to do it. I hope this will help you achieve what you are looking for. And the bonus answer on linux you can use netstat -ntpl to have detailed view on which program is using which port


text:
Is there any desktop notifier application for bitcoin prices?
There's a nice C2DM push based notifier for android but I'd like to know if there is one for the desktop environment, ideally linux?
Does anyone know if one exists?

If you're looking for a solution which will run on linux, then there's always a the wget command:
wget -q -O - https://mtgox.com/code/ticker.php

You can run it in a loop in a terminal :)
Under the xfce desktop environment you could use the genmon panel plugin and feed it Mt. Gox's last trade data. Speaking of which, I think I'll do that myself. :)

just made a quick shell script that i call from the genmon plugin. simple one-liner to grab the ticker and pull out last price: wget -q -O - https://mtgox.com/code/ticker.php --no-check-certificate | awk -F"," '{print $8}' | awk -F":" '{print $2}'

When I visit https://mtgox.com/code/ticker.php, it says the API is deprecated.....

Is there one that can use data from bitcoincharts.com? So I can monitor the price on localbtc?

While it's not necessarily a desktop notifier, there is a functional web-app notifier recently publicized on the forums: http://www.bitcoin-tools.de/
From the site:

It is nothing more than a simple alert-system which alerts you
  whenever the buy, last or sell is reaching a defined level.

The tool includes audio alerts and user-definable limits.


text:
What if any proposed blockchain enhancements that require hard forks would require new ASIC hardware?
From what little I know about ASIC they are not flexible with regard to the tasks that they can execute. Some of the proposals for scaling bitcoin up require hard forks in the blockchain. I read about one proposal about replacing the ECSDA signing algo with Schnorr that made me think of this question.
I'm wondering if any of these hard forks would actually mean that some or all current ASIC miners are rendered incompatible and worthless? This would of course have an impact upon which solutions are likely to go forward.
I expect it depends on the design on the chip, if only the core hashing power is offloaded to the ASIC but everything else is done on a more general CPU. Are most of them designed like this?

I don't think many hardforks would make ASICs obsolete. Developers would surely want to avoid that, and will always have a way to avoid it. Unless they have a reason to make all ASICs obsolete on purpose (extreme mis-behaviour by miners could theoretically cause that). In that case they could chose a different mining algorithm.
The ASIC simply gets fed the prepared header of a block and all it does is run hashes on it while increasing the nonce (32 bits) and possibly a few other bits (in the timestamp field) in case the nonce is too small. So only those bits that it actually touches could possibly cause the block to become invalid. It's highly unlikely that the developers would ever change the meaning of those bits in such a way that it would become more restrictive and cause the found blocks to become invalid under the new rules.
Hypothetically I guess one example could be where the developers decide to restrict the allowed error margin of timestamps in headers. Currently a block is allowed to have a smaller (older) timestamp than the previous block (up to two hours if I'm not mistaken). Suppose the developers decide that from now on it can only vary by 20 minutes. If the ASIC is happily incrementing the enough of the last bits of the timestamp field it could make it exceed that margin, making the block invalid under the new rules.
I guess ASIC manufacturers need to be a little bit careful, or make the ASICs flexible enough so that they can be told which bits to touch. Although I guess the above example might be a reason for the developers to never improve the timestamp accuracy (at least not in the straightforward way).

If the mining algorithm would ever be changed it would severely weaken the Bitcoin network's security at least temporarily if not kill it off completely. Such an endeavour would have to be planned and announced long in advance. In light of the block size discussion, I sincerely doubt that it would be easy for such a plan to gain support, though.
The only way it may come to pass would be if the Bitcoin network's security would be compromised more if it were not done.
Luckily, changing the signature scheme does not necessarily change the mining algorithm.

Now, that I wrote the above I realized that I'm not sure What portion of the mining process does an ASIC perform?, please take this answer with a grain of salt for the moment.


text:
What EURO exchanges have web APIs currently?
I'm wondering what exchanges in that operate in native euro, who most likely support sepa transactions have web apis?
Bitcoin-24.com was great until they had banking problems. now who is left? Is BTCe the only one?

I just tried again to find a comprehensive Bitcoin exchange overview, but the best thing I found is this: https://en.bitcoin.it/wiki/Buying_bitcoins

Kraken and Bitfinex and I'm sure others, not sure if you can deposit to Bitfinex tho.

There are quite a few exchanges in Europe with APIs. Use the Bitdango exchange search to find exchanges in European countries:
http://bitdango.com/exchanges?countries=BG,CZ,DE,FI,FR,GB,HR,MT,NL,NO,PL,SE,SI
Or use the Bitdango market search to find markets that use Euros as quote currency:
http://bitdango.com/markets?quoteCurrencies=EUR

The highest volume of BTCEUR is on kraken for a long time already.

docs for API method: https://www.kraken.com/help/api#get-ticker-info
API call: https://api.kraken.com/0/public/Ticker?pair=XXBTZEUR


text:
What is an explanation of the P2SH voting in layman's terms?
Reading this question and looking in the bitcointalk forums at the related discussion, there seems to be some kind of miner vote being done on whether a change will be implemented in the bitcoin protocol.
It seems to discuss the adding of a function which could allow clients to have restrictions on receiving coins. (Is this it? If so, it would answer Q1. below)
The following things were beyond my understanding though, or difficult to find:

An explanation in laymens terms of what the potential change achieved
Why the change is desirable
When the voting is taking place
What the vote is actually for (is it just yes/no, or are there more options?)

Note that this question addresses the question of which mining pools are voting yay or nay, though it doesn't seem to have an answer yet.
If this is done as part of the work of the bitcoin.org developers, I found it a bit strange that nothing seemed to be mentioned on the bitcoin.org site about it (I checked the news and the FAQ). I suppose that it is more of a miner issue though...

The answers to your questions, in order:

The fee paid for a transaction is determined by the size of a transaction.  Currently, if you want to do fancy things with bitcoins, you need to put a script in the transaction that sends them -- each output includes a script giving the conditions under which it may be used as an input.  OP_EVAL, p2sh and CHV (check-hash-verify) all provide ways of putting the script in the transaction that receives the coins.
This lets you have coins sent to you and do arbitrarily complicated things with them without imposing a fee burden on the sender.  The coins are yours once they're sent, but you'll have to pay the fee the next time you try to do anything with them (no free lunch here...).  The most important use-case here is to have wallets from which you can spend coins only by using two different devices (for example, both your laptop and your cellphone).  Even if both devices are "virus infested" it's highly unlikely that any single malicious entity has compromised both of your devices.  The hope is that this will put an end to the rash of coin thefts, or at least make it much harder for botnet operators to steal coins from the people who own the machines they've taken over.
The voting takes place during the blocks found during the seven days preceding 01-Feb-2012.  No timezone was specified.
The original vote was "yes/abstain".  Gavin put code into the "master" branch of the bitcoin client that would cause anybody who upgraded to the latest version to automatically vote "yes".  This angered some people, who added a new option for a "no" vote.  However, what really matters is whether or not 50+X% vote "yes" -- an "abstain" counts as a "no" vote for the purposes that matter.  If a minority of the hashpower were to enable p2sh a single malicious user could cause a permanent blockchain split, so it's important that this not be enabled until we are dead certain that a comfortable majority of the hashpower is on board.

Most of the controversy is over how quickly this proposal was put together and rushed through the approval process.  The general idea, and the predecessor (OP_EVAL) have been around for a while, but this latest incarnation is very new.
Also, at the moment the mining code in the bitcoin client has a funny concept of a "standard" transaction which is not part of the bitcoin protocol at all -- it's just a gentleman's convention by which some (but not all) mining pools voluntarily choose to omit transactions that use advanced bitcoin features -- if you want to use those advanced features you have to wait longer since there's only one big pool (and several small ones) that will take them (once mined into the chain, however, all clients respect these transactions -- it's just a question of getting them into the chain).  The p2sh specification forces the "standardness" concept to become part of the protocol -- miners will be forced to use transaction templates whether they want to or not.  Many consider this to be infringing on the miners' jurisdiction.  Others consider it an affront to aesthetics and an invitation to headaches in the future.

Note also that BIP 17 voting is the first week of February, after BIP 16 is rejected.