text:
Why did bitcoin programmers release mining code?
Why did anyone ever release bitcoin mining code, aside from promoting bitcoin and eventually raising investor awareness?
Looking at a price chart, bitcoins were valued at just a fraction of a dollar until it was better explained to people. Was this because
a) a lack of trust in fiat currencies during a recession, or
 b) release of mining code solely to get bitcoins to have any value in the collective at all.
Was the global liquidity crisis and recession merely coincidence?
I'm curious because bitcoins have offered a really great return for people that were mining before the promotions or at other points in time.

Which bitcoin programmers?

Bear in mind we can't know if there is somewhere a closed source hidden miner which outperforms the public ones.

Bitcoin is a decentralized digital currency.  It is meant to be resistant to corruption and external control.  That is the reason it was created.
Bitcoin achieves this only through the approach where consensus of the ledger is achieved by performing work.
Bitcoin is vulnerable -- this consensus mechanism can be blocked by anyone with 51% of the mining network capacity.   To prevent anyone from having that ability to block, the mining network needs to be large enough so that there it is vastly economically unfeasible for an attacker to disrupt the network.
So to achieve this requirement of being protected with a ginormous amount of hashing capacity, the mining process is subsidized.  This subsidy comes from the issuance of new currency. This subsidy helps to bootstrap the currency by putting it into many hands who might be willing to spend the funds for goods and services which draws merchants and service providers into the bitcoin economy.
So the combined goals of bootstrapping the bitcoin economy and ensuring that mining capacity is more than sufficient to dissuade any 51% attack are two reasons to release mining code and letting mining revenues be distributed to those willing to participate.
Because bitcoins aren't always circulating, there must be some willing to hold bitcoins as a store of value at all times.  Again, Bitcoin has value only because it is a decentralized digital currency that is resistant to external control.  If it doesn't have that then it is simply an online ledger -- no different than what PayPal provides, or what your online banking system provides.  There are plenty of other open source ledger software options for this.
Only from the protocol being open (and trusted as being open by having the software being open as well) would an investor that is willing to hold bitcoins be assured that the currency truly is decentralized.
For Bitcoin to be valued, the source code had to be released.   If the source code were never released, Bitcoin would never have achieved any value.

It's a chicken vs egg problem. If only one person had ever mined, or that one person only enable a small number of people to mine, Bitcoin would have likely never grown at the rate it has. We'd call it a centralized system, and it'd be little different from any other centralized currency contrived in the past several decades.
Its electronic transmission and security would be its primary benefits, but its users would still have to trust the miners to make their transactions official. This establishes a finite number of points of failure, all with an incentive to control mining. To me, this is not a very fair system.
Given your dichotomy, I'd point toward "release of mining code solely to get bitcoins to have any value in the collective at all". A thing can only gain popularity organically if it is exposed to the widest possible audience and those who choose to participate feel fully empowered. Distributed systems are pretty good ego boosters: everyone is equal, everyone can run a full node, everyone can mine.
As for the benefit of early adopters, this is true of just about any system. Those who learn something before it's popular, especially in technology, are the most likely to benefit from it as it gains popularity. This is called invention; this is called emerging technology. I personally like the title "Bitcoin consultant".


text:
Pricing bitcoins
Bitcoin functions as a a quasi-commodity currency and I believe it can be priced according to particular factors, variables, instead of simply by the supply and demand in the exchange order book.
The pricing of bitcoins reminds me of the days before options contracts had a standard pricing mechanism. Today, options are valued popularly by the Black-Scholes equation, and no matter how many buyers and sellers there are for an option, that contract will always have a particular known and predictable price, with one variable (Implied Volatility) to account for mispricing outside of that formula. Options of course, are derivatives of an underlying asset and an infinite number of the contracts can be created. Bitcoin on the other hand behaves more like commodity futures to their spot price, where there is a known quantity and a known amount of effort to acquire them.
Ignoring the overly simplistic idea of "supply and demand" imbalances, bitcoin is influenced by the following factors:

the rate at which new coins can be currently mined
the future rate at which new coins can be mined, based on perception of mining hardware and how that will affect network difficulty rates
how many bitcoins remain to be mined

I think these factors can be a greater influence than the speculators currently are, but it would require these factors to be reduced to a formula, as bitcoins are converging to a particular amount. This would allow for changes in volatility (wild swings in bitcoin price) to occur only in anticipation of real world events related to bitcoin.
Has anyone put any effort into pricing bitcoins or cryptocurrencies in general? Perhaps this is an area of study that you might be aware of

By rate, do you mean bitcoins/hash, or bitcoins/week? Because the latter is fixed.

@NickODell bitcoins/week is fixed no matter what the difficulty is? lets say 3000 bitcoins can be mined a week, if the difficulty rises above hardware capabilities, 3000 will still be mined? I'm not sure I am familiar with the entire constraints of the algorithm, so if you could elaborate...

The difficulty adjusts to keep pace with hashpower. This is also why there are timestamps on each block. The client looks at those timestamps, and if they are too close, then difficulty goes up. If they are too far apart, then difficulty goes down.

I don't think your analogy works because buyers who want Bitcoins to perform actual transactions are competing for a fixed supply of Bitcoins. If, say, the government only permitted a million options to be sold a year, you could no longer price options using anything as simple as Black-Scholes. (I believe what you're suggesting would be truly revolutionary if possible, but my gut intuition is that with significant research, you might be able to do a bit better than conventional methods.)

@Nick ODell The network aims at a fixed number of blocks per week, but this doesn't happen if the network hashrate is decreasing significantly or (as now) increasing significantly. Difficulty will lag in these cases. From the 2nd June to 9th June, for example, over 1300 blocks were solved instead of the expected 1008.

The real answers to this question are almost surely not in the open literature.

The market prices bitcoins, just as anything else (on a free market) according to supply and demand. Supply and demand is prices (expressed in any other good) and amounts. Example 10 bitcoins for USD 140 and 20 bitcoins for USD 139. That is, the lower the price a buyer can get, the more he is willing to buy. This is a value scale. All the users' value scales added together, is the universal value scale. Where the demand prices are higher than the supply prices, exchanges will take place and clear the market, after that new trades will occur when some individual's valuation changes. The price is the last trade. There is no defined value.
Bitcoins have no direct use value, only value for indirect exchange. The only reason to have some, is that others want them. Therefore it is money, since there is no use value, it is a very refined type of money. Since the supply is restricted, and they can be backed up, hidden and transferred in no time over the internet, I think the money qualities of bitcoin are extremely good.
The supply is fixed in the long run, any further supply is known in advance, and is therefore already priced in. The demand comes from the actors' preferences in their minds. If someone thinks it is a good inflation hedge, he wants to have more than just what is needed to do commerce. This is also called reservation demand, just like a car seller may want to keep a car over some time if he can not immediately get the price he wants. Since all demand pairs are added together, the number of people knowing and using bitcoins is a crucial parameter.
tl;dr It is impossible to know exactly, as the value comes from the minds of the thousands of users, but we (the current users) think that the number of users will expand and therefore the price will rise.

Unfortunately, I already propose that the free market theory of bitcoin pricing is very naive, just like how one wouldn't price an options contract by "supply and demand" because that would also be very naive. I propose that there is a formula which can also account for variance in the pricing and I would like other theories based on a formula

Is this regarding a pricing model now or 10 years from now?
Bitcoin is less than 5 years old and has progressed through several stages already; some of which contemporary economists have never seen in the wild before.
As people still consider the most relevant "price" of a bitcoin to be its external exchange rate value against a fiat currency; I don't think that the supply and demand aspect can be entirely ignored. Especially if the pricing of bitcoins is not hermetic to mining output but also involves its purchasing power in other currencies.
The supply aspect can't be entirely reduced to the release schedule and energy consumption of newly minted blocks; as there is a dead pool of many many early blocks. Any change in the hoarding habits of these bitcoin owners (if private keys haven't been lost) will distort the mining rate/pricing calculations. Even whether miners choose to mine at a given rate depends on their ability to recoup hardware and electricity costs in US/EUD/CNY/etc currency; as ASIC fabricators and energy companies won't accept bitcoins directly until local exchange liquidity is extremely high (too many downstream vendors for these industries).
The demand is influenced, whether we acknowledge it or not, by speculators and illegal drug transactions as bitcoin still lacks the scale and merchant acceptance to compete with popular fiat currencies. If bitcoin survives long enough then both speculators and illegal merchants will be flushed out of the currency, by volume if nothing else.
I suggest people should be careful in applying elaborate derivatives on a young and volatile market - even though the volatility makes these derivatives tempting. The inherent assumptions and the uncontrolled independent variables of such mathematical models essentially result in information being lost about the true past and future behaviour of the market and the actors in that market. The GFC occurred in part because information about risk was accidentally or deliberately lost. Very large and long-term  pre-existing markets can handle the inaccuracies of these models because the models fit the market instead of the other way around. Although sometimes Goldman Sachs can sell an instrument so widely as to warp the market towards the model.

Hmm, you said that speculators would be flushed out of the currency by volume. Is this even possible? Looking at fiat, the total influence of speculators on them is no small amount right?

@Pacerier High volume currencies are used so widely as to suppress the impact of currency speculators. Most old-school speculation we hear of is of stock or commodities as the volumes of these can be low enough for the equity of speculators to influence the price. The tricky problem is that the utility of mainstream currencies mean that they reflect the broader economy - which is influenced in a variety of covert ways by private equity investment; of which some hedge funds could be considered aggressive (speculative). Lower volatility "flushes out" most speculators as margins decrease.

