text:
Please help me to understand lightning-cli getinfo more
I have now clightning running for a month. I watch very often lightning-cli getinfo
Here I found in the first three weeks:
"msatoshi_fees_collected": 0

A week ago it changed to
"msatoshi_fees_collected": 1445

and since today:
"msatoshi_fees_collected": 50483

Now my questions:

I believe it is my earnings resulting from using one of my 36 channels. Which one(s)?
I want to know my channel info including name, address of nodes and fundings on both ends.
Is there a skeleton for a python program available that could fetch info and put it into a table like an excel sheet?
I got this message:

I created a channel with you. If any of your channels to
  TrueVision.club, LightningTo.Me, or blindedbythelight has all local
  balance and no remote balance, then I can help equalize those balances
  for you. Doing so would also mean my channel to you would have local
  and remote balances more equalized so there wouldn't be a need for you
  to create a channel back. It requires a bit of coordination so I
  understand if you'd rather not. Feel free to create a channel back if
  you want.

Frankly, I don't understand it. What should I do? How can I see what happen here? RENE, I need your help ;-)
bye
Ronald

First of all yes these are your earnings from routing. You can check lightning-cli listforwards to get a list (in json) to see through wich channel routings have been attempted and settled or failed. In particular you can analyze the routing fees per channel from the output of that command.
If you are interested in channel balances you can use lightning-cli listfunds to see how much balance is on which side of the channel.
As for the message you received someone offered you to balance their channels through you by asking how your capacity is organized on particular channels. You can find that information with the above mentioned listfunds command. You also have the power to share this information. Morally you should have the consent of your channel partners.
As for python: Checkout my Hack a LAPP video series or my git repo for the code of that LAPP that shows how to interact with the Lightning rpc interface.
most important lines will be:
from lightning.lightning import LightningRpc
rpc_interface = LightningRpc("~/.lightning/lightning-rpc")
print(rpc_interface.listforwards())
print(rpc_interface.listfunds()["channels"])

If you know python it should be easy to adapt to xls output

Please provide a link to the specific episode, or code, don't advertise an entire series. Also if possible it'd be nice to include the relevant code here, in order to avoid cross-referencing things that might disappear.

Thanks for pointing this out. I will do that in the way you suggest - like I usually do - once I don't have a mobile client but a real interface.

No problem, judging from your other extensive responses this felt a bit different :-)


text:
How can create individual wallet for each user
I am going to develop an exchange website in PHP something like http://coinbase.com,
Now, I have setup the http://bitcoindevkit.com/ for it and its running fine generating new addresses in the same wallet,
but now I need to create a individual wallet for each user, so how can create individual wallet for each user and then I can able to create address on that wallet.

Unfortunately not answer for a PHP based product, but there is a Django + Python library out there for creating through-the-web manageable wallets: https://github.com/kangasbros/django-bitcoin You could look here for inspiration.

Thanks for your reply! Can this Django + Python library is able to create individual wallet for each user? and if it creates then can transfer is easily and speedly of Bitcoins from one wallet bitcoin address to another wallet bitcoin address?

Django is a web framework http://djangoproject.com/ Django-bitcoin library uses Django's user management and can automatically associate a wallet with a user profle.

Thanks! is this library also used by MtGox, Blockchain and Coinbase? Actually I am going to develop a exchange like coinbase, so this library will be best suitable for me?

Some library users are mentioned on the README which I linked before. I am pretty sure big players have their own internal codebase and not a library.

I would suggest using the bitcoind Account feature to track the different user 'wallets', this way a single 'wallet' or account can have as many address's as required which can all be be accounted for to that named account.  However I would also suggest not having this on your actual server, use a database to mirror what the bitcoin client shows, and hand actual withdrawals manually, (at least the larger ones) you may want to have a bitcoin daemon linked directly with a small amount of float to handle incidental day to day transactions.

source: Stack Exchange

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

sort: votes


text:
Has the TestNet ever been reset?
The Bitcoin TestNet is a network identical to Bitcoin in every respect except that the bitcoins on it are worthless because no one accepts them in payment or values them for anything other than testing purposes.  In essence, TestNet btc are valuable because they are worthless, allowing for useful experimentation when developing.
I read somewhere that one way the TestNet can be prevented from acquiring significant value and mining power is by being reset from time to time so that TestNet btc remain easy to mine and acquire for testing purposes.  This made me curious--has this ever happened before?

The current testnet is on its third iteration, somewhat unimaginatively titled testnet3.
It was put that way by this commit:

Testnet, Mark III

gavinandresen authored 2012-04-12

