text:
Why don't people buy at one exchange and sell at another?
Bitcoinity.org shows that for the past 30 days, bitstamp's price is high at 101.00, low at 77.00, and current price is 98.04. On contrast, mtgox's price for the past 30 days is high at 115.00, low at 86.20, and current price is 110.50.
In other words, someone or anyone can just buy from bitstamp and sell to mtgox to make profit.
What's stopping people from doing so? What's the catch?
It can't be that people aren't aware that they could do it right?

Because of Mt Gox's current withdrawal problems, a dollar at Mt Gox is worth less than a dollar at Bitstamp.

@DavidSchwartz, what problems do you mean?

Google "Mt Gox withdrawal" to see various reports of difficulty withdrawing USD and EUR from Gox.

http://bitcoin-analytics.com/#arbitrage provides realtime arbitrage panel which supports history of arbitrage opportunites for last 24h between all major markets.

Many people already do this with bitcoin. In finance, this is called arbitrage trading, or simply arbitrage, sometimes even abbreviated arb.
The reason for the price differences are fees for transferring between the bitcoin exchanges (you have to transfer both, bitcoins and fiat currency for a complete cycle) and fees for trading bitcoins against fiat currencies.
Because of the arbitrage traders, who make profits as long as the price difference is big enough, the prices on different exchanges quickly adjust to be right at the border between where the fees eat up the earning and where you make profits.
There is an excellent page, http://bitcoin-analytics.com , which can tell you where there currently are arbitrage oppurtunities. Simply go to the website and click on "Arbitrage".

Do you mean that for one whole month no one bothered to do arbitrage trading even when the spread is 10% (quite high)?

It's not about the spread alone. As explained, a lot of your profits from the spread get taken away from the fees of transfers and trading. Make your own calculations of the fees and I bet you will end up somewhere at 10%. This seems high, but remember that you have to transfer the amount multiple times between exchanges to make a complete roundtrip. So if you have e.g. 2.5% fees for each trade and for each transfer on avergage, this nicely lines up with the 10% total.

Example: transfer fiat to bitstamp, buy at 100, get bitcoin out of bitstamp, transfer bitcoins to mtgox, sell at 110, get fiat out of mtgox. these are 6 steps for a roundtrip. you have utilized the spread of 10% only once, but for more than one of the steps you have to pay a percentage on the full amount. Btw, if you find a nice table with the exact fees outlined for a roundtrip, let me know.

@DanielS. : Normally all these steps add up to much less than 10%. However, right now it's simply virtually impossible to withdraw funds from Mtgox.

When I used to do arbitrage I built such tables for myself. The problem is that such tables are personalized. Your exchange commission is based on your volume and your transfer fees depend on your bank and/or payment system. Also I heard that professional traders include their risks into prices (e.g. "As I make mistakes or there are various delays I need to make at least X% on gox-bitstamp route to have it profitable on average"). So such table cannot exist or at least it will have limited applicability.

I've writen software to arbitrage on some US exchanges.
I couldn't arbitrage without software because:

It was hard to account for all fees to understand if an opportunity is profitable.
It took a couple of minutes to evaluate opportunities (query an exchange's order book, query another exchange's order book, do an evaluation, execute a sell, execute a buy) and by that point the evaluation may be invalid.

Here are the factors that make it hard for me to arbitrage with software:

Small (fractions of a percent) profit margins. As pointed out earlier everyone in the loop is taking fees.
Small (seconds to minutes) profitable time windows
Slow (2-8 days) cycle times to move USD back into position for sale
Large Capital requirements - since the margins are so small for arbitrage to be worth it on an annual basis takes a lot of assets. For example I might make a few cents or dollars on a $1K sale and purchase of Bitcoin.
Risk - with large capital requirements comes risk of loss. What if a trade becomes unprofitable before the arbitrage completes? What if Bitcoin tanks?

I am interested in non-US exchanges since the spreads are bigger but I expect it will increase some of the issues above, especially fiat cycle time since my base is USD

What's stopping people from doing so? What's the catch?

The catch is that few people have been able to get US dollars out of Mt. Gox since June 20, 2013, when Mt. Gox imposed a "hiatus" on US dollar withdrawals.  Mt. Gox has a long list of excuses for not paying their debts, which you can find on their site.  Some of their excuses strain credulity.  This has stopped arbitrage, which normally uses the same money going round and round from exchange to exchange.
Mt. Gox is still paying out Bitcoins on demand, most of the time. So people with US dollars in a Mt. Gox account are paying a premium to convert them to Bitcoins, get them off Mt. Gox, and sell them on another Bitcoin exchange.  Right now, the premium is about 15%, and it's been up to 20% briefly.  It seems to be increasing about 5% per week.  This reflects the market's collective opinion of whether funds deposited on Mt. Gox will be lost.
http://bitcoin-analytics.com has paid tools for tracking the spread.

One of the major reasons standing in the way of profiting from arbitrage opportunities has to do with "volume".
The volume for either exchanges is not high enough yet to support big trades. Large profits require large trades (in arbitrage). Making $1,000 may be feasible between exchanges, but that's an extreme best case scenario and using 10k in capital! Moving trades upwards of 100k would be just plain stupid if even possible in such a low volume market. Chances are if your arbitrage trade is big enough to profit from, it will move the market against you.
Arbitrage in the finance world is done with millions and millions of dollars and for fractions of a second. That just isn't possible with Bitcoin.

Something I am currently looking into, and a huge issue that nobody has really mentioned earlier is blockchain time.
1) Bitcoin is traded on a number of exchanges, however the entire process of buying on one exchange, transferring to another exchange and selling on that second exchange can take on the order of magnitude of 30 minutes(~10 minutes per block verification) if not more. With the volatility of the market, I would definitely not want to hinge a bet that the arbitrage window would still be open that long after it becomes present.
2) There are cryptocurrencies that have shorter verification times, but very few trade on multiple exchanges, and even fewer do so on exchanges that have APIs available. Litecoin is one of the few coins that does trade quite widely, be it still has a verification time of two and a half minutes.

I have been wondering about it myself for a long time now. I even thought of developing trading software (bot) that would automatically buy on one exchange and sell on MtGox. The price difference between BTC-e and MtGox can be as high as $100/BTC.
The problem is how to get your cash (US$) out of MtGox? Last time I tried, I waited - in vain - for almost 5 weeks and finally created a support ticket to cancel the wire transfer, bought BTCs at the inflated price and transferred them to CoinBase to cash out.
The only way I see to make some profit is this:
BTC price fluctuates wildly every second of every hour of every day.
So

buy low at BTC-e (or CoinBase) or any other exchange, say you buy 5 BTCs for $800 each = $4K
Transfer to MtGox and sell for $900 each, Now you have $4500 cash sitting in your MtGox account that you cannot get out.
Wait until BTC price on MtGox drops to BELOW $800, BUY. Say, for example, at $750, you buy 6 BTCs for the $4500 you have.
Transfer back to the exchange you started at (or to CoinBase, where ACH withdrawals to US bank accounts take only 48 hours). Now you've completed a round trip with 1 BTC profit (less transfer fees, which actually should not be more than $100 total).
Wait until BTC price is $800 again at this exchange (your starting point), cash-out, or repeat the process.

But you see where the problem is. I am assuming the BTC price will swing wildly between $750 and $900 in few short days. What if it doesn't? what if it drops in value and stays below your starting price of $800 for a long time, or keeps losing value? But then again, it's a risk inherit in any speculative trade. And Bitcoin trading is all speculation.

there are many similar question on Bitcoin.SE (search for "arbitrage" to read more).
I'll try to resume what I understood until today on this topic (I'm quite interested into it, mee too).
There is room to play some arbitrage buying and selling in different exchanges market, but the real problem is the speed of the transactions and keeping your dollars into all you accounts.
You need to keep some dollars and some bitcoins in every market you choose to use (mtgox and few others) and buy/sell keeping an eye on the different prices. The problem is when you want to trasfer some bitcoin froma a market to another (it takes time! and some fees) and when you want transfert dollars in/out a market (it takes fees!!). You should check the transfert fees when you move your dollars and count if it is still valuable...
see also this question and its answers: How can one find how much "room for arbitrage" is there in the Bitcoin market?

I can tell you also another thing; the high profit % is due to the temporary closure of bitinstant, and that speed up the process...
This graphic represents the % of profit between 27/1 and 27/6 2013 (6h timeframe)