I think pricing bitcoins will be influence by one more factor at last, the competition market of transaction fees between users and miners.
Here is an explanation and the simulation:
The value of bitcoins is the sum cost of keep transactions moving, but I think this great feature is not obviously revealed in current market. Bitcoin provide a way of low cost(low power to compute) to keep transactions smooth, ex the sum power cost is X. And people in developed economic activities can afford to provide low transaction fees, ex Y.
The lowest transaction fee is a constant value price in a period.
Then, the volumes sum of bitcoins should be equal to X, and X equals 2.1 * 10^7 BTC.
So

1BTC = X* 10^-7 / 2.1 = 1X/(2.1Y) * 10^-7 *Y

The more mining power join BTC, the bigger X is, and the pricing of BTC will go up.
Current Y/X is too high, because of kinds of reasons, ex two many middleman like Wall Street.

Okay, can you plug in real variables to rationalize current or future bitcoin prices?

source: Stack Exchange

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

sort: votes


text:
Is there a reference, authoritative resource or book on Bitcoin programming?
Is there any reference or authoritative resource, or book on Bitcoin programming?
Bitcoin is dubbed "programmable money" but there is no obvious resource for how to do that aside from trudging through subsections of hack-prone forums.
Altcoins many times are simply finding and replacing the word "bitcoin" in the code base and clients, so it seems even in that case their programmers have a thin understanding of various bitcoin programming paradigms.
I'm sure a "book" would be outdated by the time it was published, but regardless it would be helpful to have everything in one place for a potential target audience that doesn't want to reverse engineer commit history just to see whats going on.

My 7 year old question lol. This was asked in 2013. In 2020, the answer is "yes". I've launched several lucrative businesses using this knowledge in that decade.

I was asked by Hasan Hasan, a junior developer, which of the following three books I'd recommend. Personally I think all three books are fantastic (I would recommend them all) but they do approach the topic from very different angles.
Mastering Bitcoin (2nd edition, Andreas Antonopoulos) was the first technical Bitcoin book to be published. The 2nd edition was published in 2017 so there may be some outdated details but the vast majority should still be accurate today. It does have some chapters on concepts but not as comprehensively as Grokking Bitcoin (see later). It will provide instructions for configuring a Bitcoin Core build from the command line and contains a lot of Python code examples. It is especially strong at explaining Bitcoin scripting. For an example of Antonopoulos teaching Bitcoin Script see his 2017 presentation at SF Bitcoin Devs (video, transcript).
Programming Bitcoin (Jimmy Song) is also a technical Bitcoin book but covers different topics in depth than Mastering Bitcoin. Mastering Bitcoin mostly avoids cryptography but Programming Bitcoin has three detailed chapters on finite fields, elliptic curves and elliptic curve cryptography. If you like math or want to understand how public keys and signatures are generated in detail this is the book for you. There are also more Python code examples in Programming Bitcoin than Mastering Bitcoin. There are some conceptual explanations but generally I would say it assumes you understand most concepts covered in Mastering Bitcoin and Grokking Bitcoin (or that you best learn those concepts through code rather than written explanations.) For an example of Jimmy Song teaching ECDSA and transactions see this presentation at Bitcoin Edge Dev++ in 2017 (video).
Grokking Bitcoin (Kalle Rosenbaum) contains minimal code, instead it focuses on the various challenging concepts that you need to understand to get to grips with Bitcoin. For example, Kalle Rosenbaum presented  how SegWit works at London Bitcoin Devs in 2020 using the content from Grokking Bitcoin (video, transcript). If you are having trouble understanding a concept I'd recommend that book as some of the diagrams, explanations and exercises are really useful. It is easy to discount this book as being the less technical of the three but if you are already a junior developer you may have more trouble with concepts than command line and code. It is a technical yet accessible book.
They are all open source so you can try before you buy. Mastering Bitcoin is here, Programming Bitcoin is here and Grokking Bitcoin is here with a special build of the book including diagrams here.
If you like them and can afford to buy them I encourage you to support the authors and publishers by purchasing them. Whether the authors publish future editions of the book or continue to produce these kind of educational resources depends on how successful the books are. In Grokking Bitcoin's case you can buy directly from the Manning publisher here but all are available from Amazon or your usual book seller.

// , michaelfolkson++ on the Mastering Bitcoin. Re-reading it and getting my mind re-blown.

I'm writing a blog series for beginners called "Basic Blockchain Programming" that might suit your needs. It starts from scratch until building the first raw transaction:
http://davidederosa.com/basic-blockchain-programming/
It's still a work in progress, though (4 or 5 posts left).

It is in the works. Mastering Bitcoin by Andreas M. Antonopoulos
http://bitcoinbook.info/

How can I read it right now? On the website I cannot buy nor ebook neither paper version yet. I found https://github.com/aantonop/bitcoinbook but I cannot compile the asciidoc properly. Please help me with this question if you can: http://ebooks.stackexchange.com/questions/2535/how-to-render-asciidoc-with-latexmath-macros

Here you have http://chimera.labs.oreilly.com/books/1234000001802/index.html
Whole book online

The best sources that I found for free:

Mastering Bitcoin
Developer Documentation

I didn't check this out Bitcoin Programming by Mostafa Farghaly
but looks like a good wisdom source.

Bitcoin Programming Book

PDF https://gumroad.com/l/Bitcoin-Programming-book
Paperback http://www.amazon.com/Bitcoin-Programming-Mostafa-Farghaly/dp/1500176826/

As far as I know a book about bitcoin programming doesn't exists.
The best resource you will find is the bitcoin wiki that is describing the bitcoin protocols very well.

July 2014 Edit
Now there is a book called Mastering
  Bitcoin that is
  available in early release.
I believe that this book match to what you are looking.
You can buy here on
  Here

Programming Bitcoin by Jimmy Song
ISBN: 9781492031482

I would post this as a comment to another answer, but I don't have enough reputation.
I haven't read Basic Blockchain Programming, but have read at least parts of all the other books mentioned here. The one I found most useful was Bitcoin Programming by Mostafa Farghaly. Be warned that the English is poor (but totally understandable), and there are some typos in the code. That being said, it will point you in the right direction. It has some basic code examples in JavaScript, Python, PHP, and Ruby. Most of the examples are in Python. If you're new to programming, I would recommend checking out Think Python first.

I find this wonderful software a very interesting style of programming bitcoin and you can consider it as a book with this title "Asynchronous C++ Bitcoin programming". The name of the software is
libbitcoin - Asynchronous C++ Bitcoin library
Mainly it used the famous boost library ASIO. It provides developers with an asynchronous I/O model using a modern C++ approach.
The libbitcoin library took advantage of the algorithmic aspect of recent C++ 11/14 (lambdas heavily used in the coding, also an understanding of the new introduced pointers, variadic functions, bind function, promise & future is a must).

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

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


text:
is bitcoin stability by securitization possible?
Bitcoin is subject to high volatility with little means of hedging. The available ways of hedging being to be short or buy puts on VERY ILLIQUID exchanges that contain no market participants, no market makers, or any order book depth.
could a hedged bitcoin fund with redeemable shares act as a stabilized security?
This, of course, creates a quasi-central banker role, where proper management can lead to stability, but proper management may not always be. But it is more inline with commodity hedging, where a producer (of crops for instance), hedges his output with futures. Such a quasi-hybrid role being fit for a quasi-commodity currency.
As such, an Exchange Traded Fund (ETF) or Exchange Traded Notes (ETN) can be created on existing exchanges. Securitization is practically the wild west even amongst the myriad of regulators, making the leverage and hedging possibilities endless.
Anyway, thoughts on why this would or would not work for bitcoin as the underlying asset?
proper tags: securitization, securities, etf, etn, hedging

CQM, could you edit your question to include a clearer question, especially in the title?

so I wonder, did my question here predict the future or inspire the future

@Gracchus it does doesn't have to be. With derivates, the "tail can wag the dog", this is a phenomena we see in many other markets where the derivatives effect the price of the underlying asset (instead of the other way around), such as on options expiration days

@Gracchus like... in the current equities and commodities markets? I think bitcoin can attract that level of liquidity

@Gracchus I respectfully disagree, in the year since I've posted this there have been a lot of developments. I am confident that the answer to this question is "yes". There are liquid ways to short bitcoin, there are also CFDs and there are bitcoin futures and there is a bitcoin investment trust. None are very liquid, but correlated is the fact that bitcoin volatility has decreased.

@Gracchus all the derivatives products I mentioned trade on their own centralized exchanges. They do not require blockchain confirmations, they are instantaneous database entries from a centralized matching engine. I am confident that colored coins will change this reality (unlike mastercoin, xcp etc) and create a decentralized instant-enough bitcoin-settled derivatives market

@Gracchus US brokers have 24 hours to let the customer meet a margin call before closing trades. One hour is a 95% improvement .. or .. 2400% faster.


text:
How to experience the thrill of mining?
Bitcoins are hard to mine now. I've always wanted to actually earn them, but never actually gotten much of anything. I want to create my own blockchain, separate from any other networks, so that mining will be faster and I'll actually be able to experience the thrill of mining bitcoins.
Will someone give me a suggestion, program link, or what have you re: a private network? I just want to try it. Not a spendable coin fork, just something that I can enjoy watching for a bit.

Have you tried understanding why you have that desire? It might help you understand more about what makes you tick.
You might like to try mining Litecoins, or even on the Bitcoin Testnet. Or, you could try some Bitcoin mining with the Eligius pool, which from memory will pay out any amount after 2 weeks (whereas most pools have a minimum payout). If you can manage to mine 0.01BTC, that is enough to make a transaction from most eWallets (again, they often have a minimum transaction, usually 0.01BTC), and you could possibly even buy something from coindl.com with it.
Alternatively, you might get more satisfaction by playing Minecraft (it has a free trial), which can give the same sense of satisfaction when  you find something of "value".
Another option to consider is earning some dollars, or whatever your local currency is, and exchanging it for bitcoins. Or even just save some dollars on electricity by not mining, and exchange those for bitcoins. Or, sell something on bitmit maybe?