Before that, we had testnet2: (though we didn't call it that back then)

Reset testnet with a new genesis block

davout authored 2011-02-03

Before that, testnet:

Gavin's TEST network as -testnet switch, misc fixes
git-svn-id: https://bitcoin.svn.sourceforge.net/svnroot/bitcoin/trunk@168 1a98c847-1fd6-4fd8-948a-caf3550aa51b

s_nakamoto authored 2010-10-19

Man, sourceforge. Brings ya back, doesn't it?
Essentially, the devs want testnet coins to be worthless for two reasons:

to make them easy to mine
because it's nice to have a place to demonstrate attacks against bitcoin without actually disrupting the network. You can show that an attack is valid without costing people real money.

Also note that the testnet3 commit mentioned by @Nick does not specify a new timestamp for the genesis block. Thus, most testnet blockchain explorers will display the testnet2 genesis date ('2011-02-02') for block '#0' (instead of the actual testnet3 genesis date, which is something '2012-04'ish). This can be a major source of confusion. Also, it appears that between blocks 513 and 514 a sudden temporal shift occurs as the block time jumps from '2011-02-03' to '2012-05-24' unexpectedly.

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

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


text:
Multibit vs Electrum - which is more mature and secure?
I'm having a hard time finding objective reviews / comparisons of these two 'lite' clients. Can someone who tried them both give some comments?
Thanks

At the moment the Electrum client is more secure as the wallets are password protected.
I am the lead developer on MultiBit and am working on wallet encryption but it will take me a few weeks yet. There are a number of changes to make.

I think multibit shines in its ability to handle multiple wallets, which is very important to maintain anonymity and information leakage through "change" transactions.
However, Electrum is currently a much more feature rich client that allows you to create wallets and spend bitcoins from an air-gapped computer with no internet connectivity. This is the ultimate security for Bitcoins.


text:
How to reclaim unclaimed Bitcoins sent via Blockchain.info to Facebook/Email friends?
The FAQ says
What happens if the transaction is not claimed?
The private key the funds were sent to is saved in the senders archived addresses. The sender can reclaim the amount at anytime by sweeping that address, it's up to you how long you wait for the amount to be claimed. The address will be labeled "username (Sent Via XX)"
How is this done specifically?

Under Receive Money, Archived, find the address in question ("username (Sent Via XX"). Click this button to bring it back to active addresses:

Under Send Money, Custom, send all the money from that address to another address in your wallet. You can now archive the address again.


text:
What is the standard deviation of block generation times?
A block is generated every 10 minutes, on average.
What is the standard deviation of this distribution?
It seems to be a measurable property, not a calculable one.
Is there a chart of the standard dev over time somewhere (should be added to blockchain.info)?

Why do you ask about s.e. only versus robust statistics like quantiles?

Excluding complications like difficulty changes and temporary blockchain splits, you can model the block generation time as an exponential distribution.
An exponential distribution has a standard deviation equal to the expectancy value. This predicts a 10 minute standard deviation for Bitcoin.

Measuring the actual distribution isn't that easy. While each block contains a timestamp, that timestamp isn't very accurate, and sometimes the time difference between blocks is even negative.
The timestamp doesn't change over the course of a single share, and some miners deliberately use timestamps deviating from the actual time


text:
Is there a uniform measure of "difficulty", that when multiplied by price, will give "profitability of one hour of mining"?
I recently open Bitcoin Pie, a site that compares crypto-currencies.
Given the exchange rate in BTC, I would like to add another column that tells "relative mining profitability", regardless of the hardware used.
So, if at a given moment, BTC mines at difficulty X, NMC at Y, and FooCoin at Z, with the conversion rates to BTC being 1, N_BTC, and F_BTC respectively, just comparing X, Y*N_BTC, and Z*F_BTC should give an indication of which one a rational miner should mine.
What is a good number to use in the difficulty column? Where are the APIs for it? Is it just plain "difficulty", or is it some other number?
I'm not sure how to take merged Namecoin mining into account here. Any ideas?
CPU and GPU coins should not be measured on the same scale.

This might be very related, I wouldn't call it an exact duplicate though: http://bitcoin.stackexchange.com/questions/118/how-much-bitcoin-will-i-mine-right-now-with-hardware-x

its a cool idea

Note that the comparison doesn't work for Tenebrix because it uses scrypt. I like the idea, but it will only be useful until merged mining is available

@namt - merged mining of NMC & BTC is available. I added a separation between "CPU coins" and "GPU coins".

The comparison would still work for Tenebrix, actually, it's just that we can't compare hashrates on a 1:1 basis since a good hashrate for TBX is still in KH/s. Even though it's GPU-hostile we could compile for OpenCL anyway, pick a stock "reference card" (I vote for the venerable 5830) and run all the miners on that card to find their hashrates. If we did it this way then we could use Profit per 5830 per day as a metric.

The standard formula to determine the average profit per day for a given MH/s miner on a given blockchain is as follows:
(S/(D*4295))*60*60*24*R*P
Where S is the speed in MH/s rating of the miner, D is the difficulty rating, R is the reward (50 BTC/block for Bitcoin) and P is the price in USD of a single coin.
That I know of there is no standard profitability measure but it would be easy enough to create one given standard values of S. If for example we define the standard as S=100 MH/s then we could easily compare the profitability of mining various blockchains in the resultant USD calculation.

To add on to David's answer difficulty isn't a standardized between cyrpto currencies.  Some cryptocurrencies use equivelent difficulty but others have difficulty based on other starting values.  The best solution would be to devise a formula for each currency.  You then could pick a standard piece of hardware (say 5870 GPU and 2500K CPU) and show revenue per piece of hardware.

Which Bitcoin fork doesn't use standard difficulty? Even Tenebrix uses Bitcoin's difficulty calculations, it's just that the expected hashrate is so low that the difficulty is often < 1

I was just wondering where the 4295 comes from.  It looks like it might be a typo for 4095 (212-1).  But in fact it's an approximation for (216-1)*2**16 / 1e6 = 4294.90176.  Just in case anyone else was wondering...

http://bitcoinx.com/charts/ does something similar to what you ask for in the title.
They calculate (and chart) a profitability estimate in USD for 24 hours of mining with 100 Mh/s, so you could multiply their number by 1/24


text:
What's a good resource explaining the best ways to buy Bitcoin (noob friendly)?
We have a slew of questions about specific regions ... but I couldn't find a general, concise, good resource on how to buy Bitcoins.
This article offers too many choices and isn't noob friendly.
I want to link to the answer from the Newbie Guide I'm making.
An answer to this question should not be a specific way to buy (it will get stale, Stack Exchange does not handle staleness issues very well), but rather an external resource that is maintained and up to date (and will likely remain so in the future). I suggest a new Wiki entry that is noob friendly.
Update: I've opened up a new wiki entry for this, you can help edit it.

See this similar question for guidelines - http://bitcoin.stackexchange.com/questions/4178/what-is-a-good-resource-to-help-newbies-choose-their-first-wallet-s

Also http://bitcoin.stackexchange.com/questions/91/how-do-you-obtain-bitcoins

A link to some information on wallet choinces is here: http://bitxoin.blogspot.com.au/2013/07/bitcoin-newbies-start-here.html

LocalBitcons.com offers over-simplified guide in 6 languages on their site: https://localbitcoins.com/landing/en/ They aim to coverage all regions, payment methods and languages, so it should be pretty much non-US-focused there.

A guide almost needs to be one that provides results dynamically based on responses to questions.
The factors that matter are:

Where are you (country)?
How much are you looking to buy?
What payment methods can you use?
How soon do you need the bitcoins?
Is privacy / near-anonymity important?

Only once those are known can recommendations be made.
A fairly comprehensive list of methods exist on the Bitcoin wiki:

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

http://howdoyoubuybitcoins.com/
Seems to be attempting to provide this info and keep it up to date.

The linked page seems to be not working anymore. There is however now howtobuybitcoins.info, which seems to provide similar information or might even be the new site for the same webpage.


text:
How are transactions efficiently distributed to network nodes before inclusion within blocks?
How does the bitcoin core efficiently distribute transactions so that they are added to node transaction pools to be inserted into a future block?
I understand that each bitcoin node has a list of peers which they are in communication with.  As an originating node makes a payment, they send the payment across their peer network, which then continues the distribution process by forwarding the transactions to the peers within their peer list.
How is this process effeciently executed, such that transactions sent from one peer, sent numerous times across the network as it is distributed?  (For further clarification of the problem, see my Problem Outline below.)
In other words, how does a node resolve which peers to send new transactions to so that the transactions can be included into their local transaction pool?  If peer filtering doesn't take place, then the result would be a considerable amount of redundant, network traffic.
PROBLEM OUTLINE
Consider the following...

Distribution level #1 - Originator (A) sends a transaction to peers (B) & (C).
Distribution level #2 - Peer (B) forwards the transaction to peers (D) & (E), & peer (C) forwards the transaction to peers (F) & (G).
Distribution level #3 (Partial) - Peer (D) forwards the transaction to (C) and (G).

This is where we see the problem!  Peer (D) is completely unaware that nodes (C) and (G) have already received this transaction.  At best, (D) can only know that nodes (A)->(B)->(D) have received this transaction.  Since (D) is completely unaware of the state of the transaction in nodes (C), (E) & (F), peer (D) can potentially forward the transaction along to a high number of peers that are aware of the transaction.
Scale this to thousands of nodes and thousands of transactions and you could have a BIG problem.  How is this resolved?

Have a look into the specifications https://en.bitcoin.it/wiki/Protocol_specification
Check the "inv" --> "getdata" --> "tx" sequence of transaction distribution

Thank you.  Wow, that is how I mentally outlined the possibility.  I guess this is efficient, but it seems like advertising data can become a huge network bloat, with time.

Each node advertises data only to its peers. So, the incoming & outgoing traffic depends on the number (and size) of transactions, but does not depends on the size of network itself.

Yes, I understand. However, as the network increase and the number of transactions increase, total-network traffic should expand exponentially, correct? This is ultimately a graphing issue but I'm not to familiar with graphs. I was just curious of how BTC solves this problem (or if I'm missing something and it's not an issue at all!)

The effective number of transactions is also limited by current protocol rules. Bitcoin miners solve ~6 blocks per hour, block can not be larger than 1 megabyte. Also there are some anti-flood mechanisms which prevent flood.

Would you happen to have any links to articles/wiki details, regarding the flood prevention?


text:
lightning node data visibility on explorers
I'm trying to set my first c-lightning node with docker-compose using image from https://hub.docker.com/r/elementsproject/lightningd. currently, my node can connect and open channel with other nodes (and I can open a channel to the node just fine), but it's still not updated (ie has no information) on most explorers.
the following is result of getinfo and listconfigs
getinfo
{
   "id": "03db40337c2de299a8fa454fdf89d311615d50a27129d43286696d9e497b2b027a",
   "alias": "TestName",
   "color": "fff000",
   "num_peers": 3,
   "num_pending_channels": 0,
   "num_active_channels": 3,
   "num_inactive_channels": 0,
   "address": [
      {
         "type": "ipv4",
         "address": "68.183.195.14",
         "port": 9735
      }
   ],
   "binding": [
      {
         "type": "ipv4",
         "address": "172.18.0.3",
         "port": 9735
      }
   ],
   "version": "v0.7.1-906-gf657146",
   "blockheight": 601917,
   "network": "bitcoin",
   "msatoshi_fees_collected": 0,
   "fees_collected_msat": "0msat"
}

listconfigs
{
   "# version": "v0.7.1-906-gf657146",
   "lightning-dir": "/root/.lightning",
   "wallet": "sqlite3:///root/.lightning/lightningd.sqlite3",
   "plugin": "/usr/local/bin/../libexec/c-lightning/plugins/pay",
   "plugin": "/usr/local/bin/../libexec/c-lightning/plugins/autoclean",
   "plugin": "/usr/local/bin/../libexec/c-lightning/plugins/fundchannel",
   "network": "bitcoin",
   "allow-deprecated-apis": true,
   "always-use-proxy": false,
   "daemon": "false",
   "rpc-file": "lightning-rpc",
   "rgb": "fff000",
   "alias": "HubTest",
   "bitcoin-rpcuser": [redacted],
   "bitcoin-rpcpassword": [redacted],
   "bitcoin-rpcconnect": "bitcoind",
   "bitcoin-retry-timeout": 60,
   "pid-file": "lightningd-bitcoin.pid",
   "ignore-fee-limits": false,
   "watchtime-blocks": 144,
   "max-locktime-blocks": 2016,
   "funding-confirms": 3,
   "commit-fee-min": 200,
   "commit-fee-max": 2000,
   "commit-fee": 500,
   "cltv-delta": 14,
   "cltv-final": 10,
   "commit-time": 10,
   "fee-base": 0,
   "rescan": 15,
   "fee-per-satoshi": 1,
   "max-concurrent-htlcs": 30,
   "min-capacity-sat": 10000,
   "bind-addr": "172.18.0.3:9735",
   "announce-addr": "68.183.195.14:9735",
   "offline": "false",
   "autolisten": true,
   "disable-dns": "false",
   "enable-autotor-v2-mode": "false",
   "encrypted-hsm": false,
   "log-level": "DEBUG",
   "log-prefix": "lightningd(7):"
}

is there something wrong with this configuration? or is it another issue?
I understand that explorers update their node list irregularly, and as far as the node can open channels (and can be connected), everything is fine. but this thing has bugging me for weeks.

Your node is visible on explorers. I think what you mean to ask is why the explorers do not show additional data (like color, IP, alias) related to your node ID.

sorry, I must be confused with the definition. you are right, I'm wondering about alias color, and IP address. I'll update my question.

updated the docker image and put bind-addr to 0.0.0.0:9375 somehow fixed the problem for some unknown reason.

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


text:
How to confirm offline a transaction
Is it possible to confirm a transaction offline in the following scenario:

the "receiving" device is first online. There is no restriction at this point. Especially, it can prepare anything needed for the following steps.
the "receiving" device goes offline. It generates a payment request for a specific amount that was not known before and shares it to the "sending" device via an offline means, such as a QR code for instance.
the "sending" device which is always online, completes the transaction.
How could the "receiving" device, while staying offline, can get a confirmation that the transaction has really occurred? In other words, what should the "sending" device share (by QR code for instance) to the "receiving" device that will let it confirm the transaction without being fooled?

Could the "receiving" device have a public key that would verify a signed version of the transaction?

It depends precisely how secure you need to be. Generally speaking, the entire block containing the transaction and the next 100 block headers should be sufficient. The validation should consist of ensuring that the first block actually contains the transaction and is a valid Bitcoin block, the other 100 blocks form a valid chain, and all 100 blocks meet a reasonable difficulty target.
The easy way to create such a chain is to get the transaction confirmed and wait for all the world's miners to produce 100 blocks. Other than that, you'd have to find all 100 blocks yourself, which is an awful lot of work to do just to fake one transaction.
Note that this method would fail should the Bitcoin network's total hashing power ever fall below what the device expects as the real blocks wouldn't meet the "reasonable difficulty target". You do, to some extent, have to predict the future Bitcoin difficulty to make this work.
This assumes that having no central authority is a requirement. If you can accept a central authority, then that central authority can periodically issue a signed statement of the current minimum difficulty and number of blocks the device should accept. Updating this every year or so should be more than sufficient. That would allow you to wait for far fewer confirmations. 100 confirmations will take 17 hours or so.

Thanks for the answer. I'm concerned about the size of the required transfer from the "sending" device to the "receiving" one in step 4. Block header is 80 bytes so that should be fine. But I guess that an entire block can be big. How could the required transfer be optimized with the assumption that the transaction amount is limited to something 'small' (1 BTC for instance) and this transfer should happen within minutes of the transaction?

You can include just the transaction, enough of the Merkle tree to prove the transaction is in the block, and the headers of only a few blocks.


text:
Is Namecoin actually being used for anything significant?
I have some idea of what Namecoin was trying to achieve, but as of yet I've never seen it actually used. Is it being used for anything of significance yet, or are there plans by anyone to do so in the short to medium term?
If I were to register a .bit domain name and host a website, can everybody with a standard internet connection setup access it, or is special software or other setup required?

I have some idea of what Namecoin was trying to achieve, but as of yet I've never seen it actually used. Is it being used for anything of significance yet, or are there plans by anyone to do so in the short to medium term?

If a distributed, first-come-first-serve domain name system for the .bit top-level domain (TLD) is significant, then yes, it has done something significant. There are several draft proposals for additional namespaces to cover things like messaging, identity, and .tor and .i2p TLDs.

If I were to register a .bit domain name and host a website, can everybody with a standard internet connection setup access it, or is special software or other setup required?

There is and will likely always be some kind of special setup required to access domains that have not been approved by ICANN. If you're unable to resolve dot-bit.bit, then your domain name servers are not configured for it. I've used the DD-WRT instructions in the How To Browse .bit Domains guide with success. The servers change infrequently.

Any idea what the size of the community or user base is that makes use of .bit domains?

I don't. I would hazard a guess that it's fewer than 1,000.

Yes, Namecoin is used for .BIT Domains, for MoneGraph (http://moneygraph.com) and for OneName (http://www.onename.io) as the most popular examples.
And of course as a currency.


text:
Wallet account value
I have some money in my Bitcoin wallet. I'm wondering about is the monetary value which increases and decreases as the value of 1 Bitcoin fluctuates?

Typically wallets will give you your balance in bitcoins as well as a conversion of that balance into other currencies (like USD). Since the exchange rate of BTC to USD is changing all the time, your balance expressed in USD (or whatever currency it shows) will change all the time as well.
Here's a link to a chart and current conversion rates.
Your balance in bitcoin however will remain exactly the same until you make another outgoing transaction or receive one.

Blockonomics wallet watcher will show your total balance in currency of ur choice and in bitcoin. You just need to enter you public address http://imgur.com/wJNJaf4


text:
Empirical analysis of blockchain branches: once every 380 blocks?
I've completed an empirical analysis of blockchain forks from block #300000 thru #400000. I found the following: (a) blockchain forks of length 1: observed every 380 blocks on average; (b) blockchain forks of length 2: none observed.
I recognize there is variation inherent in any such analysis, as different full nodes may produce different results.
Does the above data "ring true"? I am keen to hear from anyone with good data (or even good intuition) and especially eager to hear from anyone with different numbers.

https://blockchain.info/charts/n-orphaned-blocks

Blockchain forks are an artifact from the network propagation and appear at random intervals (and far more often than what you observed). It is important to note that since nodes do not forward information that contradicts their view of the network, i.e., they have accepted one of the forks, you will not be able to observe all forks in the network, but only those that are propagated to you through the network.
For details on what causes blockchain forks and their impact on the security/performance of the network see Information Propagation in the Bitcoin Network (disclaimer: I am one of the authors).

Kudos on the excellent paper! My own analysis of time-between-blocks jibes with your data ... good to have such verification.

Christian--
Thank you for the answer AND the link to your paper. This is exactly the type of information I was hoping for, but was unable to find myself.
To confirm I understand, allow me to use a recent blockchain branch at block height 406197. Here is the output from getchaintips from my full node:
    "height": 406197,
    "hash": "0000000000000000033f1b617ad5c03cec10a6bcc19ce0778e8d75fdbf1ed152",
    "branchlen": 1,
    "status": "valid-fork"
And is my representation of the blockchain branch:

The main chain resolved in favor of what I will call block #406197-b5ab. With that data, I have a few clarifying questions:
[a] If full nodes only propagate blocks that agree with their "worldview" of the blockchain, does that mean there were sufficient full nodes that accepted block #406197-d152 (eventually orphaned) to relay that block to my full node?
[b] Does the information imply that my full node INITIALLY accepted block #406196-d152 and THEN received block #306197-b5ab? Or vice versa?
My networking knowledge is sound, my queuing theory knowledge is only modest. I am hoping to develop an accurate mental model of a blockchain branch using this particular branch as an example.
Thank you for the time & help!
Pressed250.

Hi Pressed250, please consider editing your original question with these additions :-) a) you seeing both blocks means that you are on a node-cut between the partitions that accepted the d152 and the b5ab blocks, we cannot really make any estimate on the size of the partitions (you might have received d152 from the miner itself). b) it depends on your node impementation, just seeing both blocks does not infer anything about the order you accepted them. If I'm not mistaken Bitcoin Core would have discarded d152 if you saw b5ab first so I think you are correct in assuming that you saw d152 first

