text:
Multisig vs Multi input transaction signing
Let's say we have a 2 of 2 multisig address that we want to spend from, so the transaction should be signed by both of the private keys.
Now let's say we have a transaction with two inputs, so once again the transaction should be signed by both of the private keys of the inputs.
So how does these two differ in implementation? Even on conceptual level? Are these procedures the same?

Are the two inputs both spending from the multisig address?

Related: http://bitcoin.stackexchange.com/questions/32365/if-i-am-spending-multiple-inputs-from-the-same-address-must-i-provide-a-signatu

They are fairly different things and represent very different use cases.
Imagine you are the head of the party planning committee and you have two workers (A and B) to help you buy items for the party. You are given 1 bitcoin to fund the party.
You have two options.

You can split the funds up between A and B. For example, you could give A and B each 0.5 bitcoins in two separate outputs. If they need to buy something worth more than 0.5 bitcoins, they will need to combine their outputs as inputs to the same transaction. However, for items less than 0.5 bitcoins, A and B will be able to act independently to purchase items (or steal the funds!).
You can jointly give A and B the 1 bitcoin in a 2 of 2 multisig address. Now for any purchase they will need to agree in order to spend from the party committee's funds.

To summarize:
Spending a 2/2 multisig output:
Spends a single previously UTXO and requiring two keys to sign.
Spending multiple inputs:
Spends multiple previously UTXOs and requires each input to be signed separately.

With regards to signing these types of transactions, they have to be done slightly differently.
When signing an input that spends a 2/2 multisig output, the transaction is signed by the two keys and they are encoded into the same scriptSig of the one input. The transaction only becomes valid when both keys have signed with valid signatures.
For example, suppose the scriptPubKey of the previous 2/2 multisig output is:
OP_2 {pubkey1} {pubkey2} OP_2 OP_CHECKMULTISIG

The the scriptSig to spend that output would be:
{pubkey1's signature} {pubkey2's signature}

Notice how they are in the same input's scriptSig.
When signing two different inputs, assuming their previous scriptPubKeys look something like this:
{pubkey1} OP_CHECKSIG

and
{pubkey2} OP_CHECKSIG

Then the two inputs would have scripSigs in this format (respectively):
{pubkey1 signature}

and
{pubkey2 signature}

NOTE: I've used simple scriptPubKey's to be try to be clear about how it generally works, but you should probably use Pay-to-script-hash multisig address and pay-to-pubkey-hash addresses instead of the raw multisig and pay-to-pubkey scriptPubKeys that I used in this example.

This actually was not the answer I'm looking for. In implementation level, how does these two differ: 1) requires two keys to sign 2)requires each input to be signed separately . What I mean is at the end there is a unsigned raw transaction that should be signed, how the signing procedure would differ between these two scenarios?

@Shayanbahal, does that clear it up?

That was really good, thanks. Only regarding the last part (NOTE) I'm not quite clear on what you meant by " you should probably use Pay-to-script-hash multisig address and pay-to-pubkey-hash addresses instead of the raw multisig and pay-to-pubkey scriptPubKeys that I used in this example."

@Shayanbahal, the answer to what all of those things are is probably outside the scope of this question. This answer should help explain the difference between raw multisig and P2SH multisig. The bitcoin developer documentation is also helpful. And make sure you mark the answers to your questions with the green check mark. :)

Transaction from a Multisig Bitcoin address (starting with 3) requires signature from N of M

M represents number of parties allowed to unlock UTXO (input of transaction). In case of 2-2, both signature from both parties have to be involved to create valid transaction
N is number of owners (known as threshold) whose digital signature is required to sign a valid transaction

However, Multi input transaction is a type of transaction where input involves UTXO from 1 or more either standard or multisig bitcoin addresses.
Following states may occur

Standard Bitcoin address signs transaction with 1 input

requires one digital signature with valid private key

Standard Bitcoin address signs transaction with more than 1 input (multi-input transaction)

requires digital signature for each UTXO with valid private key

Multisig Bitcoin address signs transaction with 1 input

requires one digital signature from threshold

Multisig Bitcoin address signs transaction with more than 1 input (multi-input transaction)

requires digital signature for each UTXO by threshold

Up to this point, ALL UTXO belong to signer of transaction. Now transactions will contain UTXO for more than 1 Bitcoin address.

Two Standard Bitcoin addreses sign a transaction with 1 UTXO for each of them (multi-input transaction)

requires digital signature for each UTXO by corresponding valid private key

Ex. Transaction involves 2 UTXO for 2 separate Standard Bitcoin addresses, to create valid transaction, address A have to sign UTXO(A) and address B sign UTXO(B). Transaction can now have 1 output making the cost of fees much lower than in scenario, where for each Bitcoin address is created separate transaction.

Two Multisig Bitcoin addreses sign a transaction with 1 UTXO for each of them (multi-input transaction)

requires digital signature for each UTXO by corresponding valid private key of threshold

Ex. Transaction involves 2 UTXO for 2 separate Multisig Bitcoin addresses, to create valid transaction, threshold of address A have to sign UTXO(A) and threshold of address B sign UTXO(B).

Option 5 and 6 combined.

Ex. Transaction is composed from UTXO for 1 or more Standard Bitcoin address and 1 or more Multisig Bitcoin address.

authors: Анна Самойлова


text:
What type of hedging might CoinLab be employing?
In the announcement on GeekWire that CoinLab had received seed funding, there was a statement that I found interesting:

CoinLab will pay game companies in government currency, not Bitcoin, and will use price hedging strategies to protect its own interests.

What type of hedging might they employ and why?  And from where?

I doubt it's anything more sophisticated than selling the coins, maybe shorting in Bitcoinica.

Bitcoins are easy to hedge against delivery by pre-selling, provided your working capital calculations are properly sorted, and you understand timing constraints throughout the systems you're dealing with.
We will sometimes be delivering digital goods through an intermediate currency as well, and we will use existing financial markets to sort/hedge that leg.
Shorting on Bitcoinica is another possibility, although it doesn't remove the need to manage your working capital (or credit lines)

source: Stack Exchange

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

sort: votes


text:
How does the graph of money supply of PPCoin look like?
We all know how the money supply graph in Bitcoin looks like - exponentially reaching 21,000,00 BTC.
How does the same graph behave for PPCoin (A fork that also involves Proof Of Stake)?

Why the vote to close? (alternative crypto-currencies are on-topic)

https://bitcointalk.org/index.php?topic=122467.0

Here it is:

Note that this chart goes only up to March 2014. In the future, when proof of stake dominates, there will be a steady 1% inflation every year, but also 0.01 PPC will be destroyed every transaction. It is not known exactly what will happen, i.e. whether the 1% inflation or the destruction of coins every transaction will be a more significant factor.

In case you didn't know, it is possible to attach pictures to posts here on Stackexchange.

I have amended it.

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


text:
Notable examples of double-spends
Do you know any real-world examples of double-spends, where the second transaction was accepted to the block?
There's https://doublespend.cash/ for BCH but for BTC I would like some examples where the second transaction is accepted. (And this website shows all occurences of double-spends. I just want some successful ones.)

what is high-value? is is $1k?

@amaclin I removed it, value doesn't matter. A transaction is a transaction.

Yes, I did some double-spends playing on-chain games. It was years ago when a game (for example luckyb.it) accepted transaction with high-S-value, but most of pools did not include it into the block. The strategy was: send a bet with high-S-value, doublespend it if loss or wait several hours for a pool what confirm it on win.
As far as I remember, successful doublespend was performed by pool operator (I do not remember which one) when Bitcion forked in 2013 (0.7 to 0.8 version upgrade)

If it would be possible to doublespend bitcoin, it probably wouldn't have that much value as it have, right? But some of the wallets (BRD and Edge if I remember correctly) had this UI that portrayed unconfirmed transactions as already confirmed which led to some confusion of clients of these wallets and anectodal evidence shows that these wallet's clients might have lost money in the deal.
If you are looking for something closely related to bitcoin, but not bitcoin, I'd check the issues of (~2018) exploit of bad integration of Omni layer on the exchange. As some exchange (forgot the name) wasn't looking at omni layer status of verification (True/False for doublespends) but just payload of OP_RETURN script, it was possible to doublespend it, and this problem was found by some group of researchers.

It is possible to double spend bitcoin, and it's easier if you have the support of a (few) pools

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


text:
Are there live BitcoinJS Exit Nodes?
Where can I find some live (trusted?) BitcoinJS Exit Nodes?
I'm looking it it from the client perspective - I want to write a Java app that doesn't store a blockchain. I don't want to setup an exit node, rather I want to find and use existing ones.

According the to the status message at the bottom of the page: https://github.com/bitcoinjs/node-bitcoin-exit
First permanent deployment is online at https://exit.trucoin.com:3125/

That node seems to time out – is this a temporary failure or has the node been closed?


text:
What is the superscript number in Bitcoinica prices?
Since Bitcoinica has been released I've been reading a bit about Forex. But i don't know what the superscript number refers to in the price quotes on the front page. How is this number calculated and what does it indicate? Or are they just simply pips?

These are indeed pips, according to this comment by Bitcoinica's owner. That is, they are just an extra digit denoting multiplies of 0.00001 USD.


text:
Ubuntu update litecoin-qt wallet software
I get this message when i run my litecoin-qt client:
all users must upgrade to litecoin 0.6.9.1 prior to 15 august 2013

so i downloaded the litecoin-0.6.9.2-linux.tar.xz file from litecoin.org and ran through this process: https://forum.litecoin.net/index.php?topic=43.0
Now i have the new litecoin daemon running but the qt client has not upgraded. How do I upgrade the client? I'm using Ubuntu 12.04.

found the instructions:
https://bitcointalk.org/index.php?topic=63706.0
basically just need to run
qmake "USE_UPNP=-"
make