You can always try the testnet it is really easy to mine on it since difficulty gets reseted to difficulty one.
Just start your bitcoin client with the -testnet parameter (and -gen if you want to CPU mine)

From memory, the -gen option will only work on older versions of the Bitcoin-QT client, though they probably are still available for download.

Run Bitcoin Core with the -regtest flag set:

For situations where interaction with random peers and blocks is unnecessary or unwanted, Bitcoin Core’s regression test mode (regtest mode) lets you instantly create a brand-new private block chain with the same basic rules as testnet—but one major difference: you choose when to create new blocks, so you have complete control over the environment.

https://bitcoin.org/en/developer-examples#regtest-mode


text:
What methods are available to accept Bitcoin payments?
I'm curious about offering Bitcoin payment instead of PayPal (for all the usual reasons for disliking PayPal). Is this realistic, or is my understanding of how bitcoins can be used off?
My customers are mostly nerds or at least tech-savvy people, so they are somewhat likely to be familiar with Bitcoin, and equally likely to be sceptical towards PayPal.
Are there any decent guides on how the whole thing ties together, and which merchant actors are considered serious or "big players"? I'll be looking at getting the bitcoins through whichever funnel is required and transferred to my "real cash" bank account (in any currency, really) as quickly as possible.
Of course, it wouldn't hurt if I could get the coins all the way to my bank account for a <2% commission, but I'll take reliability over price any day of the week.

Clarification: I sell a commercial software license to an open source product (free for personal, non-profit etc use), so there's nothing to be delivered upon purchase. Current options are hand-rolled integration to credit card and PayPal providers.

When the day comes that some of your supply chain accepts bitcoin you'll be less anxious to convert your revenues to fiat, as you could save that 2% by paying in bitcoins instead.  For now, it is understandable that you wouldn't plan to hold bitcoins -- especially with the recent volatility.

tbone, you should look at http://bitcoin.stackexchange.com/questions/3093/how-can-i-process-bitcoin-transactions-in-my-store?rq=1

There are a number of approaches, and the best method for you will vary on a number of factors.
For instance, if you sell a digital good it might be easier to simply sell the item through an online store like CoinDL, where you simply direct your customers there.
Similarly, if you sell a couple of items at a fixed rate, you could sell it on BitMit.net, again -- your e-commerce site simply directs your site visitors looking to pay with bitcoins there.  A blog post on Coinbase describes a "Buy Now" button modeled after another leading e-commerce payment solution.
If you already use an e-commerce shopping cart you might have an easy way to start accepting bitcoin if there is a module for that cart interface software that accepts bitcoin.
When following the DIY route, you can have the proceeds of your sales converted to fiat upon receipt.  Some exchanges (like Mt. Gox) offer "autosell" for shopping cart tools so that proceeds convert to USDs (or other currency) upon receipt.
The easiest way, however, is to use a payment processor like BitPay, WalletBit, Paysius, and ZipBit.  These are used in a similar way that a site uses PayPal to accept payment online.  The payment processor will provide all that is needed for your e-commerce site, and will provide a method to receive cash via a bank transfer.

BitPay (or other option) seems to be exactly what I need to replace my PayPal flow.


text:
Why are mining pools not removing the 250 kb block size soft cap?
I might have misunderstood what is happening, but looking at the block sizes it seems that most mining pools are sticking to the 250 kb soft cap, with BTC Guild being the notable exception. There are many blocks that are just under 250 kb, so I assume that pools are excluding certain fee-paying transactions to stay below the limit.
My question is, why are they doing so? Is the marginal cost of including those extra transactions indeed greater than the fee being paid? If not, what is their reasoning for acting in a non-profit maximizing manner?
The whole idea of Bitcoin is based on the assumption that participants behave rationally - i.e. profit maximizing. So what is going on here?

Some pools may still use the 250 KB cap for faster block propagation and reduced chance of orphaned blocks. If one block is orphaned you probably have to mine for 10 years to recover that loss with the extra transaction fees from mining larger blocks.
However I think many pools use a max size above 250 KB. The reason most of the blocks are smaller, even when there are more transactions available, is that they set a max size for how many KB of free or minimum-fee transactions they will include. There aren't enough above-minimum-fee transactions to fill up the blocks.

Thanks. I didn't know pools were excluding min-fee transactions. So the pools judge that the orphan cost of including a transaction is greater than the current min fee of 0.0001. Just trying to understand the fee situation better.

Currently, most pools consider transactions "free" if they have fees below a certain amount per KB or no fee at all. Pools limit how many free transactions are included in each block. If using max block size 500 KB and max space for free txes 50 KB, then you will see blocks down to 50 KB in size even when lots of unconfirmed free transactions are available.


text:
What does the term "Longest chain" mean?
What does the term "Longest chain" mean, as there is only one 'right' blockchain exists? How another longer chain would make the 'right' chain invalid?

Bitcoin's block chain system is really two quite separate systems, and they are easily confused. The first one is the block tree and the second is the active chain.
The block tree consists of all valid blocks whose entire ancestry is known, up to the genesis block. The rules for validness include no double spending, valid signatures, no introduction of more currency than allowed, ... These are the network rules, and every full Bitcoin node verifies them.
The active chain is one path from genesis block at the top to some leaf node at the bottom of the block tree. Every such path is a valid choice, but nodes are expected to pick the one with the most "work" in it they know about (where work is loosely defined as the sum of the difficulties). Relativity and technological constraints prevent us from doing instant communication across the globe, so two nodes can not be expected to pick the same chain as the active one. This is no problem: the mining mechanism makes sure that the chance two nodes disagree about blocks in the past decreases exponentially as they are older.
So no, there is not one "right chain", there are many. Nodes choose for themselves, but the system is designed to make sure consensus arises quickly.
The rules in practice are this: when a new block arrives, and it extends the previous active chain, we just append it to the active chain. If not, it depends on whether the branch it extends now has more work than the currently active branch. If not, we store the block and stop. If it does have more work, we do a so called "reorganisation": deactivating blocks from the old branch, and activating blocks from the new branch.

Sir, how a node selects the most recent block on the longest path; e.g., assume node knows two sub-chains, how it identifies which one is longer? Is it just going compare their lengths (number of blocks)? Thanks.

We look at the amount of work in each chain: the expected number of hashes that were necessary to build them. This loosely corresponds to the sum of the difficulties of the blocks in both chains (which is almost always the same as just comparing the length, unless the fork spans a retarget).

This answer doesn't precisely define "work". The work of a block is actually defined as floor(2^256 / (target + 1)), where 'target' is the target threshold converted from the 'nBits' field of the block header. (See the GetBlockProof function in src/pow.cpp.)

@DairaHopwood helpful comment, although technically the comment right above yours does define it ("expected number of hashes..") :) . For those wondering where the formula comes from: the expected number of hashes is 1/p where p is the probability of hashing to the target or below, so p = (target + 1) / 2^256.  (the "+1" is to count the hash with all 0s).

Imagine that the blockchain is 210000 blocks long and TWO miners both find valid blocks within a few seconds of each other and broadcast them to the network.
This is perfectly normal as the Bitcoin network is peer to peer and global.
You now have two chains, each of length 210001. Neither of these are longer than each other. Some bitcoind nodes will see the first miner's block and some bitcoind nodes will see the second.
Temporarily you have two forks of the blockchain, each of length 210001 blocks long. They are identical for 210000 blocks, but the 210001st is different on the two forks.
Sometime later another miner finds another valid block, the 210002nd block, and that will be attached to exactly one of the forks.
This chain is now the longest at 210002 blocks and becomes the longest chain. It becomes the "definitive" blockchain.
(The transactions in the alternate fork don't disappear - they simply get put back into the pool of unconfirmed transactions and miners will put them into a subsequent block).

But is that one block that was on the 210001 chain awarded? The network chose the 210002 chain, and the transactions from the 210001 chain get recycled for the next block (210003?) and the 210001th goes away?

My understanding is that under most circumstances the transactions in each of the forks are mostly the same. Any fee-paying transactions in the (soon-to-be) orphaned block (eg 210001B) would likely be included in the block immediately following (ie 210002) because those transactions are considered still available by miners working on their own fork (210001A). They wouldn't need to wait for block 210003, as the final paragraph implies.

This excellent description cleared things up for me, thanks! and the answer I was looking for is: it may be that at block N two blocks are broadcast at nearly the same time, but it is very unlikely that happens twice in a row, and vanishingly likely it happens three times in a row, thus things converge quickly.  My next question is: has it ever happened (or recently happened) that it happened twice in a row, thus there were 3 or four chains each of the same length and miners start working on each?  I guess I'll find a blockchain explorer and start looking ...

This is a nice answer!

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


text:
How many bitcoins would it require for a sustained DOS attack on bitcoin network?
How many bitcoins would it require for a sustained DOS attack on bitcoin network?
Without transaction fee, how many bitcoins would that be?
How many transactions could we generate with 1 BTC everyday (without fee)?

7 transactions per second times 60 equals per minute times 60 equals per hour times 24 equals per day = 604800 satoshis sent in individual transactions. However, nodes filter such so-called "dust" transactions. The minimum output amount for a transaction to be relayed by the network is 546 satoshis. So: 330220800 satoshis = 3.302208 BTC to fill the network for a day. http://www.reddit.com/r/Bitcoin/comments/37z9ln/how_much_btc_needed_to_fill_entire_1_mb_block/crqzv63

It appears that you posted an answer as a comment. Please rather answer your own question instead. :)