Christian: great suggestions, thank you. An observation: your paper analyzes a period when there were more "solo" miners. Today the landscape is dominated by a modest number of mining pools. In my vernacular, there are fewer "unique mining entities" today. A thesis: fewer unique mining entities result in fewer blockchain branches, other factors being equal. QUESTION: does this thesis ring true? I am NOT suggesting that my original number is accurate, I recognize that 1-in-380 blocks is definitely underestimating the actual likelihood.


text:
Storing the intermediate code to generate new encrypted keys
With BIP38 we can also generate an intermediate code (or passphrase code) and give it to untrusted party to generate encrypted key/address but not be able to decrypt the key without the passphrase.
This intermediate code can be used to generate any number of encrypted keys by the untrusted party.
So my question is, is it safe for the untrusted party to save this intermediate code and re-generate new encrypted keys using the same when it's run out of keys?. Is this intermediate code more vulnerable than bruteforcing the encrypted key to guess the passphrase?
Of course there's a possibility of the code getting hacked and changed with some other code which if used would generate encrypted keys not belonging to the original user but consider that's been taken care of.

The 6) Extended "EC Multiply Mode" BIP 38 CLI Example Set: might provide a working anchored context for your question. Rephrasing your question, how much can "EC Multiply Mode BIP 38" be trusted if the engraver/minter is not behaving properly concerning step 6A?


text:
Bitcoin protocol / algorithm scalability
I have been looking into the Bitcoin protocol / algorithm a bit. I have the basics down, I think, but there are a lot of questions about how the whole thing is supposed to scale. For example,

Each client currently downloads the entire block chain, right? How is this scalable? They are supposed to be able to prune the Merkel trees, but I haven't gotten a good insight into how this works in P2P.
What was the thought process behind tracking transactions the way they are? You kind of have to traverse a lot of that tree to validate new transactions? Right?
Because of how a transaction ALWAYS needs to be confirmed (at least 6 times?) over P2P, the transfers are effectively far from instantaneous. There is a built in delay. Isn't this a problem? There is some delay already because of the nature of the algorithm that accepts the transaction into a block (solving the reverse hash).

It will not scale (to mass-market adoption) if you want to put all transactions directly into the blockchain.
There needs to be a hierarchy of services built on top of the core protocol. In addition to improving scalability, they can also offer all kinds of features that some people need, such as reversible transaction, instant (no-confirmation) transfers, verified accounts, or anonymity. The blockchain would be used as a clearing house between those services. Most people would not need to interact directly with it, but they can still rely on the guarantees it provides to the economy backed by the chain.
Just because the underlying protocol is radically peer-to-peer does not mean that you cannot have hierarchies layered over it. Just because git is peer-to-peer does not mean that anyone has the same impact on Linux kernel development. In the Bitcoin world, there will still be banks for example, and credit cards, and insurance companies. The difference is that no matter how powerful those become, they cannot mess with the money supply (and create coins for themselves out of thin air). If they screw up enough that a large number of people stop trusting them, they can be cut out of the loop.

Because of how a transaction ALWAYS needs to be confirmed (at least 6 times?) over P2P, the transfers are effectively far from instantaneous. There is a built in delay. Isn't this a problem?

The confirmations make it impossible for someone to double-spend. If you trust the other party enough, you do not have to wait for this. Same if you have other ways to get back at them if they do cheat. If you are a merchant, you can just calculate a percentage of fraud due to loss. Or take an insurance policy. Shop owners already do that in the real world (to mitigate theft), as do credit card processors. If you provide a service to them (like one month VPN), you can stop doing that if the payment "bounces". If you ship physical goods, you can wait three hours for confirmation easily. You can buy and sell currencies instantaneously on trading platforms like MtGox (so you don't need to trust or even know who you are trading with, as long as you trust the platform).
Waiting for confirmations allows you to (in an automated fashion) accept payment from someone who you know nothing about, without trusting anyone else to vouchsafe, either. That is a nice extra feature of Bitcoin, but it comes in addition to "real-world" guarantees you already have.

1) It's not clear why you think every client having to download the entire block chain is a scalability problem. Pruning currently doesn't take place but it should eventually be possible in theory. Storage space is growing at a much faster rate than Bitcoin is.
2) To validate a new transaction, the only transactions you have to look at are the inputs to make sure it validly claims them. Presumably, you already know every currently-valid transaction output already. You have to check a block in order to accept it anyway.
3) This is the nature of the way Bitcoin prevents double-spending attacks. It's because Bitcoin has adopted a "no central authority at all" approach. Nobody, as far as I know, knows a way to do instantaneous transactions without a central authority. (Consider, for example, if a natural disaster splits the Bitcoin network into two halves and each half sees a conflicting transaction. How would you know?)

Space is not the only consideration, right? If Bitcoin was to scale to support billions of transactions, requiring everyone to know about all transactions ever seems unscalable. I probbaly just don't understand this too well, which is why I am asking.

@SanjayBhandari Bitcoin wouldn't support billions of transactions by putting them all in the main block chain. In that sense, what we have today is not scalable.

Also, don't you have to go backwards a bit to check validity? Or do you just check the most recent inputs?
Right, I do know why the confirmations are there. What I am asking is that with this built in delay, how can Bitcoin support large scale, and platforms that require extremely fast transactions.

I'm not sure what you mean by "go backwards". Your client already knows that every block is has accepted is valid, and it already knows which transaction outputs are still claimable. Updating this information is done when you receive a block, so you don't have to do it when you get a transaction. (Otherwise, you might receive/accept an invalid block and get on the wrong chain.)

Scalability is something that will have to be considered, but it's not going to be a critical issue, for several reasons.

Not everyone will need a full node. Lightweight clients offer almost as much security with very modest hardware requirements.
Not all transactions will appear on the blockchain. There are ways to make secure, instant, off-the-chain transactions requiring minimal trust.


text:
How do I get a vanity address from a hierarchal deterministic wallet?
I'm interested in finding different techniques that can be used to create vanity addresses with a BIP32 address.
For example, can any of this computation be offloaded to a dedicated server, or a 3rd party?

I'll look into it as this is a really interesting question. Can someone confirm that HD wallets will always be a small subset of the total key pool? Ie for private key pK the integer set will be pK +=/-= c where c is a constant

You can do this but the advantage of HD wallets effectively diminishes. You can simply brute force by iterating over all the indices of the HD wallet until you find one that has the vanity characteristics you want. However, its possible that it is sufficiently hard enough to find that you will have to save off the private key anyway.
The entire point of HD wallets is that you only need the master private key/seed to generate all your addresses. If you end up with an index that so far out from the last used address, you might not be able to find it in the future without also having saved the private key for the vanity address.

I was recently wondering the same and found no solution, so I hacked up something myself. The prototype is at https://github.com/zommuter/vain39/blob/master/vain39.py and definitely needs some improvement, but basically it works.