in the main directory to create the litecoin-qt file


text:
How can one download the initial Blockchain data files securely?
I see several sources for binary downloads of the Bitcoin blockchain.  Can any of these be used securely?

Does Checkblocks help at all?

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

No. Even at the highest -checklevel, signatures are not verified.

URL for the blockchain data files from Sourceforge: http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/

I believe the best answer to this question is "by letting bitcoind download it from the network" (note that you can use -addnode or -connect= to connect directly to a known reliable node). Also, I have a patch ready for 0.7.0 which will allow importing a blk0000?.dat file directly, with the same verification as done for blocks downloaded from the network. It is hardly slower than downloading though, as the index needs to be rebuilt.

So far as I know, there's no conceivable attack model if you're going to use the block chain to seed the regular Bitcoin client. It won't accept an invalid block. And it understands that the "longest" block chain wins. So a compromised file that was longer than the official block chain cannot exist, and a compromised file that was shorter would just be rejected as soon as the client connected to the network.
On startup, the client checks to make sure the chain is basically valid and contains the most recent checkpoint.
If there is any attack that works in this way, it's a defect in the client. Because someone could send you the same "broken" blockchain over the network too.

Many more checks are done on blocks received from the network than blocks read from disk; startup would be unbearably slow if a complete check of the blockchain was done every time you start.

I was under the impression a full check was done on every block after the last checkpoint. If that's not true, ...

The checks performed can be divided in three groups: A) block validity, B) linking and C) script validity. A includes rules like proof-of-work, amount generated, ... B is about whether transactions are not double spends. C is whether spends are done using the correct key. When downloading blocks, A and B are performed, and C after the last checkpoint. At startup, only A is performed on the last 2500 blocks. Since 0.6.0, you can use -checklevel=N (with N>1) to verify some of B's rules as well at startup.

[Update: With the Bitcoin client v0.7, -loadblock= will allow the client to import blockchain data, securely, from a local blockchain archive rather than from the network.  The blockchain download from BitcoinCharts.com can be used for this.  Copy the blk*.dat from that download to a temporary directory and start Bitcoin-qt -loadblock=temp/blk0001.dat   and watch the blocks load fast.]
Going to try to answer the question myself.
Recent copies of the blockchain data files are made available (and digitally signed) by one of the core developers of the Bitcoin.org team.

http://eu1.bitcoincharts.com/blockchain/

The URL isn't SSL but there is a digital signature that can be used to verify that the binary downloaded matches.
When using these I am trusting that the developer is honest and has not altered the blockchain.  If this developer were to try, invalid data could be injected into the blockchain data file which would then trick my client into verifying transactions that would elsewhere be reject as being invalid.
There is even a slightly older archive of the Blockchain from the Bitcoin Sourceforge distribution site as well:

http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/

I now see others providing binary blockchain data as well.

http://bitcointalk.org/index.php?topic=78925.0
http://pro2host.com/cryptocoin/blockchains

This site doesnt' use SSL nor is it there a digital signature to ensure the download is the same as the one the author hosts.
While these methods aren't generally considered secure, there may be situations where security can be traded off for the convenience.  For instance, if you only will be spending previously received coins and not receiving, there is little risk in using one of these blockchain files.

Short answer: If the client checks the blocks it's fine. Clients won't usually do this this and the lack of certainty about database is risky. What attack is possible will depend on client specifics but attacks most likely exist.
You would either have to trust that person and have a data integrity measure or revalidate the downloaded chain yourself. Do remember that the default client treats already downloaded blocks fairly differently from downloaded blocks.
A "low-tech" solution could be to run the bitcoin client twice, one with and one without the downloaded chain. Set them up to connect to eachother. Now one of the two will download & verify the chain locally. Not the most efficient way but it is as trustable as downloading from the web.
Edit: after a discussion with Pieter Wuille I'm sure I'm not sure about how safe downloaded chains are and removed claims towards safety.

I don't agree entirely: if a popular blockchain download site would hand out a corrupted blockchain, and a significant portion of the network would use these, there is a risk for a split the second on the of the corrupted transactions are split.

I don't quite see what you mean. Do realise that the miners are organised in pools and that these pools will have legitimate chains. These pools' contribution determine the longest chain, not the end-users. After a few confirmations a transaction can be fairly trustworthy, as with all other transactions.