7 transactions per second times 60 equals per minute times 60 equals per hour times 24 equals per day = 604800 satoshis sent in individual transactions.
However, nodes filter such so-called "dust" transactions. The minimum output amount for a transaction to be relayed by the network is 546 satoshis. So: 330220800 satoshis = 3.302208 BTC to fill the network for a day.
(As explained in, http://www.reddit.com/r/Bitcoin/comments/37z9ln/how_much_btc_needed_to_fill_entire_1_mb_block/crqzv63)

This answer does not take into account minimum fee rates or competitive fee rate environments which are the primary platform in which potential "DOS" attacks could be effectively attempted on Bitcoin. It also does not take into account that in order to effectively DOS an entire block a pool would need to execute it against the probably much more valuable and high quality chains produced by other pools. Thus you would effectively need to add in the rate at which a pool can be bribed to essentially commit career suicide by attempting such a thing.

authors: Андрей Кучай


text:
How do I mine with more GPU's than my motherboard has slots for?
I noticed pictures of some mining rigs that appeared to show GPUs hooked up to cables going to a mother board and not using pci slots. What are these cables called and how can I use them to increase the number of cards I have on one board?

They may have been using an adaptor cable which allows use of different slots, such as the one pictured here: https://bitcointalk.org/index.php?topic=66070.0
During mining the data going to and from the graphics card isn't nearly as much as when the card is used for gaming, so there's no substantial deterioration in mining output.
However, I do remember reading about at least one case where circuitry was overloaded doing this (ie it burnt out), possibly due to a faulty cable, but also possibly because graphics cards aren't designed to work that way.


text:
How does one calculate the profitability of GPU mining?
As GPU mining made CPU mining non-profitable, at some point in time more specialized mining hardwares (FPGA and ASIC) would make GPU mining non-profitable.
When is GPU mining considered not-profitable?
Considering $1000 rig, $0.2 per kWh and one year break-even period,
at which difficulty does GPU mining become non-profitable?
Or, what is the formula to find out "max non-profitable Mhash" for given parameters like, rig cost, power consumption, investment break-even period, difficulty, exchange rate, etc. (please ignore redundant parameters, and include more parameters if required.)
Or, whats the current "max non-profitable Mhash"?
Or, what is the required current energy efficiency (Mhash/J = millions hashes per joule) for mining to be profitable?
(energy efficiency; 1 joule of energy is 1 watt during 1 second: 1 J = 1 W*s)
For given parameters, Max. Non-profitable Hash Rate, is breakeven point for hash rate after which mining becomes profitable.

This is for your reference.. https://bitcointalk.org/index.php?topic=281279.0

Using the Bitcoinx calculator, I found that a $1,000 rig with a 300 W power draw would need to have 750 MHash/s just to break even on power at $0.20/kWh at the current difficulty (3,438,909), exchange rate (13.13), and block reward (25).
You'd never break even on the rig itself. Thus why GPU mining is on its way out.
For a more absurd example, I priced out a reasonable rig for ~$1,405 with three Radeon HD 7970s, the best mining card combo - 2050 MHash/s - on the market at the time of this writing according to the Mining Hardware Comparison chart. Its power draw would be around 850 W, according the MHC and a quick review of the parts. This rig would never be profitable at $0.20/kWh. Hell, at my electric rate of $0.07/kWh, it'd take nearly three years just for a return on investment. Prior to the recent halving, this same rig would make a return after just ~260 days.
More proof that GPU mining is on its way out.

Interestingly enough, having not calcuated my profitability since the halving, I just realized that my own rig isn't profitable anymore :-(

This is no longer correct, with the new exchange rate of 91USD/btc

This is true. The parameters from the first example produce a still-profitable system, likewise the second. Perhaps this price spike is breathing some extra life into GPU mining!

Well, there are calculators for that.
In general, GPU uses a lot of power and at the current difficulty doesn't generate that much bitcoins. Even if you have a return of investment of 1 year, look at the current difficulty graph. It is rising rapidly. Also, note that the ASIC devices are still not out, the difficulty will increase a couple times that.
When calculating whether it is profitable to mine, you need to calculate how many coins you can mine in a given period of time and how much money you will spend on electricity. Be pessimistic with your calculations - assume that the difficulty will rise in the future. If the number is still positive, see how long would it take to earn back the cost of your GPU and other supplies. If it is more than a couple months, you are entering the uncertainty waters of the future market.
In short, unless you have very cheap electricity and low startup costs (second hand hardware at a discount price perhaps), chances are you answer will be that the GPU mining won't ever be profitable again, at least when you are talking about block mining. There are alternative uses for a mining hardware, for example vanity address mining which can still be profitable. But remember, always do your math before making an investment.

I don't really see GPU-mining continuing much after the ASICs "finally" arrive.  However, there is one major factor that none of the online calculators properly project. That's the rise of the BTC->USD ratio. This becomes rather speculative (kind of like the stock market), but given that the next having won't be for another 4 years, a significant rise in valuation could once again make GPU-mining profitable for the casual miner.  Take a look at some of these charts.

Its OK 'online calculators' just doing their job. After all they are not speculation or technical analysis tools. :)

"rise in valuation could once again make GPU-mining profitable for the casual miner" - wouldn't it be better for the casual miner to then just speculate in Bitcoins and buy them. Less hassle and same profit/loss exposure.

It is deemed not profitable when you cannot recoup the costs you make with the energy spend (and possibly the costs of the video card). It very much depends on how much the card costs, your energy price, and how you think the difficulty will change in the future. If you can provide

Can you finish your

GPU mining will still be in demand as long as there are scrypt coins like Litecoin that of any value. Scrypt coins are ASIC resistant at this time. However the price of LTC/USD has dropped significantly recently down to just $2.40 as of this post. There are many alternative crypto coins to mine now a days though...
Here is a great crypto coin comparison table
And here is an even better Mining Hardware Comparison table


text:
With Ripple, how do Gateway IOUs work?

A Gateway must do two things

accept some form of deposit from a user and give the user Gateway
  IOUs. (Other -> ripple)
accept Gateway IOUs from a user and send that
  user payment. (ripple -> Other)

How does Gateway IOUs work? I have three basic questions:

Which one happens first in a gateway, (a) users pay money to gateway, or (b) gateways transfer IOUs to user? What guarantees that step 2 happens?
What will happen when a gateway refuses to accept IOUs, and transfer money back to user?
Is there anything similar to 'interest rate' for holding IOUs for long time?

which one happens first in a gateway, (a) users pay money to gateway, or (b) gateways transfer IOUs to user? what guaranties step 2 happens?

The gateway gets to set its own policies. However, the general consensus is that gateways should avoid risk because they'd have to pass losses onto their customers in the form of higher fees. So you probably shouldn't trust a gateway that extends IOUs to people whose money it doesn't hold.
If the gateway breaches its contract with you, you should complain publicly, sue them, or take whatever action you consider appropriate. Gateways are only worth their reputations.

what will happen when a gateway refuses to accept IOUs, and transfer money back to user?

The user can just exchange the IOU for another IOU at a gateway that will do business with them. A gateway can't can't really refuse to redeem IOUs for one user specifically because the IOUs are tradeable and fungible. Once at least one outbound Bitcoin gateway is running, you could exchange the IOU for Bitcoins.
If a gateway begins reneging on its redemption agreements generally, then the value of those IOUs will fall and people will stop accepting them. This is the counter-party risk you take when you extend trust in the Ripple system. Using Ripple as a store of value for fiat currencies requires reliable gateways. There's no getting around this.

is there anything similar to 'interest rate' exists for holding IOUs for long time?

No. Once interest rates increase from their current near-zero level, this could be a major profit center for gateways. Of course, if being a gateway is very profitable, lots of companies will do it and then competition will either drive down rates or drive up services. (Remember when banks gave away toasters?) Nothing stops a gateway from giving rewards to people who hold their IOUs.

What will happen when a gateway refuses to accept IOUs, and transfer money back to user?

Then it's no longer a gateway, it's just some random user of Ripple, and nobody should do business with it. I'd only do business with a gateway that I could sue or press charges against if they reneged.

Is there anything similar to 'interest rate' for holding IOUs for long time?

Not automatically. Gateways would have to set up a script or process for sending "interest payments" to the holders of their IOUs. (Similar to how a company sends dividends to holders of its stock)


text:
Are two factor authentication enabled wallets at mtgox or blockchain.info safe even with weak passwords?
Are two factor authentication (2FA) enabled wallets at mtgox/blockchain.info safe even with weak passwords? What are the risks here, except losing one's mobile phone?
A Google authenticator is used for the 2FA, the Google account itself is also 2FA enabled.

Could you elaborate?

Blockchain.info does not use 2FA for encrypting the wallet and instead uses it only for limiting access via the web interface.  If your system is compromised with a keylogger, and the attacker has access to the blockchain.info wallet (e.g., the backups sent via e-mail), for instance, then the attacker can perform a replay attack and spend the funds from the wallet.
Also, if your system is compromised the attacker might be able to obtain the password and OTP code and use that for login by simply being first to login with those credentials.  Mt. Gox implemented 2FA correctly, by requiring the OTP for each withdrawal request so that is less of an issue with them.  Not all exchanges and EWallets with 2FA require that.
So there still is better protection when when accessing your account only from a secure system, but those who live a little more dangerously can probably still keep their funds safe thanks to 2FA.
Also, the 2FA device should always be separate from the device where the wallet is being accessed from.  So accessing Blockchain for Android from a mobile in which the 2FA client is also running is not a secure configuration.

Hey, i figured the two-factor on blockchain was implemented as you speak too, but I was wondering, do you have more information on the matter? Like an official statement or forum thread?