text:
Lost my Bitcoin wallet and have only 11 out of 12 mnemonic seed phrase words. How can I get my Bitcoins?
I am new to the whole Bitcoin thing, and I am having my first attempt almost going sour. I lost where I created my wallet. I have my Bitcoin address and only 11 of my mnemonic seed phrase words (of 12). I attempted using a word I thought was it and then recovered a wallet on bread wallet, but after sync in, it was still zero balance for hours. I contacted the support group and they told me that I had probably made a mistake.
What can I do?

When you say 'private keys', I assume you actually mean 'mnemonic seed phrase words', right? Private keys are long, random-looking strings of numbers and letters. Mnemonic seed phrases are composed of regular words.

Yes i mean "mnemonic seed phrase words" and i have 11 words out of the 12 words

You may find https://metasafe.org useful  @Perry

If you are missing the first word and you know the rest of the 11 words, there are 2048 possible mnemonics but only ~128 of them are valid.
Using Python and this library you can print all the valid ones with this simple script:
from cryptotools.BTC.HD import check, WORDS

phrase = "{x} decrease enjoy credit fold prepare school midnight flower wrong false already"

for word in WORDS:
    mnemonic = phrase.format(x=word)
    if check(mnemonic):
        print(mnemonic)

The output is:
alcohol decrease enjoy credit fold prepare school midnight flower wrong false already
alien decrease enjoy credit fold prepare school midnight flower wrong false already
ancient decrease enjoy credit fold prepare school midnight flower wrong false already
animal decrease enjoy credit fold prepare school midnight flower wrong false already
apple decrease enjoy credit fold prepare school midnight flower wrong false already
baby decrease enjoy credit fold prepare school midnight flower wrong false already
bamboo decrease enjoy credit fold prepare school midnight flower wrong false already
become decrease enjoy credit fold prepare school midnight flower wrong false already
blanket decrease enjoy credit fold prepare school midnight flower wrong false already
body decrease enjoy credit fold prepare school midnight flower wrong false already
...

Then you can try them one by one to a wallet that support BIP39. Obviously change the last 11 words in my example with your words.
Good luck!

This is exactly what I needed. Thanks so much, you've led me down the path of a successful seed recovery!

@taky2 and Perry, where you able to successfully recover your wallets by iterating over all the 2,048 possibilities, given that you knew 11 words and their positions?

If you are missing just one word from a 12-word seed phrase, and you know the position of the missing word, then chances are you'll be able to recover your wallet. As Martin mentioned, if you are missing multiple words, or you do not know the position of the missing word, then the number of possible combinations increases greatly, perhaps to the point of it being computationally infeasible.
Here is a link to the BIP39 word list. If you remember anything about the word (eg, you think it started with an "a"), then you could just manually try recovering a wallet with each word that matches your suspicion (in combination with the rest of your seed phrase).
To run the entire list, you'll probably want to automate the process using some software to quickly iterate through the list.

If you're referring to "11 Characters" of your Private Key- you are out of luck. Brute-forcing the missing characters is not possible, at least not in today's world.
If you're referring to "11 Words" from a Mnemonic Phrase, you are also out of luck. Factoring the astronomical number of possible combinations only a three, four, or five word Mnemonic can contain -, a dictionary attack to hash out the rest of the Mnemonic Phase would be very difficult, with each additional word needed (not sure if you had a 15, or 16 word Mnemonic), creating an massively exponential increase in solving using todays computing power.
Missing 1 Word of a Mnemonic, could be dictionary attacked on a modern PC workstation. Missing 2, nearly impossible unless you know how to dictionary attack, have your rainbow tables all ready to go, but 3 words or more? --There are simply to many possible words, not even including plurals, pre-fix changes, suffix changes, or the plethora of other linguistic alterations one can make to most words rendering it a completely different word altogether.

Yes i mean "mnemonic seed phrase words" and i have 11 words out of the 12 words

If you are missing one word, do you know if it is the last, first, or any specific word - by which I mean order... because order counts.  That said - if you are missing the LAST word for example; you'd have to do a dictionary attack... which you'd have to know how to do. This would include running a wallet CLI on Linux, I'm guessing Linux Kali for an operating system (someone may want to chime in here as I'm not very familiar with bruteforcing techniques), but you'd essentially bruteforce the final word via CLI using a rainbow database of dictionary words (which you can find online).

Its the first word

Then the same goes for what I've written right above. You'd need to try word after word, using a "dictionary attack" to attempt to find the correct missing word. An online wallet like BreadWallet is not an option, they have safeguards in place to prevent any such attempt and will ban you from trying more than a few times. So you'll have to do it via a wallet, which is fully synced, with a fast processor, and via CLI. And cross your fingers... that first word starts with an A, B, or C.


text:
Why does Bitcoin use two hash functions (SHA-256 and RIPEMD-160) to create an address?
Why do we use 2 hash functions (both SHA and RIPEMD) to create an address? Why not just use one hash function?

RIPEMD was used because it produces the shortest hashes whose uniqueness is still sufficiently assured. This allows Bitcoin addresses to be shorter.
SHA256 is used as well because Bitcoin's use of a hash of a public key might create unique weaknesses due to unexpected interactions between RIPEMD and ECDSA (the public key signature algorithm). Interposing an additional and very different hash operation between RIPEMD and ECDSA makes it almost inconceivable that there might be a way to find address collisions that is significantly easier than brute force trying a large number of secret keys.
Essentially, it was a belt and suspenders approach. Bitcoin had to do something unique and rather than have to hope they got it exactly right, they overdesigned it.

Do you have a reference to why SHA256 interacts (or is known/thought to interact) better than RIPEMD160 with ECDSA? Without any citations or underlying reasoning, I could argue the same thing: RIPEMD160 could have unexpected interactions with SHA256. Moreover, say RIPEMD160 was broken and only generated a set of 100 different hashes. Then it would be trivial to break this. Say SHA256 was broken instead. Then you'd be able to generate two keys that have the same hash (and some program may depend on that not being possible). If either SHA256 or RIPEMD160 is broken, so is this address scheme?

@HaroldR.Eason We know RIPEMD160 isn't broken in the way you suggest. The issue is whether it might be broken when used with ECDSA. But what Satoshi did is used SHA256+RIPEMD160 with ECDSA, which is much less likely to be broken. It's not that one interacts better than the other, it's that a flaw in the two of them composed seems almost impossible.

But if there's a break in SHA256 to generate collisions, then one could construct two addresses with the same hash, which makes bitcoin addresses no longer a real hash. It's plausible that some code would rely on the collision resistance property of bitcoin addresses in their code, though I don't know of any.

@HaroldR.Eason agreed. This answer is incorrect. A collision in either hash variant creates a collision in the composite hash. Thus employing two variants nested if any effect makes the collision resistance worse. There’s no second preimage security advantage with a double hash.

@HaroldR.Eason That's true, but not sure why you think that's relevant to this question. I never said it protected against any potential breaks in SHA256.

Except from Where is Double hashing performed in Bitcoin?

So why does he hash twice? I suspect it's in order to prevent
  length-extension attacks.
SHA-2, like all Merkle-Damgard hashes suffers from a property called
  "length-extension". This allows an attacker who knows H(x) to
  calculate H(x||y) without knowing x. This is usually not a problem,
  but there are some uses where it totally breaks the security. The most
  relevant example is using H(k||m) as MAC, where an attacker can easily
  calculate a MAC for m||m'. I don't think Bitcoin ever uses hashes in a
  way that would suffer from length extensions, but I guess Satoshi went
  with the safe choice of preventing it everywhere.
To avoid this property, Ferguson and Schneier suggested using SHA256d
  = SHA256(SHA256(x)) which avoids length-extension attacks. This construction has some minor weaknesses (not relevant to bitcoin), so I
  wouldn't recommend it for new protocols, and would use HMAC with
  constant key, or truncated SHA512 instead.
Answered by CodesInChaos

I will reformulate my question. RIPEMD is also used to create the address, my question is why do we use RIPEMD and SHA, why not to use only SHA?

Right answer, but to a different question. ;)

Length extension attacks are impossible in Bitcoin because length extension attacks only apply where the hashed data is secret. This answer is incorrect.

My thought is that with only sha2 as an address...u have many values for the private key.
Combined with ripemd...unhave less many.  It's a checksum....it's 4bytes of ripemd right?  I'm sure I read that somewhere.
When haxoring a private key of an address there are an infinite number of values for any one sha2, or double sha2.  If you include the ripemd...there are less infinite.
So the private key actually has to be more likely the correct private key.  That means it is less likely to result in theft.
But again.  There are many universes of values that combine to make every bitcoin address...back then.
If Ed Gerck is truthful in his knowledge, reversing things isn't the issue.

Any hash function has collisions, except ZSentry. Combining two hash functions reduces but does not eliminate collisions in the resultant hash function. See why ZSentry completely eliminates collisions in a subspace that users can employ safely.