(source: http://www.wolframalpha.com/share/clip?f=d41d8cd98f00b204e9800998ecf8427ecn3c6i81m3)
You can simply reconstruct the events when bitinstant was closed or under maintenence by the graphic.
These are the steps:

fee of the bank transfer between your bank and bitstamp (sepa or
international, this depends also by your banks)
0.48% fee of bitstamp to buy BTCs
minimal fee to send to mtgox+time to verify the transaction (6
confirmations, which can take almost an hour)
now a 0.6% fee on mtgox to sell the BTCs
and a 1% withdrawal fee+time to receive the money (normally up to 2
weeks, now up to 3!)

ps. I just earned a new battery for my cellphone with this process.

Its not possible due to various settlement mechanisms.Each exchange have their own settlement period and their transaction and transfer fees.

This is (1) wrong, and (2) pretty hand-wavy.  You might include hard numbers and specifics to show how you arrived at your conclusion to avoid more downvotes.


text:
How do I backup my wallet?
Using bitcoin-qt, multibit, or any of the others, how do I backup and save my wallet in case I need to reinstall Windows?

Possibly related - http://bitcoin.stackexchange.com/q/746/323

bitcoin-qt

open the File menu
click Backup Wallet...
select a file to save the backup as

MultiBit
From http://multibit.org/help_backupWalletUsingPrivateKeys.html:

You can export your private keys from a MultiBit wallet into a file
  (using the 'Tools | Export private keys' option) and, as long as you
  do not manually create new receiving addresses, you can use the
  private key file as a backup for the wallet.

Armory
From http://bitcoinarmory.com/index.php/start-page/what-is-armory/features:

Not only are the wallets determinstic, but there is a built-in dialog
  for printing permanent copies of your wallet.  When you first create
  your wallet, make sure your printer is on and click the “Paper Backup”
  checkbox.

Electrum
From http://electrum.org/:

You do not need to perform regular backups, because your wallet can be
  recovered from a secret phrase that you can memorize or write on
  paper.

source: Stack Exchange

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

sort: votes


text:
Custom validation logic for transactions/ custom script extensions
Is it possible to add a hook for custom validation of transactions with a special script "tag" in them? If so, How? In essence, I want to add something similar in  functionality to bitcoin script, but far more complex that what that supports. It doesn't matter if most clients/servers will not recognize the extended bitcoin script , provided they will ignore it.
The idea is that a node, when seeing a transaction with a special script payload, would call some external validation routine and only if that succeeded would it then run the standard integrity checks.
Are there supported hooks for this in the JSON-RPC API, any of the various clients, or would it require extensive modification of the source ?

I don't think this will have the effect you expect it to have. All this will do is cause your client to ignore some bitcoins that other clients consider valid -- and this would apply to all bitcoins that ever "passed through" a transaction your logic rejects.

If you want the standard client to ignore a part of a script, you should add it in with OP_PUSH and remove with OP_DROP, essentially making it a comment. This schema is similar to how HTML and javascript work. As long as the rest of the transaction confirms to the Bitcoin Protocol, you can put whatever data you want between those two operations, allowing you to create custom scripts.
However, such functionality is very non-standard. You would need to develop your own software for handling such scripts, and as far as I know, there isn't a program that allows you to encode messages in transaction comments easily (I've been looking for one for a long time and I wasn't able to find it).
Alternatively, you could create your own version of Bitcoin and incorporate your non-standard scripts into it, similarly to how Namecoin operates. This would take more effort, but offer a lot more freedom.

It would require a change in the protocol to allow for the use of external validation routines, or any bitcoins spent using the "special" script will never again be spendable by any standard Bitcoin client.
None of the currently available clients offer this feature.

The only data belonging in the block chain is what is necessary for the world to verify it is valid. Anything else is essentially private information between the sender and the receiver.
I don't think there is much point in having nodes with local stricter additional validation rules. What if a transaction is sent that you yourself don't accept, but the rest of the world does?

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


text:
Bitcoin wallet taking days to receive coins
Previously withdrawing bitcoins from Intersango has only taken 24 hours.  This particular transaction has taken several days and I still haven't received the bitcoins.  I withdrew the coins from Intersango but they haven't been received by my wallet yet.  Does it make a difference that shortly after I withdrew the coins from Intersango I encrypted my wallet? Does it make a difference that it is currently 'locked,' if so how do I unlock it to recieve coins? Please somebody help this is really worrying me!

Intersango has been having a problem with their wallet recently, as described in this forum post.  Another post claims that:

this was triggered by someone spamming the wallet with a very larger
  number of small transactions

Encrypting your wallet won't make any difference to whether you receive the bitcoins or not.  You only need to "unlock" the wallet to spend coins (or to top out your pool of unused addresses).
You can check at http://blockchain.info/address/1youraddresshere to see whether the coins have been sent yet.  If they show up there but not in your wallet then it's an issue with your wallet.

Did you receive the coins yet?  A poster in the thread ( https://bitcointalk.org/index.php?topic=63877.msg1041600#msg1041600 ) says that he contacted support and received his coins immediately.


text:
How to know there is a new transaction?
I am developing a program that monitors transactions.
The first question is how can I know there is a new transaction? I can consider the command listtransactions. However, there is a bit of an issue about this command which I posted in another thread. In short, I can't list transactions from all accounts by NOT providing the account parameter.
Even if it works for me. The API says:
listtransactions    [account] [count=10] [from=0]    Returns up to [count] most recent transactions skipping the first [from] transactions for account [account]. If [account] is not provided it will return recent transactions from all accounts.
I ran this command with parameters: "", 1,3. I still got the first 3 transactions.
Does anybody have a better idea about how to get new transactions that have not been checked?

No answers yet? If you happen to find the answer somewhere else (e.g. Forums), please post it back here.

First: to get transactions from all accounts, use the "*" wildcard.
Second: Bitcoin version 0.5 includes a new listsinceblock RPC command that makes polling for new transactions more efficient.
I wrote a monitorreceived patch that does an HTTP POST whenever a new block or transaction-to-or-from-your-wallet was received, but I haven't pulled it into mainline bitcoin because it would make it VERY easy for websites to do the wrong thing and treat 0-confirmation transactions as "paid" and because it isn't clear what (if anything) to do when block chain re-organizations happen or transactions are orphaned (double-spent).

Perhaps make it configurable how many confirmations are needed for it to trigger, having it default to 6. I think it's generally accepted that if you trigger on 6 confirmations, you can ignore the possibility of re-organizations.


text:
How do I use Vanitygen on Fedora 20? (openssl restrictions)
I have seen several methods for building bitcoin from source on Fedora, but I have not seen corresponding information for vanitygen.
It builds, and it starts up, but then it gives me the error:
"pattern.c:164: vg_exec_context_init: Assertion `vxcp->vxc_key' failed."
Of course, the cause is easily searchable: the Fedora implementation of OpenSSL does not include the algorithms that bitcoin depends on. Bicoin got around this, but vanitygen does not seem to be able to.
I downloaded and built the most recent version of OpenSSL from their website.
Using "make -rpath [path to the openssl I built]", however, does not change anything.
So my question is: How do I get vanitygen to point to my OpenSSL rather than the default OpenSSL? I don't want my entire system to use the custom OpenSSL because I trust the Fedora implementation more than the one I downloaded; however I don't intend to use the generated addresses for more than small bitcoin amounts, so they don't have to be as safe.
References:
How do I build Bitcoin in Fedora 18?
EDIT: For reference, the procedure referenced in the accepted answer below is:
NOTE: In both this and the accepted answer below, REPLACE openssl-1.0.1g WITH THE LATEST VERSION OF OPENSSL. 1.0.1g may have security flaws that are patched in future versions - it is current as of this writing, but probably will not be in six months.
mkdir ~/devel
cd ~/devel

wget http://openssl.org/source/openssl-1.0.1g.tar.gz
tar xfz openssl-1.0.1g.tar.gz
cd openssl-1.0.1g

./config --prefix=/opt/openssl-1.0.1g zlib-dynamic shared
make

sudo make install_sw

First, you need to compile OpenSSL from the sources. I assume that you've compiled it as it is described in the Bitmessage Forum. That way, OpenSSL including elliptic curves support is installed in /opt/openssl-version. As for the Heartbleed bug that has recently been published, please use the very latest stable version of OpenSSL.
Following this description, I will now assume that OpenSSL including elliptic curve support has been installed unter /opt/openssl-1.0.1g
Now coming to vanitygen: Download the zip file and extract it to your hard drive. Then modify the Makefile: At the very top of that file add the following line:
export LD_RUN_PATH=/opt/openssl-1.0.1g/lib

After that, go to the line where CPFLAGS is set. Modify it, so that it looks as follows:
CFLAGS=-ggdb -O3 -Wall -L/opt/openssl-1.0.1g/lib

Basically, the line is unmodified, except for the library path to the custom OpenSSL library, which has been appended.
That's it! Now you can compile vanitygen in Fedora as well:
make
./vanitygen 1TEST

Thank you! Worked like a charm!
Unfortunately, upvote requires 15 reputation. Don't worry, I will as soon as I can. :)

I ran into this trying to help a friend with vanitygen and went the other direction, patching the Fedora packages to add the secp256k1 curve.  There are pros and cons to my approach and to Marc's, but if you want to try a system-wide patch, here's a blog post on it with links to the patches and RPM's.
If you go this direction, all you need to do is 'git clone' vanity gen and then run 'make'.


text:
Can a brainwallet passphrase be derived if an attacker has obtained the private keys of an empty wallet.dat file?
Someone robbed me at gunpoint and took my laptop. The laptop contained an encrypted hardrive with a wallet.dat file. Both the hardrive and wallet.dat had at best weak passphrases for the encryption. I have assumed both to be compromised.
My question has to do with the one-way permutation hash function of ripemd-160 to generate both the private and public keys used in brain wallet generators.
[I am assuming that wallet generators are using one way permutations. I could be wrong. If I am then please inform me. Most wallet generators use the brainwallet.py available on github.]
If an attacker has obtained your private key can he "reverse engineer" the key to obtain the original brain wallet passphrase used when the wallet was generated?
If so I assume he can use that to bruteforce any other wallet that would use the same passphrase as a seed as mentioned in this post here:
https://crypto.stackexchange.com/questions/10246/question-regarding-multiple-sha-256-rounds-on-a-bitcoin-brain-wallet-passphrase

Why does it matter if he can reverse-engineer the key to your passphrase? If he has the private key, he can spend your balance. You won't be able to make a new brain wallet with the same passphrase, as it will result in the same address. So unless your passphrase was the password you use for everything (stupid idea!), this doesn't really matter.

Any reason for your cross-post at crypto.se? You obviously already received an answer here...

I did not know where to best post the question. Sorry

Steven re-read the post. The question was relevant to the seed passphrase being obtained. The wallet was already secured (empty wallet)

Sorry to hear you were robbed.
An attacker cannot reverse engineer a private key to obtain the original mnemonic phrase.
What essentially happens is just another multitude of hashes with an algorithm (SHA256). Different approaches to this are taken by different deterministic wallet generators.
As SHA256 is considered secure. So is your mnemonic phrase

So you are guaranteeing me that a one way permutation is used to generate the private key for the wallet generators such as brainwallet.py?

Is this just an opinion or do you have any facts or evidence to back your claim? Dont take offense but im not going to risk losing all of my money on an opinion

I did some research... what I am worried about is called a preimage attack.

Someone claims ripemd-160 is a one-way hash function: http://www.reddit.com/r/Bitcoin/comments/1lsweg/

As long as your mnemonic phrase has enough entropy not to be brute forced then it is safe. I think Electrum uses 12 dictionary words to get 128bits of entropy. Don't quote me on that though.


text:
Is there a Bitcoin gateway for PrestaShop with these specific features?
PrestaShop is a free, secure and open source shopping cart platform.
I am searching for a PrestaShop payment processor with the following features:

works without without third party (save commission)
gives a new address to every checkout
automatically verifies in admin/customer after N confirmations
gives wallet info in admin panel

Alternatively, is there a PHP implementation with these functions to allow coding all this?

A fairly comprehensive list of Shopping Cart Interfaces is: http://en.bitcoin.it/wiki/Category:Shopping_Cart_Interfaces

Check this http://www.prestashop.com/forums/topic/123451-module-free-bitcoin/ it says is free and works without integrating with online payments processors

Our Bitcoin HD module for Prestashop answer all your questions. It is based on the HD (Hierarchical Deterministic) wallet so your bitcoins are safe and no need to third party.
Notice that I am the developer of Bitcoin HD module.
Link to the module page :
https://www.motionseed.com/fr/modules-prestashop/bitcoin-paiement-prestashop

Blockonomics prestashop plugin is free and has all the above features in addition to others such as:

Payments go directly into your wallet
No approvals / documentation required
Email notifications / admin panel and dashboard
Supports all major HD wallets like mycelium, trezor, ledger


text:
How to broadcast a transaction anonymously
Is it possible to broadcast a transaction to the network without revealing my personal IP address? My first guess is to connect bitcoind over Tor with proxy=127.0.0.1:9050. Is it the good way to do it or do I have other options?
Thanks.

possible duplicate of How can one remain relatively anonymous while using Bitcoin?

http://bitcoin.stackexchange.com/q/52/659 has some useful information about anonymity too.

If I want to connect over Tor the client will not be able to discover new peers by itself. Should I use a list of peers with .onion addresses. I saw some info here. https://en.bitcoin.it/wiki/Fallback_Nodes Can anyone who use bitcoind over Tor guide me on how to do it right?

Someone needs to set up a web server that accepts bitcoin transactions for submission. Then you could just use Tor to submit the transaction by HTTP.

Here is the solution I found to broadcast transaction on the bitcoin network without revealing your IP: connect bitcoind over the Tor network. Here is my guide.
Edit your torrc file to add .onion bitcoin nodes:
mapaddress 192.0.2.2 ijzt2eeizty3p5xe.onion
mapaddress 192.0.2.3 j43z65b6r2usg3vk.onion
mapaddress 192.0.2.4 pvuif6nonbhj3o3r.onion

Start Tor
Edit .bitcoin/bitcoin.conf to connect bitcoind over the Tor network. Add:
proxy=127.0.0.1:9050
connect=192.0.2.2
connect=192.0.2.3
connect=192.0.2.4

When Tor is started (green onion) you can launch bitcoind.
More infos
https://en.bitcoin.it/wiki/Fallback_Nodes
https://bitcointalk.org/index.php?topic=50547.0;all

But and what about this? https://www.cryptocoinsnews.com/bitcoin-tor-may-good-idea/


text:
Does 'simplified payment verification' work?
I was reading the original bitcoin paper where they mention a simplified payment verification scheme in section 8. I was wondering whether or not this actually works.
A quick sketch: The scheme requires you to only store all the block headers (instead of the full blocks). When you need to verify a transaction, you simply need the merkle root of the transaction and see whether or not that merkle root appears somewhere in the stored block headers. If so, you know that the transaction was once verified.
But you would not be able to use this for actually verifying new payments, right? Suppose somebody pays, and in the transaction he uses 'ins' from some other transaction. With this simplified scheme I could then check that the transaction actually happened. But I can't check that he has not already spent the money, right?
So basicly this scheme is only useful for re-verifying an old transaction for some reason? (e.g. to confirm that someone has participated in some transaction). But it is not useful for paying.
Is that a correct interpretation of the scheme, or am I missing something?

Transactions don't have a Merkle root. You need the Merkle branch of the transaction.

Simplified payment verification can't help much with 0-confirmation transactions. But once the payment has several confirmations, this fact alone (which the SPV client can verify) implies that the transaction is accepted by the network, so the payment is secure.
SPV can also be used in conjunction with a server node that has the blockchain and can verify against double-spending. The client will still want the block headers and the Merkle branch of the transaction to keep the server node honest. Without this, the server can falsely report that the client received payment; with the simplified verification, the server would have to collude with the sender.


text:
Have there been attempts at a Bitcoin-powered general purpose database?
https://en.bitcoin.it/wiki/Bitcoin-Powered_Database
As far I know, the Bitcoin blockchain is pretty much the only data structure that is both global and tamper-proof.
global - There is one global instance of the blockchain (up to forks ... which are then resolved).
tamper-proof - If a block enters the blockchain, after 6+ confirmations this block can't feasibly be faked or altered.
A Bitcoin-powered database would be an API over the blockchain, that would expose a subset of the usual CRUD database operations. In fact, it would be an append-only data structure, because nothing can ever be really deleted from the blockchain - so only CREATE and READ operations will be implemented. Object Versioning will be used to emulate updates and deletions.
Have there been previous attempts to create such a database? I have seen the MerkleWeb proposal, but I haven't really understood it, so I'm not sure if it answers my question.

@BenReeves - Hmm, I'm not sure, for two reasons - 1. You have to keep paying to get your data stored, unlike Bitcoin (for good or bad). 2. Could you distinguish a record created five years ago and renewed yearly from a record created yesterday? If not, that's not good enough for this purpose. I believe there isn't a direct API based on Namecoin that offers this. Perhaps it would be easier to write such an API over Namecoin than over Bitcoin.

@ripper: Every namecoin op is stored in the (namecoin) blockchain just like bitcoin. so you do not have to pay to get your data stored but only to keep control over a name/value pair. Looking at the chain it is possible to determine all previous ops.

This is it - the CryptoSphere.
It uses some Bitcoin concepts, and might support paying for storage using Bitcoins. I believe that "merge-mining it" using the Bitcoin blockchain would be possible (it's too soon to tell, the design is preliminary).

Page 404's now.

Namecoin is more or less what you're asking for.

Namecoin can be the basis of what I'm looking for ... but does it have high level DB-like API?

Hi GDR! One-line answers are usually not very helpful to other readers. Try to expand the answer to explain a little bit about Namecoin and why it is what OP is asking for.


text:
Pros & Cons of Self Hosting Bitcoin Node vs using a 3rd Party Service?
We are a medium size company building a blockchain application that requires us to interact with the Bitcoin blockchain (+ several other cryptocurrencies). One option is for us to use a 3rd party service that provides us with a uniform API to interact with the blockchain (some examples are BitPay, BlockCypher, BitGo & CoinPayments). The other option is to self host the blockchain node on our servers and natively interact with the blockchain (no middleman involved).
If we go with 3rd party services there’s usually a monthly fee and/or a small percentage charged for each withdrawal (between 0.25% - 1%). So this would be one big downside of going with a 3rd party service. On the other hand, if we host the blockchain ourselves we would be required to perform ongoing maintenance, server upgrades, implement extra security protocols and so on.
A colleague warned me that for every coin we wish to support, we will be required to hire a dedicated expert developer to maintain each node at a cost of $40,000 per year per node
To be clear, we are not concerned about the initial setup of the nodes as we have expert developers who will assist us with that. Our primary concern is related to the ongoing costs to maintain, upgrade, debug and deal with ongoing security concerns of running a large number of nodes on our own server.
It is cheaper for us to hire a developer who will setup all the nodes on our server vs. paying a monthly fee and/or withdrawal fee. Our only concern is related to the long term maintenance costs associated with self hosting nodes.
Are the concerns of my colleague valid or unfounded? Are there valid reasons to believe we will regret self hosting in the long term due to ongoing maintenance costs? If so, what are some issues that we are overlooking with self hosting?
Thank you
Note:
I did see this SE answer that partially addressees this issue. However, a big part of the answer is focused on the initial setup costs of self hosting:

Using RPC calls to your local bitcoin node requires then some
developer knowledge, or a dev-team. That can add to costs in setting
up your environment

As I stated in my question, this is NOT really a concern for us. Our only concern is related to the ongoing costs of self hosting vs. using 3rd party service.

Where could they have possibly got the idea that maintaining a bitcoin node costs $40,000 a year?

@Prayank No. I'm fully aware of the alternatives as I explicitly state in my question. My question is NOT about what alternatives exist but about the long term maintenance costs (maintaining, updating, scaling and securing) self hosted nodes vs. using a 3rd party service.

@Anonymous perhaps not for bitcoin, but for some poorly developed altcoins that number is maybe too low

The truth is somewhere in the middle. Your colleague is correct to point out that there is an ongoing cost for maintaining your own full nodes. Beside the employee cost, there is also the cost for the actual server infrastructure, which may be higher than you think if you consider that you will need to maintain high availability,  redundancy, testing instances, and that you should sequester each foreign software from your own network and other nodes.
Overall, you can probably get away with having fewer infrastructure engineers than the count of supported cryptocurrencies, as maintaining a full node should not be a full-time effort. For example, the maintenance work between Bitcoin and bitcoin-derived altcoins such as Litecoin and BCH would have large overlaps. Cryptocurrencies with unrelated codebases and more strongly deviating APIs and data structures will be significantly more work. Frankly, the reference implementations of some "top 20" cryptocurrencies are inadequate for production use. If you deploy your nodes in the form of infrastructure as code, you have more development effort up front, but significantly less work later on.
However, the biggest cost difference is the time and effort you will need to invest to build out your own integrations with each different full node. The wallets packaged with full nodes usually do not scale to the needs of an enterprise, so you will likely need to invest in custom blockchain indexing, wallet software, address management, key management, transaction building, balance tracking, user management, etc. This is where the mentioned services can provide a lot of the heavy lifting. If you do end up developing your own integrations, I would definitely recommend having at least one engineer per supported cryptocurrency that is passionate about it specifically.
Even if you decide going with one of the mentioned service providers, I would heartily recommend that you run your own full nodes to reconcile the information the service provides with the corresponding blockchain data. This will still save you from doing your own wallet management, address management, transaction building, multisignature setup, simplify scaling, and let you focus on getting your business off the ground more quickly. You may even consider using a service provider intermittently, and then transition to self-hosting as you finish work on your own integrations.
Just to be clear: you fully entrust the future existence of your company to such a service provider. I hope that makes you at least a little bit uncomfortable and that you thoroughly take their approach to security and your counterparty-risk to them into account for your decision.
In the past few years, I have observed a few companies being extremely successful and rapidly leveling up their UX by focusing just on Bitcoin and sidestepping altcoins altogether. You may even consider a hybrid approach where you build your own Bitcoin solution and use a separate service for whatever alts you must support to limit your exposure.
Disclosure: In my previous job I was the UTXO Coin lead at BitGo.

Thank you for your excellent analysis! "I would definitely recommend having at least one engineer per supported cryptocurrency that is passionate about it specifically" As you indicated, with self hosting option it's necessary to hire someone with a high skill set for each (loosely related) coin. And since it is a relatively uncommon skill set, this talent won't come cheap. The main problem, the way I see it, is that as a "startup" you are paying a very large sum of $$$ upfront, regardless of the number of transactions you process initially  (cont)

(continued) In contrast, while most 3rd party services charge a percentage of the withdrawal amount, you are not paying $200,000 upfront to use their service. You pay only based on the amount of $$$ you process in transactions. I think this is an important issue for startups. Also, the scaling issue you mentioned is important. Do you setup infrastructure to handle 1,000 transaction per day or 100,000?

@DesignX: I agree, developers with a cryptocurrency background is not neither cheap nor abundant. Obviously, it depends on your location, but I suspect that you may find that $40,000 p.a. to be actually highly optimistic. In the US, you'd probably be looking at $150k+ per position (salary+rest). Even going with a service provider, you will not be able to provide the full palette immediately. Start with one or two, do those well, add what makes sense as you grow.

I can't tell you at which volume your operation would break even, it depends on what amounts those transactions encompass, whether you are talking about on-chain transactions or trades, what your actual costs and revenue look like.

While my answer mentions some other cryptocurrencies and comments on the cost of supporting them, I fail to see where I endorse or promote any.

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


text:
Is possible to send transactions with blockstream satellite?
Noob question here. Is it possible to send bitcoin transactions using Blockstream Satellite node or is it used only for receiving blocks?

Not your question, but you can send bitcoin transactions via SMS.  This combined with the satellite download could build a bitcoin system for those without highspeed internet.

No, communication is unidirectional, you can only receive the data which is broadcast by the system. The satellites being used are TV relays, the uplink essentially being amplified and re-broadcast without any knowledge of the content.Transaction broadcast needs to happen by terrestrial services like a cellphone network, dialup modem, or just the regular internet.

You can use Blockstream satellite as part of a system to conduct transactions, but it can't send transactions on its own.
You can create the entire process of sending and receiving transactions (running a node), without a personal internet connection, by combining the Blockstream satellite hardware to receive blocks, offline wifi for local transactions, and localized mesh networks or SMS for broadcasting.
Excellent breakdown of process here:
https://hackernoon.com/completely-offline-bitcoin-transactions-4e58324637bd

Hello, @BTC_FTW, that's a nice link, but your post didn't answer the question of the asker, paraphrasing: Can you only receive or also send using the satellite? Any chance you could edit your answer to include an answer to that main question and perhaps a couple sentences of what was great about the linked article?

Updated. Hope that's better.

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


text:
what is the latest required hash rate to mine a block?
What is the latest required hash rate to mine a block of bitcoin ?
How much power do you need to mine a block in a day ?
Thank you

I think you can estimate the value with "getnetworkhashps" command

What is the latest required hash rate to mine a block of bitcoin ?

26,592,872 trillions of hashes per second

How much power do you need to mine a block in a day ?

average hash power of 1 day is 35,683,280 trillions of hashes per second
$ date --utc
Sat Feb 16 12:23:48 UTC 2019

// 1 block
$ curl --user 'id:password' --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getnetworkhashps","params":[1]}' -H 'content-type:text/plain;' http://127.0.0.1:8332
{"result":2.659287272432074e+19,"error":null,"id":"curltext"}

// average of 144 blocks (about 144 blocks are generated in a day)
$ curl --user 'id:password' --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getnetworkhashps","params":[144]}' -H 'content-type:text/plain;' http://127.0.0.1:8332
{"result":3.568328058845101e+19,"error":null,"id":"curltext"}

// chainquery.com (I think a little bit buggy sometimes)
http://chainquery.com/bitcoin-api/getnetworkhashps
// blockchain.com hash rate
https://www.blockchain.com/ja/charts/hash-rate


text:
Bitcoin stuck, not syncing
I recently converted from Chakra Linux to Opensuse 13.1 without formatting the home partition (I took a chance) and didn't have to do the usual reloading of email, documents and bitcoin started working straight away after I installed it from opensuse repo. Chakra installation had bitcoin-qt 0.8.6 and opensuse loaded bitcoin-qt 0.9.1. So, basically, it found the files in the home partition and seemed to carry on from there. I do have a backup from before the conversion. Bitcoin 0.9.1 did add a quite a few blocks before the error. So, maybe it wasn't the transition to opensuse that did it.
Now the wallet is six days behind. Here is quote from debug.log. It is 'catching up' from block 297123.

2014-04-23 20:59:35 ProcessBlock: ACCEPTED
2014-04-23 20:59:45 UpdateTip: new >best=000000000000000087be011f611f80fd4d3d917780a27850fb878512f492f828  >height=297123  log2_work=78.143683  tx=37308919  date=2014-04-22 09:43:51 >progress=0.993196
2014-04-23 20:59:45 ProcessBlock: ACCEPTED
2014-04-23 20:59:56 ERROR: CScriptCheck() : >447f1be22db9cca6b7539a66b54f99ea11c1c0316a72915d34d8a1c86d00ebcf >VerifySignature failed
2014-04-23 21:00:03 EnvShutdown exception: Invalid argument (22)
2014-04-23 21:21:02 CheckForkWarningConditions: Warning: Large valid fork found
forking the chain at height 297123 >(000000000000000087be011f611f80fd4d3d917780a27850fb878512f492f828)
lasting to height 297131 >(00000000000000004866bff18fa3e4378486920d6b9dc7f332f9f0bc18bd247e).
Chain state database corruption likely.

Any suggestions on how I should proceed?

A signature check failed for a valid transaction. This likely indicates a CPU or RAM problem with the system you're running on (even though you don't see regular errors in normal operation, Bitcoin does so many computations during validation that it's likely to see them more).
The result of this is that bitcoind marked the chain this transaction was in as invalid, and rejects new blocks in it.
To rebuild your database, you can start the client with the -reindex flag (if you exit while rebuilding, it will pick up where it was stopped on the next run).
One workaround that helps in some cases is running with -par=1, making validation only run in one thread. This seems to reduce the load enough to make some CPUs not cause errors anymore.

Thanks very much, this seems to be working. It is not stuck any more, but it's not passed the problem block yet. I'll let you know.

This just happened to me. I was reindexing. The weird thing is that it started from the beginning, I was beyond height 280000 already. I am running the version that counterparty recommends, with "addrindex" patch.

After more browsing, I most likely got hit by the OpenSSL issue.


text:
Getmemorypool responses
What is the expected response for a getmemorypool RPC call to a standard client, when calling it with data field? I'm mainly interested in such factors as:

Will the call return true if a sent block is not at the end of a block chain (for example, creates a fork or otherwise invalidates some other blocks)?
Will the call return false if the client is BitcoinQT, not bitcoind?
Will the call return true if the same block is submitted more than once?
Will the call return true if the block does not contain all transactions sent earlier, or contains some transactions that the client does not know about?
Are there any other specific cases one should know about when coding for this call?

BIP 22 is the draft specification for getmemorypool, and should answer all the questions you asked.


text:
Which nVersion bit is the "hard fork bit?"
A 2015 draft BIP suggested using a "hard fork bit":

The most significant bit in nVersion is defined as the hardfork bit. Currently, blocks with this header bit setting to 1 are invalid, since BIP34 interprets nVersion as a signed number and requires it to be >=2 (with BIP66, >=3). Among the 640 bits in the block header, this is the only one which is fixed and serves no purpose, and therefore the best way to indicate the deployment of a hardfork.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html
If bit indexes increase from left to right, then I imagine the hard fork bit occupying index 31, marked as * below (nVersion is a 32-bit value).
0                   1                   2                   3
0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1
                                                              *

According to the proposal, setting bit 31 of nVersion should cause a block to be rejected as invalid.
BIP-9 places further constraints on the available bits, specifically, bits 0-2 must be set as [0, 0, 1]:

Blocks in the STARTED state get an nVersion whose bit position bit is set to 1. The top 3 bits of such blocks must be 001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive.

https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
In addition, BIP-9 arranges version bits in increasing order from right to left. That is, version bit 0 is nVersion bit 31, version bit 1 is nVersion bit 30, and so on.
But if this were the case, then version bit 0 would be off-limits. BIP-9 says nothing about this, and in fact BIP-68 was signaled using version bit 0:

This BIP is to be deployed by "versionbits" BIP9 using bit 0.

https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
My questions are simple:

Given my diagram above, which nVersion bit index is the "hard fork bit?"
If I'm correct in my interpretation (I don't believe I am), then how could BIP-68 have been signaled without causing the blocks doing so to be rejected as invalid?

Update: the source of my confusion was thinking that nVersion bit indexing and version bit indexing ran in opposite directions. The don't. To signal readiness for a proposal using version bit 1, for example, nVersion bit 1 is set. BIP-9's rules activate when an nVersion signature is detected. This signature is bits 29-31 set as 1, 0, and 0, respectively. This leaves bit 31 unset.
Peter's answer addresses question (1) above.
As for question (2) BIP-68 signaling didn't cause block rejection because bit 0 was being set, not bit 31.

Bit 31 is sometimes referred to as the hard fork bit.
BIP34 put a constraint on version numbers to be 2 or higher. As the block version is a 32-bit signed integer, setting its highest bit results in a negative number, which would violate BIP34.
As a result, any usage of that bit results in a backward incompatible change to the rules - a hard fork - that is obvious to all participants in the system.

That seems to match my interpretation. If so, how could BIP-68 signaling call for setting bit-31 and not result in those blocks being rejected?

BIP68 gives meaning to bit 31 of the nSequence field of a transaction. The hardfork bit is bit 31 of the nVersion field of a block.

Oh, I see, you're confused by bit order. Don't think of bits as having an order - it's not well defined, depends on the hardware, and is generally irrelevant. nVersion is an integer, and bit X of it is the value of (nVersion >> X) & 1.

BIP-68's deployment plan calls for setting version bit 0 (nVersion bit 31) as a signal. I understand the functionality of BIP-68 was to assign meaning to the nSequence field. My question comes from the deployment mechanism for BIP-68, which requires signaling nodes to set nVersion bit 31. At least that's what it looks like.

I don't understand where you read that. BIP68 was signalled for using nVersion bit 0, not bit 31.

"This BIP is to be deployed by "versionbits" BIP9 using bit 0." (from BIP-68) AFAICT, versionbits bit 0 is bit 31 in my diagram.

Bit 0 is bit 0, bit 31 is bit 31. I don't understand why you think there is a swap?

Let us continue this discussion in chat.


text:
How can I determine the block height on a certain day?
Is there an easy calculator to determine the block height on a certain day?
i.e what was the block height on 14th October?
This was asked by JoeNakamoto on Twitter.
There is a related question on converting block height to UNIX time here.

There is blockheightat.sh script included in my bitcoin-scripts (requires running Bitcoin Core). Examples:
$ ./blockheightat.sh 2022-10-14
758524
$ ./blockheightat.sh "2022-10-14 13:37"
758612

There is a script here from jsarenik that does this.
You can run it like this:
$ ./grepdate.sh 2022-10-14
758593

Alternatively there is a Google Sheets that seems to work.
Thanks to those on Twitter who answered.

You can also estimate it like this:
h = (t-1213787930) / 596.066637

where t is the unix timestamp as stored in the block header.
And h is the block height.
These values were derived using a least-squares fitting over the last 160000 blocks.
Note that theoretically bitcoin attempts to make the factor close to 600, but in practice the value of 600 is not reached.


text:
Why is my bitcoin core not downloading any blocks?
I am using Centos 7 and I installed the newest version of bitcoin core.
I just want to run a full node to download all the blocks.
According to their documentation, the first time we start bitcoin core, it will start automatically to download the blocks.
This is my /.bitcoin/bitcoin.conf file:
datadir=/.../blocks
server=1
txindex=1
rpcport=8332
rpcuser=<something>
rpcpassword=<something>

After I run bitcoind -daemon, bitcoin-cli getblockcount gives me 0.
Is there anything wrong with the ports?
I tried netstat -na | grep 8333, and it gives me this:
tcp        0      0 0.0.0.0:8333            0.0.0.0:*               LISTEN
tcp        0      1 <***>:40706     <***>:8333     SYN_SENT
tcp6       0      0 :::8333                 :::*                    LISTEN

And netstat -na | grep 8332 gives me:
tcp        0      0 127.0.0.1:8332          0.0.0.0:*               LISTEN
tcp6       0      0 ::1:8332                :::*                    LISTEN

Output of bitcoin-cli getblockchaininfo:
{
  "chain": "main",
  "blocks": 0,
  "headers": 0,
  "bestblockhash": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
  "difficulty": 1,
  "mediantime": 1231006505,
  "verificationprogress": 1.835803992430469e-09,
  "initialblockdownload": true,
  "chainwork": "0000000000000000000000000000000000000000000000000000000100010001",
  "size_on_disk": 293,
  "pruned": false,
  "softforks": {
    "bip34": {
      "type": "buried",
      "active": false,
      "height": 227931
    },
    "bip66": {
      "type": "buried",
      "active": false,
      "height": 363725
    },
    "bip65": {
      "type": "buried",
      "active": false,
      "height": 388381
    },
    "csv": {
      "type": "buried",
      "active": false,
      "height": 419328
    },
    "segwit": {
      "type": "buried",
      "active": false,
      "height": 481824
    }
  },
  "warnings": ""
}

Result of bitcoin-cli getnetworkinfo:
{
  "version": 200000,
  "subversion": "/Satoshi:0.20.0/",
  "protocolversion": 70015,
  "localservices": "0000000000000409",
  "localservicesnames": [
    "NETWORK",
    "WITNESS",
    "NETWORK_LIMITED"
  ],
  "localrelay": true,
  "timeoffset": 0,
  "networkactive": true,
  "connections": 0,
  "networks": [
    {
      "name": "ipv4",
      "limited": false,
      "reachable": true,
      "proxy": "",
      "proxy_randomize_credentials": false
    },
    {
      "name": "ipv6",
      "limited": false,
      "reachable": true,
      "proxy": "",
      "proxy_randomize_credentials": false
    },
    {
      "name": "onion",
      "limited": true,
      "reachable": false,
      "proxy": "",
      "proxy_randomize_credentials": false
    }
  ],
  "relayfee": 0.00001000,
  "incrementalfee": 0.00001000,
  "localaddresses": [
    {
      "address": "<***>",
      "port": 8333,
      "score": 1
    }
  ],
  "warnings": ""
}

I know the question is kind of dumb but please help me figure out what's wrong.
Edit:
bitcoind always freezes at this:
Loading addresses from DNS seed seed.bitcoin.sipa.be
2020-07-07T04:16:00Z Loading addresses from DNS seed seed.btc.petertodd.org
2020-07-07T04:16:00Z Loading addresses from DNS seed seed.bitcoin.sprovoost.nl
2020-07-07T04:16:11Z Loading addresses from DNS seed dnsseed.bluematt.me
2020-07-07T04:16:12Z Loading addresses from DNS seed dnsseed.emzy.de
2020-07-07T04:16:12Z Loading addresses from DNS seed dnsseed.bitcoin.dashjr.org
2020-07-07T04:16:23Z Loading addresses from DNS seed seed.bitcoinstats.com
2020-07-07T04:16:23Z Loading addresses from DNS seed seed.bitcoin.jonasschnelli.ch
2020-07-07T04:16:23Z 202 addresses found from DNS seeds
2020-07-07T04:16:23Z dnsseed thread exit

Is there anything wrong?

What is the output for bitcoin-cli getblockchaininfo?

@RaghavSood I just edited it in the question.

can you run bitcoind without the daemon option? do you see any error?

@vincenzopalazzo oh yea there's an error: Error: Cannot obtain a lock on data directory /home/zmengaa/.bitcoin. Bitcoin Core is probably already running. I think I also used another machine to run bitcoind a few days ago. Maybe that's the problem.

I can delete the whole ./bincoin folder and run bitcoind again, is it gonna help? @vincenzopalazzo

Maybe yes, but is the bitcoin core is already running, the bitcoin core should be print another error. I think that you run bitcoin with two different used (like sudo and you normal used). Before to cancel this directory you can run chmod 777 /home/zmengaa/.bitcoin

I edited it in the post, should it be right? Do I just wait for it to continue or is there anything wrong? Thanks! @vincenzopalazzo

Mh I posted the wrong command, I'm sorry, I think that you should use the recursive command, try to run this  run sudo chmod - R 777

What is the result of bitcoin-cli getnetworkinfo? From the other info you have posted, it looks like you don't have any connections. Make sure there isn't anything preventing you from making outbound connections to port 8333.

I edited it. @AndrewChow But I'm not sure what the output means. Onion is not reachable, so do i need to do any setting about "tor" or something? Thanks!

Unless you specifically want to be using tor connections, there's no need to setup tor stuff.

The problem is that you have 0 connections. Your node isn't connecting to other nodes on the network. It is able to connect to the DNS seeders and get node IPs to connect to, but something is preventing it from making the actual connection itself.
Make sure there isn't something preventing your node from making outbound connections to port 8333. This could be a firewall, an antivirus software, or even your Internet service provider.


text:
How to use Electrum with a local regtest network?
The problem

I have a regtest network running in 127.0.0.1:18443.
I can access to regtest with user:123.
I would like to use Electrum (v4.0.2) with my local regtest but I cannot realize how to do that.

What I tried
When I run:
electrum --regtest

The Electrum console opens as expected but the status is not connected:

My ~/.electrum/regtest contains:
{
    "auto_connect": false,
    "blockchain_preferred_block": {
        "hash": "0f9188f13cb7b2c71f2a335e3a4...........a11466e2206",
        "height": 0
    },
    "check_updates": false,
    "config_version": 3,
    "dont_show_testnet_warning": true,
    "gui_last_wallet": "/home/xxx/.electrum/regtest/wallets/default_wallet",
    "is_maximized": false,
    "oneserver": false,
    "recently_open": [
        "/home/xxx/.electrum/regtest/wallets/default_wallet"
    ],
    "rpcpassword": "123",
    "rpcuser": "user",
    "server": "127.0.0.1:18443:s",
    "show_addresses_tab": true
}

I changed rpcpassword and rpcuser with the user:pass of my local regtest, but I'm still unable to connect Electrum with my local network.
My questions

What am I doing wrong?
What does the "s" mean in 127.0.0.1:18443:s?
What's running in 127.0.0.1:51002?

@Prayank Interesting, I'll take a look.

Electrum doesn't connect directly to Bitcoin nodes. Instead it connects to Electrum servers using the Electrum protocol. These servers run Bitcoin nodes and additional Electrum server software in order to provide the data that Electrum actually needs to operate. So you need to be running an Electrum server software that connects to your node and then connect Electrum to that Electrum server.
Some Electrum server software:

Electrum Personal Server: EPS is designed for use with a single Electrum wallet and is probably the easiest to get an Electrum wallet connected to a full node
Bitcoin Wallet Tracker with Electrum plugin: BWT is like EPS but does more stuff and isn't just limited to Electrum
ElectrumX: ElectrumX is the official Electrum server software. It is a full fledged Electrum server software that is intended to be used by any connecting Electrum wallet. As such, it indexes the entire blockchain. If you want to do experimentation with the Electrum protocol, you may want to use this.
Electrs: Like ElectrumX but written in Rust.

Hi, Andrew, thanks for the clarification. I'm able to run electrum --testnet and connect to testnet network (receive funds from faucets, send money to other address, etc) without setting up any of the servers you've mentioned. So, why do I need EPS or ElectrumX when running electrum --regtest? Sounds like a wired design hack.

@Cartucho Testnet is a public test network. There are people who run Electrum servers on testnet in the same way that people run Electrum servers on mainnet. When you use testnet, you are connecting to those public testnet servers. However regtest is a private testing network. This means you need to setup all of the relevant infrastructure yourself.


text:
Segwit2x/btc1 block header changes: wipeout protection for SPV nodes?
Are there any current plans for segwit2x/btc1 to change the block header in a backward-incompatible way, either permanently or with a signal block (e.g., "hard fork bit"), before it goes live? This is sometimes referred to as "wipeout protection."
AFAIK, btc1 will require a large signaling block. The problem is that SPV nodes won't be able to detect it because by definition they avoid downloading entire blocks. In other words, an SPV node knows nothing about block size (and can know very little about block bodies in general).
I have found nothing about this and want to confirm that the plan is really to leave the block header untouched.
If so, it looks like SPV nodes will have no way to distinguish s2x and Bitcoin chains. They will follow whichever chain has the most proof-of-work - even if that chain contains invalid block bodies. This would have serious implications for the security of funds controlled by SPV wallets.

From following most of what has been going on in the btc1 repository, it is S2x's express plan to take along SPV wallets with their hard fork. Therefore, they are limiting wipeout protection to anything that doesn't break SPV wallet compatibility. Most notably they don't plan on using the proposed hardfork bit. I believe they are going to require a block with a base size greater than one megabyte (srsly!) for the block at fork height: ISSUE/PR

Replay protection is an important, but separate issue. I'm specifically interested in what is sometimes called "wipeout protection." Wipeouts can degrade the security of SPV users of either chain, and so there aught to be more of an incentive to adopt it in btc1. Still, the discussion you linked does suggest that neither wipeout protection nor replay protection will be part of s2x. I've updated my question to make it more specific.

@RichApodaca: Sorry, didn't pay enough attention. I'll edit my answer.

Segwit2x/btc1 does not contain any wipeout protection for SPV wallets. Their only wipeout protection is that the block at their forking height must have a block weight greater than 4 million weight units. This means that SPV wallets will not be able to easily distinguish which chain that they are using. This will cause a situation similar to that of Bitcoin Cash's before their emergency difficulty adjustment went into effect.

Are you sure about the weight? I think they're actually tying it to "base block size": if (::GetSerializeSize(block, SER_NETWORK, PROTOCOL_VERSION | SERIALIZE_TRANSACTION_NO_WITNESS) <= MAX_LEGACY_BLOCK_SIZE)

"Base block size" is directly tied to block weight, although if they are implementing it with "base block size", they may have behavior that is different from what they intend.

I'm confused by your statement that "base block size is directly tied to block weight". There's quite some range on the ratio of stripped size vs vsize of transactions.


text:
Since Bitcoin Core 0.14.0, how does a node with default settings compute the dust limit?
In earlier releases of Bitcoin Core, the dust limit was defined as an output whose spending would require more than 1/3 of its value as fees:
https://bitcoin.stackexchange.com/a/41082/10845
The minimum fee was in turn defined by minRelayTxFee, a user-adjustable setting that defaulted at one point to 1 satoshis/byte.
The release notes for 0.14.0 have this to say about minRelayTxFee:

Since the changes in 0.12 to automatically limit the size of the mempool and improve the performance of block creation in mining code it has not been important for relay nodes or miners to set -minrelaytxfee. With this release the following concepts that were tied to this option have been separated out:

incremental relay fee used for calculating BIP 125 replacement and mempool limiting. (1000 satoshis/kB)
calculation of threshold for a dust output. (effectively 3 * 1000 satoshis/kB)
minimum fee rate of a package of transactions to be included in a block created by the mining code. If miners wish to set this minimum they can use the new -blockmintxfee option. (defaults to 1000 satoshis/kB)

The -minrelaytxfee option continues to exist but is recommended to be left unset.

https://bitcoin.org/en/release/v0.14.0
Unfortunately, this statement doesn't clarify the question of how the dust limit is computed going forward. In particular, the statement "calculation of threshold for a dust output. (effectively 3 * 1000 satoshis/kB)" is confusing. It appears to mean that the dust limit is hard coded with a fee density of 1 satoshis/byte, yielding a minimum output value of 546 satoshis ((34 + 148) * 3, as per previous policy). But this doesn't make much sense given that the market fee density for next-block confirmation is routinely above 100 satoshis/byte, and changes daily.
Assume I'm running a 0.14.0 node with default settings. What's the effective dust limit for this node, and how is it calculated, given that I'm being instructed not to touch minRelayTxFee?

The dust limit in 0.14.0+ is set by a value called the dustRelayFee. This is separate from the minRelayTxFee although it has the same default value of 1 satoshi/byte. That is what is used to calculate dust now, and the dust calculation is still the same as before. So the default dust limit in 0.14.0+ is 546 satoshis. You can configure the value you set for the dustRelayFee by using the -dustrelayfee=<n> option.
In Bitcoin Core 0.15.0, this will change slightly. The calculation changes to be that the dust limit is the amount that we would pay to spend the output at the dustRelayFee. To keep the dust limit the same as before at 546 satoshis, the dustRelayFee is increased to 3 satoshis/byte.

is there an RPC call that can return the minimum amount allowed to be sent in a tx?

AFAIK, there is not.


text:
Possible error in the white paper Calculations section?
Section 11 presents calculations of the probability of double spending, P(z, q), given an attacker relative hash rate q and a block count z.

P(z, q) can only be understood by knowing exactly what z represents. From the Calculations section:

The recipient waits until the transaction has been added to a block and z blocks have been linked after it. He doesn't know the exact amount of progress the attacker has made, but assuming the honest blocks took the average expected time per block, the attacker's potential progress will be a Poisson distribution with expected value... [my emphasis]

Clearly, the transaction has one confirmation. The transaction "has been added to a block" and zero blocks have been linked after it. In other words, the transaction is hosted by the tip of the active chain.
Nevertheless, the probability of this transaction being double-spent is 100%, regardless of the attacker's hash power. In fact, the probability is 100% even with no active attacker.
This contradiction is reinforced by the equation Satoshi gives:

When z = 0, P = 1.0.
What am I missing?
There is at least one answer to this question that claims that z=0 means that the transaction is unconfirmed. That's inconsistent with the paragraph I quoted.
There appears to be an error somewhere in the Calculations section leading to a contradiction. I'm looking for an answer that either points the error out, or explains what I'm misinterpreting.
EDIT
One response offers the suggestion that Satoshi may have been talking about a Finney attack. In other words, the attacker has already pre-mined a block before attempting the double spend. Assuming the attacker can propagate blocks faster than the network, there would be a 100% chance of success. In this scenario, the attacker and network are tied at z=0, and given faster block propagation, the advantage goes to the attacker.
However, the Calculations section explicitly disallows a Finney attack. In particular, the attacker has mined no blocks prior to the attack:

The receiver generates a new key pair and gives the public key to the sender shortly before signing. This prevents the sender from preparing a chain of blocks ahead of time by working on it continuously until he is lucky enough to get far enough ahead, then executing the transaction at that moment. Once the transaction is sent, the dishonest sender starts working in secret on a parallel chain containing an alternate version of his transaction.

I believe at least part of the problem is mathematical. Specifically, Satoshi gives the value of λ as:

When z=0, λ=0.
Referring back to Satoshi's original derivation of double-spending probability P(z, q):

λ=0 means that every term is zero, independent of hash rate. In other words, the attacker can never double spend.
This contradicts the "rearranged" form of the equation, which gives a probability of 100% as noted above.
I'm no math specialist, but from what I can tell, the two forms of P(z, q) that Satoshi gives are not equivalent for z=0. In fact, they give the opposite answer:

in one case, the attacker always fails, P(z, q) = 0
in the other case, the attacker succeeds with 100% probability, P(z, q) = 1.

Either way, the attacker's relative hash rate doesn't factor into the analysis when z=0.
I realize that other treatments of this problem have appeared. For now, I'm just interested in fixing the apparent problem with the white paper's analysis for z=0.
Is this possible, and if so, how can I do that?

One way to interpret this is that there is, indeed, a mistake.
A more charitable interpretation is that there are two unstated assumptions:

The attacker is performing a Finney-like attack - that is, he has already pre-mined a block before even attempting the transaction. So while z=0 means the honest network has 1 block, so does the attacker.
The attacker wins propagation races. So if there is a leaf attacker block with the double-spending transaction, and a same-height leaf honest block with the original transaction, the attacker's transaction will be accepted.

Together, these give a 100% chance of success for the attacker if there is only 1 confirmation.
In my own paper on the subject, I have explicitly stated the assumption that the attacker already has one block (while removing a different simplifying assumption).

This makes sense, thanks. In that case, shouldn't the probability of the attacker already having mined the block be factored in? In other words, an attacker with low relative hash rate will not very often be in a position to start the attack in the first place.

@RichApodaca: The probability that the attacker has already mined a block is 100%, given that he has already mined a block. That is, a low-hashrate miner will not have a lot of opportunities to perform an attack - but he will not even attempt to purchase from the merchant until he has an opportunity, and when he does, it will be when he has found a block. So the attack will definitely succeed if the merchant doesn't wait for confirmations.

@RichApodaca: The attacker will also need to complete the purchase itself immediately, before the block he has just found is orphaned, just like in the Finney attack. It is something of a stretch, which is why arguing that Satoshi was simply careless with his calculations is just as reasonable.

The Calculations section explicitly rules out a Finney attack: "Once the transaction is sent, the dishonest sender starts working in secret on a parallel chain containing an alternate version of his transaction." In other words, the attack begins with no blocks mined by the attacker.

Does z = 0 mean that a transaction hasn't yet been confirmed, or that it has been confirmed but its block hasn't yet been extended?

Z = 0 means that the transaction has not yet been confirmed. The probability is 1 because, under the assumptions made for these calculations, unconfirmed transactions can always be considered insecure and double spendable by the attacker regardless of their hashrate.

z=0 clearly means that the transaction has one confirmation: "The recipient waits until the transaction has been added to a block and z blocks have been linked after it." In other words, the transaction has been added to the tip of the active chain.

@RichApodaca z=0 clearly represents the point where the race starts (honest chain vs attacker chain). If you want to be pedantic about it, assume that both chains have one block each (same height).


text:
What indexes does a Bitcoin Core node maintain to serve Bloom-filtered requests and SPV peers?
The Wiki makes this statement:

It [getdata message] can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not). [my emphasis]

https://en.bitcoin.it/wiki/Protocol_documentation#getdata
Yet "Connection Bloom filtering" (BIP-37) seems to require just such an index system:

The filter can be tested against arbitrary pieces of data, to see if that data was inserted by the client. Therefore the question arises of what pieces of data should be inserted/tested.
To determine if a transaction matches the filter, the following algorithm is used. Once a match is found the algorithm aborts.

An ordered list of criteria is then given.
It appears that a node supporting such a filter would also need to maintain an index (or several), or risk denial of service attacks.
I saw this question:
70% of nodes accept Bloom filters, despite DoS attack vector?
which doesn't appear to answer the question about indexes.
I saw this question:
Is there a way to index transactions so that filterload commands can be answered without iterating through all transactions in a block?
the only answer to which implies, without stating explicitly, that no indexes are created at all.
What indexes does a node create for the sole purpose of supporting Bloom filtering for SPV nodes?
If none are created and transactions are filtered on the fly, how can this statement in the linked question above be true?

Thus you can easily trigger exactly the same DoS attack by just using regular getdata requests on large blocks over and over. You don't need Bloom filtering. If you don't want to actually download the blocks just don't TCP ACK the packets and then FIN after a few seconds .... the data will all have been loaded and be sitting in the send buffers.

Bitcoin Core maintains an index of blocks and their locations on disk. When someone requests a block, it pulls the block from disk, and if they used BIP 37, it will run the block through the filter. The block index is required for normal node operation; there are no other indexes created. The only "index" like thing is the mempool, and that is maintained solely in memory. That is where transactions come from if they are requested; confirmed transactions will not be in the mempool and cannot be relayed.
For BIP 37, things are only tested against the filter prior to being relayed to a node that had set a filter. The only things that will ever be relayed are unconfirmed transactions and entire blocks.

If none are created and transactions are filtered on the fly, how can this statement in the linked question above be true?

The statement is true because a node can set a filter and request blocks and unconfirmed transactions from the node. The node will then pass those blocks and transactions through the filter before relaying them.

Fragmenting transactions and running the pieces through a Bloom filter as BIP-37 recommends consumes node resources, doesn't it? If a node just sends without filtering, then those resources need not be consumed. Doesn't filtering transactions on the fly open a DoS attack vector that doesn't exist when blocks and mempool are sent without filtering?

Yes, it does consume resources and can potentially lead to DoS attacks. There are also ways to mitigate DoS attacks such as rate limiting. That is why most developers consider BIP 37 to be bad, but so far, it is the only thing that supports lightweight wallets in a decentralized manner.

The design of BIP 37 is more or less incompatible with any kind of indexing in any case, as the serving node is required to continually modify the filter in order on a transaction by transaction basis.

authors: Дмитрий Пушин


text:
Is there a place or tool to monitor all addresses for unmoved coins?
I've been looking for a way to easily monitor all address with a balance, that the balance has not moved/changed for a period of time (based on a criteria such as 1 year). Is there a site/tool already available? or do I need to build it myself? if I have to build it, where can I start to look for the relevant data? Thanks

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

In aggregate, this is shown in BitcoinDays Destroyed (e.g., unspent for one year or more).
This can be done with some degree of effort using the Bitcoin API.
v0.7 getrawtransaction gives you access to transactions even those not in your wallet.

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

There are other tools that you can use to build this capability as well.

libBitcoin
Armory (see Extras)
Bitcoin ABE

I'm not sure how to read that BitcoinDays Destroyed chart, or if it is accurate. It fluctuates too much I think, like for the past month, it shows at some point there's only 180k unmoved coins? and there are spikes up to 14M? how to read this chart correct?

There is a no central place or tool yet, but there is a very informative paper by Adi Shamir one of the giants of cryptography.


text:
Is there any way for a script to depend on blockchain info?
The locktime opcodes OP_CHECKLOCKTIMEVERIFYand OP_CHECKSEQUENCEVERIFY indirectly allow for an approximate block number check, is there any way to obtain other information such as the previously mined block hash or current difficulty without having to rely on oracles?

No, by design.
Script evaluation gives an unconditional boolean output: valid or invalid. If script validation could depend on context, that would mean script validity would need to be re-evaluated any time that context changes, complicating reasoning about mempool transactions, the meaning of confirmations, as well just generally causing significant CPU cost to nodes that keep unconfirmed transactions around.
Note that neither OP_CHECKLOCKTIMEVERIFY or OP_CHECKSEQUENCEVERIFY actually let scripts depend on height/time information; they only depend on the locktime/height that's in the transaction itself. Validation of those locktime fields happens outside of script, which does mean that while transaction validity isn't entirely context-free (it can't be, because double-spending!), script validation never needs to be rerun.

What do you mean context changes? The context are the already confirmed blocks (aside from temporary forks) and the script validation would only require to take that into consideration in an immutable way

Confirmed blocks can change, that is context, as it is not committed to by the transaction itself. If there was some mechanism for transactions (not scripts) to only be valid in a chain which has a block with a specified hash as ancestor, then information about that block and its ancestry could in theory be made available to the script interpreter too.

I'm sorry but I don't understand what you mean, how can a confirmed block change? That would modify (and thus invalidate) its hash after all, so I assume you're meaning something different than I do?

No, but which block(s) have been confirmed can change from under a transaction. New ones can be added, old ones can be reorganized away.

Ah yes, that for sure, that's what I meant with temporary forks. But isn't the validity of a transaction checked in the context of the confirmed blocks so far after all? Otherwise double-spending would be possible as you stated, so I don't see a difference between that and e.g. a hypothetical OP_LASTBLOCKHASH pushing the parent block's hash to the the stack, the context of the confirmed blockchain must be respected either way

@TobiasKienzler Yes, transaction validity is checked in context, but script is not. Its validity is a pure function of data that is committed to by the transaction itself. Transactions can get relayed long before they make it into blocks (weeks in some cases), during which time scripts would need to be re-evaluated any time the context changes.

Maybe I've misunderstood/misremembered something fundamental then - are you saying a P2SH is executed/validated not by the block miner but already before by the relaying nodes? The script is evaluated upon block inclusion or not? Otherwise how can you be certain a node didn't sneak an invalid script into the mempool that just happens to exploit a loophole to pose as a valid transaction?

@TobiasKienzler Both. Script validation is performed when the transaction is relayed across the network already (before being included in a block), and its validity is cached. When transactions are seen in blocks, the scripts are validated again (but the already validated ones can just use the cached value). If all you care about is block validity, then the context is fixed and these concerns matter less. But the network needs to be able to reason about transaction validity before being included in blocks too (how do miners know what to include? what transactions can be built on by wallets?)

Ah I see, thanks for your elaboration! It's a bit of a pity, context depend scripting would make for some interesting features in the direction of smart contract like features, but then again that never was the scope of Bitcoin

@TobiasKienzler None of this means that context dependence is impossible - it just has to be designed such that script doesn't see it. After all, this has already happened with OP_CHECKLOCKTIMEVERIFY etc., by having an indirection through a constraint on the transaction outside of script (nLockTime for OP_CLTV, nSequence for OP_CSV). As a mentioned higher up, it would for example be possible to have a "mandatory block hash" field in transaction, making the transaction only valid in a chain descending from the specified hash, and then make properties of that block available to script.

Thanks! But that is purely theoretical and would require BIP first, right? The "mandatory block hash" idea could be interesting in the event of a hypothetical "fork wars" scenario, now that I think about it...


text:
How much can be stripped of a base58 address in a recoverable way?
Since P2PKH and P2SH addresses use Base58Check_encoding, the 4 byte checksum appended in binary contains some redundancy. Strictly mathematically speaking, those 4 bytes correspond to ca. floor(log(2^32)/log(58)+1) = 6 base58 "digits" (but 6 base58-digits encode 36 bits, i.e. probably only 5 instead of 6 can be omitted). But is this sound? In a 2^n base this would be trivial, but base 58 basically influences all bytes... Is there a recovery algorithm?

The checksum of Base58Check encoding is simply a truncated hash of the rest of the bytes. This means there is no recovery algorithm other than just brute-forcing until the hash matches.
That is one of the big advantages of the Bech32 address format proposed in BIP-173. It uses an algebraic BCH code which can actually correct errors rather than just detect them, and has better error detection/correction properties than Base58Check.
In both cases, however, it is strongly discouraged for code to perform any address recovery itself. You should report to the user that errors exist, and let the user fix them. Otherwise, you risk loss of funds.

Hmm the checksum is completely redundant so if you get an address with the last 4 bytes missing you could just recalculate the checksum no? You don’t have to brute force anything

If the checksum is the only thing missing, yes. But then you have no guarantee that the rest of the address is valid. If the checksum is missing that is quite concerning. So you should certainly not just add a checksum and use it.

Note that an address without its checksum is the same as just sharing the public key hash directly.

No worries, my question is basically "how vain can a vanity address get", I hope I didn't XY-problem this too much  But as @Mike stated, my question is mainly about omitting the checksum. In a power-of-two base this would be trivial since the checksum would then be exactly the last few bytes, but in base58 there's a mixture with higher order bytes which seems to render this a bit more complicated (though this might just be my lack of sleep...)

@TobiasKienzler you can omit up to log58(2^32) = 5.46 digits in base 58 and not lose any information as you said so basically up to 5 digits

@MikeD Exactly, that's the theory. I'm just unsure about the practical implication, if possible. I'll give an actual algorithm a shot later


text:
Must a lightweight wallet be connected to the same servers that were used years ago to receive money
My question is back in 2016 i purchased bitcoin not knowing nothing about it forgot i even had it they were i believe segwit or bip39 anyways when i got back into trying to locate my wallets no data is showing on my wallets someone told me somthing about a fork and changing software not really sure but my real question is when i go try and get back in my wallets do i need to be on the same path and server as when i did the actual transactions? Alot of my addresses start with bc1q if thats any help thank you for your time

my real question is when i go try and get back in my wallets do i need to be on the same path and server as when i did the actual transactions?

It probably depends on what wallet you were using. There are many different wallets. Your question is tagged electrum-server so you must be using Electrum.
If by path you mean "derivation-path" - yes, you need that to be the same.
Some lightweight wallets, also known as SPV wallets, which are typically used on a mobile phone, are linked to specific servers but I believe many can work with other servers that provide the kind of service needed by that specific wallet. Obviously you need to be very careful to use trustworthy servers and not just ones suggested by online friends. In the case of Electrum, I think anyone can download compatible server software such as this example and run it so that they can link their Electrum wallet to their own server. Presumably there are other people or businesses who run Electrum servers. Any honest server should provide the means to access (i.e. spend) your money using an Electrum wallet.
It doesn't apply to you but sometimes people use the word "wallet" for an online custodial account provided by a business. In that case you need to use the same servers provided by that specific business. Since businesses don't survive forever, and many disappear or otherwise fail, I believe this is the least reliable way to hold Bitcoin long term.


text:
Is a wallet just a collection of private and public keys?
There is a fundamental bitcoin concept I don't get. Am I correct in that all I "need" to send and receive money are a single address and its associated private key?
In other words, can't I just create an address and private key and print them off and store it in my desk? And in this case, if I print two adresses and private keys, couldn't my physical desk be considered a "wallet"?
I'm just trying to figure out what a wallet is specifically. Is this just some sort of file or folder that stores those private and public keys?
Thanks!

http://bitcoin.stackexchange.com/q/3173/659 talks about what the standard client's wallet.dat file actually contains, if you're interested in that.

Just be very careful about making sure you have backups of all your private keys. Typical clients create a new account to receive the "change" from every transaction they do, resulting in a new private key you need to have backed up or the change from that transaction is lost.

A wallet can be as simple as just a private key by itself even as software that has access to that can derive the public address from it.  So yes, that data alone can be considered a bitcoin wallet.
But you asked if that is all you need to send and receive so for that you will need software that uses the private key to spend the funds.  Sometimes the term "wallet" is used to refer not to just the data stored but transaction data as well, along with the software that can create transactions and do the accounting for them as well so that you can know your balance.
Proper vocabulary would describe wallet software as being a bitcoin client.  The bitcoin client from Bitcoin.org (also referred to as the "Satoshi" client) does this, and has a local wallet as well.
My Wallet from http://BlockChain.info/wallet is managed through a server, but the wallet itself is stored in your browser.  That type of wallet and client is termed a Javascript-based wallet.  Sometimes the term "hybrid wallet" is used, since to spend using My Wallet you need to use their hosted service where the transaction gets processed.
Another type of wallet is an e-wallet where the wallet data is stored by the service's operator.  An e-wallet can also be referred to as a "hosted wallet".  InstaWallet is one of these.  The just-launched Paytunia is another.  An account at an exchange which hold bitcoins for you is another type of e-wallet service.  Using a hosted wallet incurs risks involving trust extended to the wallet's operator.
But the simplest form of a wallet comes from http://BitAddress.org
It gives exactly what you describe -- a private key and a public address.  This happens to provide one of the most secure wallets as well.  The html source can be copied to a thumb drive and then used to create paper wallets from an "air gapped" system (such as a computer running a secure operating system perhaps using a LiveCD linux distribution) that has no connection to the network and is used for printing out paper wallets.

Brilliant. Both blockchain.info and bitaddress.org are exactly what I was looking for. thanks!

@Stephen Do you mean that you are receiving and sending BitCoins without a client installed on your computer?

But wouldn't you have to "send" your private key over in order for the "hybrid wallet" to help you make a transaction, or am I misunderstanding something?

To receive only, you don't need a client -- just BitAddress.org.
So that paper wallet would generally be useful only for a savings wallet.  If you want to spend from that wallet,  then the methods include using a local client that will import the key (e.g., Multibit) and spend the funds using that, or to use a service that imports the key and lets you spend the funds.  Mt. Gox's mobile app, for instance, will scan the QR code, import the private key, and issue a transaction that sweeps those funds into your Mt. Gox account. A variety of options, appropriate for a variety of security concerns.

Yes, the only thing you need in order to send coins is a private key (or some way to derive it). The address isn't strictly needed as it can be reproduced from the private key.
You can certainly create physical wallets, and some are offered for sale (e.g. Casascius physical bitcoins). In order to send the contained bitcoins you'll still need a computer to calculate the ECDSA signatures, and a computer (not necessarily the same one) to broadcast them on the internet.
The standard Bitcoin client stores in wallet.dat some information other than the private keys, such as your address book and the transactions that involve you.


text:
I sent money to a bitcoin wallet from Blizzcoin and there's nothing there?
Using blizzcoin.com I sent bitcoins to the address I have for the bitcoin wallet client, and it took forever to sync the blocks. Once it had finished I was expecting to see the money there, but saw nothing.  Can anyone explain or tell me how to resolve this?

Can you tell us what address you sent the coins to?

The coins have not been sent yet. You can check it out on blockexplorer.

Thank you. I can't seem to find an email address to ask if blizzcoin has sent them :(

blockchain.info would show if a transaction had been sent but was waiting for confirmations.  It shows nothing, so blizzcoin probably didn't send anything.  I've never heard of blizzcoin before.  Is it possible you were ripped off?

Looks like it arrived.

It's possible OP used the same address elsewhere.

According to blockchain.info the coins weren't sent yet.
Here's a post from another blizzcoin customer saying that it took 2 days for his purchased coins to be sent:

apparently because I Manually transferred money to them instead of ordering through their web interface, it wasn't an instant transfer of bitcoins.

Could that be your problem too?  How long has it been since you sent the money to them?


text:
Is there anything called anonymous or private bitcoins?
Are there different types of bitcoins? Is there anything called private or anonymous bitcoin which can not be traced?
This question may sound stupid but I am facing this question right now. I have a client who wants to pay in bitcoins. However the kind of bitcoins he is talking about I have never heard of.
For verification he opened a separate wallet for me from a website called www.fifthelement.io (I never heard of it). Then he transferred a bitcoin and 0.001 in that wallet. Then I transferred that bitcoin back to his wallet for testing. However the confusing part is that I checked these wallets
[![enter image description here][1]][1]
on blockchain.info, it does show the wallets but doesn't show any transaction history which I assume means no record on the ledger.
I am posting the image of that wallet. I know very little about bitcoins so help in this matter will be highly appreciated.

Edit: This is almost certainly a scam - I'm looking at the source right now, and they have replaced the actual Bitcoin seeds with IPs, so it is likely a cloned network that tries to trick you into accepting worthless coins. It may also steal your keys, but I don't have evidence for that yet.
Within Bitcoin, there is no form of private transactions (in the form that you will not see it on Blockchain.info).
Moreover, the website you linked to is almost certainly a scam - The footer claims that it is built by the Bitcoin Core Developers, which seems unlikely (archive.org). You can find the actual wallet/node built by them directly on Github -https://github.com/bitcoin/bitcoin.
It seems likely that they have either:

Created an altcoin network, and are distributing their own wallet that connects to their network while branding it as a Bitcoin wallet. This would trick you into believing you have received Bitcoin as payment, while you have actually received worthless coins from a cloned network. This would also explain why blockchain.info is not showing the transaction.
Distributed a malicious wallet client that is able to steal your keys in some way (or provide you with keys that are already compromised), so that if you receive actual Bitcoin, they can take it from you.

If your client wishes to pay in BTC, there are many safe ways to accept it. You simply need to download an actual, reliable bitcoin wallet, such as from the link above, or Electrum, or buy a hardware wallet such as a ledger or trezor.
Then simply provide the client with an address from your trusted wallet - As long as you receive BTC with multiple confirmations, you can be sure that it is valid. When dealing with someone who is already attempting to scam you, make sure you check multiple sources before considering the payment completed, such as checking your transaction on multiple, independent explorers, in addition to what your wallet shows you.

Thanks very much. Your answer has been very helpful.

I couldn't possibly add much more to the answer. Raghav nailed it. Never "use" a wallet someone tells you to use. If "testing" always confirm with a few blockchain explorers. If explorers fail to pick up the transaction, it's probably not the main chain.


text:
Loading to Bitcoin wallets
I've downloaded some bitcoin wallets because I am planning to load some amount in it using my ATM. But I don't know how. Will somebody help. How can I have some bitcoins in my wallet?

Firstly
Read

Help
I am new to Bitcoin, how can I get started?
How do you obtain bitcoins?
Can bitcoins be traced to scammers
scam with blockchain

Bitcoin "ATM"/BTM
Scrutinise "ATM" for fees etc to determine exactly how much BTC you will receive.
Open your wallet. Click the Receive button. Enter appropriate details (all aptional). Click the Request Payment button. Carefully write down or otherwise record the generated address. Details depend on exact wallet used.
Follow the "ATM" instructions and make sure you tell it to pay to the address generated by the wallet. You may need to type in the address or will be able to scan the QR-code.
Fiat ATM
Use a service like "local bitcoins" to find someone willing to swap your local currency for BTC.
Consider what you will do if the BTC don't show up for a few days (or never).
Meet them. See above re generated address. Give them your money and the generated bitcoin-address.
Hope they are honest.
Either
Take a careful note of the Transaction Id
After the transaction, wait half an hour and see if your wallet shows the amount of BTC you expected. If not, check your wallet is synchronised and/or wait a couple of hours.
Try doing a web-search for "blockchain explorer" and type in either your receiving address or the Transaction Id.