text:
Solo mining requirement to win a block everyday?
What's the hash power requirements to solo mine and win at least one block a day?
Two cases (with 10% luck, means mining requires to iterate 90% of unsuccessful hashes),

Mine 24 hours a day and win at least one block
Mine 10 - 30 mins and win at least one block

The following is assuming the difficulty has balanced with the current network hash rate (right now, the difficulty is actually about 10% low, but it will adjust in about 3 days):
Network hash rate (current) = 61 Thash/s
Blocks per day = 24 * 6 = 144
Hash power required to solve 1 block per day = 61 Thash/s / 144 = 424 Ghash/s
To get a block on average every 30 minutes, you'd need control of one third of the network's hashpower, which (unless you purchase mining equipment already in use) would require 50% of the current hashpower, or 30.5 Thash/s.
To solve a block on average every 10 minutes is only possible if you control the entire network, which you can't do unless you stop everybody else from mining.
More info available here: Equation for mining profit

Thanks for the answer. If I have 424 GHash mining power, and solo mine for 24 hours a day, is it possible, still I win nothing?

@vi.su. Yes, and it doesn't increase the chances of you solving a block the next day either. However, it's also possible to solve many blocks within the same day. This answer has some info that may be relevant to you: http://bitcoin.stackexchange.com/a/3911/516

You can mine 1 block roughly every 10 mins, hence total blocks per day is 6 x 24 = 144
The current Hash Rate in the Network is about 70000 GH/sec (Source: Blockchain.info]1
If you have 100% of the Hash power, you will get all the blocks each day.
To get at least one block a day, you will need roughly 0.7% of the current total hash power (1/144), that is about 486 GH/sec of hash power.
To get at least one coin a day, you will need at least 19.44GH/sec of hash power ( 486 / 25 coins per block)
The hash power requirement will change as the network hash rate rises with more ASIC devices shipped.


text:
Why is a hardfork a problem?
My understanding of "hardfork" was that it referred to anything that requires re-building the blockchain from the genesis block. But now, I understand that anything that requires a Bitcoin-Qt client upgrade is a hardfork, too. Why is a hardfork considered a problem in the Bitcoin community?
User wallets and stored keys are more important, so all upgrades must ensure they wouldn't break these, but does it matter at all that it's required to upgrade old clients to use new features?

All the nodes in the Bitcoin Network have agreed on a certain set of rules. These rules are coded into the client and everything that changes the state of the ledger is checked against those rules.
Hardforks happen when a change in those rules (for example the reward halving rule or the difficulty adjustment rule) causes the new clients to make different decisions about the validity of transactions and blocks. This basically means that over time the state of the ledger on older clients would diverge from the state at new clients, creating two incompatible networks, as transactions would be valid in one but not in the other.
As transactions and blocks are chained together, even a single disagreement about the validity of a transaction or block can cause large parts of the state to become inconsistent over time, it is therefore crucial that the network as a whole agrees on the rules.
The developers keep a wishlist of changes for hardforks, because hardforks should be a rare event, breaking changes be bundled into on hardfork. The changes decided in hardforks have a trigger height after which they are applied, which is usually several months in the future in order to let developers of alternative clients and the users update their nodes before the switch, minimizing the number of incompatible nodes left behind.

This does make it sound like only a disagreement about the effect on the ledger is a problem. Even something as simple as changing the encoding of digital signatures could however cause a hard fork, and it's not just "large part of the state" that become inconsistent: it is immediately all of the state that starts diverging, as the two sides do not accept eachother's coinbases and transactions that depend on it.

A hardfork is not when old clients must upgrade to use new features. A hardfork is when old clients must upgrade to use the system at all. For example, if a new type of transaction was added, people who didn't upgrade wouldn't be able to understand the new transactions and wouldn't be able to spend or receive any Bitcoin that had ever been transferred by a new transaction anywhere in its history.


text:
Is pre-mining of a future block possible?
Is it possible to pre-mine next block when everyone is mining current block?
Let's say, if we need 1T hash power to mine (solo / pool) a block in 1 hour, then is it possible to run 1G hash miner for 1000 hours and then use this data as proof of work.
With 1G miner, I am essentially targeting n'th (x + 6000) block in future, hoping to solve it. I will broadcast it as soon as I get hash of n-1'th block.

Does solving block X+1 if you solved (but did not broadcast) block X count as one of the approaches?

You seem to be asking if you can mine block X+1 while the network is still working on block X.
The answer is no, you can't mine block X+1 until block X has been solved, as each block requires a hash of the previous block to be valid.

hash(block X) needs to start with (block X+1) mining, or just to broadcast mined (block X+1) ?!

can you please comment on my previous question. Thanks.

@vi.su. I'm not sure what you're asking exactly. Block X+1 requires a hash from a block X though, which means block X must have been solved already before mining of block X+1 can start.

thanks. I thought it is also possible to start mining x+1 block, even before block x is mined, and to broadcast x+1 block, We need block x hash (because block x hash is just part of block x+1, not included in the mining calculations).


text:
Is Lightning Network vulnerable to sybil attacks?
A dialogue partner of mine claimed that Lightning Network is vulnerable to sybil attacks. He stated that LN needed explicit identities in order to support the "routing" which would cause ending up with whitelists.
Is Lightning Network vulnerable to sybil attacks?

Not true.
You have funds locked into a multisig wallet with party A, B and C. There's nothing to Sybil there: the funds have been transferred and only you and them have keys.
Then you want to transfer money to G. None of your parties has a direct link to G, but C has links to D, E and F. And G is advertised as having a link to D. So C relays your money to D and D relays it to G.
How do you know it's actually G and not some fake G? Because you have out-of-band communication with G, because G is the restaurant you are standing in right now or G is the webshop you are trying to pay. A secret token is exchanged directly between you and the real G, which makes sure we're talking to the correct wallets and any relay transactions can only be redeemed with the knowledge of the secret token.
The example above is simplified of course. In practice the goal is to have more hops between you and G, both because finding a shorter route might be hard/impossible, but also for privacy reasons (it uses Tor like routing and encryption to hide identities and IP addresses).

What if G is in coordination with fake G to deceive you? /s

@PyRulez They don't need any kind of attack to take your money. You're already trying to send them your money. They could send your money anywhere they wanted after they received it, so them being able to divert it doesn't matter.


text:
How is the construction of atomic swaps improved by Schnorr?
How does the availability of Schnorr signatures improve the ability to perform cross-chain atomic swaps?

To perform an atomic swap, both assets need to be locked up to ensure the eponymous atomic execution of both payments or neither. Traditionally, this uses a complex output script that has two outcomes. On both chains, funds are locked such that either the receiving party signs with their private key while also revealing a preimage, or the original owner can take back the funds themselves after a timeout has passed by signing with their private key. This way, whenever one of the two parties reveals the preimage to take the funds, the other party can immediately take the funds on the other network. The drawbacks of this approach are that the two transactions are easy to link due to featuring the same lock hash, that the script is fairly heavy and that everyone sees what is going on.
Atomic swaps can be improved with Schnorr signatures both regarding their privacy and their blockchain footprint.
Instead of the previously described output script, the funds are locked to a 2-of-2 multisig address with a timeout condition to return the funds. To ensure atomicity, one of the two parties creates transactions on both networks that make use of "adaptor signatures". These transactions are fully valid except that the creating party's signature is damaged by a linear offset. The creating party provides a zero-knowledge proof to the counterparty that they are both damaged by the same value and that they otherwise would be valid. After the counterparty also signs both transactions, either party can fix the damage on one of the signatures to make the transaction valid, revealing to the other party the original offset and thus enabling them to fix the other.
Due to Schnorr's compact multisignature the 2-of-2 multisig address with the timeout fallback looks like a standard 1-of-1 Pay-to-Schnorr-public-key-hash address, and the 2-of-2 transaction spending from it also looks indistinguishable from any other standard transaction. The transactions are not visibly linked, third parties cannot tell which public keys were involved, and since it would be trivial to recreate the damage after having the two valid signatures, it's difficult for either party to prove that this exchange ever took place.
In result, Schnorr allows to perform atomic swaps by creating two standard transactions on each network, whereas previous atomic swap constructions made use of 2-of-2 multisig addresses and HTLC contracts which were much heavier and easily distinguishable.
For this to work, at least one of the two networks has to support Schnorr signatures (preferably both).
H/T Pieter for feedback and for linking me to this more comprehensive writeup by Kanzure: http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/

Technical nit: this has nothing to do with signature aggregation, but with Schnorr multisignatures. The distinction is that signature aggregation is about combining multiple signatures on distinct messages (and in Bitcoin context refers to aggregating across different inputs), and multisignatures is about multiple participants signing the same message. In fact, the usage of (cross-input) signature aggregation conflicts with the adaptor signature approach you're explaining here.

@PieterWuille: I've amended my posts.

A slightly different take: if you have Schnorr signatures, then you can build payment channels based on aggregated multisignatures. Such payment channels look indistinguishable from regular p2pkh on the blockchain.
With any payment channel, you can hide hash-locked atomic swaps inside. In contrast to the traditional on-chain atomic swaps, such in-channel atomic swaps are anyway faster to set up, more secure, and support high frequency trading between the parties. In the case of a cooperative closure, the HTLC secret never hits the blockchain and it looks like a regular payment channel. And with schnorr, as just mentioned, a regular payment channel looks like any other transaction. So you get a hash-locked atomic swap that is "totally invisible", or at least looks unremarkable.
Since this uses entirely standard hash lock techniques, it lets you do trading even when the two blockchains don't use the same elliptic curve (in contrast to adaptors).


text:
I have lost my wallet, what can I do?
I used to be interested in Bitcoin a few years ago and have recently become aware of it again. I used to have a wallet back then. Given that many years have passed, what I remember is a bit fuzzy. What can I do if…