Here’s a highly speculative idea which isn’t asserted to be definitive nor certain. Yet it’s the only plausible reason I’ve contemplated given I reject the inconceivable presumption that Satoshi misunderstood or did ‘not have to think about’ length extension attacks. Length extension attacks are obviously impossible in Bitcoin because length extension attacks (never apply in Bitcoin and) only apply where the hashed data is secret. It’s not fathomable to me that Satoshi would have been so sloppy. Although by employing the double hash everywhere (c.f. also) he ostensibly intended to fool us into (i.e. give us enough rope to hang ourselves with) that anodyne explanation. That is if as I speculate he only had a use for the double hash for the spending function.
Additionally double hashing doesn’t increase security against collision nor second preimage attacks, c.f. also.
So imagine in the future 256-bit ECDSA is realistically exploitable. Two scenarios: 1) all UXTO are trivially and cost effectively exploitable; or perhaps first 2) only high valued outputs are cost effectively exploitable given high computational cost.
In the latter case no adversary can be assured of not being undermined by a competitor in terms of booty percentage they must award to the miners, as the miner who wins the block will take the (adversarial, booty grabbing) replacement transaction with the highest fees. (Naive readers should note the miner can’t distinguish between an adversarial and the non-booty grabbing transaction.) This appears to be a Prisoner’s dilemma unless in the seemingly unlikely event the miners can form a consensus 50+% oligarchy to enforce said booty percentage, rejecting all minority hashrate blocks which defect. One might argue that the high valued only scenario exploit forces the formation of said oligarchy, lest a model seems to show loss of the incentives compatibility that normally converges on a single longest (i.e. highest difficulty) chain rule. But miners won’t likely destroy their non-repurposable sunk mining hardware capex, nor would hodlers have an incentive to forsake said percentage of their ₿ for reasons I explain below.
In both scenarios there are UXTO that can’t be spent without being stolen, unless the Bitcoin validation protocol is modified to offer spending with a non-exploitable NIZKP (proof) of either preimage of the RIPEMD160(SHA256) hash.
(ADDED: naive readers note that compromising ECDSA doesn’t compromise the stationary unspent transactions outputs (UXTO) if the hash function isn’t also compromised. Those UXTO would be stranded by a threat to steal them with said posited future ECDSA exploit when and iff spend transaction is published to the network because it reveals the ECDSA public key which is otherwise obscured and protected by the hash until spending.)
I also contemplated an alternative in which the payor first records to the blockchain with a low valued (either not cost effectively exploitable or in the first of aforementioned scenarios by incentivizing the miner out-of-band with colored coins to not chose the adversarial) transaction with zero-valued outputs[1] or OP_RETURN (c.f. example)[2] the hash(preimage||txn_hash) before publishing finalization (i.e. proof) of the otherwise higher valued exploitable transaction.
Although both of those ideas would suffice if Satoshi has employed only a single-hash, Satoshi may have not wanted to depend on a contentious political outcome (e.g. the block size limit controversy) for the layer zero protocol change, so as to not hold spending hostage interim. The miners would likely resist any solution and if I may express the tendentious fact that the 1% that normally decides (because the inviolable power-law wealth distribution has no exceptions) would be impotent in either aforementioned scenario (thus opening up a power vacuum of the factionalized analog of warlord chaos) if their UTXO can’t be spent without being stolen. In other words, the Nash equilibrium is such that any changes to the layer zero protocol are stable only if the vested interests of the economic majority (i.e. the 1%) have no better strategy. In the inconceivable event Satoshi was derelict enough to design such that the 1% could be entirely divested, the miners would be destroyed along with Bitcoin.
If instead my second idea for the exploit work-around is employed on the intermediate preimage of the composite hash, i.e. RIPEMD160(preimage||txn_hash), thus an ad hoc colored coin spend is instantly possible (and adopted by Schelling point convention as the only option) without any change required to the layer zero validation protocol that the miners enforce. When spending with the intermediate preimage then the exploitable ECDSA public key was never revealed if the payor had spent his publicly received outputs to himself with a secret public key before the ECDSA exploit arrived. The double hash is only required if the payor has some incentive to not publish the public key (instead of the said intermediate) as the preimage to finalize (i.e. prove) the colored coin spend. Said colored coins remain non-exploitable thus likely retain value regardless. The prospect of a future hard fork that restores the ability to spend ₿ unexploited, incentivizes not spending with the public key prematurely thus requiring the double hash interim for spending the ad hoc colored coins.
I was motivated to conjure up this idea as a partial rebuttal to Craig “Faketoshi” Wright’s unsubstantiated claim that he explained the reason for the double hash. That is if my idea survives cross-examination by the community-at-large.
[1] Not to be confused with blackhole public keys.
[2] Ignore the following drivel: As an aside so I won’t be ridiculed by the 1% economic majority who know the truth, but please if you have any conscience the following shouldn’t be considered when deciding whether to agree or disagree with my answer, my personal opinion is OP_RETURN is an invalid fork that will eventually be destroyed.

Btw, a linked video where Faketoshi avoided any examinable technological details for his hand-waving, vacuous word salad.

I am advocating that intelligent readers ignore all politically motivated down votes, i.e. all those that aren’t substantiated with a factual comment explaining why the answer is incorrect or not germane to the question.


text:
What could drive Ripple adoption?
Now, I have been reading a lot about Ripple lately and here is something that still eludes me: For example Bitcoin has a clear early adopter advantage, which incentivices investments and helps build up a critical mass of people until the network effect sets in. Additionally, the Bitcoin system is designed to reward collaboration towards stability (mining rewards).
Ripple seems to have some problems here:

It is hard to make out an early adopter advantage for users, except perhaps scoring a few Ripples to spend for free. After spending that money, there seems little advantage for users to stick around.
There seems to be mostly a first mover advantage for businesses (see 1, 2). However, for most businesses this should be a chicken-egg problem, without customers there is no interest to implement, without usage opportunities there is no interest for customers.
There is no strong incentive to do what is good for the network: While inactive users in the bitcoin network don't matter, should users in Ripple lose interest, their outstanding IOUs lose worth. So, not only do I have to trust that somebody is good for their money, but also that he will stay interested.

My question then is: How is Ripple supposed to attract enough interest to build a user base that propagates a network effect?
Related questions:

1 : Does Ripple give an advantage to early adopters?
2 : What benefit or incentive is there for someone to run their own ripple client or ripple server?

It is hard to make out an early adopter advantage for users, except perhaps scoring a few Ripples to spend for free. After spending that money, there seems little advantage for users to stick around.

That's probably true for people who have no real urgent use case. But what about users who need to make international payments such as remittances? But largely I agree with you, pursuing users directly is not a good adoption strategy this early.

There seems to be mostly a first mover advantage for businesses (see 1, 2). However, for most businesses this should be a chicken-egg problem, without customers there is no interest to implement, without usage opportunities there is no interest for customers.

The good thing about chicken-egg problems is that if you get one, you get the other for free. So when adoption is blocked by a chicken-egg problem, you pick the side of the problem that's easier to solve and work on that. Then the problem turns into something that drives adoption.
So what's the wedge into that problem? Well, businesses can accept payments through Ripple whether or not their customers send payments through Ripple directly, and customers can make payments through Ripple whether or not the businesses accept Ripple payments directly. The obvious example is the Bitcoin outbound bridge which lets Ripple users make payments to merchants that accept Bitcoins whether or not those merchants adopt Ripple. Similar bridges can be constructed in the inbound direction and from conventional payment systems.
There are numerous adoption strategies that don't require getting users directly but where Ripple is used as a "back end" payment rail and remains invisible to users.

There is no strong incentive to do what is good for the network: While inactive users in the bitcoin network don't matter, should users in Ripple lose interest, their outstanding IOUs lose worth. So, not only do I have to trust that somebody is good for their money, but also that he will stay interested.

Community/social credit is not expected to be a realistic use case for Ripple for some time. It's reasonable to expect that the initial adoption will be driven primarily by assets issued by gateways, possibly even by business-to-business transactions using Ripple as a back end to provide irreversible, high-speed, cross-currency settlements.

authors: Ігор Заморока


text:
What is the difference between Ripple and Stellar?
I went through the site but I don't see how Stellar differs from Ripple. I see that there are differences in distribution, everything is made open source from day one and the company is non profit instead of for profit as in Ripple.
Both were co-founded by the same person and the technology seems to be the same.
What am I missing?

[Note: This answers the question as written and at the time it was written (and for quite some time afterwords). See a later answer for the current state.]
The Stellar code is a straight fork of Ripple with mostly trivial changes. It does have certain controversial features omitted (I assume on purpose) such as freezing. From a server and protocol perspective it has the exact same strengths (and weaknesses!) as Ripple does.
The client appears to have have had much functionality hidden/removed. For example it's currently impossible to set up trust lines.
The internal "currency" (transaction tokens) has been renamed from XRP (ripples) to STR (stellars). Sadly, "STR" doesn't even attempt to be ISO 4217 compatible.
The STR distribution model differs from the XRP distribution model including an "inflation" feature whereby new STR is issued (and for the foreseeable future, goes to the "Steller Development Foundation").

Further to this, a blog post describing the server code changes. tl;dr: nothing useful

This is no longer true. There is no code in common now.

