text:
What is the best way to buy bitcoin for long term investment to sell for cash later?
I apologize if this is a duplicate of this question, but it might be because of my ignorance about this topic that I think I am asking for different information.
I would like to buy some bitcoin. About $100 USD worth. From today's rate that is a little more than 0.1 bitcoin. I am fine with hanging on to it for a few years. Maybe five or longer. My concern is that there doesn't seem to be an easy way to sell bitcoin, like through mt.gox. Maybe I'm mistaken about that. I just want to make the purchase and have it to easily sell later, like I do with stock on Scottrade.
Also, if it is on topic, suggestions for litecoin and peercoin would be very much appreciated. It seems like it is on-topic according to some meta posts.

Exchanges work by letting you both buy and sell bitcoin (see How can I withdraw dollars from Mt Gox?). That's who is doing both the buying and selling in most cases: people like you who got their starting bitcoins by buying them.
When you're looking long-term, you should consider the stability and reputation of where you store your bitcoins. MtGox and Coinbase are two options for exchanges you could use, but as the above-linked question states, getting USD out of MtGox isn't straightforward at the moment, while getting it out of Coinbase is (but nobody really knows what the legal status of these exchanges and Bitcoin will be in 5 years). To eliminate the possibility of someone else losing your bitcoins (or you losing access to your account), instead of keeping the bitcoins in the exchange, you could transfer them to a wallet of your own (especially if you decide to buy a more significant amount of bitcoins).
Then the onus is entirely on you: print the private key and keep it somewhere secure (a bank's secure deposit box would be perfect, but too expensive to just store $100 worth of bitcoin), or encrypt it and remember (or write down, and secure the paper) the password while putting the encrypted file on various drives and cloud storages, or whatever else you decide to do. Of course, this means that you might accidentally lose access to your bitcoins if you aren't careful.
You can decide which risk you're more willing to take. I think I'd do the following: Buy it on Coinbase and transfer it to an offline wallet. Secure that as mentioned above, then when you're ready to sell, transfer it back into Coinbase (or whatever exists then) and to your bank account.

Can you trade altcoins on those? I'm also interested in litecoin and peercoin.

I've traded altcoins on btc-e. Look at the withdrawal minimums and fees for the altcoins you're interested in before depositing coins, though, to make sure you're not surprised (as I once was; moved a small sum around and was unable to withdraw).

LTC currently at .5 min withdrawal and .1 fee. PPC currently at .2 min withdrawal and .1 fee. BTC at .01 min withdrawal and .001 fee. Seems to all be about 8 USD fee every time. That's comparable to trading stocks on Scottrade or E-Trade. About what I would expect.


text:
Plain text for the Bitcoin symbol
It seems that the most widely used symbol for Bitcoin is a B with two vertical lines through it1. It makes sense, as a single letter with a line or two through it is common for many currencies. Is there a plain text printing for this symbol, or perhaps a font that can insert it into documents and the like? What about a hex code or something for HTML printing? I'm looking for other ways to denote the currency without using an image.

With the symbols found here, it looks like a circle around it might become part of the official symbol as well. Maybe I should ask that separately.

Like Murch said, there isn't a current text based symbol for it, but if you're going to use it on a web application, you can always use Font Awesome.
After you include the fontawesome library, you use the bitcoin symbol like this:
<i class="fa fa-btc"></i> fa-btc

Example output of the code above would be:

You can find more information regarding fontawesome bitcoin symbol documentation here.

That's neat, however, isn't that an image? The asker said "I'm looking for other ways to denote the currency without using an image.".

Yes you are correct, but he also mentioned being able to print it through HTML. Plus when you use it like in the example, it behaves like text, not an image.

Very cool. I will look into that.

I got the common Bitcoin symbol (B with two lines) approved for addition to Unicode as U+20BF last year. It will hopefully become part of the next Unicode standard in June and then it can be used in text. The character (₿) is already supported by iOS and macOS.

Apparently that character is not approved for windows ... I can't see it.

@fredsbend: currently iOS and macOS support the ₿ character even though it's not "official" yet. Presumably Windows is waiting for it to be officially part of the standard. I thought Android was going to include it by now, but I guess they decided to wait.

How to get it on android? They are dragging feet. What's the work-around? It needs to be a text-based solution. Thanks.

Embedding in HTML: ₿

Update in 2020: The Unicode 10.0 release included the Bitcoin symbol ₿ as U+20BF. For your computer to show the symbol in text, you may need to install a font that includes it. For Linux, one such font is GNU Unifont Glyphs.

To my knowledge there doesn't yet exist a single symbol font representation of the B with two vertical lines, although it seems to be possible to compose it by combining a B and a double vertical stroke overlay: B⃦. However, this doesn't display properly for me.
Some people have been using ฿ instead, however, this is actually the symbol for another currency, the Thai Baht. There has also been some discussion that a B with two vertical lines doesn't distinguish well enough from the Baht symbol.
One could also see Ƀ being used, but its usage doesn't seem to be widespread.
On Bitcoin.it one can find a comprehensive wikipage about the Bitcoin-Symbol. Unfortunately, it has not been updated since August 2013.
Until a proper unicode symbol is introduced, the best option for a disambiguous textual representations for Bitcoin might be one of either of the following.

BTC: A common abbreviation for Bitcoin.
XBT: Proposed as standard currency representation in ISO 4217, also see CoinDesk: Bitcoin gaining market-based legitimacy as XBT

Thank you for the link. I do agree that the current symbol is too similar to the Thai Baht (which may turn out to be a widely used currency in Asia over the next few decades). BTC is perhaps best for now, if I want to avoid using images. It seems to be used enough that Google has it as the 1st listing. Someone on the site preferred a different symbol with a half horizontal line through the bottom left side of the B. I think that is pretty distinct.

I personally think that some combination of a B and a C would be best. Maybe the B and the C can be on top of each other in some aesthetically pleasing way.

I just tried it, but the ideas I came up with didn't look particularly like a currency symbol to me. ;)

I came up with this a few minutes ago.

@fredsbend: Not sure that would scale particularly well. Here is also a nice combination for BC: cartman on Bitcoin-talk thread "Official Bitcoin Unicode Character?"

That's not bad. It seems like a B with a full circle might become popular in the future. When writing it, I like mine better.

For historical reasons, the US dollar and the Mexican peso both share the $ symbol (they both took it from their common ancestor, the Spanish dollar of course). As long as it's clear by context which currency a text is talking about, no one gets confused. When both are talked about, in Mexican media at least practice is to use "US$" for dollars and "MX$" or "MXP$" for pesos. A similar convention could arise should the Baht symbol starts getting used for the Bitcoin as well...

After reading more in that thread on Bitcoin-Talk, I am entertaining the notion of using ฿Cin the future. ;)

That's a good one. Supports what @JoePineda says might happen anyway. I narrowed the the thing I made by 20%. Fits more inline with typical text width to height ratios.

We can continue in chat ...

Ƀ is the best. You can change a registry setting on Windows so that you can type unicode, then you can type it by pressing Alt+243, you literally press the "+".

Also Ƀ has an interesting history. It was once used by old German Saxon Tribes as their "V" and made a "Vah" sound before the Latin V entered the alphabet. I say Ƀ sounds like Victory to me.