I don't remember which service I used
my wallet service shut down
I lost access to my wallet service account
I removed the wallet from my computer or phone and have no backup
I had a wallet, and still have the device that it was installed on

If your question is not covered here, please ask a new question, explaining how your situation differs from the topics collected here.

This is intended to form a canonical question to act as a lightning rod for the flood of lost wallet questions we have been receiving lately. Please contribute additional answers to help make it as useful as possible.

Related: Wallet gone and lost recovery phrase, how to get back my bitcoins?

I had an account on a website, but don't remember which one
Search your email account for an account creation confirmation email. Helpful search terms may include "bitcoin", "wallet", "exchange", "btc", "blockchain", or "cryptocurrency". If you purchased bitcoins, you may want to look at your old bank statements as well. There is no global register of bitcoin users or services, so if you cannot find anything you may be out of luck—we cannot help you, because we don't know either.
I had a web wallet, but the service shut down since
If the service had custody of your bitcoin balance, it is likely lost. Research the name of the service to determine what happened to the service, in case it just rebranded and is still around.
My wallet service still exists, but I lost access
We don't have insight into your customer relationship with services, so we cannot help you. Contact the service and initiate an account recovery process.
I had a self-custodial wallet, have lost the wallet, and have no backup
Bitcoin balances are tracked via the blockchain, and a user's bitcoin wallet's primary purpose is to secure the private keys which are used to establish ownership and to track any transactions related to those keys. The key space is enormous. If you have lost your wallet, the same keys will likely never be regenerated and no one will ever be able to spend the associated funds.
I had a self-custodial wallet, and still have the device that it was installed on
Looking over this selection of wallets may help you remember which one you used. If you still have the wallet files, you may be able to recover your funds. The name of the relevant files depends on the software that you used, but one of the most common file names is wallet.dat. If you find a wallet file, create a backup first before trying to recover the wallet.
I have a 12 or 24 word backup, what do I do?
This is called a mnemonic seed phrase. It is a standardized way to backup a wallet's private keys. Keep the words confidential, do not enter the words in a website or untrustworthy software. You should be able to recover your wallet from the phrase. You can find instructions how to recover the wallet from it on this site.
I had a bitcoin card purchased from a drug store¹ many years ago
Without knowing the details of the card or the business that created the card, it will not be possible to recover control over any money associated with the card.

¹ Inspired by lost bitcoin card purchased from a drug store many years ago


text:
How does the Branch and Bound coin selection algorithm work?
Murch described in his Master thesis [PDF] an algorithm for coin selection called "Branch and Bound" or "BnB". It subsequently got implemented into multiple bitcoin wallet implementations. How does it work?

Disclosure: I’m describing my own work: the Branch and Bound coin selection algorithm was first described in my own Master thesis.
The Branch and Bound algorithm searches for the least wasteful input set that produces a changeless transaction. To that end it deterministically searches all possible relevant combinations of the wallet’s UTXO pool. Since the powerset of a collection grows exponentially in the size of the collection, Branch and Bound bounds its search in a number of ways whenever an area in the search tree cannot yield any better solutions.
The gist of the algorithm is as follows:

Calculate the effective value of each UTXO: effective_value = amount - input_weight × feerate
Sort the UTXOs descendingly by effective value
In order of the sorted UTXOs, keep adding the next UTXO until the total_selected_effective_value exceeds the selection_target
If total_selected_effective_value is also smaller than selection_target + cost_of_change_output, we have found an input set that would produce a changeless transaction. Keep this input set if it has a better waste score than the prior best input set.
Whenever you exceed the target, backtrack by deselecting the last selected UTXO and omitting it instead.

Let’s assume we have three UTXOs with effective values of 0.1 ₿, 0.09 ₿, and 0.05 ₿. We are searching for an input set that raises 0.14 ₿. Our search would look like this:

via Erhardt: An Evaluation of Coin Selection Strategies (2016) [PDF]

{0.1}: We have insufficient funds and continue.
{0.1, 0.09}: We select 0.1 ₿, then select 0.09  for a total of 0.19 ₿. We have overshot above the target window. We backtrack.
{0.1, 0.09, 0.05}: We deselect 0.09 ₿, then select 0.05 ₿ for a total of 0.15 ₿. We have overshot above the target window and backtrack.
{0.1, 0.09, 0.05}: The omission branch of 0.05 ₿ leaves us with insufficient funds. We have completely searched the subtree that starts by selecting the 0.1 UTXO and continue by skipping the 0.1 ₿ UTXO.
{0.1, 0.09}: We have insufficient funds and continue.
{0.1, 0.09, 0.05}: With a total of 0.14 ₿, we have found an input set that produces a changeless transaction. This is our new best input set.
{0.1, 0.09, 0.05}: The omission branch of 0.05 ₿ has insufficient funds.
{0.1, 0.09}: The omission branch of 0.09 ₿ also has at most 0.05 ₿, so we cannot find any solution there.

For a wallet with a larger UTXO pool, this search would likely yield multiple solutions. In that case, we would compare the input set candidates on basis of the waste metric and keep the input set with the best (i.e. lowest) waste score.
So far this just generates all possible combinations of inputs, skipping just input sets for which a prefix already exceeded the target.
The implementation in Bitcoin Core limits the number of attempts to 100,000 and has a number of optimizations to skip parts of the search tree that cannot yield better solutions:

more wasteful: if our current selection already has a worse waste score than the best solution, and we are in the high-feerate mode, we can exit early as adding more inputs can never produce a better solution
lookahead: by keeping track of the total available effective value in the remaining UTXOs, we can exit subtrees early when there are insufficient funds to reach the target (i.e. when selected + lookahead < target)
max_weight exceeded: if our current selection would lead to the inputs set being bigger than the limit for standard transactions, we can exit a subtree early, because it cannot yield solutions
skipping clones: if the previous UTXO matches the current UTXO in weight and effective value but is not selected, selecting this UTXO would recreate equivalent input sets to ones created prior. We can therefore skip selection of such a “clone UTXO”.


text:
What could be the reason that my node syncs so slowly during Header Synchronization?
I¹ am trying to sync Bitcoin Core v24.0.1 on my Desktop with 16 GB RAM and an Intel Core i7-7700HQ processor, but it is taking forever even to get past the header synchronization. It tells me that it will take over 3.5 years to synchronize.

3 hours later, my node is still in Header Synchronization:

I have a decent internet connection and am connected to my router via wifi
I downloaded Bitcoin Core v24.0.1 from bitcoincore.org
I’m using an internal hard drive
I have ten connections, but have only received about 340 kB across my eight outbound connections in the past ~10 minutes minutes
I have tried to add a few nodes from bitnodes.io via addnode <ip> onetry to perhaps learn about more peers (and the added nodes show up when I call getaddednodeinfo as past connections)
I have over 365 GB of free disk space

Update:

My node was already configured to run in pruning mode
I’ve increased my dbcache to 10 GB
My debug.log appears to show that I’m switching my peers frequently

Any ideas what else I should try?

¹Asking for a friend.

What has changed in the next few hours? Has the header synchronization finished? Has anything progressed?

Without knowing your bitcoin.conf settings and debug.log, it is difficult to say. Generally speaking, however, here are a few things:

365GB is not enough space, so you'll have to run in pruned mode or upgrade your hard drive
SSD drives tend to be much faster than HDD drives when performing IBD
dbcache is 450MiB by default. If you have 16GB of RAM available, you can set dbcache to a much higher value to help speed up IBD
If you are pruning, make sure to set your dbcache and prune values to be similar. If your prune value is lower than your dbcache value, your node will not use all the available memory. See Does pruning during IBD reduce the ability to utilize the dbcache fully? for more information

EDIT: As pointed out in the comments, headers sync should not be taking 3 hours. Based on https://github.com/bitcoin/bitcoin/issues/26391 , it sounds like corrupted block data could be the cause. If you can confirm that by looking in your debug.log, restarting your node with -reindex is an option. However, it's difficult to recommend a solution without knowing what's in your debug.log first.

That's good general advice, but i don't think using a SSD or increasing the dbcache applies here: it's apparently stuck at syncing headers.

Ah, I missed the "3 hours" comment in the OP. Do you know how long headers sync should take normally?

A handful of minutes. :/ (Well, depend on the bandwidth but they disclaimed having a decent connection.)

Why not collecting and insepcting debug logs? There could be traces of the reasons that the node is synchornising slowly. Upload a debug.log file generated by Bitcoin Core started with the -debug option, i.e.

.\bitcoin-qt.exe -debug

3 hours of headers synchronisation doesn't seem to be slow to me.

The headers are less than 65 MB. Header Sync should take no more than a few minutes.


text:
A common criticism of Segregated Witness is that it is "unnecessarily complex". Why is it chosen over alternatives?
Segregated Witness (SegWit) is well-along the way to being implemented and deployed as a soft-fork.
Facts:

SegWit eliminates most forms of transaction malleability.
Discounts input scripts in comparison to other block content.
Adds a new function/constraint to the Coinbase transaction by requiring it to contain the root of the SegWit data.
Provide a capacity increase upon adoption.
Makes future changes to Bitcoin Script easier.

Questions:

What other methods could achieve the above benefits?
Why was Segregated Witness chosen instead?
Is there an alternative that is less complex to introduce when regarding the complete picture, i.e. technical, economical, and social aspects?

Intent: The above is a criticism that is frequently stated in parts of the Bitcoin community, and I hope to provide an anchor for a visible collection of expertise on the matter.

Yes, I'm aware that this is fairly broad. Yes, this is subjective, but I hope that it falls into the good subjective category.