Stellar rewrote their code base using a different consensus algorithm (https://www.stellar.org/papers/stellar-consensus-protocol.pdf). Now the technology is quite different than ripple's.

Are you the same Jed McCaleb that's on the Stellar dev team?

This answer is rather short. Could you please provide more details and some examples?

@NickODell yep that's me

Stellar actually consists of two entirely different code bases at this point.  It started out as a fork of the ripple code base.  That software, called stellard, is still running in production.  However, about half a year after launching, Stellar subsequently released a completely unrelated payment system called stellar-core.  Stellar core is based on a new consensus algorithm (called SCP), and an entirely new code base.  Because it is a clean slate design, there is no backwards compatibility and any transition will presumably take the form of either a flag day or trading old stellars for new stellars while both networks run for a period.
Stellar-core has many differences from stellard (and hence ripple).  One of the big differences is the new consensus algorithm, SCP, which was released with a proof of safety and boasts being "optimally safe" for a given configuration and failure pattern.  SCP allows a lot of flexibility in terms of how nodes configure their quorums, and is explicitly designed to accommodate Byzantine failures (where bad nodes lie) and different nodes trusting different subsets of the system.  By contrast, ripple uses a fixed 80% threshold, and their analysis does not apply to cases in which different nodes have different sets of nodes to trust.  (If what ripple calls the unique node list, or UNL, is not the same everywhere, then safety proof does not apply.)
There are numerous other differences between the two systems at both the implementation and protocol level.  For instance ripple allows freezing currency one has issued, which Stellar does not seem to support (at least yet).  Stellar is explicitly inflationary, with 1% new coins being created every year and all fees being recycled, while ripple destroys fees, meaning the total number of ripples in existence is slowly diminishing over time.  Stellar uses the Ed25519 signature scheme (basically Schnorr) and 32-byte public keys as addresses, while ripple uses ECDSA and 20-byte hashes as addresses.  At the implementation level, stellar's protocol is specified using Sun XDR, whereas ripple uses a combination of google protobufs and hand-written marshaling code.

Note: Due to a network fork, the stellar network now follows a single validating node. https://www.stellar.org/blog/safety_liveness_and_fault_tolerance_consensus_choice/

@NickODell Yeah, that was the old stellard based on rippled.  The new stellar-core uses an algorithm (SCP) that guarantees consistency across multiple nodes.  It's still in beta, but there are already five different organizations running nodes.  https://github.com/stellar/docs/blob/master/validators.md

Although the question has been answered, but the following are the major differences I have observed about Stellar and Ripple which I felt was omitted

The consensus algorithms are not the same, stellar uses (Stellar Consensus Protocol)SCP, SCP is the first provably safe consensus mechanism that simultaneously enjoys four key properties: decentralized control, low latency, flexible trust, and asymptotic security. Ripple uses probabilistic voting Those are fairly different even though they both tackle the same problem of reaching consensus between nodes. SCP biases towards correctness at the expense of liveness; Ripple follows a model similar to Bitcoin allowing ledger forks to occur temporarily and relying on majority validation.
The native currency of stellar is Lumen(XLM) and that of ripple is (XRP)

As a minor comment: SCP is provably secure in a very specific (and very restrictive) model, but we have no idea whether this corresponds to reality. Especially the transitivity and the strong connectedness of the network are pretty strong assumptions.

I don't see how point number 2 can count as a difference :)

Stellar:
Thе Stеllаr nеtwоrk іѕ a рrаgmаtіс blосkсhаіn рrоjесt thаt аіmѕ tо funсtіоn аѕ a brіdgе bеtwееn thе орроѕіng wоrldѕ оf сrурtосurrеnсу аnd trаdіtіоnаl сеntrаlіzеd financial іnѕtіtutіоnѕ.
Rаthеr thаn create an еntіrеlу nеw fіnаnсіаl model, Stеllаr іѕ fосuѕеd integrating wіthіn thе current fіnаnсіаl ecosystem dеlіvеrіng the bеnеfіtѕ оffеrеd bу blосkсhаіn tесhnоlоgу whіlе wоrkіng in сооrdіnаtіоn wіth existing bаnkѕ аnd рауmеnt gаtеwауѕ.
Stellar іѕ nоtаblе for its unіԛuе соnѕеnѕuѕ mеthоd thе Stеllаr Cоnѕеnѕuѕ Protocol, whісh uѕеѕ a fеdеrаtеd bуzаntіnе аgrееmеnt mоdеl thаt іѕ whоllу unіԛuе іn thе blосkсhаіn есоѕуѕtеm аnd dеfіеѕ dеfіnіtіоn аѕ a “blосkсhаіn” іn a trаdіtіоnаl ѕеnѕе.
Aѕ ѕuсh, Stеllаr іѕn’t a trulу dесеntrаlіzеd рlаtfоrm, аѕ сеntrаlіzеd оrgаnіzаtіоnѕ аrе сrіtісаl to іtѕ соrе funсtіоn, but іt does hоld thе роtеntіаl tо іmрrоvе thе сurrеnt international іntеr-bаnk рауmеnt ѕуѕtеm significantly.
Stеllаr іѕ a blосkсhаіn рlаtfоrm thаt іѕ рrіmаrіlу fосuѕеd оn іntеgrаtіng dіѕtrіbutеd lеdgеr tесhnоlоgу into еxіѕtіng fіnаnсіаl infrastructure. Stеllаr рrеѕеntѕ іtѕеlf аѕ thе “futurе оf bаnkіng,” аnd intends to аddrеѕѕ thе gарѕ thаt сurrеntlу еxіѕt bеtwееn the disparate сlоѕеd system thаt соmроѕе сurrеnt іntеrnаtіоnаl fіnаnсіаl mаrkеtѕ.
Stеllаr’ѕ аррrоасh tо сrеаtіng a соmmоn іntеrnаtіоnаl financial рlаtfоrm іѕ dесіdеdlу еgаlіtаrіаn  іnѕtеаd оf fосuѕіng on еіthеr side оf thе fіnаnсе сеntrаlіzаtіоn/dесеntrаlіzаtіоn dеbаtе, Stеllаr adopts a bіраrtіѕаn ѕtаnсе thаt ѕіmultаnеоuѕlу рrоvіdеѕ solutions tо thе сеntrаlіzеd bаnkіng ѕуѕtеm аnd еxраndѕ ассеѕѕ tо lоw-соѕt fіnаnсіаl ѕеrvісеѕ tо thе unbаnkеd аnd under bаnkеd.
https://www.cryptocurrencyblog.co.za/crypto-news/stellar-xlm-coin
XRP:
Thе Rіррlе соnсерt was fоundеd uроn thе сrеаtіоn оf a distributed lеdgеr network rеԛuіrіng various раrtіеѕ tо vаlіdаtе trаnѕасtіоnѕ, аѕ орроѕеd tо a сеntrаlіѕеd аuthоrіtу or bаnk.
RіррlеNеt іѕ thе name оf thе рауmеnt nеtwоrk uѕеd tо соnnесt bаnkѕ аnd оthеr lаrgе іnѕtіtutіоnѕ, gіvіng thеm thе tооlѕ tо trаnѕfеr mоnеу аnd dіgіtаl аѕѕеtѕ thrоugh thе dесеntrаlіѕеd XRP lеdgеr. It іѕ a nеtwоrk thаt hаѕ bееn wаrmlу rесеіvеd bу bаnkѕ аnd рауmеnt рrоvіdеrѕ thаt lіkе the іdеа of frісtіоnlеѕѕ trаnѕасtіоnаl еxреrіеnсеѕ.
Rіррlе XRP іѕ thе сrурtосurrеnсу uѕеd fоr аll trаnѕасtіоnѕ соmрlеtеd іn thе RippleNet ѕуѕtеm. Thіѕ сrурtосurrеnсу wаѕ designed tо rеduсе the соѕtѕ аnd tіmе аѕѕосіаtеd wіth mаkіng wоrldwіdе trаnѕасtіоnѕ. It tаkеѕ a mаttеr оf fоur ѕесоndѕ fоr thе RіррlеNеt ѕуѕtеm tо соmрlеtе a trаnѕасtіоn. Whеn уоu соmраrе thаt wіth thе twо minutes іt tаkеѕ to transfer Ethеrеum, thе 60 mіnutеѕ іt takes tо ѕеnd Bіtсоіn аnd thе fіvе-dау wаіt іt саn tаkе tо ѕеnd сurrеnсу thrоugh trаdіtіоnаl banking ѕуѕtеmѕ, іt’ѕ сlеаr tо ѕее why Rіррlе іѕ аll thе rаgе оnlіnе.
Unlіkе Bіtсоіn, Rіррlе XRP was never сrеаtеd tо bе uѕеd tо рау fоr gооdѕ аnd ѕеrvісеѕ. Whаt'ѕ mоrе, the RіррlеNеt ѕуѕtеm wаѕ nоt dеѕіgnеd tо роѕе a thrеаt tо thе Bіtсоіn есоѕуѕtеm. Inѕtеаd, RippleNet іѕ соnѕіdеrеd a 21ѕt сеnturу competitor to lеgасу bаnkіng ѕуѕtеmѕ such аѕ SWIFT. Whаt’ѕ еxсіtіng аbоut RіррlеNеt іѕ thаt іt саn рrосеѕѕ 1,500 trаnѕасtіоnѕ реr second wіth ease. It’ѕ even gоt the роtеntіаl tо ѕсаlе uр tо VISA-lеvеl рrороrtіоnѕ оf 50,000 trаnѕасtіоnѕ реr ѕесоnd.
https://www.cryptocurrencyblog.co.za/crypto-news/ripple-xrp-from-a-to-z-guide

If you are associated with cryptocurrencyblog.co.za you need to make that clear in your profile, and preferably in any answer that suggests people visit the blog.  If you don't do this, you're likely to have your answers banned as spam.


text:
Does the official Bitcoin version 0.8. client still download the whole blockchain?
The release notes for version 0.8 of the "Satoshi" client say

"Bloom filter" support in the network protocol for sending only relevant transactions to lightweight clients.

Is this an optional feature or on by default? Does this mean that the client will no longer download the whole blockchain? What is a relevant transaction? Is it only transactions related to keys in my wallet?
Does that mean that I can no longer keep the machine that downloads the blockchain separate from the machine that hosts my wallet (and that I keep offline, copying over the blockchain manually by USB). If so, is there an option to get the old behaviour?

Please separate out these questions, as they are all good. At least put question 3 in a separate question.

@lemonginger: http://bitcoin.stackexchange.com/questions/7824/what-are-the-privacy-implications-of-partial-blockchain-downloads

0.8 doesn't actually use the bloom filter feature, but it enables support for letting other nodes use it.
0.8 does download the entire chain.

The blockchain index though doesn't include all transactions by default, so anyone wanting the ability to access transactions (i.e., "raw transactions") for addresses other than those in your own wallet need to  reindex and include -txindex=1 to cause the full blockchain to be indexed, just like it was in v0.7 and earlier.


text:
When downloading the blockchain for the first time using bitcoind, how do I know when it's done?
I'm using bitcoind on Ubuntu, headless. So there's no GUI to tell me when it's done.
So how do I know?

Run bitcoind getinfo in your shell of choice and compare the block count, listed after "blocks", to the block count listed here. If the two numbers are the same, your client is up to date.

Here's a script doing just that:
echo `bitcoin-cli getblockcount 2>&1`/`wget -O - https://blockchain.info/q/getblockcount 2>/dev/null`

Run bitcoind getblocktemplate. If you're not caught up, then it will come back with an error of -10.

I checked this, it's not so. (I checked it on the testnet network though, but should not be different that mainnet in this case.)

This is a slight hack, but it more or less works. Great :)

@StevenRoose, what was the problem you found with this method? When did it not work? It seems to be working for me, erroring when I'm in the middle of downloading blocks.

@StephenM347 it's been more than a year, probably there was an issue back then that has been resolved by now..

The bitcoind command shows different errors now.
The new way to check is with bitcoin-cli getblocktemplate
Scripted use has been posted where I first ran accross this question
How to check if the block chain is up to date using bitcoind or json-rpc?

Simplest way is to run
bitcoind -blocknotify myscript.sh %s

On the blocks after bitcoind catches up with the blockchain, your scripts will get called with the new blockhash. You can print a message or do anything else required in this script

An alternative method, (working with recent versions), that does not depend on external websites, is to use bitcoin-cli getblockchaininfo and compare the headers field and the blocks field.
Currently, in order to sync the blockchain faster, headers are downloaded before the actual blocks. This is known as Headers-First Sync
As a consequence, the number of block headers during the Initial Block Download (IBD) will be higher than the number of blocks.
When this number "catches up" with the number of blocks, we can say we are "up to date" with the blockchain that our peers advertised to us.
I wrote a script to start bitcoind and outputs dots while still in IBD phase.
When the blockchain is up to date, it will output a message.
Here's the script:
https://github.com/frz-dev/btcutils/blob/master/bitcoin-core/start-bitcoind.sh