But if 10% of users use the same corrupted download in their nodes, one transaction could seem invalid to them, after which they ignore the real longest chain. If they have some mining power as well (p2pool users, for example), they will create a block chain fork (albeit very slowly, initially.

I see. The client will have to evaluate the scripts but that is default behaviour. So popular a bad chain could easily be spotted, but that's a weak argument. It is fairly stealthy as many transactions could still process normally. This is a fair danger. Checking whether the most-recent mercle hash is the same as one published somewhere should counteract this attack. Checkpoints also kill these bad chains, as they no longer line up. Introduce daily checkpoints?

I see. Shouldn't connecting with random other nodes get you the legitimate blocks as if you're on just-any fork? The blockchain forks a little all the time, that gets resolved very decently. The part after the latest checkpoint must be considered a potential fork, downloaded or not.

Merkle hashes are inside transactions, we are talking about blocks. And all checkpoints do is guarantee that when a particular block is downloaded, its hash is correct, locking that and every part before it in the chain. However, if you download the entire block database in final form, all these checks have already been performed. They are not performed again at startup after download... 0.7.0 will introduce a way to load blocks from a file (while checking them entirely). Without that, downloading a block database should be considered risky.

Interaction with other nodes doesn't help a thing. If your blockchain database is corrupted, you already have the blocks. They will not be downloaded again, as your client doesn't realize that the ones you already have are invalid.

let us continue this discussion in chat

There is a recent archive with raw blockchain data and instructions how to get your bitcoin-qt client running fast at:

https://github.com/dailyblockchain/bc

I've followed the instructions and it worked perfectly. I had my client up and running in under 3h


text:
Is there a list of news articles related to bitcoin?
What articles if any have been in the mainstream media about bitcoin?

Topic should be changed to "Is there a list of news articles related to bitcoin"? A press release is something different. http://en.wikipedia.org/wiki/Press_release

You can find a list of articles about bitcoin here:
http://howmanycoins.com/#shortcodes

@ D.H. - symantics

The most up-to-date list is the Bitcoin press hits thread. However, if you want a shorter list with more quality content, I recommend Press page on wiki.

The most complete list I'm aware of is the Bitcoin press hits thread at bitcointalk.org .  But be aware that there is a lot of content there to sort through. BitCoin has been covered repeatedly in Forbes, Wired, the Wall Street Journal, the Times, etc.

BitcoinTalk has a Press board dedicated to discussing news articles. Each article has its own thread there, which amounts to about 7500 articles by now.
A lot of articles are also linked and discussed on r/bitcoin, although they don't make up the brunt of the topics there.


text:
Extract private keys from Bitcoin Wallet
I have encrypted my bitcoin wallet. I know the passphrase, that's not the issue.
I want to transfer my bitcoins to blockchain.info but it's asking me for the private key. I cannot find it nor can I find how to find it. I have searched around on google; a few sites say that pywallet will extract the private key, but I have used this and all I get is the address I have created.
Where is my private key(s)?

Is it important for you to keep your old addresses? Otherwise it might be simpler to just send the bitcoins to a new address that you generate at blockchain.info.

Welcome to the site! By the way, I'm wondering if it's just coincidence that the three people involved with this question are Danny, D.H., and me (Daniel H.).

@D.H. That is true, and I thought of that, but there are transaction fees, waiting, and lack of anonymity involved with that which aren't involved with simply importing the keys.

Use pywallet to extract the private keys and copy the output to blockchain.info's Import Backup page.
To use pywallet, you open a command prompt/terminal window at the folder where you saved it and type ./pywallet --dumpwallet --password="Whatever your passphrase is". NOTE: this will output everything in plain text, so if you do this on a public computer or with somebody looking over your shoulder, some of your bitcoins may be stolen.

I did that but its saying pywallet.py: error: no such option: --password

I was using a different one to the one you gave its doing something now ill post an update if it works, Thanks

That worked i had to create a bat to dump to a file

So you have everything uploaded now?

I just installed pywallet: In Mountain Lion I get the error "no module names _bsddb" ... Do you have any suggestions?


text:
How should I get all transaction history in a format that I can analyze?
I want to download the entire bitcoin transaction history and store it in a database at my end to perform certain analysis. How do I get from the blk*.dat files to a useful format?

possible duplicate of How can one download the initial Blockchain data files securely?

@HighlyIrregular Edited to not be a straight duplicate.

possible duplicate of How can I read information from the blockchain?

I want the transaction information is some kind of usable format. How do I make sense of this ??

I want which public key(s) sent how much bitcion to which keys at what time for all transactions starting from the inception till now..

@user1754257 Then clarify your question. You've got an edit button for a reason.

I wanted to do a similar thing to put all the transactions in the database (it was PostgreSQL for me, but you can use anything). After some research ended up using bitcoin abe and it worked great for me. Be patient though, it does take a long time - was several days in my case.


text:
Are there time-series of Bitcoins in circulation?
For a study on Bitcoin, I would like to find (or construct) a timeseries of the total value of all Bitcoins in circulation (market capitalization). At least for the last two or so years. This could be quoted in e.g. US Dollar.
Is there such a time series? If not, is there a timeseries with the total amount of unlocked bitcoins, which could then be multiplied with an exchange rate?

Historical time-series of exchange rate:

https://docs.google.com/spreadsheet/ccc?key=0AmcTCtjBoRWUdHJuUE1mUkFxa3A0eHBDQkxZLVVFZmc

Source of the data is the "Raw Data" from BitcoinCharts.com.
The raw data of daily "market cap" is available in json

http://blockchain.info/charts/market-cap?timespan=all
http://blockchain.info/charts/market-cap?timespan=all&format=json <-- Thanks to Ben's comment below.

yes, thank you. it could also be taken from this:
http://blockchain.info/charts/total-bitcoins but I was hoping for an easier way

@BenReeves , thank you that is useful. Any suggestions for importing (e.g. R or CSV), do you want to put that into an answer?

Ha, wish I had knowsn about the &format=json before.  Super!


text:
Did P2SH (BIP 16) get accepted?
Based on this, it seems like it did http://blockchain.info/p2sh but it seems I can't find a definitive answer.

Yes it did, on April 1, 2012.
[removed link to chain of orphaned blocks]

I'm slightly new to this, how does that show anything?

Yes, it did.
BIP: 16
Title: Pay to Script Hash
Author: Gavin Andresen <gavinandresen@gmail.com>
Status: Final
Type: Standards Track
Created: 2012-01-03

(Final is the stage after being accepted - it means that it's done.)
(Source.)


text:
Why can't we set fees to a fixed amount say 0.005 BTC?
The current fee mechanism is confusing and difficult to implement.
The current fee system uses transaction size and the size of the block the transaction is due to appear in to calculate the fee. If you're writing a Bitcoin client such as a web wallet or android app this is not easy to implement.
Is there any reason we couldn't have a well documented fee mechanism along the following lines ?

Fixed fee, or
% of transaction amount, or
% of transaction amount capped or floored.

I was also giving the problem a bit of thought, and here are some conclusions I reached:

It is impossible to set a fixed fee once and for all, as one does not know the volume of transactions that will appear in the future, nor how big an exponent of Bitcoins will be a "common sight" (before Bitcoins became popular, someone paid 10kBTC for a pizza for example). So the fee would need to be adjusted over time, a bit like difficulty.
Percentage of transaction amount would be harming the people owning large amount of Bitcoins in one address, as in order to spend some of their Bitcoins, they need to send the rest back to themselves. This would encourage people to spread their Bitcoins over many addresses, creating an accounting mess at times.
Calculating the fee based on real-world value of 1BTC would be too hard, as it would require a lot of knowledge form outside the network.
Calculating the fee based on current difficulty can be slippery for transactions sent around the difficulty adjustment block.

So in general, the current way of calculating the fee might not be that good, but nobody smart enough has come up with anything better.

Why would spreading your coins over many addresses help if the transaction fee was a flat percentage? EDIT: forget my comment, I see what you're saying: there's less change in a transaction if your coins are spread out.

The current fee schedule exists to defend against spamming the network. The load on the network has nothing to do with the amount transferred and everything to do with the size of the transaction. The likelihood that a transaction is intended as spam rather than legitimate is influenced by the use of recent coins (since an attacker will rapidly use the same coins again and again).
If you enforce a fee which is independent of those, you'll allow attackers to overload the network by broadcasting rapid, huge transactions and having to pay only 0.005 BTC fee each.
The value 0.005 BTC specifically is a lot for legitimate microtransactions.
In the future the way fees work will be completely different, but nobody knows exactly how.

Not saying your statement is wrong, but I don't believe microtransactions are a design goal of Bitcoin.

@jl6: Agree that microtransactions are not as good a match for Bitcoin as it initially seemed, but if there is real Bitcoin adoption, 0.005 BTC could be a lot of money.

@jl6: Depends on how "micro". The transaction fee shouldn't be much more than the amortized cost of a transaction in the network, which I believe is much less than $0.03. I think raw Bitcoin should aspire to enable transfers of below $1 without having to worry about tx fees taking a large chunk.

There are some people who think the potential for microtransactions is one of the core value propositions of bitcoin. The cost of transmitting and storing data is dropping.

@KinnardHockenhull: They're dropping but they still exist. Nanotransactions are more likely to be achieved with https://en.bitcoin.it/wiki/User:Aakselrod/Draft.

Why set a fee, when the market can very well find it?
How do you know 0.005 BTC is "the right amount"? This is important, because it will become the main incentive to mine, when the block reward drops to zero. It's impossible to predict now what the best amount will be ... too low, and not enough miners will mine, opening the network to double spend. Too high, users suffer.
Practically speaking - for the time being, just use a constant 0.005. APIs will be available in the future to determine a recommended TX fee, based on actual statistics.

We could make the cost related to the current difficulty (of generating a new block) but quite frankly this slightly complex system is just fine. It only kicks in on strange or really small transactions and it's not that high.
Not only that but it's only the default with which the standard Bitcoin client now works. If you think a much lower fee would also suffice, why don't you starting mining including everything with that fee?
There's a clear difference between a profit driven fee and an anti-spam measure. I think this is still solidly in the latter category.

Why can't fees be calculated based on current network activity, so that people wanting cheaper fees will send money at quieter times? This will mean a more even volume of transactions which will enable fewer miners and so increasing their revenue?
I don't know about block size is this the same thing, I still don't totally understand the mechanics of it but it would seem logical to reduce waste in the network, so zero fee payers might only get there transactions processed at quieter times.

Related Is the current network difficulty algorithm appropriate for “Peak transaction-only mining”?

Ideally, there won't be a quieter time. Financial transactions are a 24/7 thing. There might be a perceived "quiet time" right now because most of the Bitcoin community is based in Europe and North America. That will go away when Bitcoin catches on more strongly in Asia.

The major scaling pain of bitcoin is diskspace and the time it takes for a client to bootstrap into the network. For both of those, it doesn't really matter when a transaction is made.

Miners can choose any fee schedule they want. However, a fixed fee has proven problematic on scamcoin chains like Solidcoin, when people create huge (data-size) transactions.


text:
Does using deterministic wallets reduce our anonymity?
Is it possible to figure out that certain addresses belong to the same wallet? Say I have 2 or 3 addresses that I know were created by a deterministic wallet like Armory. Is there a way to find all the other addresses that have been used by that wallet? I mean by that instance of a wallet, not all the addresses created by the Armory software.

It is hard, if not impossible, to do so when you only have the addresses. Most clients that support multiple deterministic addresses for a wallet, make sure it is impossible to know that two or more addresses are linked together. They usually use a random value as the starting seed and another random value to chain consequent new addresses.
Also keep in mind that they chain the addresses by generating new private keys. These private keys are generated through their algorithm (and are already hard to link together), but normally no one will come to know the private keys of the addresses you use. So it is already hard to link private keys together, but it is even harder to link addresses resulting from the public keys together. So it's good to assume it's impossible.
But, there is more than the addresses alone. There also are transactions. Most wallets generate a new address from a sequence whenever change is generated. This way, people could f.e. track all the transactions coming from one of your addresses and be able to follow the chain of addresses from your wallet.
To do so, they must be able to distinguish between transaction output and change, which is not trivial. This is not easy, especially when you have multiple transaction outputs. Also, once they make one mistake, they lose their track.
But this method is not as hard to exploit as using the addresses. However, the vulnerability of this method has nothing to do with the fact that you use a deterministic wallet. People will also be able to do this if you would generate completely random addresses for every change output.


text:
I traded XRP for BTC. How do I withdraw my bitcoins from ripple.com?
I traded XRP for BTC. How do I withdraw my bitcoins from ripple.com? I guess I need to withdraw to bitstamp.net somehow?

See https://ripple.com, https://ripple.com/wiki, and/or https://ripple.com/forum . You probably have BTC via Bitstamp, if so see https://bitstamp.net/account/deposit/ripple

If you traded on the Bitstamp/BTC exchange, then log into your Bitstamp account (create one if you don't have one), select 'Deposit' and then select 'Ripple'. Follow the instructions.

Ripple can't hold Bitcoin natively. Instead, you have an IOU from somebody saying that they owe you 3 BTC. Now, you can go to the person who issued that IOU, and ask for those bitcoins in exchange for cancelling the IOU. If you don't like the terms that they give you for the IOU (example: they only deal in amounts larger than 5 BTC), then you can trade that IOU for one from a different gateway.
To figure out what IOU's you hold, look at the trust tab of your client.

As David Schwartz notice, it can be done via Bitstamp.
Today, Bitstamp require an authentication.

Means:

TO VERIFY YOUR ACCOUNT PLEASE SUBMIT
1.) a valid government issued ID,
  acceptable high quality images of documents are: international
  passport (double page) national ID card (both sides) driver's license
  (both sides)
2.) a proof of residency, acceptable scanned images of paper documents are: bank statement utility bill for utilities consumed at your home
  address tax return, council tax certificate of residency issued by a
  government or a local government authority You can also submit other
  documents to serve as proof of residency such as; government-issued
  documents, judicial authority-issued documents, documents issued by a
  public agency / authority, utility service company, or similar
  regulated service providing companies.

The great news, that you can withdraw bitcoins directly from ripple.com client.
Read this,
https://ripple.com/blog/bitcoin-bridge-lets-ripple-users-make-payments-to-bitcoin-accounts/

If you push "Send XRP" button, it magically convert xrp to btc and send coins to you.


text:
Stuck on blockchain 8791 - Synchronizing
I don't know what's wrong with it, but I would really appreciate it if someone can help me. I've already been receiving money from this address so I really don't want to delete it. I have 3 BTC coming in.

Do you have any connections to other peers?  You can see that by mousing over the bars at the bottom-right corner.

You should backup and secure/encrypt your wallet before messing with anything. If you have a second computer, I'd recommend getting the software working there and ensure that your wallet works on that computer.
If you're running an older version of Bitcoin-Qt, upgrade to 0.8.1 or later.
Check out this other question after that.


text:
Why does it take 15 minutes for my Bitcoin client to start?
I use Ubuntu 11.10 and have recently installed the standard Bitcoin client 0.40. But the GUI only appear around 15 minutes after started. My machine is an AMD64 Athlon 4600x2 with 6GB RAM. Is this normal? (I don't think so) Any idea?

This also happened to me, but I never really looked into it. Although 15 minutes seems a little too much. My GUI appeared after 5 minutes or so. I was using Ubuntu 10.10 at the time and the client version 0.4.

I think 5 minutes stills so much.

What command-line options are you passing? If, for example, you pass '-rescan', this is not unusual.

David, unfortanelly, I don't have yet a near half-quarter of the linux knowledge that you have, so to find the launcher of the gui to me stills hard complicated. I apologize for this, but all I did was adding the bitcoin client to the startup aplications. I started early just double-clicking the icon, bitcoin or bitcoind.  Because of the 15 minutes delay to show GUI, I even don't know yet where this 2 programs differ. Sorry for some bad english too. =) Well, I think no command-line options here.

I can't be sure why your client specifically took 15 minutes to start. But I have benchmarked the client's startup process. Most of the time is spent validating the database to ensure the client has a sensible view of the hash chain.
It is "fast verified" up to the most recent checkpoint and then "slow verified" to the current block. Fast verification entails checking only that the header is valid. Slow verification is a much more complete verification that can only be done at about 20 blocks per second on hardware like yours. (Upgrading the client will help, since newer version of the client will have more recent checkpoints.)
If you passed the -rescan option, the client will check every transaction in every block to see if it relates to any account in your wallet. That will add some time to the client's startup time.
When you run the Bitcoin client for the very first time, it will take several hours to sync up to the network. The downside of a decentralized system is that you cannot trust anything and must check everything yourself. This literally requires you to fully verify every Bitcoin transaction that has ever taken place. I've seen that take 9 hours on Pentium 4 class computers with 100Mbps Internet connections. (Though I think it should be a bit faster now, thanks to bugfixes in the client.)

Is there any flag that shows a verbose output of what the client is doing?

You can check the 'debug.log' file. On Ubuntu tail -f ~/.bitcoin/debug.log should show it to you.

Maybe you are mining?
From my experience, when I run the miner before bitcoin,
bitcoin will block at "Loading address..." or "Loading block index..." for a long time.
You can see it in debug.log.
Stop the miner and bitcoin will start soon. Then you can run the miner again.

No mining here, as far as I know.  Thanks. I ll check my debug.log file and post it here soon.

I've been evaluating some bitcoin clients and my nastiest one; bitcoin-qt on a ten year old single-core 32-bit intel with 512MB RAM has been struggling all week and it has still only got to 22GB of 34GB of the blockchain loaded.
This morning after it crashed, the next restart required "rescan" which took an hour before it could resume downloading the full blockchain.
I've had much better luck with Electrum (bitcoin wallet application; without the whole blockchain) which works fine on both the 512MB singlecore and on the 1024MB quadcore raspberryPi.  That starts up in 1 to 2 minutes.

Please read up on how this site works. In short: Questions and Answers. You replied to an 4 year old question but it's not a reply to the question at all. Slowness on an ancient 32bit PC with insufficient memory is not surprising at all. Also, comparing it to Electrum is apples to oranges.

This question was about starting the client,  your answer is about  synchronization. There certainly would be a question somewhere along the lines of "how long does synchro take" that would be a better match.


text:
Backing up bitcoins on Mt.Gox
I have some bitcoins on Mt.Gox. Against the possibility that a nuclear holocaust or some sort of hanky-panky or the like were to wipe out Mt.Gox tomorrow morning, how should I back those up?

Mt. Gox operates a hosted (shared) EWallet.   They claim to have cold storage and perform other backup practices, but there is nothing that you as a Mt. Gox accountholder can do to "back up" those funds.  And if there is a problem restricting you from accessing your Mt. Gox account, there is nothing you can do to recover those funds.
If you have your own wallet, perhaps running the Bitcoin.org client, you then do have the ability (and responsibility) to back it up.

You're saying as long as they're on mtgox, that can't be backed up except by mtgox?  How would I back them up if I move them to somewhere other than mtgox?  I don't trust my home computer, and if I get storage elsewhere, it would be only as secure as the companies that own the servers, so it seems as if I should use several independent locations.  Are there some considered the best for the purpose?

You'd better use blockchain.info's wallet, which backups it automatically via email.

Don't trust MtGox or any exchange to store your BTC.  Any BTC on an exchange is at risk of being lost, stolen, or made inaccessible.
So keep your BTC stash in your own cold storage.  To do this create a wallet using blockchain.info (or equivalent), create your own BTC deposit addresses and move your BTC from MtGox to your addresses.  Now if you keep the associated private keys for your addresses offline, this is what's known as "cold storage".  Note that it's actually "warm storage" since your BTC still exist on the blockchain; there is no such thing as real cold storage for BTC.  Now you can (and should) back up your private keys.
Your BTC addresses can be added to your wallet as "watch only" addresses (the private key is not required).  This way your wallet will be able to display your BTC balance but your BTC is still safe.
To spend your cold stored BTC, import one or more of your BTC addresses into your wallet by providing your private key.  The BTC address(es) that you import are at risk, so do not re-use them.


text:
View bitcoins per address in MultiBit
I have a wallet with 100 addresses in MultiBit. From what I've gathered, bitcoins are linked to a specific address. Is there a way to see in MultiBit how much of my balance belongs to each address?

My suggestion would be to choose 1 address out of them.... send ALL your bitcoins to your own address and this would organize it for you. Now query blockchain and that one address should have all the worth of bitcoins which should be equal to the figure being shown by multibit.


text:
Blockchain.info Receive Payments API problem
I am building a little online app to accept bitcoin payments in my website. I have a blockchain.info wallet and I am following their Receive Payments Api, which can be visited here: http://blockchain.info/api/api_receive
The monetary part works great, but the HTTP Callback Notification does not take place and my online store is not notified of the payment. However, the TEST callback does work.
I think it is a problem on his application.

Has anyone implemented the "Receive Money API" successfully?
Is there any other alternative for received instant payment notifications?
(To several different addresses)

A friend of mine reports the same issue. We need a little help :)
Thanks!