I recently took a deep dive into studying Bitcoin technology, and I'll try to answer this in retrospect.
SegWit was designed within boundaries of one key constraint: you shall not hard-fork; meaning that Bitcoin consensus specification could only become more tight, not less. In other words, only soft-forking consensus changes would have been considered.
With that constraint in mind, SegWit is a solution where you'd logically arrive at if you wanted to address the two key problems at the same time:

Block size limit
Transaction malleability

which was the case at that time in Bitcoin history.
Block size limit
If we wanted to address just the blocksize limit then we'd have to put some data "outside" the data structure covered by the 1MB blocksize limit, have the data validated by upgraded nodes, and have a hash anchor it somewhere in the legacy 1MB block so integrity of the blockchain remains tight.
One solution would have been to just have a kind of extended block space, that could be specified with some new size limit or an algorithm that would be adjusting it. This would require solving these 2 problems:

Moving BTC from 1MB space to the extended block space would have to be seen as a valid operation from the point-of-view of non-upgraded nodes.
Moving BTC back from extended block space back to 1MB space would also have to be seen as valid operation from point-of-view of non-upgraded nodes.

This could be solved by declaring some anyone-can-spend locking script pattern as a magical address that will hold the record of balances moved to extension block and have all transactions that move BTC between the 2 spaces encode entry/exit points so that those migration transactions are considered valid by non-upgraded nodes. Upgraded nodes would prevent someone just taking the funds as if it was really anyone-can-spend, and non-upgraded nodes trying to steal from the address would see their transactions rejected for reasons unknown. This kind of solution was actually proposed and rejected at the time SegWit was being discussed.
It would have been more complex than SegWit for many reasons and it would introduce another key problem for non-upgraded nodes: they'd not have the correct view of the UTXO state. They'd just see this black box address where BTC sometimes goes in and comes back from, they'd have no idea of who owns the BTC inside the black box (the extended blocks space).
SegWit doesn't suffer from those problems, because it doesn't change the definition of UTXO state and it doesn't change the view of UTXO state transformations for non-upgraded nodes. They'd continue to see the correct view of WHAT has changed, but they'd not anymore have the correct view of WHY has it changed because they'd not see the "witness" anymore. If we consider "you shall not change the UTXO view" as another constraint then SegWit is the maximum possible circumvention of the "hard" 1MB limit. Any further circumvention would require some approach like described above.
Transaction malleability
If we wanted to address just the transaction malleability then the "witness" could have still been "segregated", but it wouldn't have been necessary to segregate it outside the transaction or the 1MB "hard" block space. It could have stayed inside to keep it all less complex as it would have been sufficient to segregate it just from the signature preimage, so that whole transaction except the signature itself could be covered by the signature. This would have avoided touching the Merkle tree structure, and the change would have been contained to transaction validation rules. So, solving transaction malleability alone could have been less complex than SegWit, but that was not the only objective of the upgrade.
Conclusion on SegWit
By adopting the approach of only moving the input data somewhere to solve (1.), it became almost "free" to solve (2.) so naturally that path to solving transaction malleability was taken. There are some alternative design decisions like particular choices in encoding or choice of sha256 vs sha256d that could be argued about, but on a high-level I think we can say that SegWit is the logical result of engineering within the two tight constraints: the upgrade being soft-fork only and maintaining a consistent view of UTXO set and its state transformations.
Note on anyone-can-spend FUD
When SegWit was being intensely discussed, people were bringing up the issue of possibility of someone stealing the funds if SegWit hashrate would drop, because from point-of-view of non-upgraded nodes the BTC locked in SegWit addresses would be free for the taking. This is not possible, because it is not only mining nodes which were upgraded: after activation the new consensus rules are enforced by all nodes, even non-mining nodes, and they'd straight-out reject transactions violating new rules even if it had more than 51% hash-power.
I think the only possibility of theft would've been by a reorg replaying post-activation SegWit transactions and having them mined in a pre-activation block so they'd be seen as valid by new nodes but this was mitigated by having a high activation threshold.
This is very much similar to P2SH BIP-0016, where someone could argue that all P2SH hashes with known redeem scripts would be free for the taking, which is simply not true.
Once activated, reverting the P2SH BIP-0016 or SegWit BIP-0141 would require a hard-fork. Convincing any remaining non-upgraded nodes to follow a chain that doesn't enforce new rules would require 51% hash-power but that chain wouldn't be BTC since most nodes have upgraded, so the hypothetical 51% attacker would be losing extreme amounts of money, making the attack on non-upgraded nodes practically impossible.
Note on hard-forks
If the soft-fork constraint would have been lifted, then the alternative solutions space would become bigger, and there would be opportunities for more efficient and less complex solutions at the expense of breaking backwards-compatibility with non-upgraded nodes while still being backwards-compatible with non-node software such as wallets, indexers, etc. However, I feel that discussing those is outside the scope of the question and may be considered off-topic here.


text:
What development stage do the version 0.13.99 nodes represent?
So, obviously Bitcoin Core 0.13.0 and 0.13.1 have been released, 0.13.2 is nearing release, and 0.14.0 will have its feature freeze in a few weeks. However, there are also some hundred odd nodes that show up as 0.13.99. What does that version represent?

I can see there is a release candidate for 0.13.2, but has it really been released?

@SvenWilliamson: Sorry, I was getting ahead of myself. You're correct, only the rc is out.

well it is out now :)

While releases are carefully tested, tagged and then made available as executables, it is also possible to compile Bitcoin directly from the source code.
Bitcoin Core nodes that were built directly from a commit on the master branch instead of one of the releases show up as 0.XX.99, where XX is the latest major release.


text:
In what ways was the "Hong Kong Agreement" infringed upon?
There is a favorite talking point in some parts of the community claiming that this or that party broke the Hong Kong Agreement.
Mentioned are for example:

Delivery time of SegWit
Delivery time of hardfork code
Signaling for Classic

What infringements of the agreement where there, when did they take place and how clear is it that there was a breach in the agreement?

Is there any written agreement besides what's posted on the @bitcoinroundtable medium account? Seems kind of bare.

@NickODell: I believe that's it.


text:
What portion of the mining process does an ASIC perform?
If ASICs were described as a black box, what would their inputs be?
Obviously, the actual hashing, the churning of the SHA-256 function is performed by the ASIC. Also, they must of course be able to tell when they have succeeded, so they must have a mechanism to store and compare the target to their result.
Yet, how much of the pre-processing steps do ASICs perform? I would assume that they increment the nonce, as it is raced through in less than a second and perhaps the extra nonce? Can they change the timestamp? Do they manage the complete block header? How much of the block header do ASICs vary by themselves?
Do ASICs assemble their own blocks?

Of course, the answer might vary between devices.  Some devices might have an onboard CPU or microcontroller to handle some of these tasks, while others might leave it to software on the host computer.  The latter might be more efficient if the ASIC is connected to the host via something fast like PCI Express, whereas a device connected via USB or Ethernet might need more "smarts" of its own.

In the devices I've seen, the ASIC is given everything that does not need to be done per nonce and runs through all 2^32 nonces.

Both sound like great starting points for answers :)

TL;DR: ASIC input/output is the bold text below.
No, the ASIC does not assemble a block.
The block is assembled by a mining pool server. If you are solo mining you could let bitcoind assemble the block but you'd still need mining pool or proxy software in between to make a modern ASIC machine (stratum only) and bitcoind (getblocktemplate only) communicate.
Modern ASIC miners have a small computer built-in, acting as a controller. Some use a beaglebone. This is a low-performance computer which handles the stratum protocol, generating work, pushing work to the ASIC chips in the machine, and receiving results from them. The ASIC chips only handle the part of the number crunching that must be repeated many billions of times.
When the miner receives data over the stratum protocol it is allowed to change the nonce, the timestamp and part of the coinbase (often called the extra nonce). An ASIC chip goes through all possible nonce values pretty quickly, so the controller needs to be able to make more work using the extra nonce.
When the controller changes the extra nonce it needs to generate a new hash for the coinbase transaction (which has now been modified) and use this hash together with a merkle branch received from the pool server to generate a new merkle root. This merkle root goes in the block header.
After a merkle root is generated the controller can now calculate the midstate. The bitcoin block header is 80 bytes. SHA-256 hashing is done in chunks of 64 bytes. Since the interesting parts which we are going to change are not in the first chunk the controller will hash the first chunk once and then the ASIC chip will do the rest billions of times while changing the nonce in the second chunk each time. The midstate is the state of the SHA-256 hashing engine after the first chunk has been processed.
So the input for the ASIC chip is the midstate (32 bytes) and the 16 bytes of the second chunk (last 16 bytes of our bitcoin block header). The outputs are nonces (4 bytes) that resulted in hashes below the target. These nonces are retrieved by the controller and passed on to the pool server.
So what are those 16 bytes of data the ASIC chip needs in addition to the midstate? These 16 last bytes of the bitcoin block header are the 4 last bytes of the merkle root, 4 bytes of timestamp, 4 bytes of "bits" indicating current bitcoin target/difficulty, and 4 bytes of nonce.
In reality the ASIC doesn't need to receive a 4 byte nonce from the controller. It is going to try different nonce values on its own. So we are left with this:
The inputs to the ASIC chips are a 32 byte midstate, the last 4 bytes of the merkle root, a 4 byte timestamp, and 4 byte "bits" (target/difficulty).
If I managed to explain the above properly then you should now see why the ASIC chip is focused on this specific part of the work. For each time the work up to completing the midstate is done, the work after that point is repeated billions of times.
You can also see that generating a new midstate (which also entails generating a new merkle root) is a lot more work than just incrementing the timestamp. So once you have enough midstates to keep the ASIC chips happy for one second, you can reuse the same midstates over and over every second just by incrementing the timestamp. If the controller is slow enough and the ASICs fast enough then this "time rolling" may be necessary for the machine to work.
The slowness of the controller can also mean that the ASIC machine has a minimum difficulty it can operate on. Otherwise it will get more results (nonces) than it can handle. But the same thing goes for the mining pool server which would also not want to be spammed to death.
For maximum efficiency the ASIC is designed to only handle a limited area where expensive specialization really pays off, while the rest is handled by a tiny computer that is very cheap and very energy efficient.
Note: there are of course some differences between manufacturers. For instance some ASIC chips do not scan the entire nonce range. But the above should be the gist of it.