With only a Web browser, you can visit http://bitcoinwatch.com/ to discover the current Bitcoin Network's block height or count.
Or point your bitcoin-cli to a production Bitcoind server and issue the following command (note, the *.conf file should be the one you use instead):
% ../bin/bitcoin-cli -conf=mainNet-productionServer.conf getblockcount
The easiest way is to query all of your peer connections for numerous details that also includes the "startingheight" for each of them.
% ../bin/bitcoin-cli -conf=mainNet-localServer.conf getpeerinfo
Alternatively, the following libbitcoin-explorer command (bx, serves an analogous role as bitcoin-cli) provides only a single number when the bx client connects to a production bitcoin-server (previously called Obelisk) to query it for the Blockchain's height.
% bx fetch-height
To get the current height of your localServer that is being built try:
% ../bin/bitcoin-cli -conf=mainNet-localServer.conf getblockcount
For contrasting purposes, the following bitcoin-cli help command provides additional details to for your local Blockchain image you are building:
% ../bin/bitcoin-cli -conf=mainNet.conf help gettxoutsetinfo
gettxoutsetinfo
Returns statistics about the unspent transaction output set.
Note this call may take some time.
Result:
{
  "height":n,     (numeric) The current block height (index)
  "bestblock": "hex",   (string) the best block hash hex
  "transactions": n,      (numeric) The number of transactions
  "txouts": n,            (numeric) The number of output transactions
  "bytes_serialized": n,  (numeric) The serialized size
  "hash_serialized": "hash",   (string) The serialized hash
  "total_amount": x.xxx          (numeric) The total amount
}
Your blockchain is complete when the two numbers match. This approach will give you a good idea about your current status.


text:
How to open bitcoind -daemon using command line in Windows?
I have created a conf file on the following path:
C:\Users\NAME\AppData\Roaming\Bitcoin\bitcoin.conf

When I run the Bitcoind file, nothing happens. My command line window becomes unresponsive as if it's waiting. I've waited ~1 hour, and my computer is pretty highend (i7 processor, 16gb ram).

I want to run the server and fire some commands on the bitcoind server.
I have the following conf file:
# bitcoin.conf configuration file. Lines beginning with # are comments.

 # Network-related settings:

 # Run on the test network instead of the real bitcoin network.
 #testnet=0

 # Connect via a socks4 proxy
 #proxy=127.0.0.1:9050

 ##############################################################
 ##            Quick Primer on addnode vs connect            ##
 ##  Let's say for instance you use addnode=4.2.2.4          ##
 ##  addnode will connect you to and tell you about the      ##
 ##    nodes connected to 4.2.2.4.  In addition it will tell ##
 ##    the other nodes connected to it that you exist so     ##
 ##    they can connect to you.                              ##
 ##  connect will not do the above when you 'connect' to it. ##
 ##    It will *only* connect you to 4.2.2.4 and no one else.##
 ##                                                          ##
 ##  So if you're behind a firewall, or have other problems  ##
 ##  finding nodes, add some using 'addnode'.                ##
 ##                                                          ##
 ##  If you want to stay private, use 'connect' to only      ##
 ##  connect to "trusted" nodes.                             ##
 ##                                                          ##
 ##  If you run multiple nodes on a LAN, there's no need for ##
 ##  all of them to open lots of connections.  Instead       ##
 ##  'connect' them all to one node that is port forwarded   ##
 ##  and has lots of connections.                            ##
 ##       Thanks goes to [Noodle] on Freenode.               ##
 ##############################################################

 # Use as many addnode= settings as you like to connect to specific peers
 #addnode=69.164.218.197
 #addnode=10.0.0.2:8333

 # ... or use as many connect= settings as you like to connect ONLY
 # to specific peers:
 #connect=69.164.218.197
 #connect=10.0.0.1:8333

 # Do not use Internet Relay Chat (irc.lfnet.org #bitcoin channel) to
 # find other peers.
 #noirc=0

 # Maximum number of inbound+outbound connections.
 #maxconnections=

 # JSON-RPC options (for controlling a running Bitcoin/bitcoind process)

  server=1 #tells Bitcoin-QT to accept JSON-RPC commands.
 #server=0

 # You must set rpcuser and rpcpassword to secure the JSON-RPC api
 rpcuser=USERNAME_IVE_CHOSEN
 rpcpassword=PASSWORD_IVE_CHOSEN

 # How many seconds bitcoin will wait for a complete RPC HTTP request.
 # after the HTTP connection is established.
 #rpctimeout=30

 # By default, only RPC connections from localhost are allowed.  Specify
 # as many rpcallowip= settings as you like to allow connections from
 # other hosts (and you may use * as a wildcard character):
 #rpcallowip=10.1.1.34
 #rpcallowip=192.168.1.*

 # Listen for RPC connections on this TCP port:
 #rpcport=8332

 # You can use Bitcoin or bitcoind to send commands to Bitcoin/bitcoind
 # running on another host using this option:
 #rpcconnect=127.0.0.1

 # Use Secure Sockets Layer (also known as TLS or HTTPS) to communicate
 # with Bitcoin -server or bitcoind
 #rpcssl=1

 # OpenSSL settings used when rpcssl=1
 #rpcsslciphers=TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!AH:!3DES:@STRENGTH
 #rpcsslcertificatechainfile=server.cert
 #rpcsslprivatekeyfile=server.pem

 # Miscellaneous options

 # Set gen=1 to attempt to generate bitcoins
 #gen=0

 # Use SSE instructions to try to generate bitcoins faster.
 #4way=1

 # Pre-generate this many public/private key pairs, so wallet backups will be valid for
 # both prior transactions and several dozen future transactions.
 #keypool=100

 # Pay an optional transaction fee every time you send bitcoins.  Transactions with fees
 # are more likely than free transactions to be included in generated blocks, so may
 # be validated sooner.
 #paytxfee=0.00

 # Allow direct connections for the 'pay via IP address' feature.
 #allowreceivebyip=1

 # User interface options

 # Start Bitcoin minimized
 #min=1

 # Minimize to the system tray
 #minimizetotray=1

Any ideas how to make the server work?

What you could try is adding daemon=1 to the bitcoin.conf file and just run the bitcoind command without arguments.
I have no experience with Windows command lines, if the executable file is in that folder but not in your default binary path, in Linux the command would be ./bitcoind -daemon, with the ./ meaning that you want to execute a file in that particular folder.

As far as i know, you are running the bitcoind client as it should be run.
You need to explicitly say that you want your bitcoind to be run as a daemon.
try changing your server=1 configuration lines to this (your comment may have inadvertently messed with bitcoin... but i don't know that for any fact, just a hypothesis) here's your example modified
# JSON-RPC options (for controlling a running Bitcoin/bitcoind process)
# server=1 tells Bitcoin-QT to accept JSON-RPC commands.
server=1
Also, when in doubt run bitcoind in one cmd window and bring up a second one.
Recurse in to the directory containing bitcoind (inside that second cmd window).
Then try to run a simple command (try bitcoind getblockcount) if you get a result then you know bitcoind is working, but it is not starting as a background service.
If you are using the bitcoin-qt client, don't edit anything in the config file. Configure the Bitcoin client to start automatically.
"
GUI-Settings:
Settings -> Options
then mark the checkbox titled:
[X] Start Bitcoin on system startup
"
Source: https://en.bitcoin.it/wiki/Running_Bitcoin
Also, if your reason for using bitcoind over bitcoin-qt is due to the ability to pass text commands to bitcoin: the console is accessible from the Help menu (Help->Debug->console)
I am not going to claim i know everything, and im sure some of this is not perfect information, but i will update it and gladly work through issues with anyone i can help. Just be kind ;)

Thanks :) Yes it is running, but simply not in the background!

great! let me know if i can help you more :D


text:
Can an old passphrase recover my bitcoins using an old backup wallet.dat file?
I forgot the new passphrase for my wallet.
But i previously backed up the wallet with a passphrase  i do remember.
Can i then access that previously saved wallet and recover my btc ?

The passphrase is stored as part of the wallet.dat file, so yes, that should work, as long as you haven't received any payments to addresses with private keys that don't exist in the old wallet.
Note that these received payments can actually occur when you send a payment, as a hidden "change" amount is sent to an unused hidden private key which is stored in your wallet file. Your old wallet file should have had stored 100 of these generated in advance though, which means you're probably ok as long as you haven't used more than 100 private keys since your backup.
Most payments you make will use one of the pre-generated private keys, as will each receiving addresses you create.


text:
Will Bitcoin taxation be enforced by the IRS?
Ive heard bitcoins are about to be taxed by the IRS. The decision has been taken to regulate the virtual currency as there are concerns of it being used for illegal purposes. Is this True ?

Related: Do you have to pay taxes on Bitcoin revenues?

In the US income is taxed so I would expect income from Bitcoin to be taxed in some manner. Usually the tax occurs when there is an increase in USD but not in virtual currencies such as the Second Life Linden. Bitcoin is a little different and it's place is still unknown, it is somewhat virtual and moving into the real world, real things can be bought and sold making it more a "real" currency.
To think that one can escape taxation by using Bitcoin instead of USD is not realistic. It is not particularly different that using the Euro to escape US taxation.
There is also a moral issue: Using Bitcoin (or another currency) to escape taxation yet still using services and infrastructure paid for with taxes by others. Think roads, schools, parks, etc.
Concerning illegal purposes" That is a concern of the government and seems to be the reason US currently denominations are limited to $100. The Euro's largest note is €500. The concern is not helped by the CryptoLocker perpetrators using BTC for the ransom.