Hi Ben :-) I am generating addresses with the anonymous flag to false. The "fire test callback" works great, but when I actually send bitcoins, the http notification is not sent. Any ideas?

So, if I send bitcoins to the forward address, the payment is sent to my real address successfully. But the notification is not set :-(

Hi Ben. Could you please help me out? I would really appreciate since I can't go beyond the documentation. Test callback works ok, bitcoins are forwarded to the real addres but the notification is not sent from your Java App. I am sure about this because I am logging all queries and have access to the apache2 access logs.

Perhaps you have a list of blacklisted servers?

It is working now! Issue closed. Great service provided by BlockChain.

Well, can you tell us what was the problem and how did you solve it?

After I reported the issue via email/this post, Blockchain.info solved it and now everything works fine.

Hi John. You have to set up a forward address in the "Developers" -> "Receive Payments API" section of Blochkchain.info. By doing that, you provide them with an URL to be called every time a payment is received. Data arrives via $_GET.

Or examining any given address with the Block Explorer API. This is much easier if you can set up a cron job.

Hi. Just use this: https://blockchain.info/api/blockchain_api. Send an http request to the single address URI and parse the JSON your application receives.


text:
Why was Bitcoin designed with a decreasing production rate?
I have no doubt that the person who designed Bitcoin was many times smarter than me but with the benefit of hindsight was the decreasing number of bitcoins a good design decision given the 'hoarding' it encourages? Wouldn't a steady and low inflation rate increase the incentive to spend bitcoins and make it more attractive to the later adopters?

Please note that a constant production rate measured in a fixed number of coins would result in a deflationary system very much like bitcoin because the relative number of coins per block gets less (asymptotic curve). The difference of such a system would only be a psychological one. So a system with a fixed PERCENTAGE of production would be necessary to achieve what you have in mind (e.g. 3% per year).

The main issue with Bitcoin is not attracting late developers, but early developers. At its infancy, Bitcoin was an interesting curiosity - people would play around with it but not necessarily use it as money. But due to its scarcity and many benefits, Bitcoin came to be recognised as a digital currency.
At that point people could either wait and see if it gets bigger, or start using it. If Bitcoin's reward wasn't decreasing, probably a lot of people would put off getting into Bitcoin until it is more stable. If everyone decided to wait, Bitcoin would be going nowhere and fade into obscurity. Nobody would then care for late adopter's benefit. This is why getting early adopters on is so crucial - with them comes incentive for late adopters anyway.

I understand the rationale and it seems to have been an effective way to gain traction. Given the amount of wealth not being utilised http://arstechnica.com/tech-policy/2012/10/78-percent-of-bitcoin-currency-stashed-under-digital-mattress-study-finds/ it unfortunately now looks to be a hindrance. Could you explain more why you think gearing a system to early adopters will encourage late adopters though?

"Hoarding" is a loaded term used to denigrate saving by people who like having the government give money to bankers. To "hoard" money, what do you do? You produce something, you trade it for money, and ... well, that's it. So "hoarding" is actually just producing.
The idea that hoarding is bad is just a broken window fallacy. Hoarding means producing without consuming, giving without taking.

But at times it could be good for a country to make its own currency that can go down in value to increase export and get more tourists. To get people to use such a FIAT people in that region must pay tax in that currency.

Good for some people in that country, bad for others. Those that it is bad for will only go along with such a scheme if they have no practical choice. In other words, this is one way a government picks winners and losers and makes markets less free.
As for increasing exports, that's another fallacy. Imports are what you get from other countries. Exports are what pays for it. If you raise your exports relative to your imports, you are paying more to other countries and getting less. That's not good.

It's an interesting point but I consider hoarding to be a symptom of people being effective at making money  but less willing to spend it. If I have a system that allows me to accumulate 90% of the wealth in the world and spend only what I need to survive, although I produced, I'm also stopping the free flow of money through the system. Others can't use it so I'm hoarding. Looking at the distribution of wealth in bitcoin, this is currently the situation.

@fj2942ks: Others can't use the currency. But they are absolutely free to use the real wealth that you produced. If you're going to let the world trade you pieces of paper for trucks and factories, the world should be thrilled. You can hoard all the pieces of paper or strings of digits you want. We'll all profit from driving the trucks you made and using the fruits of your labor.

Bitcoin is deflationary, in modern "economy" it is deemed to be bad.
The modern economist argument is that we will be hoarding, instead of spending. Because we know that tomorrow the things will cost less.
This is modern myth(=mistake), because:

We always need to buy important things (food, transport fees, clothing), no matter what the price will be tommorow.
Inflationary economy force us to buy useless goods. We are promoting low quality products, while those that are important for human beings are getting less capital.
For sustainable economy we need to have a production of real goods. When majority of people are buying goods while creating debt. It may seem that GDP grows. But the truth is rather that the consumption is growing, not production.

Wouldn't a steady and low inflation rate increase the incentive to spend BitCoins and make it more attractive to the later adopters?
The answer would be almost the same as the previous one. You are speaking about attractivity.
In our world, there are payment systems that are inflationary.

They can promote economy (By QE = printing money), when there is recession.
When there is boom, they must draw money back.

It is not happening in most cases. We may say, that it is caused by people in power. Actualy it is mostly the problem of system and its incentives. I recommend this video. The biggest problem is that it always ends and ended with hyperinflation.
It is everybody choice: Convenience vs. Sustainability.
If you choose Bitcoin, you will use a system that gives right incentive. It may even lead into convenience.

The amount of money I 'need' to spend and the amount of money I 'choose' to spend will be very different if by doing nothing I increase my relative wealth.

With every purchase at retail with a Visa/Mastercard/etc. payment card, somewhere in the range of 3% goes to the banking system in the form of fees.
With Bitcoin, the fees are tiny fraction of that.
If the merchant will accept payment in bitcoin, then there is room to offer a discount for customers paying with bitcoins at no cost to the merchant.
So as a consumer, let's say you are given the option for your $100 purchase:
$100 if paying with Visa/Mastercard
$98 worth of bitcoins (at current market rate) if paying with bitcoins.
If you hoard, do you know that you can make more than 2% by holding your coins?  Or is it beneficial to take the 2% discount today (and then through a bank transfer buy more bitcoins to replenish what was just spent)?
So the argument fails because there is greater value in using bitcoins in commerce than comes from the potential future increase in the exchange rate.

This is true but to move money in and out of bitcoin costs > 3% for most people.

Had Bitcoin be designed inflationary the first clone would have been a deflationary one. Given the choice most people would then have moved to the deflationary one for savings (keep or increase value). Thus an inflationary coin does not stand a chance.

Bitcoin was designed to have potential to increase in value a lot over the long term. If not, noone would want to take the risc of adopting it, caring about it or developing tools for it.
This gives it potential stability.
When people hoard it means that they have a longterm look at the value of Bitcoin.
If noone was hoarding it would mean that everyone wanted to get rid of their Bitcoins as quick as possible.
And if everyone wanted to get rid of their Bitcoins, that would mean they would not want them.
Now you can be sure that people will want your Bitcoins in the future.
When people say hoarding is bad, they look at Bitcoin as if it was to replace a FIAT currency. Bitcoin is not a FIAT and must not replace any other currency, thus does not need to drive a countrys economy.
A currency that allways goes down in value such as FIAT must be forced upon people with laws. Noone would want money that goes down in value if they had a choice between money that keeps it value or goes up and money that decrease.
But at times it could be good for a country to make its own currency that can go down in value to increase export and get more tourists.
To get people to use such a FIAT people in that region must pay tax in that currency.
But that currency will only be used by those that need to pay tax with it so its of no interest for example a African person or someone in india.
However a currency such as Bitcoin that can hold and will probably increase 100 fold in value is of interest to everyone on earth.
It is also in the best interest of everyone to deal in a currency that noone, not a single country can print as much of as they like. Thus Bitcoin does not give away the power to another country since there is noone who can decide to print more of it.
Thus its a excellent tool for trading across the borders, such as on the internet, something which another countrys FIAT money is not.


text:
Can I run p2pool with a thin bitcoin client?
Everytime I restart my mining machine due to heat, I have to wait the following sequence to mine at p2pool:
bitcoind -> download blockchain & rescan -> p2pool -> download shares -> start mining

It took me about 10~20 minutes.
Can I substitute bitcoind with thin client (without having to download blockchain)?
*PS1. I know I can connect a remote bitcoind, but I am thinking the possibility of a thin client on a local machine.
PS2. Mining at public p2pool node is out of consideration.

You might consider Eligius, which offers decentralized mining without the requirement of a local bitcoind (you only need it if you want to do extra verification yourself). http://eligius.st

No. P2Pool, unlike a normal pool, requires you to verify incoming transactions, and you can't do this without having all of the unspent transactions in the block chain.


text:
The context of FBI involvement with Bitcoin
A number of articles appeared recently linking to a leaked document about Bitcoin written by the FBI.

Bitcoin Virtual Currency: Unique Features Present Distinct Challenges for Deterring Illicit Activity

What involvement or interest has the FBI had with other alternative currencies, such as Liberty Reserve, Dwolla, e-gold, etc?
This question should help provide some context to compare with the interest they've shown in Bitcoin.

Wow, nice find. Guess I'll have to look into using some FBI documents as a reference in my thesis;)...

There was quite a hype in the US about how bad Bitcoin is, and how they were going to crack down on it. I suppose this report comes from those feelings. Liberty Reserve has actually been closed recently, by the police forces.
Their interest is chiefly identifying and, if possible, removing threats. The EU actually has a similar (but better) report, to assert the status of digital alternative currencies.
The red thread to all of these documents is "Bitcoin is independent of law. Bitcoin cannot be legally prosecuted, and if it could it would be difficult to do it. Anonymity makes it suitable for criminals but it isn't fully anonymous, so maybe we can do something (because of the blockchain). Personally we think Bitcoin is pretty cool.". They also somewhere seem to understand there is a legitimate purpose to Bitcoin, but it's unclear whether that matters or not.
It's very hard to look into the mind of a millions of people wide security organization. If we don't know something it probably exist but it's still classified. This document had only public sources, so did not need classified status. They likely have build a much more detailed document now with knowledge from the NSA (about cryptography) and from Bitcoin companies in the US.
The NSA, meanwhile, has likely been tracking Bitcoin usage very closely. It likely has a pretty good way to de-anonymize Bitcoin traffic. All the aforementioned are, of course, as unprovable as PRISM was.
Most police forces in the world will have reports or accumulated knowledge about Bitcoin because it presents "a novel challenge to law enforcement". These reports will contain "nothing we didn't already know" and reflect the legal perspective of the agency, but only the mood the report writer thought his boss wants.
Good luck people. The police are our friends. Sometimes in the "Do not run, we are your friends" kind of way, sometimes as the robot friend.


text:
How do I mine with FPGAs?
I'm not entirely sure how FPGA's work...
Do I simply buy a ZTEX and it mines, or do I need to plug it into a computer via USB?
Can I chain them?
I'm so confused.

The very basic idea of an FPGA is that it can be loaded with a specific firmware (a layout of logical gates, in essence). That page contains the firmware you'd need to load onto a Xilinx FPGA (A Spartan 6) in order to use it as a mining device. ZTEX refers to a suite of the FPGA, and various IO controllers (USB, etc.).
Roughly speaking, the steps you'd need to follow would be:

Buy device
Plug in device to your computer
Load firmware onto device from your computer
Run a piece of software on your computer that interfaces with the firmware now loaded on the FPGA
Profit (in a couple years)

To answer your questions: yes, the device would need to be plugged in to a computer using the method in your link, and yes, you can "chain" them - i.e. have more than one plugged in. I've greatly oversimplified steps 3 & 4, by the way.

Oversimplified is such a great description - I'm using Modular Python Bitcoin Miner with a Mining_proxy software program.  IT works...but I'd like to discover how KNCminer converted their FPGAs to clock around a gigahash each and not ncecessarily 400 Mh

Which FPGA would you use for mining?

FPGA mining for bitcoin was never popular, and has not been economically viable since around the time this was written (2012). Hypothetically you'd want something recent (e.g. Stratix 10).


text:
Why are some transactions larger (in bytes) than others?
There's this transaction: http://blockchain.info/tx/2588df59035129de0f0cb20d2cb5d77d18830043aa68ad2a1a2df7d727bc7a62 that is 802 bytes but for only 1.4BTC
Another transaction: http://blockchain.info/tx-index/14803514/781333d877bae2b4d8fc7ff856b38989013f0a11668395b8f90b423dd2ffc230 is for 50.4BTC by only 118 bytes.
So what exactly goes into a transaction that would increase / decrease the size of the transaction?

I give a formula that you can use to calculate the size of a transaction given the number of inputs and outputs here.
The most significant factor contributing to the size of a transaction is the number of inputs to transaction has.  Each input contributes 179 to 181 bytes to the size, and each output contributes 34 bytes to the size.
Your large transaction has 4 inputs - that's why it's bigger than the other transaction, which has none.
The actual number of bitcoins spent by a transaction is completely irrelevant, except that there may be a tendency for transactions which spend more coins to require more inputs to make up the amount.

If you click the link "Show scripts & coinbase", you'll see the inputs and outputs for the transaction.
The 802 byte transaction had 4 inputs and 2 outputs (1.4BTC and some change, probably). The 118 byte transaction is a mined block and just has a single output.


text:
What are the implications of BIP 12 vs BIP 16 and OP_CODEHASHCHECK?
There is a discussion about two different Bitcoin Improvement Proposals - BIP 12 and BIP 16, and probably only one of them is going to be included in Bitcoin 0.6 (miners will decided which by a majority vote of mining power). LukeJr proposed an alternative to BIP 16 called OP_CODEHASHCHECK.
Can anyone summarize the core differences between the three proposals, and their respective advantages / disadvantages?

Why the "TL;DR" in the question title?

@D.H. - well, I originally put it there because the answers I seek might be contained in the long discussion I linked to ... but you're right, the question is legit without this prefix.

BIP 12 creates a new Script opcode which allows scripts to execute more script stored in a string (like eval functions in other languages). There's not much debate about BIP 12: it will not be used. It's very complicated, it allows some looping (which Script should not support), and it makes it difficult to analyze scripts without executing them.
With BIP 16, scripts are allowed to execute scripts stored in a string one time (not recursively), and there are also other restrictions that eliminate all of the BIP 12 drawbacks mentioned above.
CODEHASHCHECK does the same thing as BIP 16, but some technical differences make it arguably more elegant.
All of these proposals are designed to solve the problem of how to allow recipients to choose which restrictions to place on coins they receive at an address (two-factor authentication, etc.). Currently senders always define the restrictions on sent coins, which is inconvenient in many cases.

Thanks. I updated my question to be about the comparison between all three proposals. Can you please elaborate on the technical differences between BIP 16 and CODEHASHCHECK?

With BIP 16, scripts that match a certain template (OP_HASH160 hash OP_EQUAL) have additional checks applied to them even though these additional checks are not specified explicitly in the script. BIP 16 creates no new opcodes. CODEHASHCHECK does create a new opcode to do the checking. BIP 16 would be the only case of "template-based" behavior in Script, so I think that CODEHASHCHECK is more consistent with the rest of Script and should be preferred.

So ... is the difference between them merely a matter of style? Is there a functional difference? Could you explain it as if I were a ten year old? (Or just someone without much knowledge in the core Bitcoin protocol), perhaps with an example of why this matters?

For me it's mostly a matter of style. CHC does not use ugly scripts-within-strings or template-matching. BIP 16 has lower data size and a simpler implementation, but it's clearly a hack. This will define a protocol which may last years, so style counts. (I don't care that much, though -- either would be acceptable.)

I strongly disagree that CHC is more elegant. It adds an opcode that behaves differently based on whether or not the opcode appears in the scriptSig or the scriptPubKey.

The biggest drawback of OP_EVAL (BIP 12) was making the scripting system used for transactions turing complete, thus blowing any attempt at static analysis out of the water.
This was regarded as a very serious issue and BIP12 has been pretty much shot and buried.
P2SH (BIP 16) is intended as another approach to the same problem of introducing multiple-key authorized transactions at protocol level. It is specifically designed (as the original scripting system was) not to be turing complete.
There was a lively discussion between the core developers and Luke-Jr who proposed using his own solution, OP_CODEHASHCHECK, instead of P2SH.
Read the post for more detail.

Thanks for the info. I updated my question to include OP_CODEHASHCHECK in the comparison as well - what I'd really like to know is what is the big difference between OP_CODEHASHCHECK and BIP 16. I might go and read the post, but until I do (and for those who don't), it would be good to summarize the core difference here.

There are three BIPs which all aim to provide the push-to-script-hash (P2SH) feature:
BIP 12 (OP_EVAL): A new opcode takes a value off the stack (from anywhere) and executes it as if it were part of the Script itself.Disadvantages: This makes Bitcoin Scripting turing-complete (it enables loops), and not statically analyzable.Advantages: You can do things that require a turing-complete language in Scripts.
BIP 16: When a magic Script template is seen, after the Script is done executing clients must then execute the top stack item also.Disadvantages: Requires special-casing a Script template and behaving differently than simply executing it as a Script. Cannot be used in combination with the current Bitcoin Script protocol, yet does not deprecate it.Advantages: Retains the current mostly-staticly-analyzable status of Scripts.
BIP 17 (OP_CHECKHASHVERIFY): A new opcode hashes the Script that has already been executed, and simply compares it to the top stack item.Disadvantages: Cannot be used to evaluate code in any capacity.Advantages: Statically analyzable using the same exact method as right now, and only requires a trivial opcode addition without restructuring the entire Script protocol.
Also note, that BIP 17 does not preclude BIP 12 or 16 from being implemented in the future, should some other need for their more complicated capabilities arise.


text:
Can I remove the passphrase from my Bitcoin Wallet?
I'm using the standard Mac Bitcoin client and I added a passphrase. I'd like to remove that passphrase. Is that possible?

I don't know if the client allows you to do it without tricks, but in the worst case scenario you can still send all your coins to another address, create a new wallet, and send them back into this new one.

The Bitcoin.org client does not yet have the feature to remove encryption from a wallet.  You can use a single space as the encryption key but there no way to get it to no longer use encryption.
That is expected to be implemented in a future release.
In the meantime, those that want this will create a new wallet and leave it unencrypted, and send their coins from the encrypted wallet to it.

how to transfer keys from one wallet to another without transferring funds with a FEE ?

Set fee to zero and wait or import/export the keys.

You can dump your old wallet to a backup file, restart the program to generate a new wallet and import your old wallet into it.
Assuming you are in the directory where your wallet file is located, using the command line that would look like this:
bitcoind walletpassphrase "xxx" 60
bitcoind dumpwallet "wallet.dat.backup"
bitcoind stop
mv wallet.dat wallet.dat.old
bitcoind -daemon
bitcoind importwallet wallet.dat.backup

I would be interested in a less dirty way, if anybody knows one.

Yes. It is possible.
Either the UI supports it or it does not. You are better equipped to find out than I am but I suspect it does not (yet).
If it does not you can either:

Export the keys, move the wallet files (rather than deleting it, so you can move it back if things to wrong, on Mac the wallet files are here: ~/Library/Application Support/Bitcoin/), import the keys.
implement it yourself / pay someone to implement if for you
find an alternative client to do it for you (Armory might have it, a list is here)
find an alternative client to open it and export the private keys, so you can import them into a new unencrypted wallet.
when all else fails: transact your Bitcoin towards a new unencrypted wallet and ditch the old, encrypted, wallet. Be sure to tell people you've migrated, your old addresses are still in your encrypted wallet.

pay someone to implement it for you * use the standard client to export your keys, make a new wallet, and import the keys

I guess that's almost mentioned in the third bullet, and is the most obvious answer. I'll correct. Maybe I didn't really understand the question last time?

If you are wallet.dat file was encrypted with passphrase, then you may try with pywallet, hashcat and btcrecover. This may help you to find the passphrase. But, Atleast you should know two or three letter of passphrase and how many digit it was.
If you tried and getting no success or Perhaps, If you don't know the password, then watch this video. It may helpful to you. It will open wallet.dat without passphrase.

https://youtu.be/C_yNMPnnqS0?si=_6M1Sgfv6gyONcrL

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


text:
Is there a blockchain.info for testnet?
I'm trying to test to see if transactions went through or not and blockchain.info is super helpful for this on the real network.

I’ve collected all of the below answers in the linked Community Wiki.

Yes, blockchain.info has its own testnet service: https://testnet.blockchain.info/

Awesome. That works really well!

but https://testnet.blockchain.info/pushtx seems to just redirect to https://www.blockchain.com/btc/pushtx -- which doesn't look like testnet to me

2022 update - testnet.blockchain.info does not seem to be working - does anyone have an updated url for this service from blockchain.info or do I have to find another provider?

www.blocktrail.com/tBTC now supports testnet too and has an API for it too (including wallet API)

It doesn't work anymore at least as of August 2023.

Blockcypher supports testnet3 and has their own testnet.

TestNet Bitcoin Block Explorer appears to be not working too well at the moment. However, BTCLook does appear to be supporting TestNet and looks like a good alternative.

Your could also use Biteasy.com Testnet Block Explorer which is pretty fast and also includes a REST API.

Apparently it's no longer up.

Blockr.io now also supports Bitcoin TESTNET

Dead as of 4 September 2017: https://twitter.com/blockr_io

I might be a little late to the game here, but blockchain.info do offer testnet resources for SegWit2x. Go to https://testnet5.blockchain.info and you'll see an identical site to the original, but with testnet coins.

This is actually very helpful to me! Thanks, I didn't know that

Oh, it's actually bitcoin2x testnet, not bitcoin core testnet. That's very confusing actually. Please note it in the answer

Oh sorry, I didn't notice that! I haven't got around using it yet so I didn't know.

This not working now.

the hostname does not resolve.  I tried also just 'testnet' but it just redirects to the mainnet page :(

You can use mine, for now it's on a best effort basis
  host: 'rcorbish.ydns.eu',
  port: 18332,
  user: 'bitcoinrpc',
  pass: 'password'

A bitcoin daemon isn't exactly a replacement for blockchain.info. For one, it doesn't have a user interface that a non-technical person can easily use.

No, was trying to help. If this helps: https://tbtc.blockr.io/

Bitpay's insight project supports and has a live version of the testnet.

Coinprism.info has a testnet blockchain explorer. It does colored coins as well.
Note that the SSL certificate is self signed.

The testnet block explorer and API for blockchain.info doesn't appear to be working at the time of writing (July 2021). It may get fixed but in the meantime or perhaps regardless blockstream.info can be used instead.

still works as of this writing.  thanks.

Yes. Blockchain.info has its own testnet service, Check this link https://testnet.blockchain.info/

dead.
As of this writing, this works:
https://blockstream.info/testnet/


text:
Can a scriptPubKey have multiple addresses?
When working directly with bitcoind, I can getRawTransaction for any transaction in the network. The vout has multiple outgoing addresses usually which contain a scriptPubKey. The scriptPubKey has a field called addresses, which is an array. I've only seen transactions with one address in this field. Is it possible to have more, if so, what does that mean?

Any of the addresses in that array can spend that output. Multisig transactions will give you multiple addresses there.

So, if it's a 1 of 3 raw multisig, then it will list all three addresses? And if it's a 2 of 3, then it will list no addresses because no single address can spend the UTXO?

Nope, I just found this transaction, which disproves my theory. If it's an n of m raw multisig output script, all m addresses are given in the scriptPubKey array.


text:
Colluding miners attack: Is the Bitcoin protocol compromised?
A very interesting academic paper has been recently published by two researches from the Cornell University (abstract, full PDF):

Abstract
The Bitcoin cryptocurrency records its transactions in a public log
  called the blockchain. Its security rests critically on the
  distributed protocol that maintains the blockchain, run by
  participants called miners.  Conventional wisdom asserts that the
  protocol is incentive-compatible and secure against colluding minority
  groups, i.e., it incentivizes miners to follow the protocol as
  prescribed.
We show that the Bitcoin protocol is not incentive-compatible. We
  present an attack with which colluding miners obtain a revenue larger
  than their fair share.  This attack can have significant consequences
  for Bitcoin: Rational miners will prefer to join the selfish miners,
  and the colluding group will increase in size until it becomes a
  majority. At this point, the Bitcoin system ceases to be a
  decentralized currency.
Selfish mining is feasible for any group size of colluding miners. We
  propose a practical modification to the Bitcoin protocol that protects
  against selfish mining pools that command less than 1/4 of the
  resources.  This threshold is lower than the wrongly assumed 1/2
  bound, but better than the current reality where a group of any size
  can compromise the system.

The article suggests that miners who group together can earn more than their fair share, which means rational miners will eventually group together into a pool whose size is larger than half the network's computation power and control the currency. The method was termed "selfish mining" by the media.
This seems to be the first serious cryptographic exploit of the Bitcoin protocol.
Do you think this poses a real threat to the stability of the currency?

I hope to read the paper at lunch. Are mining pools decentralized? Not the mining, but the job scheduling. If not, the upstanding citizens of BTC could DDoS any pool approaching that size. Hell, it could be built into mining clients such that anyone who opts in would attack pools of certain sizes. It's not the best solution, and likely wouldn't stop a large company from taking over the network, but it could certainly make it economically infeasible for individuals or small companies from taking over.

The report is not heavily disputed.
In the hours following the paper's release, several developers are discussing solutions:

http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03128.html

and

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

There has not been any evidence that such an attack is imminent or likely even.  And remember, even an attacker with 51% cannot do much.  One risk is that a transaction could be canceled after it has confirmations, if the selfish pool is that much further ahead.

The paper mentions some fairly easy approaches to reducing the incentive to engage in selfish mining. Even without these fixes, selfish miners who get greedy would be hurting their own profits if they drive people away from bitcoin.

http://en.wikipedia.org/wiki/Hippocratic_Oath  First, do no harm.   Those "easy approaches" may instead make the problem worse.   Further analysis and ideas needed.

The interesting thing about that paper is that, if I understood correctly, it doesn't require pools to collude in order to attempt the "selfish miner" strategy - any pool with more than 25% of the total hash power could do it solo - right now there are pools which could do it.
And with just slightly more than 33% of total hash power, they could make their attack unstoppable, earning much more coins than their fair share - thus providing a strong incentive for people to abandon their pools to join the fest. And even without reaching the magical 51% number, just with more than 33% they could eventually run the network, deciding which transactions they like or not.
Their logic seems pretty compelling though I admit I wasn't able to understand everything - which means the real threshold for Bitcoin's network security, as-is right now, is actually 33% rather than 51%. Which in turn means there ought to be a big emigration of people out of the biggest pools to the small ones, for the benefit of the whole network.
Will be interesting to see what the main devs do to address this...


text:
What is BlitCoin?
I saw BlitCoin mentioned on this forum thread, but didn't understand what it was.
Can someone explain what does it do?

I read the entire thread that you linked and said good, then immediately setup tor as per this article: Setting Up A TOR Hidden Service For Bitcoin Core

Dan Kaminsky has the idea that if you have enough bitcoin nodes/connections under your control, than by looking at how transaction spread across the bitcoin p2p network, you can determine ip address of a node that was the source of transaction, Blitcoin is suppose to be to the tool for that. I think that won't become a problem because use of a simple proxy that hides ip address of a sender, will be sufficient solution.
Post on forum from Dan Kaminsky himself BitCoin Deanonymization
Disscusion among developers Blitcoin? (Black Hat 2011)

If that's what it does, it's kind of silly. All someone has to do is create a web page that allows you to submit a transaction and the page posts it to the network. That's very easy to do, and that will completely obscure the origin of the transaction from the Bitcoin network.

@David Schwartz: A single website that hides your IP can be malcious itself or can be forced to give up your IP to say, the CIA. In that case your IP is no longer anonymous.

My point is that it renders Kaminsky's attack irrelevant. It's also very easy to hide your IP from a web site, Tor for example.

Indeed. Tor, I2P, proxies and readily-available VPN services can all thwart this attack, so I don't really see it as a serious problem. Still it's good to know what's out there.


text:
What are some reasons that a rational miner won't switch to P2Pool?
Besides the initial time investment of downloading & learning how to use a new tool ... what are some more reasons for a rational not to switch to P2Pool?
(Some reasons to switch is a slightly higher payoff in P2Pool due to bonus donations, and the overall contribution to a more distributed Bitcoin network).
Is running P2Pool more maintenance than using one of the larger pools? Is it more buggy, or has a lower total hashrate and thus higher variance?

Variance. Raw connection to p2pool will always have variance for a typical miner - if the pool is small there will be large pool-based variance, if it is large the share difficulty will be high and there will be large share-based variance.
Running a Bitcoin node is already nontrivial and going forward will become impossible for at-home miners. For example, some mining rigs run on a cheap USB flash drive, which may soon become insufficient to hold the blockchain.
Normal mining pools have additional features such as worker monitoring, SMS notifications, automatic conversion of NMC to BTC and so on.
Some of p2pool's suggested advantages are a bit exaggerated. The recent P2SH woes are a non-issue since miners who want to vote can simply go to a pool that votes as they want. The more generic concentration of power problem can alternatively be solved with smart miners (miners who generate blocks themselves or from an independent party, and submit shares with Merkle branches of the generation transaction which are accepted if it credits the pool).

Because of these reasons, I believe the future will be small PPS pools which act as a proxy to p2pool (with or without the use of independent block-issuing nodes). These will have low fees, no variance, as many features as the pool operator wants to implement, and will not be highly centralized. Until we see more of these I don't think there's much justification for p2pool going mainstream.

Time investment is not to be discounted so lightly. In addition to that, inertia and lack of awareness probably have a role. There's also the need for extra computer resources (ram mostly) to run the bitcoind and p2pool daemons. There's a bit of a higher variance as well, since the pool is relatively small.
If you do have some spare ram, and a bit of time, it certainly is a good idea to reduce hash power centralization.

It isn't clear how well p2pool will work with Butterfly Labs upcoming ASIC devices.

This is true (because of the latency), but your answer would be more useful if you expanded on why they wouldn't work well.


text:
What are the limits of the bitcoin protocol for making thousands of transactions, and what are the alternatives?
What are the limits of the bitcoin protocol for microtransactions, and what are the alternatives?
I am contemplating an application that would require each user to spend fractions of bitcoins multiple times every second. I understand that there are limitations in the protocol to prevent such a thing from happening. How can I proceed thousands of microtransaction using bitcoins without having a central server?

Rather than telling us that you want to make hundreds of transactions per second, you should tell us why you want to do that, because this sounds like an XY problem

Are you sure the "accounts" feature of bitcoind isn't what you need?

There are systemic limits based on storage per block.  So the limit isn't the number of transactions, the limit is instead the amount of data all transactions for inclusion in a block consume all together.
The definition of a "microtransaction" varies.
Bitcoin might be used to send a transaction without a fee if it is not a microtransaction.  The Bitcoin-Qt/bitcoind client (and thus nearly all mining capacity) has special rules that if any outputs are under 0.01 BTC (currently about $5 USD), then it must include at least the minimum fee.
The minimum fee, when required, is 0.0005 BTC per KB of data.
In all likelihood then, all of your transactions would need to pay a fee.
However, simply paying a fee is no guarantee that a transaction will be included.   The blocks have a limit of 500KB but as storage climbs above 250KB the fees needed for each additional KB increase.  As space for blocks begin filling, those transactions with the higher fee will bump out those with a lower fee, which will need to wait to be included in a later block.
So to answer your question is not what the limits of the protocol, but what level of a fee in the future will be necessary for a transaction. That's something that is not known today, but most all will agree Bitcoin probably won't work well for transactions worth a fraction of a dollar especially if the value of the fee itself is in the "many cents" per transaction range.
Alternatives
Decentralized crypto currencies are decentralized to make them resistant to corruption.
But a decentralized currency can be used as the form of money on a centralized service.  Most online gambling sites using bitcoins deal in bitcoin denominated microtransactions, and only use the bitcoin network whan a customer adds funds or when a user withdraws their funds.  So that is an example of how Bitcoins can still be used for a service that deals in microtransactions.
Other methods:
Open Transactions is a technology that allows an issuer to receive bitcoins and issue bitcoin vouchers. Those vouchers can them be transacted on one or more Open Transactions servers.
Ripple is a distributed transaction system which might be able to handle your problem.  Bitcoins are one of the types of funds that can be transacted.

The Bitcoin protocol has some built-in support for this, but I do not know whether it is currently being implemented. See https://en.bitcoin.it/wiki/Contracts Example 7 at the bottom.
Also, see http://www.youtube.com/watch?v=mD4L7xDNCmA for explanations of some of the advanced features.


text:
Is Bitcoin a scam?
Adam Cohen of SeatGeek called Bitcoin a "scam".  Other people have compared Bitcoin to a Ponzi or pyramid scheme.  Can Bitcoin be considered a scheme to defraud people?

See this FAQ entry: https://en.bitcoin.it/wiki/Myths#It.27s_a_giant_ponzi_scheme

It's also worth noting that, as Amin points out below, Adam Cohen later retracted his use of the word "scam".

It's important to differentiate between a scam, where a person or entity stands to profit fraudulently from others, and a high-risk investing decision, where there is potential for a person to lose significant amounts of money without being defrauded by anyone.  With that clarification, Bitcoin is clearly not a scam.  Like any other currency, Bitcoin is designed to be used as money, not as an investment.
A Ponzi scheme is a type of confidence scam where people who think they are earning unusually high returns on an investment are actually being paid from their own money and that of later investors.   If investors try and withdraw their original investment from the Ponzi operator, the scheme collapses because no actual profits exist and there is not enough money to return the deposited amounts.  Alternatively the Ponzi operator may simply leave and take the investors' money with them.
Similarly, a pyramid scheme is a type of confidence scam where people who "enroll" by paying a certain amount of money are made to believe they can make a large return on their investment by recruiting other people and receiving some portion of their enrollment fee.  The scheme collapses because it requires exponential growth, so it quickly runs out of new people to enroll.  The person starting the pyramid scam, who didn't have to pay an enrollment fee, makes money off of all their referrals; while the people at the bottom parts of the pyramid, who cannot find anyone new to refer, are left with no return.
Unlike either of these situations, Bitcoin has no person "at the top" who collects money paid for bitcoins, or has to pay out when bitcoins are sold.  Neither is there any kind of scheme in Bitcoin to harvest money off of unsuspecting people in complicated ways.  Instead, bitcoins are bought and sold on public exchanges amongst members of the general public who must all obey the same rules.  If someone has told you that Bitcoin is a moneymaking scheme, they have misconstrued it--bitcoins follow the same economic model as any other finite commodity and over time will tend to approach a price that reflects the value people ascribe to being able to use them.  People who have made money off of buying and/or selling bitcoins are either lucky or have correctly predicted an increase in demand for them.  People who earn bitcoins through "mining" are being paid for verifying and securing network transactions in a highly competitive market.  In neither case is any kind of fraudulent activity or confidence scam happening.
Despite the fact that Bitcoin itself is not a scam, caution is strongly advised when entering into transactions with untrusted entities.  As with any other valuable commodity, there are many people willing to separate your bitcoins from you in sneaky or fraudulent ways.  Remember that for all practical purposes Bitcoin works just like cash.  Bitcoin Ponzi and pyramid schemes do exist and if you fall prey to them you will suffer the consequences.
In addition, bitcoins are a very new and unproven type of money.  Because their value depends on how widely they are accepted, they are susceptible to the same types of economic bubbles as any other commodity that is surging in popularity. The Bitcoin software is still in beta, and bitcoins should be considered "high-risk" from a financial perspective.  You should not invest money into bitcoins or Bitcoin-related technologies unless you can afford to lose it!  Even firm believers in Bitcoin tend to think it will take a while for the value of bitcoins to stabilise, and no one knows at what value that stabilisation might occur.  Trade and transact safely!

Adam Cohen later retracted his allegation of it being a scam, which is mentioned at the end of his answer:
"Update 6/2: For those of you also on Hacker News, I made a couple of clarifying points, which included an apology for glibly using the word scam. Read more here.
http://news.ycombinator.com/item?id=2612237"
Open source software can obviously not be a scam, since it has no agency, and due to its licensing, cannot be owned by any party with agency.
The most that can be alleged is that someone created an open source program in order to conduct a scam, or that someone is using the software as part of a scam.
In the case of Bitcoin's creator, the pseudonymous Satoshi Nakamoto, his purpose in creating Bitcoin was clearly to effect political and economic change -as evidenced by what he writes in his white paper and in the mailing list through which he communicated about it before and shortly after the release of the software- and not to personally profit.
As for the criticism of it being a ponzi scheme, it's not true by definition. A ponzi scheme is structured so that those who join the scheme later give money to those who joined earlier, and nothing else is traded.
There is only one possible outcome in a ponzi scheme, and that that the early adopters profit, and the later adopters have membership in a ponzi scheme that they paid into but that they cannot profit from.
For any asset like Bitcoin, or a company stock, the early adopters will profit in the event of appreciation, but there is something of underlying value that all adopters will have if it succeeds. In the case of Bitcoin, it is a currency that can be used in trade as a medium of exchange, allowing for a reduction in transaction costs and an increase in transaction speed and convenience, and providing a store of wealth that doesn't depreciate due to inflation.

Bitcoin by itself is a protocol. It is not an investment nor does it make any claims that you will get a financial return for using it.

Bitcoin is definitely not a scam.  People have opinions about whether it will or will not succeed, but it's not a scam.  It like to think of it as the first money that is designed for the internet.  There have been previous attempts at digital money, but all have relied on a central authority to solve the "double spend" problem.  Until the advent of bitcoin, a transaction on the internet required a third party to the transaction (for example, a bank that manages account balances).  Bitcoin, like cash, requires no third party.  Also like cash, it is an irreversible transaction and can be stolen.  Bitcoin was designed with the modern internet in mind unlike credit cards (invented in the 1950s) or ACH (invented in 1972).  Bitcoin can serve as a solid (as in secure) foundation on which many other financial instruments and innovations can be based.  The software systems that the current banking system uses are antiquated, haphazardly put together, and could not have foreseen the needs of the modern internet.

A lot of people state that no claims are made that you will earn a financial return.  That may be true, but manufacturers certainly imply that you will earn money.  Why else would they charge thousands of dollars for mining hardware?
I think your question is fair, because there are calculators out there that predict a user will never earn-back the $5K they spend on expensive mining hardware, especially when said hardware won't arrive until Spring of 2014 (when difficulty has increased dramatically by then).  Still, any time you question the manufacturer on an unrealistic price, they hide behind the aforementioned claim that they "can't predict market activity" and that you should purchase their equipment "at your own risk".

It's just a new method of conducting transactions, similar to paypal but impossible to reverse transactions.  People who don't understand it call it a scam, but it is not.


text:
When thinking about e-currency in a general sense, what features discourage black market usage, but promote anonymity?
I'm interested in e-currency that discourages black market usage (child porn, meth deals, etc) but allows for anonymous operation (donations to charity, buying a pizza, viagra, or other health issues)
What pre-existing work exists that researches applicability of various "controls" into e-currency systems such as e-cash, Bitcoin, Open Transactions, etc.  And by "controls" I mean:

Psuedo anonymous user registration
Usage "escrow" allowing third party audits or reviews of transactions
Anything else that would be resisted by the Bitcoin purist.

I'm interested in any example you can think of, links to Bitcoin Talk, or any other whitepaper that discusses ways to legitimize e-currency to a moderate fiscal conservative.

The issuing of currency by a central authority discourages black market usage in a sense that all coins in the system can be tracked by the central authority - with AML and KYC policies.

Right, but then anonymity is also gone. The question is looking for a better compromise.


text:
Websocket API: Uknown mtgox message type
Here's a bit of node.js code:
var WebSocket = require('ws');
var ws = new WebSocket('ws://websocket.mtgox.com:80/mtgox?Currency=USD');
ws.on('open', function() {
    console.log('Connection opened');
    ws.send(JSON.stringify({ "op": "mtgox.subscribe", "type": "depth.BTCUSD" }));
});
ws.on('message', function(message) { console.log(message); });

When this client sends {"op": "mtgox.subscribe", "type": "depth.BTCUSD" } the API returns {"message":"Unknown mtgox message type","op":"remark","success":false}.
What am I doing wrong?

try using socket.io-client
var io = require('socket.io-client');

then its as simple as
var socket = io.connect( 'https://socketio.mtgox.com/mtgox' );

and then to subscribe to a specific channel
var message = {
  "op": "subscribe",
  "channel": "24e67e0d-1cad-4cc0-9e7a-f8523ef460fe" // this is the market depth channel
};

socket.send(JSON.stringify(message));

socket.on('message', function(message) { console.log(message); });

should give you the results your looking for
I think your main problem is that your not using the channel id's in your connection message. Here is the Mtgox web sockets api which has a list of all the different channel id's. And heres a project which implements them generically.
Hope this helps


text:
When do I have to backup wallet.dat?
Is it obligatory to backup wallet.dat after each outgoing transfer?
I understand it is, but not after each incoming transfer.

This question has already been asked and answered; see How should you backup your wallet?.

Every 100 transactions, counting both sending and receiving. For receiving, you can treat multiple transactions to the same address as a single transaction.
This ensures that you don't lose any bitcoins if, for example, your hard drive crashes.
The option keypool in Bitcoin-Qt client adjusts this.

You're never obligated to back up your wallet. It is something you do to protect yourself.
You do not need to backup your wallet to prevent from double spending (you spend BTC, loose your wallet, restore from an old wallet and try to spend the same coin). The protocol will stop that from happening because the transfer exists in the block chain.
However, you do need to back up your wallet to know what you have to spend. Without a current wallet the protocol won't know that you own a BTC and that you can spend it.
It is impossible (without a lot of computing power) to double spend BTC. Without your wallet you won't know what you have to spend. You can loose Bitcoins forever just like you can loose cash forever.

This is all true but doesn't answer the question.