ASIC only does the most performance-expensive thing. It solves the block.
Everything else like preparing the block, checking payments, sending the solution to others, can be done by a standard computer.


text:
Are any miners still considering priority in their transaction selection?
A new answer on Who gets Bitcoin transaction fees? has spawned discussion on the paradigm shift from selection by priority (= coin age × spent value) to selection by fee rate (= fee / transaction size).
It's clear that Bitcoin Core v0.12.0 has turned selection by priority off by default, but I am wondering whether it follows that all miners have discontinued using it.
Is it known whether any miners are still selecting the transactions to go into their blocks using selection by priority?

is it even possible to know for certain? Small time miners can have ridiculous transaction selection algorithms and it'd still be valid by consensus rules.

Of course any selection is valid. However, one could tell by analyzing whether more profitable transactions were available at the time of the block while the block contains less profitable transactions with a higher priority.

Nobody ever really proved that turning it on mattered in the first place.

Generally, no miners still use the priority system for selecting transactions. You can easily test this by spending a very old UTXO (e.g. 1 BTC that has remained unspent for several years) and paying no transaction fee. If miners still are using priority, your transaction should be confirmed relatively quickly (hint: it won't be). Otherwise, your transaction will not confirm for several weeks.

The answer of this question depends on the setup of the miner who succeeded to solve the block. In general the priority still matters most; only the spare additional resources up to the maximum block size include transactions not paying the recommended amount of network fee(s).
As a miner you can even setup a minimum (or maximum) transaction fee amount needed to get your transaction included into a new block:

At all times, Bitcoin Core will cap fees at -maxtxfee=<x> (default: 0.10) BTC. Furthermore, Bitcoin Core will never create transactions smaller than the current minimum relay fee. Finally, a user can set the minimum fee rate for all transactions with -mintxfee=<i>, which defaults to 1000 satoshis per kB.

Hey Flo, thanks for your answer. I'm curios how you arrived at the conclusion that "In general the priority still matters most" and whether you could perhaps provide more evidence for that. I think this is the part of your answer that most directly addresses my question. – I'm surprised by your statement because I've provided evidence that "selection by priority" has been deprecated as recommended selection mode for some time.  I'm not sure how min and max fee are supposed to be related to my question.

Hi Murch, you have linked to the release notes of bitcoin core v0.12.0: Bitcoin Core has a heuristic ‘priority’ based on coin value and age. This calculation is used for relaying of transactions which DO NOT pay the minimum relay fee, and can be used as an alternative way of sorting transactions for mined blocks...

... looking at https://en.bitcoin.it/wiki/Transaction_fees#Priority_transactions you can set priority on your transactions increasing the transaction fee. https://anduck.net/bitcoin/fees/ shows that there are blocks which have been (almost) completely filled up with transactions paying more than 1$ per kB which means vice versa that the transaction fee matters on setting a priority for payment; at least if the number of transactions is larger than the current blocksize limit of 1MB.

Keep in mind mining BTC is a professional business, now. At least the large players for sure take care to make the most profit as possible of every new block mined.

It seems to me that there is a misunderstanding of what "priority" is here. It's a term used to describe confirmation age × spent value. Priority was replaced by fee rate as the main selection metric. That's exactly what this question is about.


text:
How can one reinitialize the HW.1?
I've got a HW.1 a while back at a conference without any additional information. I had played around with it a little bit then, but didn't intend to use it as a wallet immediately.
Now, I've been trying to set it up as a wallet. When I start the Ledger Wallet Chrome Plugin, it tells me that I should do a Chip-Firmware-Update.
Unfortunately, it will not let me progress with the Update unless I put in the "Security Card QR-Code". I don't have it, as I just got the plain card, and didn't make note of anything when I was playing around with the HW.1 at first.
So, the Chrome plugin won't let me do anything except go to "update", but won't let me do the update without the Security Code.
How can I reset or reinitialize the HW.1?
Update:
I've found the page on Ledger's site to generate a new Security Card. By entering the code, I got to a new page requsting that I check a sample from the Security Card. Unfortunately, clicking "Continue" on that page doesn't seem to have any effect. So, I'm still stuck.
I've already written the usb-rules to my system.

I have a HW.1 too. I purchased mine, so it came with the recovery card. If you have your recovery card, you might be able to contact their support and ask how you could convert your security card's details into the 16 byte key
If you can't do this, then use the link you posted previously to generate a random key, and then generate your card. Remember to save both.
Delete the seed currently on the HW.1 by typing in the seed 3 times incorrectly.
Plug your ledger in and then try to update the firmware. Once it prompts you, put in your random key. If this doesn't work, try using their online site. It may not be as safe. IIRC you can download their special initializing software and mount it as a boot drive on a USB and do it air-gapped.
If it still doesn't work, I guess your best bet would be to contact their support.

That I could delete the seed by typing in the seed 3 times incorrectly solved my issue.

The CTO of Ledger on reddit said:
Could be an issue with the 32 bytes generated code for the security card - if you're using copy & paste, make sure that there are no extra characters, or try to enter it manually.


text:
Do Lightning Channels have to be resolved before a certain time?
I seem to remember that Lightning channels could remain open indefinitely with the introduction of CLTV. Yet, I'm confronted with claims that they time out and coins are lost when they do.
This seems wrong, as when channels time out they should send back the money, and as I said above, I thought they could remain open. What is it?

What is the source saying that they do timeout?

@StephenM347: A reddit user named shmazzled. (I'm Xekyo on Reddit.)

I seem to remember that Lightning channels could remain open indefinitely with the introduction of CLTV

I think instead of "CLTV" you mean "CSV" (as in OP_CSV, BIP112).  As far as I know, nobody claimed that OP_CLTV would allow HLTC-style (Lightning) payment channels to stay open indefinitely, but that was definitely a claim of OP_CSV.
An additional prerequisite for indefinitely-kept open channels is segregated witness or another malleability fix.
Although it's a bit difficult to know what is confusing you without reading the source quote and context, I suspect that you're confusing the (1) dispute period for a unilateral spend with (2) a timeout.
When one party to a Lightning channel broadcasts either the current channel state or a previous channel state, there begins a dispute period where the other party can submit evidence proving that the channel was not closed in its current state (that is, it was closed fraudulently).  That evidence is cryptographic evidence that can be submitted to miners, who can add it to the blockchain and have it accepted by full nodes if the evidence is valid.
The dispute period is an arbitrary length of time from the point where one party attempts to close the channel by broadcasting a transaction.  However, there's no point at which either party is required to close a channel, so it's correct to say that channels can remain open indefinitely.  There is no timeout on the channel itself---there's just a timeout whose clock starts when one party decides to start closing the channel.


text:
How thoroughly has Segregated Witness been tested?
I've encountered claims that Segregated Witness was "not really tested" and is being "rushed".
It is my understanding that SegWit had been running on Elements for more than half a year already, and that it is currently being run on its own testnet.

Has development of SegWit been rushed?
What level of testing has been performed on Segregated Witness?
Is it reasonable to expect SegWit to be sufficiently tested and ready for deployment in April?

https://medium.com/@octskyward/the-resolution-of-the-bitcoin-experiment-dabb30201f7#.xyunn2g5h

Summarized from Bitcoin Core's Segregated Witness announcement:

The original version of SegWit was implemented in April through June 2015 for the Elements Project. It has facilitated every transaction on the Elements-based sidechains since then.
The new softfork-variant of SegWit moved to the multi-user testing stage in December 2015 by activating on the SegNet, a dedicated testnet.
A pull-request was submitted in April 2016 to Bitcoin Core for review.
Since May 2016 SegWit was enabled on the regular testnet facilitating tests in a mixed environment with non-upgraded wallets.
At a meeting of twenty Bitcoin Core developers in May 2016 an in-person review of SegWit's code and test coverage was performed.
An updated version building on the current state of Bitcoin Core's development was provided for final review in June 2016.

Altogether, the concept has been in development for fourteen months, and variants of SegWit have been in production and network testing for a year. The Bitcoin version has been rigorously tested for over six months. It received final review approval today and was merged to Bitcoin Core's master branch.
After all testing is successfully concluded, a release candidate including Segregated Witness will be released for broader testing by all types of users. Once a release candidate without known issues is found, it will be released and made ready for signaling.

I'd suggest starting here: https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/. There's also a SegWit adoption page on the site somewhere.
Finally, this article has some details on recent testing: http://www.coindesk.com/bitcoin-scaling-segregated-witness-expected-launch/


text:
Do unsynced Bitcoin ABC nodes send Bitcoin transactions instead of Bitcoin Cash transactions?
Bitcoin ABC is fully compatible to Bitcoin up to the fork. Does that mean that an unsynchronized Bitcoin ABC node sends Bitcoin transactions instead of Bitcoin Cash?

Yeah, sounds very likely.

The latest version of Bitcoin ABC that is released before UAHF happened, sends Bitcoin-style transactions if it is not synced.
Proof: https://github.com/Bitcoin-ABC/bitcoin-abc/commit/fda9dab6a9fba4a95aa2d9620f28b787efccf748
The current latest version always sends Bitcoin Cash transactions.
Proof: https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/src/wallet/wallet.cpp#L2966