As a side-note, I once read the 500 euros bill is incredibly difficult to find on the market, which some authorities in the Eurozone believe is due to criminal gangs hoarding it to be able to export more cash using less volume and weight :(

There are other legal usages of currency in rather large amounts. Many years ago I lived in England and there were controls about how much money could be taken out of England, less than $1000. My money came from the US and in order to take any of it out later I had to have an "external" account. Only money from outside England could be deposited. I had a car and I wanted to sell it and buy another. The only way the transaction could be done was with cash. I received the entire amount in 1 Pound notes, rather unhandy!

Something to consider is that taxation does not make Bitcoin legal.
For example, my country (NZ) will charge criminals tax on the proceeds of crimes. You deal in drugs and the taxman wants their cut. Those drugs are not anymore legal just because of the tax.


text:
What are some ways for virtual currency like Bitcoin to have price stability?
What are some ways for virtual currency like bit coin to have price stability?
If there is a method, can it exert its influence only in a country or a large group?
However, when virtual money has price stability, how does it differ from existing currency?

There is no straightforward approach that a currency can take to achieve price stability.
There are things that can contribute to a more stable exchange rate, however.  These things are not specific for virtual currencies, though, but also apply to commodities or stock markets.
Mainly, trading liquidity and market availability are key to achieve price stability.  The more an asset is traded, the more stable it will become over time.  Especially when it is traded in different ways.  F.e. the presence of arbitrage and margin trading have an effect on the stability of the price.
Bitcoin has a long way to go on those fronts.  Even though there a numerous Bitcoin exchange websites of which several already support margin trading, the liquidity is still very low compared to traditional FX and commodity markets.  Many people think that the creation of a Bitcoin ETF will benefit price stability, as it enables a new range of traders to enter the market.


text:
what do red and green bars at bitcoinity.org mean?
The changebars graph at http://bitcoinity.org has red and green bars. Some of them below and some above zero.
What is their meaning?

If they are above zero

and are green
and are red

if they are below zero

and are green
and are red?

Is there a wikipedia article about that kind of graph? What would the search term be?
The rest of the graph is explained here https://i.sstatic.net/UbXtB.png but not the red and green bars.
Thank you.

If you're answering your own question, please put it as an answer and select it as the correct one.

If you click on the WTF on the upper right corner you get explanations for all of the graphs. But not yet for the bars being below or above zero. The author will add that soon (2013-03-23).
Meanwhile you can look at a reddit question here: http://www.reddit.com/r/Bitcoin/comments/1aqtgo/a_note_for_newbies_about_market_forces_feel_free/c8zz2ro

green bars above the axis represent increases in buy/bid orders
red bars below the axis represent decreases in buy/bid orders
red bars above the axis represent increases in sell/ask orders
green bars below the axis represent decreases in sell/ask orders

(I think you can replace axis and above/below by current price and right/left, then it is correct. Though this does not explain the bars above and below the line parallel to the x axis)
Well, I didn’t completely understand, why they are above and below, but I understood from the WTF explanation on the site, what red and green means. tl;dr: Green has different meaning, if it is left of the current price or if it is right of the current price. Same for red bars.
Maybe comboy, the author of that site, adds a good explanation for this soon (he promised to do so on freenode irc chat).


text:
What is the Merkle root?
The Bitcoin wiki Vocabulary article explains why the Merkle root exists:

Every transaction has a hash associated with it. In a block, all of
  the transaction hashes in the block are themselves hashed (sometimes
  several times -- the exact process is complex), and the result is the
  Merkle root. In other words, the Merkle root is the hash of all the
  hashes of all the transactions in the block. The Merkle root is
  included in the block header. With this scheme, it is possible to
  securely verify that a transaction has been accepted by the network
  (and get the number of confirmations) by downloading just the tiny
  block headers and Merkle tree -- downloading the entire block chain is
  unnecessary. This feature is currently not used in Bitcoin, but it
  will be in the future.

How can you check if a transaction has been verified only using Merkle roots? How does that mechanism work?

While I could grasp the definition of Merkle Tree and Root immediately, I struggled to figure out the larger context and their use, like many posts on this thread, until I did a bit more research. I try to explain a scenario here.

The idea (as I understand it) is that the Merkle tree allows for you to verify transactions as needed and not include the body of every transaction in the block header, while still providing a way to verify the entire blockchain (and therefore proof of work) on every transaction.
To understand this, first understand the concept of a tree. Consider an 8 transaction block. Imagine each of those 8 transactions at the base of a pyramid: these are called leaves. Put four "branches" on the second tier of the pyramid and draw two lines from each of them to the leaves so that each branch has two leaves attached to it. Now join those four branches to two branches on pyramid level 3 and up to one branch (what is called the root of the tree) on the top of the pyramid. (Our tree is growing upside down in this example.)
Now we can start to understand the hashing process. Hash the hashes of the "leaves" and include that as part of the 2nd level branches that those leaves are attached to (these are called child nodes and parent nodes). Now hash the hashes of those hashes and include that as part of the third level branches. And so on. (And if you had more than 8 transactions, all you need are more levels to the pyramid.)
So now you have a root node that effectively has a hash that verifies the integrity of all of the transactions. If one transaction is added/removed or changed it will change the hash of its parent. Which will change the hash of its parent, and so on, resulting in the root node's hash (which is the Merkle root) changing as well.
So how does this help us with potentially not having to have the entire blockchain? Because we could verify the transactions as needed. If we have a transaction that claims to have been from block #234133 we can get the transactions for that block, verify the Merkle tree, and know that the transaction is valid. We can do that without necessarily knowing all of the transactions from #234132 or #234134 because we know that the blocks are tamper proof.
Even better, if we know where it is in the Merkle tree and we know the hashes of the branches we don't even need all of the transactions from #234132. (There were 868 in that block.) We start with just our transaction and its sibling (if it has one) and calculate the hash of those two and verify that it matches the expected value. From that we can ask for the sibling branch of that and calculate the hash of that and verify it. And continue with this process, up the tree. Which only takes ten verifications for 868 transactions. (That's one of the great things about trees, they can hold a lot of values with only a relatively small number of layers.)
How do we know that the source of this data isn't lying to us about the hash values? Because a hash function is one-way, there is no way that a deceptive party could guess a value that would hash with our second-to-last value to create the Merkle root. (Which we know from our verified blockchain.) This reasoning holds further down the tree: there's no way to create a fake value that would hash to our expected value. Another way to think about it, is that even a single alteration of a transaction at the base of the tree, would result in a rippling change to all the hash values of nodes in its branch all the way up to the root's hash value.
In short, the Merkle tree creates a single value that proves the integrity of all of the transactions under it. Satoshi could have just included the hash of a big list of all of the transactions in the Bitcoin header. But if he had done that that would have required you to hash the entire list of transactions in order to verify its integrity. With this way, even if there are an extremely large number of transactions the work you need to do (and the number of hashes you need to request/download) in order to verify the integrity is only log(O).
[As always, feel free to edit this. This is primarily just inference on my part from looking at the spec.]

A block header does not include the transaction ids from the transactions in the block, does it? So basically the idea of the last part of the quote will only work if txid's were included in the block headers.

It reads "block header and merkle tree". That makes more sense. Does the original protocol allow for requesting merkle trees and/or headers including them?

What if we do not know the block# of the transaction. In that case are we require to iterate through all blocks on the block chain? @David Ogren

Maybe this is a bad question but what if I find two certain transactions with equal hashes with birthday attack and do one of those transactions and later claim that I had done the other one. How can I be proved wrong?

It's too long to answer your question here @tgwtdt. In short, you can't execute a birthday attack because you don't have arbitrary control over inputs. Second, even a birthday attack on SHA-256 isn't realistically possible. But, in general, yes, if you can find a way to exploit SHA-256 then you can do all kinds of nasty things within bitcoin: the difficulty of reversing the hash algorithm is a founding principle. On the other hand, hash algorithm security is a very well researched field.

"Figure 7-2. Calculating the nodes in a merkle tree" from Mastering Bitcoin shows the Merkle Root (HABCD) of a list of four transactions: Tx A, Tx B, Tx C, and Tx D:

To verify that a transaction—for example, that with hash HK—is a valid transaction (i.e., part of a list of, in this example, 16 transactions with hashes HA, HB, …
 HP), one need only perform at most 2*log2(N) < N hashes, shown in the Merkle path here:

If HK leads to the correct Merkle root, then TK was in the transaction list.
And the Merkle path, needed to verify Hk corresponds with the Merkle root, only contains 4 hashes in the above example. The Merkle path takes up much less space than storing all the transactions in a block. (In the example above: 4 hashes takes much less space than 16.) This is why SPV is lighter-weight.
In this case N = 16, and 2*log2(16) = 5.55… is indeed less than 16.

To verify that a transaction: How do we know the exact location of Hk on the Merkle Tree? @Geremia

@Avatar To construct Merkle paths from scratch requires knowing all the transactions. Also, forge a fake Merkle path that corresponds to a given Merkle root would be even more difficult than to crack SHA256.

For example from root when we follow: right left right left we reach to Hk, which we want to verify. But how could we know that we should follow that path? @Geremia

@Avator Verification of a Merkle path proceed from the leaf node to the Merkle root.

Got it much clear now. But again how could the algorithm knows that from which leaf should it start from. On your example there are 16 leafs so how could we detect the starting point of the Hk on the tree’s leafs. @Geremia

@Avatar Sorry, I meant to say that one simply needs to search for the transaction in the "list of transactions."

As I understand, we know the index of all transactions that at which leaf they located. @Geremia

Let us continue this discussion in chat.

the discussion link seems dead... still haven't found the explain: if it's searched from the "list of transactions", if the position is founded, doesn't it mean that this transaction is a valid transaction?

@limboy A SPV server sends a transaction's Merkle path to the lightweight client; this is enough for the lightweight client to verify the transaction is valid, without the lightweight client needing to have a list of all the transactions.

The 2nd diagram is the only thing you need to understand everything. The "green" hash H_K is the /claim/ given to the PAYEE (who also has the Merkle root). The VERIFIER (full node) sends the "blue" hashes as /proof/, because they can be used to calculate all of the "blue dashed" hashes all the way up to the Merkle root. If the calculated Merkle root matches the known Merkle root, H_K is in the block. Obviously, the "blue" hashes are a small subset of ALL the hashes, i.e. 2*log_2(N) is less than the whole set N for N > 4. Graph it for yourself at desmos.com, with y=2log(N)/log(2) vs y=N.

It's not true that you use just the merkle root (nor does the article say that).  Rather, you use just the parts of the merkle tree that relate to your transaction.  That includes the root.

This may be a good introduction. Ripple may be using Merkle tree but I am not sure:
http://en.m.wikipedia.org/wiki/Hash_tree
Also check this:
https://stackoverflow.com/questions/5486304/explain-merkle-trees-for-use-in-eventual-consistency

The Merkle Root, as I understand it, is basically a hash of many hashes (Good example here) - to create a Merkle Root you must start by taking a double SHA-256 hash of the byte streams of the transactions in the block. However, what this data is (the byte streams), what it looks like, and where it comes from remains a mystery to me.

BE AWARE! The merkle root is important for mining. since the merkle root is the hashed value of ALL transaction hashes from the block, the value of the merkle root is taken into advance when miners do their work. See: https://en.bitcoin.it/wiki/Block_hashing_algorithm. Previous hash:
81cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000

Here an excerpt of the algorithm there:
>>> import hashlib
>>> header_hex = ("01000000" +
 "81cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000" +
 "e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122b" +
 "c7f5d74d" +
 "f2b9441a" +
 "42a14695")
>>> header_bin = header_hex.decode('hex')
>>> hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()
>>> hash.encode('hex_codec')
'1dbd981fe6985776b644b173a4d0385ddc1aa2a829688d1e0000000000000000'
>>> hash[::-1].encode('hex_codec')
'00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d'

First of all, all values here are in little endian notation, so you have to ready byte per byte from right to left (remember one byte are TWO characters). So the first value is the preivous block hash, then THE MERKLE ROOT, then the creation time and then the bits. To compare the values, just have a look at: https://blockexplorer.com/block/00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d
Conclusion: The merkle root is implicitly used by the bitcoin blockchain! It playes an important role when it comes into mining!

The value on the Wiki is correct, as anyone can check by looking at the hash of the previous block's header or by running your code, which will not produce the values you claim.

Ah yea, I read the bytes wrong.