I've made a custom font with Bitcoin, Litecoin, and Dogecoin symbols. There's a download link in .otf format in this bitcointalk thread. (It's labeled "Download.")
If this font file doesn't include a cryptocurrency symbol that you need, I'm willing to add it.

Here is the unicode for '₿'. paste in any symbol you want the code for. Then hold CTRL+Shift & press 'u' followed by the code it gives. ₿ is 20bf.

I think that will only work in some operating systems. Could you clarify what the prerequisites for your instructions are?

source: Stack Exchange

license: 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/

sort: votes


text:
Where are the blocks in the blockchain stored?
I understand that every transaction of bitcoin is stored in a "block" which is then added to the "blockchain". I realize that this is data of some sort that must have a physical location. Where is that location(s)? Where is the data of the blockchain stored?

Since it's unclear what context you are asking in:
The blockchain is stored, distributed, on every machine in the Bitcoin network being used to mine Bitcoin.
This network is self-regulating and peer-to-peer. There is majority rule, meaning that if one node on the network no longer agrees with the other nodes (on, say, what the hash of the last block was), it is kicked out of the network and will have to "resync" its data to be in agreement with the network.

This is the answer I guess. Just to clarify, every computer mining bitcoins has the entire blockchain stored on it? People who only use bitcoin with a wallet on their computer do not have the blockchain stored on their computer?

@fredsbend Yes, that's correct. The reason is that the mining process is a confirmation both of the transactions that have taken place recently, AND of all of the transactions that have ever occurred in the blockchain.

And as a quick addendum, you can browse an online copy of the blockchain using a variety of websites, most notably http://blockchain.info/

So.. what happends if someone has access to most of the nodes in the network and chooses to overwrite the entire blockchain with a brand new one of his own?  (With today's hashrates of 12PH/s and setting a difficulty level of 1 on all blocks, he can recreate the entire chain within seconds) what happends in such a scenario?

In order to strong-arm the uncompromised nodes, your regenerated blockchain would need to find hash collisions for every single block, which is computationally infeasible. In your difficulty 1 scenario, you’re basically just creating an entirely different blockchain that your compromised nodes will mine, removing their hashpower from the legit blockchain. The compromised and uncompromised nodes will just ignore each other.

Some who are not mining also store copies of the blockchain; they run so-called "full nodes", typically because they don't want to have depend on someone else's full node in order to use their wallets.

On Windows the blockchains and other files are stored by default in C:\Documents and Settings\yourusername\appdata\Bitcoin. You can change this directory by passing the argument -datadir=c:\newdirhere to your Bitcoin executable. For a more detailed information please see https://en.bitcoin.it/wiki/Data_directory

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


text:
Are there estimates on the geographical distribution of the bitcoin supply?
There are two similar question on the site:

Is there data on the geographic distribution of bitcoin users?
I am eager to know details about distribution of bitcoin

The first is asking where the users of Bitcoin are located. The second is asking about percentage distributions among those users. Interesting data.
What I want to know is the geographic distribution of the bitcoins themselves. For example, what percentage of the bitcoin supply is held by North Americans (or North American companies)?

This can probably use better tags. I invite help with that.

The bitcoins themselves exist both everywhere (on the physical storage of everybody who is running a full Bitcoin client), and nowhere (since it's a virtual currency and coins don't physically exist). So your question really reduces to the same as Is there data on the geographic distribution of bitcoin users?.

http://fiatleak.com/
This tool supposedly gets data from "Mt. Gox, Bitstamp and BTC China to show you which countries and which currencies are moving in and out of bitcoin in real time."  I'm assuming it's just Mt. Gox and Bitstamp now and possibly others.
-http://www.zerohedge.com/news/2013-11-11/meet-fiatleakcom-%E2%80%93-real-time-map-bitcoin-transactions-country

UPDATE
As of September 2019, the exchanges from which the data seem to come are listed under "exchange" in the bottom left of the tool. Perhaps take it with a grain of salt, as there's some obvious errors, such as gdax still being listed along with coinbase pro. Gdax was rebranded as coinbase pro about two years ago. The listed exchanges are:

bitfinex
bitflyer
bitmex
bitstamp
bittrex
cex.io
coinbase pro
exmo
gdax
gemini
itbit
kraken
livecoin
neraex
quoine
yobit


text:
What is the chance of someone (randomly) finding the private key for an existing Bitcoin address?
Say I have created a paper wallet with one bitcoin address in a vault. What are chances that someone else will find the private key for this wallet?
Related: what are the chances of vanitygen address - private key pair collision?

related: http://security.stackexchange.com/questions/9688/what-happens-if-two-parties-have-a-same-pair-of-publicprivate-keys

There are around 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976 possible bitcoin addresses according to BitcoinTalk.org. This makes it a very small possibility of finding another address that is being used. So the chance is around %0.

The method used to figure it this number is through ripemd-160

You should give a exact number not just around 0%

The probability is 1 divided by the above number of addresses.

@nvd To be a bit nitpicky, that would be the probability to find some specific existing address. The probability of finding any extant address is notably larger, but still probabilistically very very small.

Essentially zero. They would have to find a private key whose public key hash matched yours. The public key hash is 160 bits long. If they had a billion computers, each of which could try a billion keys a second, and they tried for a billion years, they'd have much, much less than a one in a billion chance of getting it.

I understand this if you're trying to match a single public key. But with the entire blockchain freely available and the entire world possibly working on checking each private key, constantly on thousands of different computers, the chances should be slightly different than the model you described.

I assumed a billion computers, and I gave a billion years. There are only 21 million Bitcoins. So if you figure it's not worth much trouble to steal less than 0.01 Bitcoin, that means at most there are 2 billion keys worth stealing. That doesn't change the numbers much (when you make the number of computers and number of years reasonable).

There are 21 million bitcoins yes, but many more addresses.

Since there are 21 million Bitcoins, that means at most 2.1 billion keys could hold at least 0.01 Bitcoins.

Not wanting to revive this, just adding the actual numbers… 2¹⁶⁰ BTC addresses / 2,100,000,000,000,000 Satoshi = a fraction more than 695,953,160,633,763,294,382,707,063,198,230 addresses per Satochi.

There is a guy who has been testing this. He has ran a computer which generates addresses and checks the balances. Out of several years, processing millions of addresses per day, to my knowledge, he has found 3 with small balances. So, you can talk theoretical, where the chances are practically zero, but when there is someone who has attained at least 1, then perhaps it's not as unlikely as the math suggests.

You are new here. (1) It's not ok to put your LTC/BTC/ETH... adress in your comments. This will give you a lot of downvotes. The reason of this platform is not earning money. (2) If you tell that someone found 3 private keys of adresses, then prove it (with a link to a website/video for example). I'm pretty sure, it's not possible.

It depends on the sort of computer you use.  Current silicon based digital computers are exactly what the elliptic curve signature scheme is designed to beat, so it is highly resistant against an attack with such a computer.
Quantum computers are predicted to be able to implement Shor's algorithm efficiently.  If they can be implemented with 4,000 effective Qbits they would be able to find the private key of a wallet with an exposed public key in seconds.  In 2017 Aggarwal et al. predicted that it could be completely broken by a quantum computer as early as 2027, by the most optimistic estimates.
Since then research has come on in leaps and bounds, in February-March 2022 81 percent of senior UK executives expect quantum computing to have a significant impact in their industry within seven and a half years, with almost half (48 percent) believing that quantum technology will begin to transform industries as soon as 2025.  Andersen Cheng, CEO of London-based cryptography company Post-Quantum says there's been some evidence that it could well be around two years away.

Unfortunately the chance of finding randomly using private key is great , because wallets uses almost the same algorithm to generate private keys

It is what? Great? No, the chance is approximately zero for all intents.

This is an interesting take. It might be true if wallets used deterministic algorithms (or bad randomness) to generate private keys. However, that would be a bad implementation mistake. Such problems do exist in practice, of course, and people have searched the blockchain for such patterns for a long time (and found/recovered/stolen lots of bitcoins in brainwallets and such). However, any good wallet should use 256 bits of randomness in generating a private key, and then the probability of collision is unimaginably small -
1 / 2^256.

The only true way to defend against this is to avoid large balances with each private key.  But if people do that then it will be much easier to find something if adoption happens and active addresses continued to double every 5 years.
Assuming btc is eventually $ 2 million  per bitcoin and average person saves say 200k in bitcoin. They would need 2000 keys with 0.00005 to avoid losing more than $100 though a random collision attack.
I guess there should be some kind of insurance against this happening but it goes against this idea consolidating uxtos to save fees is a good idea. It’s another reason why low fees are required for btc to work.


text:
Are pseudo-random number generation algorithms good enough to cover all possible Bitcoin addresses?
Part of why Bitcoin works is that it's completely unlikely for someone to end up with the same Bitcoin address. But since Bitcoin address generation is based on pseudo-random generation it raises the question: Are pseudo-random number generation algorithms good enough to cover all possible Bitcoin addresses?
See also What happens if your bitcoin client generates an address identical to another person's?
And note that the Android Bitcoin wallet already had an issue with this:
Google patches Android after Bitcoin wallet issue

There are plenty of PRNG algorithms that are good enough. You just run into trouble when you, through ignorance or error, pick one that isn't.
The simplest adequate solution is to gather enough information, from any source and of any size, to ensure that it has at least 160 bits that are unpredictable by any attacker. You can then SHA256 hash this data. You may need to gather a large amount of data to ensure it has sufficient unpredictable bits, but that's okay.
You can make things a bit more secure by hashing many, many times or using a memory hard hashing algorithm. That way, an attacker that can guess some of your bits has to go to much more effort to try random combinations of the ones he can't predict to try to replicate your key.
If you don't have access to sufficient unpredictable data, from any source, then there's not much you can do. Your security is only as good as the unpredictable input your PRNG has.

When done correctly, yes. The default Bitcoin client uses OpenSSL's RAND_bytes, which...

puts num cryptographically strong pseudo-random bytes into buf. An error occurs if the PRNG has not been seeded with enough randomness to ensure an unpredictable byte sequence.

Whether you'd call this a pseudo-random algorithm might be a matter of semantics, and of course some programs might use insecure algorithms, but at least Bitcoin-QT uses something that provides the full amount of randomness needed for security.

authors: Алексей Андреев


text:
Is Ripple's UNL list maintained by the network?
Who maintains the Ripple UNL list?
This says

We periodically poll our sources. If they mention a new node with a score over an amount, we add the node to our trusted core set.

Who is "we"?  Are "we" the network, or are "we" a set of maintainers, founders, etc?

Currently, Ripple Labs runs five validators and most Ripple servers have only these five validators on their UNL. A transition is in the works to distributed community management of UNLs, and that transition is expected to be completed during the first half of 2014.
In the final scheme, publishers will be able to publish lists of validators (by public key). They will ensure validators accurately report their identity, jurisdiction, type of organization, and so on. Publishers will monitor the validators they publish to ensure they are operating reliably. Since validators must sign every proposal and validation, most types of misconduct will be easily provable.
The Ripple server software will come with a default list of publishers, though you can add or remove them as you see fit. You can also manually add validators or remove validators. You will be able to tune the policy based on the parameters the publishers vouch for. For example, if you don't want any validators operated by governments, you can opt to do that. If you don't want any validators in Australia, you can opt to do that.
Your server will periodically poll the publishers and statistically combine their lists to come up with a set of validators to use.

I love the nurturing turned removing the training wheels strategy!


text:
Ripple network overhead
I like the way Ripple provides effectively instantaneous transaction verification.
When building consensus how much traffic and their equivalent of orphan blocks are accumulated?
Is communication throttled at all?
Is the candidate set processed by the network or the founders?

See also https://bitcoin.stackexchange.com/questions/13330/what-is-the-exact-consensus-protocol-ripple-uses

When building consensus how much traffic and their equivalent of orphan blocks are accumulated?

Once a consensus round starts, the amount of information that needs to be distributed is fixed, since new transactions cannot be introduced. If there's no reason a transaction shouldn't be included, then almost all honest nodes will ask that it be included. If there's any reason a transaction shouldn't be included, then the avalanche algorithm quickly excludes it.

Is communication throttled at all?

Each validator rate-limits how often it changes its position. There is no reason to send a position that is already obsolete due to the decisions made by other validators.

Is the candidate set processed by the network or the founders?

Once each validator determines that a particular candidate set has a super-majority, it applies the transactions in that candidate set and signs the resulting ledger. If a super-majority of validators sign that ledger, then we have a new "last fully-validated ledger".
Any transactions that could have gotten into that candidate set but didn't are then recovered using a deterministic process.

how much time does the average round consume?

The network bases each round's timing on the previous rounds, trying to make the round a little bit faster if it can, but making it slower if it must.
There are a few minimum timings to ensure network stability. A ledger must be open for at least two seconds in order to ensure nodes have a chance to finish processing the previous ledger. A consensus cannot be declared for at least two seconds after the ledger closes to ensure nodes have a chance to take an initial position before other nodes conclude there is a consensus. (These are absolute minimums. If needed, they will rise.)
This makes a typical consensus round take about 5 seconds, plus 1 second for each additional avalanche needed to reach consensus. The number of rounds tends to grow logarithmically with the number of nodes and linearly with the network diameter (time it takes for a flooded message to reach the majority of nodes). We don't expect the timing to get over 10 seconds, even with a large network, so long as the network is confined to Earth.
Underperforming nodes will "bow out" of the consensus process to prevent the network from becoming as slow as the slowest node. Overperforming nodes will slow down to prevent the network from becoming as fast as the fastest nodes (as this would reduce decentralization). The algorithm is designed to self-regulate to keep the fastest subset of sufficient size operating.

If you don't mind, how much time does the average round consume?  I love your system!

Lol, mind blowing!  I like the way you guys did that!


text:
What is Transaction Malleability?
The Bitcoin exchange MtGox has stated in this press release that "transaction malleability" caused them to stop sending bitcoins. A recent question asked if it really is an issue. But what is transaction malleability in the first place?

Bitcoin transactions have a transaction id (txid) formed as a hash over the data involved in the transaction. That suggests that it is a unique identifier for a transaction.
However, the tx-id of a transaction is only unique once the exact data in the transaction has been finalized by being incorporated into the blockchain (and confirmed). Until then, there are hacks that allow altering the underlying data and hash. This is not a security issue because it is not possible to alter how many bitcoins are transferred from what input to what output. But details such as what format the cryptogaphic signature confirming that the input authorizes the transaction takes, or the exact signature script used, can be changed: They are malleable, making the hash or transaction id malleable as well.
This should not be a big issue at all. But it is if you built your Bitcoin handling on the assumption that transaction ids are not malleable, as MtGox may have. You also need to be careful about spending unconfirmed transactions, because this only works if nobody changes the intermediate transaction ids. None of this is an issue in the standard Bitcoin client, but if you roll your own, especially if you wish to use only a single Bitcoin address to handle many individual transactions, rapid-firing transactions directly building upon the unconfirmed previous one is an easy mistake to make. If people altered transaction ids from MtGox withdrawals, and MtGox adopted such a rapid-fire approach, this may explain why there have been many complaints of never arriving withdrawals: Altering one transaction id in the chain of unconfirmed transactions invalidates all successor transactions, until the originator resynchronizes with the blockchain rather than its own idea of which transaction ids it has sent.
EDIT: A much more elaborate explanation can be found in this Quartz news article

I’ve used this answer as basis for the transaction-malleability tag wiki.


text:
Is price volatility necessarily a bad thing?
Discussions of Bitcoin as the potential basis for a future global monetary system often point to the currency's price volatility as a shortcoming. Fiat currencies, by comparison, are (mostly) a lot less volatile. My question is whether an economy that relies on a low-volatility currency is actually preferable to one that is agnostic to currency volatility. The latter strikes me as more robust.

Interesting question! Related: How does bitcoin's price volatility compare to commodities/stocks with comparable market capitalizations?, How to stabilize Bitcoin's exchange rate (reduce volatility)? Why aren't early adopters intervening in the market in order to stabilize the BTC price?

Volatility has two sides of course, an upside (commodity or currency increasing in purchasing power) and a downside (decreasing).
When you invest in something as a store of value, you're always going to appreciate when it gains value as you hold it and dislike when it loses value.
Before you invest (EG, you have another money you're about to use to purchase it) you like when the price comes down so that you can get more of it (with the expectation of going back up again once you have it) and you dislike when the price shoots up prior to your purchase.
It is always a bad idea to price loans and contracts in a volatile currency, however. Since each party would be in a position to hope for an opposite swing direction, one party would always be inconvenienced by a change in value. Since loans and contracts are designed to offer joint utility, you don't want one party suffering or resenting the other party for their perceived unjust lucky gains: people would just avoid such contracts instead.
Today it is common to price items in USD then allow for spot payment in Bitcoin, for example, or to loan out money or establish contracts denominated in USD with sides paid by Bitcoin spot value. EG, I borrow $100usd from you today when Bitcoin is, say $100usd/BTC so you give me 1BTC. I pay you back later $110usd (principal + interest) but Bitcoin is in a dip when the contract matures so at $90usd/BTC I have to pay you back 1.222BTC.
And finally, while it is nice that Bitcoin appears to be on a long term up-trend, it's shorter-term volatility makes investments and contracts that can't hold out for the duration required to "get to the moon" much riskier and more difficult. Most Bitcoin-related business (including merchants, arbitrage, obtaining BTC and then holding to pay off payroll or suppliers and avoid paying multiple interchange fees) require maintaining balances in BTC over time and those balances may ebb or flow. Again, if you receive BTC on a rise (customer pays you; hey they get to choose the timing!) and have to pay it during a dip (regular payroll, running lower on parts than you can afford to wait for an upswing) then you are experiencing a significant capitol loss.

I understand why price volatility is currently a problem, but what I'm wondering is whether a future economy could have inherent protections against it, or even learn to thrive from it. I don't have a concrete suggestion for how to accomplish this, but I'm also not convinced such solutions are impossible. Here's an idea: what if every BTC priced contract came with two-way hedges (leveraged) against price volatility? That would reduce the risk but increase (slightly?) the cost of transaction.

Volatility is indeed a shortcoming for an asset to be the basis of a monetary system. Money aims to solve the problem of double coincidence of wants in barter by acting as a medium of exchange. And to do so, it must be an asset that everyone is willing to accept in payments, even those who do not demand to hold it for long. The more volatile an asset, the greater will be the spreads when traded against other assets, and hence the less convenient as a medium of exchange for those who do not demand to hold additional amounts of it, and will need to trade it immediately.
We should also note that people prefer to ensure their most immediate needs are covered before thinking about the future, so the demand for assets with a greater expected return in the long-run but greater uncertainty in their short-term value is smaller than that for stable assets. The wealthier you are, the further away in the future will be the needs you care about.
A volatile asset introduces friction in most trades, while the purpose of money is precisely to reduce that friction. In its function as a medium of exchange (MoE), it forces the exchanging parties to agree on two prices instead of just one —the price of the volatile MoE and that of the object traded for it—. And, in its function as a unit of account (UoA) it forces both sides of every contract to assume (or hedge) an additional exchange risk that they most likely do not want.
Bitcoin is an inherently volatile asset, useful as a censorship resistant tool to carry wealth to the future and to exchange it with others —this can overpower the inconvenience of its volatility—, but it does not have the qualities required to be the basis of a monetary system.

Yes, price volatility is a bad thing as it shakes peoples faith in the currency as a whole. The reason why money has value is because people use is in transactions. If people do not trust a currency, then they will be less likely to accept it as a form of payment.

This has me very worried about bitcoins as once 21 million coins exist, no more will be generated. This allows for extreme volatility as all a person would have to do to change the value of the currency is buy a large amount of bitcoins, print them out, and burn them.

So, why would that worry you? The value of the network would the be shared among fewer units.

@Murch Much like the near collapse of several US banks a few years back (great depression), it would shake peoples trust in butcoin as a form of currency. The government was able to step in and back the banks up. This was really a symbolic gesture, as it reestablished trust in the dollar.

Major difference here being, that the failing banks would have lost lots of funds of other people instead of only "burning their own". It doesn't really compare.

It depends on how you think about it.
Arguably Bitcoin will strongly incentivize people to think of the long term and discard the short term volatility in their perception due to the fixed supply. Similar to how we don't constantly worry about the weather being volatile, because we have adapted relatively well to it and it doesn't really impact our lives much. When it's winter and you want to take a swim in a lake, you simply wait a couple of months and then do so. Perhaps an incomplete analogy but hopefully the point is clear.
Another part of the equation is, that Bitcoin is a relatively new technology so volatility is expected and could go down in the future. If Bitcoin is a niche obsession, one big player entering the game has a big impact. If it's a globally dominant monetary system these swings will likely decrease.
The last argument would be 1BTC = 1BTC. Prices always change and the change in prices is not only expected, it is a signal necessary to assess the true state of the world. Artificial price stability through government control can be simply thought of as a lie. So if you count everything in Bitcoin, Bitcoin is just as volatile as the speed of light. If a car changes how fast it's going we don't consider the car as the universal measurement of speed. We take constants for that, and arguably Bitcoin is the first time we have a constant in the economic world.
So just because things change in relation to it, does not mean the thing itself is volatile.

At this point, Bitcoin and crypto are highly speculative assets... excluding most stablecoins.  Volatility is to be expected as its part of price discovery.
Long-term (10+ years), I think you'll see far less volatility as Bitcoin, Ether and more cryptos become widely adopted. And the leaders are designed to appreciate overtime.  Bitcoin has a hard-cap on how many coins can exist.  Ether is now systemically deflationary.


text:
Ripple node compensation
How does Ripple charge fees for XRP-only transactions to compensate nodes?
I've heard of what I can only describe as a "network fee", that some XRP are burned per transaction.  What is the motivation for that?
I'm also unsure of how the node types are compensated.  There seems to be consensus builders and some kind of set of miners, but I can't be sure.  Are they also compensated through BitCoin type fees?

possible duplicate of What are the transaction fees with Ripple.com?

@dchapes Somewhat.  Should I change to "how are ripple nodes compensated"?

I'm not sure (I don't claim to be a be a StackExchange expert). I can't find another Q/A here that directly addresses why anyone would run a validator; on first reading I didn't see that as the main focus of this question. I'd guess that a question (probably a pre-existing one) should address the how and why of XRP fees and a separate one (this one?) could address the why companies, individuals would run validators and/or public Ripple servers.

@dchapes Thank you dchapes!  The infrastructure fees was my intent.  Edited.

During normal operations, the "fee" is set to be a small fraction of .01 USD. This is for ALL transactions, regardless of the units being exchanged through the system.
This is a protection measure for the ledger against spam attacks. If there was an attempt to overload the consensus system, the fee would increase in increments. It would still be a very small amount for a normal user and would be a financial hindrance to a spam attack.
There is no monetary compensation for being a part of the consensus. The base fees and load fees are destroyed. Ripples are not mined, it was all created at once. People will likely be running their own servers for fast, secure access to consensus, not coin rewards.
A basic and technical overview of transaction fees and how they escalate to prevent spam
https://ripple.com/wiki/Transaction_Fee
How consensus works.
https://ripple.com/wiki/Consensus
"Finding consensus by trusting validators not to collude is a simple and strong way to establish the valid ledger. Because, the network is not relying on proof work, this consensus process is fast and allows the Ripple network to validate ledgers in seconds."
An excellent visual explanation of consensus. Also shows how transactions can be verified within seconds as opposed to the minutes required for many other crypto-currencies.
http://www.youtube.com/watch?v=pj1QVb1vlC0

Though Ripple works vastly differently from crypto-currencies such as Bitcoin, I've found a simple way to explain it to people familiar with only the latter is to liken it to a crypto-currency that was 100% pre-mined "on purpose" since such pre-mining is absolutely fundamental to the way its network is supposed to work: burning txn fees rather than redistributing them. What I wonder is what would happen if/when the number of freely usable ripples comes too low - another massive mining? Massive migration to XRP network 2.0?

Considering how divisible Ripples are, that sounds like an incredible problem to have. Not realistic in my opinion though.

@JoePineda The community will face problems of one kind of another and will have to come to a consensus on how to handle it. Ripple's consensus mechanism provides a specific way to do that, by the way. One thing they could do is multiply all XRP balances by, say, 1,000 to restore sufficient divisibility. But it would take more than a century to get there and most likely so many other things will have changed by then, if Ripple is still around, that some other solution will be better. Until we know in what form we face that problem, if ever, we can only guess what solutions make sense.


text:
Does the Bitcoin client not record original signature data per connection?
I just read the malleability page.
Can someone confirm that this

While transactions are signed, the signature does not currently cover all the data in a transaction that is hashed to create the transaction hash. Thus while uncommon it is possible for a node on the network to change a transaction you send in such a way that the hash is invalidated.

means that the protocol actually doesn't assign signature data to addresses in the database?
Please tell me that's not true.

I don't understand "the protocol actually doesn't assign signature data to addresses in the database". What signature data? What database?

I understand Bitcoin well, but the question is still messy, because there's no clear meaning to "the protocol actually doesn't assign signature data to addresses in the database". The protocol doesn't maintain a database. 'Signature data' isn't 'assigned' to 'addresses' by the protocol or software, signatures are attached to transactions. Regarding your additional comment, there's no 'bad data' to be deleted - the mutated transactions are still valid, and if they win their way into the blockchain, they live forever as valid transactions. They just confuse some other software.

The signature covers everything except the signature itself.  Since the signature and public key make up the input script for the most common payment type (pay-to-pubkey-hash), the input script is not part of the signed data.  This means the input script can be modified and not break the signed transaction as long as the new input script is equivalent to the original input script.  The recent attack did this by changing one of the script opcodes to an equivalent opcode.  So the new script was valid and performed the same function.  But since the opcode was changed, the transaction hash was different.
Once a transaction is part of a block, the transaction hash cannot be changed since it is now included in the Merkle tree for the block.  So the attack window is only from the time the transaction is created until a miner includes it in a block.  During this window, a modified transaction can be broadcast and it is a race to see which one makes it into the block.  The one that loses will never be confirmed since it spends inputs that are already spent.  No matter which one wins, the coins are sent to the proper destination.
The problem for Mt Gox (and others) is they track a transaction based on its transaction ID.  If the modified transaction wins and gets included in a block, the original transaction will be discarded.  This then led Mt Gox to think the money was not paid (since the transaction ID was not in the block chain) and they would create a new transaction to pay the money again.

@Gracchus I wouldn't call it incompetence exactly.  They made a pretty natural assumption that something called a 'transaction id' could be used to identify a transaction.  I'm guilty of that myself and have had to change my code to use a 'normalized transaction id' instead to easily spot duplicates.

@Gracchus I wasn't insulted, sorry if I gave that impression.  What I meant was, if you tell a programmer that something is an identifier, the programmer is going to assume that it is immutable.  The problem is the transaction id is a hash of the entire transaction and is not part of the transaction itself.  So any change in the serialized form of the transaction will cause the id to change.  Since the signature cannot itself be signed (chicken and egg problem), that leaves it open to modification.

@Gracchus There wouldn't be a problem if a canonical encoding were enforced from the beginning.  Then there would have been only one acceptable byte stream for a transaction and the transaction id would be unique.  You can't have just keys, signatures and data without some framework for encoding the data, unless everything has a fixed length.  Otherwise, you have no idea what parts of the byte stream belong to what object.

@Gracchus No, I meant that you need an encoding schema if they aren't fixed-length.  An example would be ASN.1, of which DER (distinguished encoding rules) is the canonical subset.  In fact, the signature is encoded using DER.  A problem arises because the decoder (OpenSSL in the case of the reference client), allows non-DER encodings.  So now you need to either scan the signature yourself to enforce the DER rules or you need to change OpenSSL to add a flag saying that only DER-encoded data is acceptable when decoding the signature.  So the input script is not the only vulnerability.


text:
History of cold boot attacks on Proof-of-Stake miners
Have instances of theft due to cold boot attacks been recorded?  If so, is this a common problem?
If so, are miners installing memory encryption software like Trezor?

It's not an appreciable issue. If somebody has physical access to a a miners server rack, it's game over no matter what "memory encryption" is used. As for the attack specifically, I doubt it's ever been used outside of security demonstrations and high level infiltration rather than something as completely insignificant as Bitcoin mining.

This kind of attack would be hard to pull of due to the nature of Bitcoin and if you are capable of accessing the physical machine why not just steal it and mine with it?
It's hard because what is there to steal? You can steal the solution to a new block but you will have to work very quickly. As soon as a miner finds a solution there are only a few milliseconds before the block is hammered out and sent out to the network. When it reaches a node it can be considered a "game over".
You'd have to act fast, say you detected the machine sending a completed block and managed to make sure the block never propagated beyond the machine. You'd be racing against the Bitcoin network, they will find a solution if you don't. It's possible that miners will find a solution within minutes.
You could possibly disconnect it's connection to the internet but that will only disrupt the pool the physical machine is most likely participating in. It won't be able to complete it's own share and that's the end of it.


text:
Are there any works of science fiction out there that relate to blockchain technology?
It feels like science fiction is lagging behind Bitcoin and the blockchain technology that is powering it.  Are there any writers who have discussed similar technology in their stories? Even in the past 5 years?
See also the same question at the ethereum forum

Found one: Stephenson's Cryptonomicon.
See also Digital Currency: ten years before Bitcoin, Neal Stephenson's Cryptonomicon

Credsticks from Shadowrun by description work similarly to a Bitcoin hardware wallet, i.e. they are digital, but can't be double-spend. Yet, as far as I know, the mechanics are never explained in novels or rpg background material.

See Karl Schroeder's "Eminence" in David Brin's recently published Chasing Shadows, Visions of our Coming Transparent World.

Could you please add a few sentences to explain how the book relates? (If it doesn't spoil the story.)

Slow money in "Neptune's Brood" by Stross was interesting and relevant.
If thats not enough for you, pick an arbitrary altcoin whitepaper... :P

You might like the short story The Ghost of Gox, about a hacker fighting autonomous software agents operating on the blockchain.

The on going science fiction TV series Almost Human has mentioned Bitcoin in several episodes. Video and Discussions. In the show, Bitcoin is considered as a well recognized way for anonymous money transafer. And 5000 btc will be a fortune the size of a country.

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


text:
Confusion over 'change' when transferring funds from bitstamp to paper wallet
I was about to transfer my funds from bitstamp -> paper wallet for the first time, but wanted to try it out first with $0.01 etc. I'm worried that since you have to specify where 'change' goes with bitcoin wallets, the rest of my funds will be diverted. Is this incorrect? Thanks in advance.

You are correct, the rest of your funds will be diverted. However, they will be diverted to a new "change" address that is also managed by your wallet. So, you will still own the change.
For example, suppose your wallet contains 10 BTC [1]. If you send 0.01 BTC to a paper wallet address, then your client will automatically send the remaining 9.99 BTC to a new address inside your wallet.
For more information, see the following questions:

Why do outputs need to be spent entirely?
Why does Bitcoin send the “change” to a different address?

This simplified explanation assumes that you originally had all 10 BTC sent to a single address. Normally, your wallet manages multiple addresses and adds up all the individual balances to show you the total wallet balance.

Thanks for your help, just wanted to clarify since you're saying something different (I think) to the other two answers. Using your example- if my bitstamp account had 10btc and I transferred 0.01btc to a paper wallet would my bitstamp account still have 9.99btc?

@jacklocke: I'm saying the same thing as the other answers. Yes, your Bitstamp account will still have 9.99 BTC. Bitstamp will automatically manage the change addresses and you don't have to think about it.

You don't need to worry about change addresses unless you're manually crafting a raw transaction or try to manually use funds from a paper wallet. Your online wallet or local wallet software is supposed to handle that for you.

You can send any amount to a paper wallet without concern for the change.  The critical part to worry about is when you spend the funds on the paper wallet.  If you do not spend all of the funds whatever is left over will be used as a transaction fee regard less of the amount.  uminatsu is correct in stating that this only occurs when you try and craft a raw transaction using the keys from that wallet.  It is suggested that you import the private keys into your own wallet before attempting to spend these funds to ensure that you do not make a mistake.  You will need to use the importprivkey function of the bitcoin-qt wallet application to be able to spend your BTC.

authors: Käññåñ ßhãrp


text:
What does the mining difficulty number really mean?
I'm new to bitcoin; please bear with me.
I'm looking into mining, how it works, and how to get started. I see a "mining difficulty" from many sources and list a 3 billion something number without units.
What exactly does this number mean and how does it relate to the processing speed of the hardware used? For example, what predictions can be made on the number blocks you will solve with a 100 Gh/s ASIC at any given difficulty?

I assume Gh/s is giga hashes per second, though I don't know what a hash is either.

I found this related question, but I don't understand the answer.

As an extension question, how might this relate to mining in a pool? Bitminter says it has 424 Th/s, so my 100 Gh/s is a drop in the bucket.

(If I may repeat myself a bit...) Mining is like having a lot of people throwing weighted coins (such that 1 millionth of the time it comes up heads) and telling you when they hit a heads. If one such "heads" is reported every 10 minutes (600 seconds), you can make a very accurate estimation of how many times per second the coins are being flipped. In this example:
(1,000,000 flips/heads) / (600 seconds/heads) ~=
1,667 flips/second

The network difficulty is how you adjust this 1,000,000 figure so that the 600 figure stays consistent as the network's total hash power (1,667) changes.
To see real-world calculations of how the difficulty affects the coins discovered per time spent, see any mining profitability calculator, and change the "difficulty" figure. The Bitcoin wiki has details on difficulty, as well.

I don't know what a hash is either.

When mining, your computer creates a block of data, which has a list of all of the transactions it knows about, includes a transaction that pays you the mining bonus, and then hashes that. If the hash happens to be a small enough number (as defined by the difficulty), the block is valid. If it's not, you increment a random number called a "nonce" that's in the block, so that the block has the same meaning but different data, and hashes the block again. Lather, rinse, repeat. (the nonce is included from the start, of course, but I didn't mention it to avoid being confusing)
The details of the block hash are explained in more detail at Bitcoin wiki's Block hashing algorithm.
Gigahashes per second, then, are how many billion times your hardware can do this hash per second.
If the pool you're in has 424 Th/s and you have 100 Gh/s, then you are about 1/4000th of your pool's total power. You can expect to be the one to solve about 1/4000th of the blocks (on average) that your pool finds.
(technical details intentionally omitted; those are available at my various links, and your link)

Is double the difficulty twice as hard, or does it not scale this way?

@AaronFranke Yes, it scales that simply.

Miners task is to find a hash below a target T. Obviously if T is smaller, its more difficult to find the hash number.
Difficulty D is defined by:
D = Tmax/T

where Tmax is: 2^224
The probability of finding the hash is:
P = T/2^256
which is equal to 1/D2^32
So if you can make h number of hashes in t time, the probability of finding the target hash is:
P = ht/D2^32

How do you calculate if a hash is below a target value T?

how? its just a simple if statement. target is a constant and hash is the value generated continuously.

I'm looking into mining, how it works, and how to get started. I see a "mining difficulty" from many sources and list a 3 billion something number without units.

The difficulty is just an arbitrary value, it has no unit. A difficulty 8 block is 8 times more difficult than a difficulty. Today the difficulty is 3B, but this chances on a bi-weekly basis as the hashrate of the network varies.

For example, what predictions can be made on the number blocks you will solve with a 100 Gh/s ASIC at any given difficulty?

It takes about 4 Billion attempts to find a difficulty 1 block, you can scale up approximately from here. 100 GH means the hardware makes 100,000,000,000 attempts a second, or about a difficulty 1 block every 0.04 seconds. In practice a 100GH machine might find a block every 5 years or so, if you're lucky.
Pooled mining pools the resources to find blocks faster and split the income between the miners. It would average to about 0.13BTC a day at the moment, but it's dropping about 2% a day at the moment and doesn't look like stopping any time soon.
You won't make any income mining, nobody has except for the very first ASIC owners in January 2013.

If people aren't making money doing it, then what is their motivation to continue mining?

Supporting the network. Only people like Bitfury who have the capital to design their own hardware are the ones making a profit.

"Only people like Bitfury who have the capital to design their own hardware are the ones making a profit" haha that's absolutely not true.


text:
Why is mining difficulty increasing?
I have heard in many places that mining difficulty is increasing, meaning that the hardware used to mine new coins will need to be more and more powerful as time goes on.
What is pushing mining difficulty upward? Is it related the number of people mining (a supply and demand kind of thing), the size of the blockchain, an intentional system design?
I found two related questions 1 2, but they are not exactly the same. I am more interested in what factors affect the difficulty and how. For bonus points, include predictions about future conditions.

The mining difficulty directly reflects the amount of computing power that the Bitcoin network has. This is adjusted on a periodic basis so that the average block solution time is 10 minutes (Bitcoin clients recalculate the difficulty every 2016 blocks). The difficulty can go up or down depending on how much effort people are putting into mining.
More information about difficulty can be found on the Bitcoin wiki.

So it is by system design?

The goal is that a single block is mined every 10 minutes? So if half the miners dropped out, the difficulty would drop too?

Yes, if a large number of miners dropped out, then the difficulty would decrease. See What would happen if 90% of the Bitcoin miners suddenly stopped mining? for more discussion about that.

Just to clarify a point, the difficulty does not decrease immediately. So if half the miners dropped out, the immediate effect would be that a block is solved every 20 minutes on average. However, at a difficulty retarget time, the difficulty is reset to give a 10 minute average time.

A bit more info, the difficulty adjustment is a scripted algorithm in the Bitcoin core code. It runs after every 2016 blocks and compares the actual time it took to add those blocks with 20160 minutes (two weeks). To prevent big fluctuations in difficulty, the maximum adjustment is a factor of four. When there are very large increases in performance, such as the introduction of ASICs, it takes several adjustments every two weeks to re-establish the ten minute average time to add blocks. This restricts the supply of new bitcoins to a predictable rate and supports the emergent consensus security trust model. Thus playing a part in preventing double-spends and denial of service attacks.
If there were a large decrease in mining performance, the decrease in difficulty (actually an increase in the hash difficulty target value to make SHA-256 hashing easier) would be adjusted accordingly. Think of rolling two dice. Getting a score less than twelve is easy. Getting a score less than three is hard. Same goes for finding a hash of the header (including new nonce) with a low numeric value.

Mining difficulty is periodically adjusted to ensure that block time stays at about 10 minutes. As more mining capability is brought online, difficulty will increase accordingly.


text:
Have network DDoS attacks ever been successful on any coin?
Has a cryptocurrency network ever been fully DDoSed so that the blockchain did not advance during the attack?
If so, which one and how?

Would be really difficult to DDOS a whole coin's network unless it were a coin still in infancy. 51% attacks have happened (intentional or not) and do stop the chain from advancing. Don't know if "dust spam" attacks (flooding the network with various ultra-tiny transactions transactions of real worth take a lot to get confirmed) have succeeded so far...

Because, except at a coin's release date, you don't know the IP addresses of most of miners to effectively DDOS them out- with just one miner the blockchain would go on save it'd be now at the mercy of that miner (51% attack).

Another type of DDOS attack I just thought of would be to pollute the network by using plenty of modified clients that connects to the usual port but emit badly formatted packages - or randomly corrupts the transactions it relays. Don't know how feasible/effective it'd be, though...

@JoePineda, What do you mean by "dust spam"?

@Pacerier Please have a look at http://bitcoin.stackexchange.com/questions/10986/what-is-meant-by-bitcoin-dust

This is more or less impossible, since you don't know where the miners are. Attacking the major mining pools is feasible, though they deploy some anti-DDoS measures. But even when such an attack would succeed, there still are people non-affected (eg. running behind NAT) and running the *coin network like if nothing happened.
The only issue that I can notice there is that the difficulty for getting a new block would be too high, so that the blocks would be mined much slower.

@Gracchus Yes, of course, those centralized services are vulnerable places (cf. DDoSes at major bitcoin exchanges). NAT protects from DDoS, since you don't publish your IP address, so that nobody knows, that there is a node behind this NAT, of course except from nodes you are connected to (unless they choose to publish it, which is a nonsense). I'm talking about a full NAT and not about a situation when you have an open TCP port. I also believe that p2pool users shouldn't be affected, since it's a decentralized protocol.


text:
What are the differences and advantages of stratum to HTTP?
I understand that Stratum is a kind of protocol specifically designed for ASIC miners. I found this page from its creator, but it is very technical.
I want to know, in layman's terms, what are the differences between Stratum and HTTP. I also want to know if this means anything to me; do it give me more hash, or more shares in the pool, etc. Or is it mostly a concern for the pool operators; running my miners on Stratum is better for them.

Stratum is an over-the-wire protocol that solves the headaches created by HTTP when used for mining. To understand why Stratum is necessary, you have realize the fact that HTTP is designed for serving web applications and web pages, it's main job is to return files and not to coordinate peers. But miners need to do more than receive information, they also need to send. The following are issues with HTTP:
Miner's request information
If a miner wants a new mining job, they have to send a request through HTTP. Why bother with having the miners request this information when the mining pool knows more efficiently what each individual miner should be doing? What happens if a new block appears on the network and the miner doesn't know about this? So Stratum flips this and has the mining pool sending information as it becomes available, not miners asking for available information periodically.
Long-polling
Long-polling is a very hacky solution to fix the one-sided nature of HTTP. It's done by setting a very high timeout limit (say 10 seconds) where the server purposely delays sending information until it has something to send. Imagine a URL address taking minutes to load because the server is simply waiting for something to happen on it's network. This creates a lot of inefficiency as miners are requesting data that simply isn't there and servers have to maintain those connections as well for as long as mining happens.
Ntime rolling
This is a more technical problem, and its fix is considered the biggest innovation of stratum. Miners are given the ability to modify 2 fields, the nonce and the time. This becomes a problem for large miners as they can run through all possible values of the two fields in search of the solution. If a miner runs out of unique possibilities, they have to send a new request. Newer and faster miners make this more easier to do by the month and bandwidth usage for a pool increases dramatically. Stratum solves this by giving the miners a few more fields which seriously increase the total possible solutions to a block.
TL;DR
Stratum makes it so that the miner and pool are freed from the inefficiencies of HTTP, which is not meant to support mining at all. It makes communication more efficient meaning future exohash mining equipment will have enough jobs to complete while the pool operator isn't being gutted by massive bandwidth and server fees.

So, to clarify, it helps the pool and every individual miner by not wasting resources; it is significantly more efficient, therefore, if your device supports it then you should use it. Second, exohash? Are we even close to talking about that? The highest hash I see on the market today is 4 Thash/s.

Along the same lines as the first question, my miner reports 205 Gh/s but the pool reports between 196 and 200. Will this change if I switch to the stratum protocol?

In can, may just be inherently caused by network latency. And exohashes concern the future more than anything where stratum becomes a must.

Excellent answer! Simple and concise

Do you happen to know why it is called Stratum?

@fredsbend Not too sure, but it's name bares similarity to the Electrum (as in the wallet) because Stratum was intended to be used for Electrum's networking. And both have meanings that correspond very well to their names.

@Jacob When I hear the word Stratum, I think of a single layer. Is the Stratum protocol appropriately called a "layer?"

Yes that's true, it's a layer of networking.


text:
Which altcoins have testnets?
Bitcoin can be run on a public testnet (by using a different port than the real Bitcoin network). This is very useful for development, because you can test software handling Bitcoin without handling actual value.
What is the situation for Bitcoin alternatives? Is there a testnet for most (or all) altcoins? Which altcoins have such a testnet feature?

Most mine-able coins are essentially clones of the bitcoin code and therefore have testnet. Many alt-coins do not have very active testnets so finding another peer on this network can take time, but given enough patience, your alt-coin testnet node will find another connection.
If you are impatient you can google for "testnet addnode" and include the coin you are looking for; this will (hopefully) find forum posts of people who have setup/found the IP address of a testnet in your desired coin, adding this to your configuration file will make your client attempt to connect to this IP on startup. If you need help with a particular coin, let me know :)

Talking about alternatives, CryptoNote based coins do not have a testnet mode but you can effectively create a testnet with a few simple steps.
https://github.com/zone117x/node-cryptonote-pool#setting-up-testnet
However there's one drawback to this method. You'll be able to set up your own testnode but the connection with other peers is done manually.
If you haven't heard of CryptoNote, it's a platform allowing for creation of absolutely anonymous cryptocurrencies. The best example of which is Bytecoin (BCN). This coin was launched in 2012 and is the first cryptocurrency to have used CN protocol as a core technology.

Bytecoin was actually launched in 2014, but backdated to hide an 82% premine. Today, the most widely used CryptoNote blockchain is Monero, which does have a public testnet mode.

Ethereum has multiple testnets. The general testnet running at the moment is called Ropsten, while the Rinkeby and Kovan testnets are used to test different versions of a new consensus algorithm.


text:
How did Ripple handle DoS/DDoS during the ripplescam.com days?
I'm going to assume that during the days where Ripple was irrationally hated by some sub-population, a la the ripplescam.com site which used to be the first result on Google for "ripple coin" until Ripple set the decentralization plan in motion, that it was mercilessly DoS and DDoS attacked.
How were/are the servers protected?

Companies generally discuss their internal security-related network operations. I don't think that RippleLabs is different. And now for the obligatory disclaimer: I am speaking in my personal capacity, not my capacity as a RippleLabs employee.

Of course it is - see http://www.github.com/ripple - but what does that have to do with protecting against (D)DoS attacks?

No, that's not what I said. The servers take steps to protect themselves, to the extent possible, when they detect that they are under load (e.g. by returning "too busy" errors for expensive operations or penalizing users who impose heavy load) but that's only a partial mitigation against a DoS attack, whose defining characteristic is an overwhelming number of connection requests, each requiring the server to do a lot of work.

Again, that's not what I said. Ultimately, when the server is being attacked by being forced to consume resources and do a lot of work, it's response is to protect itself by penalizing users placing a lot of load and limiting the amount of voluntary work it will do, focusing instead of the work that is mandatory (e.g. processing transactions and reaching consensus). Sometimes this will mean that legitimate users will be denied service - that's what a (D)DoS is all about! If you know of a magical way to distinguish good users from bad then I'm all ears.

it's not out, but it's not really practical either; in the era of botnets, blacklisting a single IP or 20 isn't likely to help significantly.

OK, since the comments section is starting to get unwieldy, I'll type a longer and slightly more elaborate answer, that incorporates some parts from the answer by @VinnieFalco.

According to Wikipedia, a DoS attack is defined as: "an attempt to make a machine or network resource unavailable to its intended users" and it commonly involves "saturating the target machine with external communications requests, so much so that it cannot respond to legitimate traffic, or responds so slowly as to be rendered essentially unavailable"
We all agree that a system that is connected to the Internet and is offering a service at some port cannot just magically prevent bad people from connecting to it, nor can it choose to accept only "good" traffic while avoiding receiving "bad" traffic.

There many "types" of DoS attacks, but they all boil down to one thing: they seek to consume resources:
As you know, resources come in many forms; sometimes attacks will consume bandwidth, other times they will consume RAM, disk space, IOPS, file descriptors, license slots/seats, or just about any finite resource that your service requires.
Fundamentally, you have two options: either increase available resources above the level of the attack, or ride it out.
Sometimes you can do a little better: you can attenuate an attack that seeks to consume bandwidth by using a content-delivery network. You can go from rotating hard drives to flash-based storage, and even to RAM based storage if the attack causes I/O performance to drop. You can limit the use of commands that require resource under attack.
Sometimes you can do better still: you can detect that the attack traffic comes only from a subset of hosts and filtering those data streams off at an upstream provider. If I/O is a bottleneck, you can attempt to rearchitect code to reduce the amount of I/O necessary. If commands are computationally expensive, you can attempt to optimize them or even reimplement them in a more efficient manner.
But, ultimately, all you can really do is blunt the force of a DoS attack. Generally speaking, you cannot prevent a DoS, and if it hits, you usually end up having to buckle down and waiting for it to pass.

So what about the Ripple servers?
As far as increasing the available resources, obviously that's outside the purview of the code: it can't magically provision more resources. That's the job of server operators who will typically ensure that their servers have sufficient excess capacity to provide servers even when demand for service spikes. So this isn't anything the code can do about something about.
What the servers can do something about, however, is to attempt to detect when they are under heavy load or attack and respond to that. In a sense, both those scenarios play out the same:
The servers will penalize connections which are forcing the server to do more work per unit of time than the server considers reasonable. Typically the penalty is to inform the user that the server is too busy and to ignore the command and to disconnect him if he persists in issuing commands at an unacceptably high rate.
Of course, the server has no real way to distinguish with perfect accuracy whether a user is abusive or not because it doesn't have a crystal ball. All it knows is the commands that it receives from a source and the rate at which the those commands are being sent and it bases its decision on that. So while this countermeasure will affect users who are, indeed, abusive, it can also affect legitimate users.
The server can also track load across all its connections and can decide to make some commands (which it knows are very expensive but not strictly necessary) temporarily unavailable, as load begins to climb. In that way, the server can conserve resources to use in processing the commands which are necessary.
Of course, this approach is more blunt and will affect legitimate users, as the server may refuse to execute an expensive command even from a legitimate user  who has not issued any other expensive commands nor caused undue load.
On top of that, there's what Vinnie Falco mentioned: the servers seek to protect themselves and the network from abuse by:

Imposing (miniscule and neglible) transaction fees that are payable in XRP and which scale dynamically in response to various factors, including network load; and
Imposing network-wide 'account' and 'action' reserves.

This means that someone seeking to attack the network in certain ways must, in essence, pay for the "privilege" of doing so and they harder they attack, they more they must pay.
Why is this helpful? Generally those who are orchestrating a (D)DoS attack don't really have to pay and their costs are minimal, making the attack not only  cheap to launch but cheap to maintain as well. This is a huge advantage
By imposing fees, which, for regular users are negligible, Ripple servers and the network take that advantage away: they "prevent" (D)DoS attempts because the cost of launching and sustaining an attack against Ripple quickly adds up.
There are a few other mechanisms which Ripple servers implement to protect against and mitigate the effects of (D)DoS attack. Combined, all these things work pretty well, but the bottom line is that we have come full circle to what I said earlier:
A system that is connected to the Internet and is offering a service cannot just magically prevent bad people from connecting to it, nor can it choose to accept only "good" traffic while avoiding receiving "bad" traffic.

One other thing I didn't touch upon: Optimizing the Ripple server code to improve performance. This is something that we at Ripple Labs spend a lot of time on and we still have things we want to do and ideas we want to implement. We also hope that the vibrant community of talented open-source developers will take a look and contribute their many great ideas as well.

All decentralized systems like Ripple that expose shared resources suffer from the problem of transaction spam. Bitcoin solves the problem by allowing a fee for each transaction, and imposing a hard limit on the amount of storage each block in the blockchain may take up.
In Ripple this problem is handled similarly. There's a base "reference fee" paid in XRP (the cryptocurrency built-in to the Ripple network) that sets the cost for transactions. XRP used to pay fees is literally destroyed - no one gets the money. It is there to prevent the monopolization of resources. Servers can vote to increase or decrease the fee. When the network is under load, the fee is dynamically adjusted upwards. This raises the cost for spamming the network above the value of the spam thus thwarting the attack.

@Gracchus An attack on transaction clearing using a large number of transactions will raise the transaction fee. Other kinds of attacks are handled differently, but they can't (at least not easily) affect the stability of the network, more the availability of service to particular endpoints (by attacking the servers that serve those endpoints).


text:
Are public keys included in signatures?
I can't easily and quickly determine from these wiki pages, 1 and 2, if the public key is included in the signed message.
Are public keys included in the signed message, or are they transmitted alongside the signatures, external to the signed message?

From a malleability perspective, I think this is a moot point: if a valid public key and signature is not provided, then the transaction can't be valid anyway (finding multiple valid public keys for an address is near-impossible). Still, better documentation on what is signed when/where/by whom would be great.

Are you asking about signing transactions or signing messages?

@Gracchus As Peter noted, the answer is incorrect if you are asking about transactions.  Bitcoin does things differently when signing transactions versus signing messages.  The public key is provided separately (either in the input script, the output script or a hashed script)

There are two answers to your question.
For a signed message, you can recover the public key if you have both the signature and the message that was used to create the signature.  The algorithm actually returns four possible keys, so the signature includes a header byte to identify which of the four should be used.  This is possible because we know which curve (secp256k1) is used by Bitcoin when it generates the signature.  If you want to see how this is done, look at recoverFromSignature() here
For a transaction, the public key is provided in the input script, the output script or a hashed script.  In the case of a multi-sig transaction, there are multiple signatures and multiple public keys.  There are also multiple ways to sign a transaction as determined by the signature hash type (a control byte added to the end of the signature).  If you want to see how this is done, look at checkSig() here

The signed message is the original message that was used to generate the signature.  I'll change the answer to specify the original message.

You are talking about message signatures. The uestion is about transaction signatures, which do not use key recovery and do not have a header byte to indicate which public key is to be recovered.

@Gracchus: Bitcoin (the reference client, and some other software) has the functionality of cryptographically signing messages using Bitcoin keys (with associated Bitcoin address). This has nothing to do with transactions or the peer to peer network though, it's purely a local operation. For these message signatures, a more advanced signing technique is used that wasn't known when Bitcoin transactions were designed.


text:
How exactly is network time sampled?
How exactly is network time sampled?
Is it as simple as one node stamping data right before being sent, the receiving node logging the current time before all other activity, and taking the difference?  Or is there something more complex involved?
Links to code would be much appreciated.

related: How is network time enforced?

Bitcoin block headers serve as the timestamp system for bitcoin. Whichever miner finds the next block includes their systems timestamp and the network either agrees it is valid or throws it out for being outside their margin of acceptance.
Bitcoin verifies the time with a margin of nTimeOffset, which is set by bitcoin asking other nodes what time they think it is and taking the median. You can find this code by looking at AddTimeData in util.cpp, found here: https://github.com/bitcoin/bitcoin/blob/master/src/util.cpp
It should also be noted that some miners, principally ASICs, do so much hashing that they actually push their timestamps a few seconds into the future using rolltime to get extra work sets: https://en.bitcoin.it/wiki/Getwork#rollntime


text:
How prevalent are multisigs?
There seemed to be great demand for multi-siganture transactions to be provided, but they don't seem to be so popular now that they are available.
What percentage of transactions are multisig since their release?

You can find the stats of different transaction types here: http://webbtc.com/stats


text:
Is it theoretically possible to limit the hash rate?
I am thinking of developing an altcoin that is truly asic/pool proof. I haven't tried yet (or even downloaded the source code), but I was wondering if it is possible for the network to behave in such a way that it will not accept a block found by a peer if the hash rate of that peer is above a certain threshold.
Would that be possible? If not, how could one achieve it?

I see no problem with ASIC hashing, in fact it is a good thing for a currency, cheaper transaction validation. It is just a bad thing for miners that want to get rich--but that is not what digital currencies are supposed to be about. Disclaimer: I am a miner.

Yes, it's possible. You just need a few rules. All miners must sign their blocks. All miners must "register" their public key before they are permitted to mine with that key. Blocks signed by the same public key are invalid if they are too close together by some rule.
The trick is controlling the registration system so that a single party can't just register thousands of public keys. You can do this by charging a fee for registering. You can also do this by having human approval required in the registration process.
You can design the fee so that if you mine for a month, it pays your fee. That way, only people who intend to mine long-term or invest in the coin will be able to mine. This will protect you somewhat from hit and run attacks.
However, for the record, I think the entire reasoning behind this is backwards. ASICs make coins more secure because they increase the investment required to attack the coin, just as this scheme would do. With ASICs, it's already done -- people have to invest in the coin to attack it.

The last paragraph is key. It seems that miners (I mine) miss the point of mining: to validate the transactions, not to make miners rich albeit that is nice. The sooner we get really efficient ASIC miners online the better and more stable the system will be.

Thank you, David, for this no nonsense thinking. For what I have in mind, I think this may actually work.

can you suggest how to implement this in go-ethereum. I shall be really thankful.

@RameshPareek Can you ask a more specific question? Which part are you stuck on?

Given the current proof-of-work paradigm, no. What do I mean by this? A coin which is mined by computing the hash* of data depending on both the previous block (so that the integrity of the blockchain is preserved) and the payload of the current block (so that the integrity of each individual block is preserved) as well as a nonce, such that the hash satisfies certain criteria (typically, being smaller than a certain value determined by the difficulty). In such a case, there is no way of telling whether a hash was found after trying trillions of times or just one lucky guess.
That said, I wouldn't rule it out entirely. But it will be very hard. In fact, I can relax some of the assumptions I just made and it would still not be possible to discriminate based on hashrate. To be able to discriminate effectively, you must have some way of preventing someone with a large hashrate from pretending like they are multiple people with small hashrates.
*Technically, any collision-resistant function mapping to a sequence of n bits will apply. I believe Primecoin's PoW is also applicable.

First: I doubt there's any point in doing this. A lot of work and potential for creating DOS and other exploit posibilities for proably no gain.
However: one way I could think of is somehow requiring the miners to sign each block, so you could only accept 1 block per x days from each miner. So that means you need to give each miner a private key with which they sign their blocks.
The next problem then is that you need some way to prevent the same miner from simply using 100 different private keys. So you have to have some mechanism to regulate those private keys: some central organisation handing them out or some trick where those keys are kept track of on the blockchain again. In the end you'll always have a problem that you don't know who you are giving a key to: maybe he already has 20 keys.


text:
Does Ripple use NTP?
Does Ripple use NTP or expect the nodes to do so?
If not, why not?  It seems that Ripple is a little more closed than your standard cryptocurrency, so this doesn't seem like an excessive demand.

The Ripple server has SNTP support to tolerate system clocks that are inaccurate.
The consensus process also builds a consensus network time. Each validator pulls the consensus network time a bit closer to their local time. This consensus network time becomes the close times included in ledgers that support features like expiring cross-currency offers.

We're client-server between the server and the client. We're p2p among servers. Anyone who wants to can run a server. We don't want to gratuitously cause problems just because someone's clock is off.


text:
Why did Ripple do a giveaway?
Was there ever a stated reason for the giveaway?
Was this in response to the ridiculous criticisms they received such as "centralization" and concentration of wealth?

Are you referring to a specific XRP giveaway? Right from the very beginning, they planned to give away ~%50+ of the XRP and before any of the many official giveaways were handing XRP out to anyone that wanted to alpha test the system.

Have you read https://www.ripplelabs.com/xrp-distribution/

The best description of XRP distribution/giveaways I've seen is on Ripple Labs XRP Distribution web page.
The whole page is worth reading, but I'll just include a few select quotes that may address the question:

Users don’t need to hold XRP if they prefer to transact in other currencies (e.g. dollar, euro, yuan, gold).

…

The inventors of the Ripple protocol created 100 billion XRP at its inception, and no more can ever be created according to the protocol’s rules. The creators gifted Ripple Labs 80 billion of the 100 billion XRP in existence.

…

Ripple’s method of confirmation, called consensus, doesn’t need mining; therefore, it requires comparatively negligible computing power, confirmation time adapts to network latency, and transactions are immediately irreversible once confirmed.
Because Ripple’s new architecture does not require mining, the creators of Ripple had a choice: distribute XRP exclusively via mining or diversify the distribution methods.
Distributing value is a powerful way to incentivize certain behaviors. Bitcoin’s mechanism, for example, led to an explosion of processing power devoted to bitcoin mining. Our goal in distributing XRP is to incentivize actions that build trust, utility and liquidity in the network.

There is no distribution mechanism for the XRP in the Ripple Protocol, instead all XRP were created with the network's emergence. However, XRP are necessary to create accounts, create trust lines, and to pay for transactions, so every user needs some in order to use Ripple.
So, Ripple was bound to have all XRP afer creating the network. They could have started selling them, but since at that point nobody used Ripple, why would anybody pay for XRP at that point?
Consequentially, there would be no other way to spread the XRP besides giving them away. As far as I remember, giveaways were announced in the very first thing I read about Ripple. So, no, giveaways were not a response to criticism.

Would you buy telephone minutes, if you know nobody that owns a telephone? Maybe, but it's a tough sale.

My observation and my interpretation. So, perhaps one should wait for someone that watches Ripple closer than me such as @dchapes or David Schwartz.


text:
How do goods & services sellers manage price instability?
How do retail outlets manage the massive price instability?
Are they really repricing every second with 25-50% spikes and drops over 24 hours?
How much does it cost to maintain accurate prices?  Most stores I go to have printed prices.
Please only reply with actual accounts of price instability management by sellers.

This isn't an account, but it covers anything an account could.
They update their prices based on how many USD they want for the item and the current BTC/USD ratio. There's even an electronic price tag that does this automatically: http://www.bbc.com/news/technology-26031331.
Online, it's usually handled by some outside payment process company like Coinbase. You set up the website to communicate to Coinbase "I need $x for this guy's order" then they redirect the user to Coinbase's payment page, where Coinbase asks the user for $x worth of BTC at the current price. When Coinbase gets the user's coins, you (the merchant) gets your money. Most merchants never touch the BTC.
In person, without the electronic price tags, it would be impractical (or even impossible) to price items in bitcoin by hand. One way around this would be to price them in USD, then take their total at the register to determine the amount of BTC needed for the purchase. Ie, the customer comes to the register with $x worth of goods, the merchant looks up the price of BTC (which they could do quickly), then asks the customer for $x worth of BTC.
If you mean how do they manage the risks of holding an asset that is volatile, the answer is that they don't hold it. They use Coinbase or similar.

This instability isn't an inherent feature of cryptocurrencies. If it were used at the same scale that USD/Euros are today, I'd expect it would be highly stable, just like those fiat currencies. I believe the instability is, ultimately, temporary.

@Gracchus Gold is not used as our everyday currency, and hasn't been since the USD became fiat. I think cryptocurrencies have the potential to become everyday currency (e.g. your "prices listed in a store" example), and in that situation, I believe they would be stable.

The universal demand for a currency is what gives it its stability. Gold isn't stable because it isn't a currency anymore. At best, it's a store of value. You have to ask yourself why people buy gold. It's all investors who are trying to avoid the crash of some fiat (gold bugs), investors trying to ride the bubble created by the gold bugs, and people looking for a good store of value. (The former 2 being the reason for instability. BTC has the same problems now with the former 2, but once it's universal, there won't be anymore instability caused by them.

Another way to explain it is with market depth. Right now on BTC-E, you could raise the price by 1.5% by buying an insignificant $100k worth of BTC (at $6b market cap). I couldn't find any data on the market depth of a big stock or something similar, but it would require at least 1 or 2 orders of magnitude more to move a NYSE stock that much. Now, imagine 10% of the people in the world used bitcoin and it had a total of say $10t invested in it. How much do you think would have to be bought or sold of something with $10t invested in it to move the price 1%? A LOT more than $100k.

Unless you only print currency for which you already have gold. A currency doesn't necessarily have to be arbitrarily inflated.


text:
Who has copied or reimplemented Ripple?
There have been almost an infinite amount of Bitcoin clones, but I have yet to see a Ripple clone or a Peercoin clone for that matter.  I'd include Nextcoin, but I don't think the full source has been released yet.
Is this correct?  If so, why not?
Ripple seems the most logical to clone because of the superiority of the code, and all one need do is generate a new genesis and checkpoint etc.
Are there a ton of Bitcoin clones because it has the largest market cap, and all want to get a piece, or does all of the undeserved bad rap that comes with Ripple repel clones?  That last logic doesn't hold much water when it comes to Peercoin.  Or is it harder to attract miners for Ripple because of the fee structure?
This makes no sense to me.  Why haven't the other major coins been cloned into oblivion like Bitcon?

See https://ripple.com/wiki/Forks

Also, your comments about mining doesn't make sense to me. Ripple has no mining by design. Those looking to make an alt-coin for the purpose of a pre-mine get-rich-quick-scheme would instead just create a new "scam" IOU within Ripple. Several people have tried this but so far no one has given them any value (worth mentioning) for the worthless IOUs they try and promote.

See the list of forks on the Ripple wiki. It currently lists four projects.
As to why there are not more, any answer will by necessity be opinion based which tends to be not appropriate on a StackExchange site. But my answer would be that, as you say, producing an identical fork is trivial to do but also useless. The value of system like Ripple comes from network effects that a clone would lack. The only reason rational people would consider a using a fork would be if it had some important new feature (hard, lots of work) or if the existing implementation had some serious actual or perceived flawed that the fork did not (including possibly just the perceived control a specific entity may have on the network). For many issues people appear to have with Ripple, instead of forking it makes much more sense to work towards having a set of validators with a robust set of UNL entries that possibly exclude Ripple Labs and additional non-Ripple Labs contributors to the code base.


text:
Fastest cryptocurrency
What cryptocurrency is the fastest in terms of reaching 100% transaction confirmation?
I've found sites like this that show that Fastcoin is the fastest at 48 seconds.
I think David Schwartz said that Ripple gets 100% confirmation in ~10 seconds.
Is Ripple the fastest, or is there another coin that is left out of calculations because of bias like that attributed to Ripple?
In this world of high frequency trading, is 10 seconds the best that can be done right now?

The number of confirmations considered to be 100% is arbitrary. Bitcoin could have chosen 1, or 100, instead of 6, trading off speed and security. If we turned Bitcoin's difficulty way down, we'd have a currency that got hundreds of confirmations per second, but you'd need millions of confirmations to get reasonable security.

If average block time is all you take into account to declare fastest, "42coin" would be fastest at (you guessed it) 42 seconds. But it's moot: you can design a crypto-coin with a block generation time of 3 seconds if you wish, but the massive amount of orphaned blocks would force you to wait for a lot of confirmations, thus negating the speed advantage. Ripple uses a totally different way to achieve consensus which results in faster confirmations, NXT could potentially be as fast or faster as everybody knows who will mine next block and so transactions can be sent directly to that node.

No, no, I was comparing "42coin" to "Fastcoin" - block generation time is a bit faster for the former. Yes, Ripple's method is ingenous and achieves much faster confirmations, plus a number of other niceties they baked-in altogether. Nxt's idea of deterministically chosing next miner seems interesting as well, but opens the door to a kind of DDOS attacks.

@Gracchus, What do you mean by "not the only way to skin the Fed"?

@Gracchus, Oh and I always wanted to ask... what do you mean by "asker oppression"?

@Gracchus, Might get left behind? I consider it already done: http://meta.stackoverflow.com/questions/251758/why-is-stack-overflow-so-negative-of-late

I know people tend to get obsessed about the confirmation time, but the important factors are the number of nodes and the speed at which any given transaction is seen by the network as a whole.
I believe this is under three seconds for a transaction to be seen by the entire bitcoin network.
Why is this measure important? Because this is the so-called "window of opportunity" for a double-spend. In fact as soon as the transaction hits the network, the race is on, so we are actually talking about milliseconds.
Satoshi provided an answer to this somewhere (I can't find it right now) which explains what the real issue is.
A large number of nodes means that any double spend attack, has to work harder to get the transaction seen first, and hence included in a block first. But again this is totally arbitrary because nobody can predict the winner of the block (who gets to choose which transactions to include).
So this "fastest confirmation" metric is a red herring.

I addressed the speed question which is often misunderstood. Regarding price stability, this has nothing to do with the mechanics of the coin networks, and was not mentioned in your question.

I think the point T9b is trying to make is that the first confirmation isn't the point at which the transaction is "complete" it's the point at which it becomes dramatically more difficult to change or reverse. Once a transaction has network saturation it is quite unlikely to become a double spend or orphan. Confirmations are more akin to the finalization of a transaction, the point at which a consumer has no ability to alter or reverse the transaction. At ~60 minutes, Bitcoin is leagues faster at this than credit or debit, which often take months.

There is a good reason why there is a delay - in fact the solution that Satoshi proposed to solve the Byzantine Generals problem and the double spend issue only works BECAUSE of the delay. What you don't seem to understand is the difference between a centralised system where someone agrees to immediate confirmation, but at the same time takes on the risk, and a decentralised solution where the risk is virtually eliminated, thereby not requiring a 3rd Party.

I'm not being facetious but I genuinely don't know what you mean by "Cowardly not to ping".

@Gracchus Cryptos can never be instantenous (i.e. < 1 sec for confirmation) unless you want to go back to a centralized model. Never. Because information takes real time to travel from one node to the other. Given Internet connections in the 3rd world are attrocious, I believe it really takes way more than 3 secs. for a transaction to be seen by the whole network - it's probably more like 1-2 minutes.

@Gracchus Please remember this is not meant to be a forum for discussions, rather a Q/A site. OTOH, you can always open a discussion in chat.