text:
Do you sign only the previous output of transaction?
I need to confirm that I understand how transactions work in the Bitcoin network. Ok, so:

Alice is a network node. Alice wants to send bitcoins to someone in the network. Alice is creating a transaction using her wallet.
Every transaction has inputs and outputs. The inputs of every transaction are just references to some previous outputs of some other, older transactions that previously sent funds to Alice addresses.
To send bitcoins Alice needs to resolve the puzzle given in the scriptPubKey of a previous transaction's output by using her scriptSig which her wallet generates upon making a transaction. Basically Alice just needs to prove that she is in control of private key (related to address previous bitcoins were sent to) by signing the new transaction.

Did I get these steps right?
My confusion started when I was exploring the hash type because I saw many sentences that said the Output of a transaction is signed correctly. With my understanding (from above) I assume that the previous output is signed correctly? And therefor, an input of a new transaction is considered valid. But I couldn't find confirmation for this. Am I missing something? Thank you!

When creating a Bitcoin transaction, each input explicitly states which unspent transaction output (UTXO) is consumed (via an outpoint consisting of txid:vout) and then proves the spender's authority to use this unspent. For the standard output format such a proof is a signature created by the private key corresponding to the public key the funds were previously locked to. I think what's actually unclear is what exactly the signature is signing.
Imagine yourself signing a contract. Putting your signature on a contract signals that you have understood and agreed exactly to that contract. The signature is not meant to be taken out of the context of the contract and certainly not supposed to get stuck onto another contract.
Similarly, the signature on a Bitcoin transaction commits to the specific context of the transaction! If the signature was simply signing for the input without context, an attacker could grab a number of inputs from unconfirmed transactions and reassemble them into a transaction paying the attacker themselves.
Luckily, in Bitcoin we can actually enforce that a signature is invalid when taken out of context. Each signature commits to the complete set of the transaction's instructions, i.e. which UTXOs get spent in the inputs and which UXTOs get created in the outputs as well as the transaction's meta information. (Obviously, a signature cannot commit to the other inputs' signatures as that would be cause an unresolveable recursion.) This commitment to the transaction's structure is called the sigHash. By default a sigHash will be built from the whole transaction using the signature type (or "sigHash flag") SIGHASH_ALL. @darosior touches briefly on other sighash flags, but you can read more about that in (Raghav Sood's article about all types of sighash flags).

First, thank you for your editing support for given question. Second of all, thank you for clearing it out. I was doing just that, taking the signature out of the context and binding it only to transaction input. Thank you @Murch and @darosior!

The sighash type conditions what is part of the digest which is eventually signed for the transaction to be valid.
Some sighash types allow to either include (commit to) part --or none-- of the outputs of the transaction in the digest. Using these far less common sighash types introduce some malleability for a transaction, which usually allow more flexibility when different parties create a single transaction.
You almost always want to use SIGHASH_ALL and you anyway should append a SIGHASH_ALL signature to an input before broadcasting a transaction.
Regarding your question and to sum up, you always sign the current transaction and append this signature to the witness or the scriptSig. This signature can be conditioned using different sighash types.
For reference, you can see the wiki page on OP_CHECKSIG (it only covers the legacy transaction format, though).

Thank you for your answer. However, it still bugs me because, ok, i sign the transaction inputs, but those inputs are just outputs of some previous transaction? So I'm signing outputs of previous transaction. So hash type has nothing to do with output of current transaction? It's more like : which of the outputs of previous transactions are signed inputs inside of new transaction? Sorry if i don't follow correctly.


text:
Where does "Included in Block" value comes from?
I was exploring transactions inside of a blockchain using  this site, and inside of a transaction I noticed there is attribute called Included in Block and its description is: block this transaction is mined and confirmed in.
(I don't know does it matter but, transaction I was looking is this one)

I was wondering, how is this attribute populated? The reason of my question is that I was exploring how can you, by looking at transaction inside of your UTXO, check in which block transaction was included (and then I found this attribute). Is this the right way?
Thank you!

I was wondering, how is this attribute populated?

The site uses an index that simply remembers this information. If a block B is seen that contains a transaction T, an entry is stored in the database that signifies "transaction T is in block B".

by looking at transaction inside of your UTXO, check in which block transaction was included (and then I found this attribute)

The UTXO set does not contain this information, nor can it be efficiently requested from arbitrary nodes in the network.

source: Stack Exchange

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

sort: votes


text:
Did the FIBRE protocol reduce the occurrence of chain forks?
I've just learned that Fibre protocol is used for really fast block propagation. My understanding is that if blocks are propagated faster, miners can more quickly continue to work on (what seems to them) the head of the chain, there is a lower chance for temporary forks to happen and even if they occur, they are likely to be short (small length). Please correct me if I got that wrong. That leads me to two questions:

Is the Fibre protocol the reason for rare temporary forking?
Is the Fibre protocol also the reason why mining difficulty is pretty much the same across the network (I assume it's the same, otherwise it would be problematic, right)? If difficulty changes after 2016 blocks on average and block propagation is fast, everyone can adjust their mining difficulty pretty easy and there wont be much difference inside the network (most of the nodes will up to date)?

As usual, it would be much better if you asked about something instead of asking for comments on a statement. Please improve the title by including what it is that you are asking about FIBRE, e.g. "Is FIBRE the main reason why blockchain forks occur less frequently?". Also, I'm not sure what you mean with "deserved" in the first sentence of each block. Do you mean to say "it's the reason for something"?

More concretely, you could for example ask: "The goal of FIBRE appears to be to relay blocks as fast as possible. What benefits does faster block relay have for the mining process and the Bitcoin network in general? Does FIBRE have any other benefits?" Then answers will focus less on what you already thought you knew, but tell you something new.

Hello, i understand your suggestion, but I wanted to focus only on these two assumptions. If I would ask the benefits, maybe someone would answer me with some of the benefits that are much important than these two.
Yes - deserved - the reason for something.
Thank you for your constant support Murch, I appreciate it very much!

Hi ddavi03, I made a very opinionated edit to your post. Sorry. ;) — I've moved the underlying statements into the introduction of your question to first provide the framing of the question. I've put the main question in the title to make it more informative. I hope I got right what your main question is. MHO, the question about difficulty is rather unrelated to block propagation and should be separate. If you did want to ask about the benefits of effect of faster block propagation that should also be a separate question. Please feel free to edit further, or roll back my edit.

Is Fibre protocol deserved for rare temporary forking? If blocks are propagate that fast, there are less chances for temporary fork to happen and even if it do, they are short (small length)? Miner can fast continue to work on (what it seems to him) block head of the chain?

Well the point is that a miner can more quickly switch to a new block that has been found on the network. The time a miner spends on building on top of block A, while a block B has already been found by someone else, is very likely a waste of money and energy.
Note that this is not just in the interest of the miner, but of the entire network: a hypothetical 51% attacker is not subject to these losses, as they only build on top of their own blocks. Thus, faster propagation of blocks on the network means that this advantage 51% attackers have over honest miners is reduced.

Is Fibre protocol deserved why mining difficulty is pretty much the same across the network (I assume it's the same, otherwise it would be problematic, right)? If difficulty changes after 2016 blocks on average and block propagation is fast, everyone can adjust their mining difficulty pretty easy and there wont be much difference inside the network (most of the nodes will up to date)?

No, difficulty is not a function of time, but of the previous blocks. So regardless of which block a miner is working on, they always know exactly what the difficulty of that block needs to be (as they have the block's ancestors).
Better block propagation means they can switch to the next block faster, along with the difficulty change that that entails, however.
PS: Note that as of September 2020 the public FIBRE network is no longer operational, and I don't know if any private deployments exist.

Thank you for your answer Pieter, but could  you please explain your sentence in PS section. What do you mean by that? FIBRE wont be in use anymore or they just gonna stop working on its improvements?

FIBRE is a protocol for fast block relay that can be used between nodes that explicitly set up FIBRE software and configure it to use between each other. There also used to be one public FIBRE network operated by the protocol's author between public nodes all over the world, accelerating block relay for anyone who connected to it, and others indirectly too. The latter has been shut down. You can still use FIBRE on nodes you control yourself, and a variant of FIBRE is in use on the Blockstream Satellite project. More information on https://bitcoinfibre.org.

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


text:
Why do multihop LN payments start settling from the recipient's end?
In HTLC, after all the parties have locked their funds in the contract, claiming payment happens in a reverse way, starting with the receiver who reveals the preimage of the corresponding payment hash.
What would be the problem if it had started with the sender? After the receiver confirms receipt of the contract, it sends an acknowledgment to sender. Sender releases preimage, timelock set in increasing order across the path, contract initiated by sender having the least locktime. Receiver is the last node to settle the payment.

For reference, I am adding a picture so that one can visualize what I am trying to say.

Hello Subhra,
Stackexchange is a question and answer platform. Topics are started by someone creating a question post and then getting one or more competing answers. Please see our [tour] for an illustration. This means that a question post should only post the question, however, you've also included your own answer. This turns your "question" post into a "please check my answer" post which makes it difficult for others to address your question. Please edit this post to reduce it to the question and post your answer as an answer below.

Ya I have corrected that

Great, thanks! I updated the title, made a little formatting change to highlight the question in the post and reopened it.

In HTLC, after all the parties have locked their funds in the contract, claiming payment happens in a reverse way, starting with the receiver who reveals the preimage of the corresponding payment hash. What will be the problem if it had started with the sender?

Firstly the sender has technically nothing to claim, secondly the receiver is the only one able to reveal the preimage in the first place.

After the receiver confirms receipt of the contract, it sends an acknowledgment to sender. Sender releases preimage

Do you mean the receiver would then hand the preimage to the sender ? This adds even more interactivity (if not using the Lightning Network itself to transfer the information) and also drops (partially ?) the Proof Of Payment.
I didn't think too hard about it but it may also open up a lot of other issues, what would be the rationale for doing so ?

Yes without the interaction, sender will not be able to figure out whether receiver has accepted the incoming contract for claiming payment or not. Had it not been the case, then sender would have started the transfer of fund but there might be parties in between who don't forward the payment. Hence for the atomicity of payment, this step is needed. I am thinking about a payment protocol with some incentivization mechanism and for that, a reverse payment looks feasible rather than settling payment from receiver.

I think you have answered your question yourself. If all nodes would behave honestly and in good faith your process would work. But in that case we would not need to go through the hustle of setting up htlcs to begin with but we could just forward money by changing the balances in each channel. The whole point of using htlcs is to make the payment process atomic and prevent nodes along the path from stealing funds.
Other than that I do not see any additional flaws.
Offtopic:
Looking at your recent post on the mailing list (c.f: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002718.html ) I wonder if this idea of "forwarding a second preimage" in addition to the current process of "releasing a preimage" could be constructed to prevent griefing attacks because the sender could enforce settling the htlc in case someone stalls the process. But the way how I  imagine such a solution right now, it would basically run into the same problems as you already described in your initial question. It might be interesting to investigate if PTLCs (with adoptor signatures and payment decorellation) could be used to identify the griefing node and use such a process.

Thanks for the reply. Yes we are looking into some other methods of countering reverse-griefing. The idea of second preimage sounds good!


text:
How to prevent selfish mining?
I'm exploring the topic of selfish mining attacks and how to detect and stop them. I do not really understand any of given solutions. Can someone please explain in plain English, how selfish mining gets detected, how to stop it from happening and how to react to it when the attack happens? Were there any selfish mining attacks so far? Were there any mitigations of the selfish mining attack added to the Bitcoin protocol since it was described?

We do have a number of questions here tagged [tag: selfish-mining], but it's maybe a bit more of an academic topic. Have you tried looking for academic papers about it?

Thank you, I did. That's the reason I wrote this question and used the phrase ("plain English")

I do not really understand any of given solutions. Can someone please explain in plain English

I also find this stuff difficult to understand however I'm a little skeptical of the idea that complex issues can always be simply explained. There is a reason why people spend decades studying a subject in order to understand something. Selfish mining isn't one one of these, it isn't quantum mechanics or some esoteric branch of mathematics, however it probably isn't simple.
I find this website works best when you ask one, specific question rather than bundling a bunch of questions together. So far as I can tell, this isn't a place where you can routinely expect volunteers to write substantially long multi-page essays.
A google search finds Majority is not Enough: Bitcoin Mining is Vulnerable; Ittay Eyal and Emin Gun Sirer; Department of Computer Science, Cornell University which, looking at the first few pages, seems to be readable. I would start there and ask here about any single specific points that I needed clarification for.
Cornell is a reputable institution and a peer-reviewed paper with substantial citations ought to be a reasonable starting point.

I did not expect an essay I just needed some simple explanation on existing solutions to the selfish miner problem. I already tried to understand the paper you mentioned, but I will give it another shot. Thank you for your answer.


text:
How Bitcoin avoids double spending?
If someone is sending bitcoin with low transaction fees and then sends the same bitcoin with higher transaction fees before the previous one is confirmed, so it is obvious that miners will pick the second one, so ethereum has nonce value of each transaction which avoids this, but how does bitcoin avoid it?

Nonce doesn't prevent the scenario you mentioned in Ethereum. You can still create two transactions with the same nonce and the one with the higher fee will be taken by miners. Though wallets generally don't presume bad intent, so they just increment the nonce. Nothing prevents you from creating two transactions with the same nonce twice, manually by hand. In that case, only one will be mined/added to a block. The one with the higher fee.

If someone is sending bitcoin with low transaction fees and then sends the same bitcoin with higher transaction fees before the previous one is confirmed, so it is obvious that miners will pick the second one

By default, the miner won't pick the second one, except the previous one had Opt-in RBF enabled.
However, technically or theoritically speaking, a miner always has the ability to pick any transaction he likes into his block template, so that he could mine such transaction(s) into his block. It's just the matter of whether his block would be widely accepted by the network (including other miners, non-mining full nodes which the wallet relied on, etc).

ethereum has nonce value of each transaction which avoids this, but how does bitcoin avoid it?

I don't know much about Ethereum. As far as I know, the UTXO model itself is the equivalent of the nonce value, since each UTXO (uniquely identified with TXID and output index) could be spent only once, otherwise it would be an invalid transaction or block.

Note that the nonce value/UTXO model and double spending by forking the chain are two distinct problems.
Without the nonce value/UTXO model, even an individual chain itself cannot rule out double spending or replayed transactions, which is actually inflation in bitcoin, or replay attack in ethereum (the replayed transaction would make the victim make another unexpected repeated payment, so he would lose money).
However, even with nonce value/UTXO model, the attacker can still produce forked chain to "rewrite the history" (in such case, the previous transaction would be actually discarded, which generally means the previous legitimate payment would be maliciously withdrawn), which is the reason why we need a consensus mechanism like proof-of-work.

it is obvious that miners will pick the second one, so ethereum has nonce value of each transaction which avoids this, but how does bitcoin avoid it?

Replace-by-fee is essentially Bitcoin creating a feature "RBF" on top of some behavior "A" (miners preferring the second transaction, or actually whichever transaction is economically preferable for the miner) refusing to consider the behavior "A" as a drawback, therefore consolidating "A" as a feature.
Double spending is still prevented by Bitcoin's high hashpower and by users waiting the number of recommended confirmations, both before and after replace-by-fee was invented.
A scenario requiring the possibility of accepting unconfirmed transactions as final without losing funds requires, as you know, a different crypto asset. Use different crypto tokens and networks for different needs. Bitcoin is a network for settlements ledger, not a network for fast payments.


text:
about bitcoin starting directory and .conf location
When I first started my bitcoin core node (version v23.0.0), it asked for directory where to start. I chose a different drive.  However, how does the .exe know every time where to start? I cannot find a configuration file where the data directory is specified. I do not use --datadir every time. Also, how do I make sure that it is reading the bitcoin.conf file in my working directory E:\bitcoin?

how does the .exe know every time where to start?

On Microsoft Windows The Bitcoin Core GUI application stores the name of the data directory in the Windows Registry at registry key Computer\HKEY_CURRENT_USER\SOFTWARE\Bitcoin\Bitcoin-Qt\strDataDir


text:
Why might my db be locked on starting bitcoin-qt after a clean shutdown and reboot?
I have LND v.16.2 running under Windows 10 with Bitcoin Core 23.0 on same machine.
When I need to reboot, I gracefully stop my LND node and close bitcoin-qt from the GUI, waiting until it has completely shut down. Then, when I try to restart bitcoin-qt after rebooting, it claims that the db is locked. Bitcoin-Qt is not running already, it is not in the autostart.
I have found that deleting the wallet.dat and creating a new one enables me to proceed. I am not worried about a financial loss, since the Bitcoin wallet contains no BTC, but it’s a yellow flag.
Can anyone explain why this might be happening and how I can prevent it?
.conf files below.

bitcoin.conf

server=1
listen=1
daemon=1
rpcuser=xxxxx
rpcpassword=yyyyyyyyyyyyyyy
zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333
txindex=1

lnd.conf

debuglevel=info
listen=0.0.0.0:9735
externalip=x.x.x.x   (my external fixed IP)
rpclisten=0.0.0.0:10009
restlisten=0.0.0.0:10010
tlsextraip=x.x.x.x    (my external fixed IP)
alias=nodenodealias
color=#ffdc00
maxpendingchannels=10
bitcoin.mainnet=1
bitcoin.active=1
bitcoin.node=bitcoind
bitcoind.rpcuser=xxxxxxx
bitcoind.rpcpass=yyyyyyyyyy
bitcoind.zmqpubrawblock=tcp://127.0.0.1:28332
bitcoind.zmqpubrawtx=tcp://127.0.0.1:28333

The base directory for bitcoin is e:/bitcoin that contains the node's data, logs, configuration file, etc. That is reflected in the windows registry and lnd seems to find it with no problem.
bitcoind.dir=E:/bitcoin

LND files, on the other hand, are in Appdata/local/lnd.

Use Microsoft's Handle tool to see what files are open, and add the details to your question (You can limit the output to a specific folder or keyword such as 'bitcoin' by running the tool like this:
handle.exe E:\bitcoin

That will tell you all the files existing in E:\bitcoin that are open, and which process has them open.  That should allow you to narrow down what process is causing bitcoin-qt to report that error.
If handle shows no open files, then perhaps you have a permissions issue - i.e. maybe bitcoin-qt can't open the wallet.dat due to limited permissions.  Use icacls.exe e:\bitcoin to check permissions.


text:
How can I update lnd to 0.17 on Windows?
I am running lnd 0.16.2 on a Windows 10 system.
I just downloaded v0.17. Can I just drop the new files
lnd.exe and lncli.exe
into my directory and run on the same install?  Any tweaks needed?

Yes, simply stop LND, replace lnd.exe and lncli.exe with the new files and start it again. As described in the release notes, there is a database migration that needs to run once after the update, so make sure not to stop LND before that finishes.

Thanks.  Since you seem in the know, can you look at my question here https://bitcoin.stackexchange.com/questions/119443/why-might-my-db-be-locked-on-starting-bitcoin-qt-after-a-clean-shutdown-and-rebo?noredirect=1#comment136334_119443                                     I have yet to get a satisfactory answer. Thx in advance.


text:
Verify your download
Why does Bitcoin core wallet bitcoin-26.0-win64-setup file
does not match the signatures of the SHA256 binary hashes or
SHA256 hash signatures which i can download same side. I think i do it wrong, somebody help how to check. I know to show me the hash, but they are different.

Please provide more details. What steps you undertook, what value you get, etc..

I downloaded both files from https://bitcoincore.org/. bitcoin-26.0-win64-setup (1).exe then the corresponding SHA256SUMS and also SHA256SUMS .asc. According to the instructions, the checksum of both files should match, but it doesn't. I think I'm doing something wrong

It's not the checksums of the SHA256SUMS themselves which is important, but the checksums contained in the file. Did you follow the instructions at https://bitcoincore.org/en/download/ under "Windows verification instructions"?

I suspected something like that, how can I open this file quickly? I don't understand the description on the bitcoin page

Generally you don't need to open it, but you can just use a text editor if you want. Checksum verification tools (like sha256sum on Linux; no idea on Windows) can directly compare the computer checksum of files with those in the SHA256SUMS file.

OK thanks to all very much, i do now understand. windows is just the same was matching the sha256


text:
to_remote output 0 during unilateral closing of lightning channel
If there is a lightning channel A-B where A had a balance of c coins and B had 0 balance, it could be the case that A makes several off-chain payments and now the balance of A is 0 and balance of B is c.
Can B now unilaterally close the channel given that to_remote output of A is 0 (this amount is below the dust limit) and to_local output is c or will this lead to failing of channel closure? Is it so that channel closure is allowed only when A has balance more than the dust limit? Also while doing a channel update, does A need to keep a channel_reserve that prevents him from transferring all the c coins to B? Or is this something checked only during open channel?

Can B now unilaterally close the channel given that to_remote output of A is 0 (this amount is below the dust limit) and to_local output is c or will this lead to failing of channel closure?

It can. If the output of A ended up being 0, the closing transaction would simply not include that output. That won't be the case though, check the last answer for why.

Is it so that channel closure is allowed only when A has balance more than the dust limit?

No, a channel closure is always allowed. If an output of the closing transaction is below the dust limit, that output will simply not be created, so the balance corresponding to that output will be set as fees. You can check BOLT3 for more details on that.

Also while doing a channel update, does A need to keep a channel_reserve that prevents him from transferring all the c coins to B? Or is this something checked only during open channel?

A does indeed need to keep a channel_reserve, as so does B, therefore, A balance will never be 0 (assuming she's the one unilaterally funding the channel), and B's will never go below the limit once his balance is above it.

How is A enforced to not exhaust the channel_reserve while updating the channel? So suppose A wants to do 1 single channel update that sends all c coins to B. Then will B deny signing this off-chain transaction seeing that A has exhausted the channel reserve and fail the channel?

Yes. https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#rationale

Thanks for sharing. But this is where I am having the confusion. It mentions that this check holds true for the initial commitment transaction while accept channel (opening of channel phase) but what about channel updates done later? Suppose A does x number of transactions, each transferring c/x coins, so will B deny signing the i^th channel update if B finds that A will have a balance less than channel reserve after i^th update?

It actually says the opposite, given this is normally not held by one of the sides for the initial commitment (given channels are usually one-sided when funded): "Initially, this reserve may not be met, as only one side has funds; but the protocol ensures that there is always progress toward meeting this reserve, and once met, it is maintained."

You can look down the same doc for "Adding an HTLC: update_add_htlc", under "A receiving node : receiving an amount_msat that the sending node cannot afford at the current feerate_per_kw (while maintaining its channel reserve and any to_local_anchor and to_remote_anchor costs):
SHOULD send a warning and close the connection, or send an error and fail the channel."

Thanks for the clarification and pointing this out that for every update channel_reserve constraint is maintained.

Let us continue this discussion in chat.


text:
Why doesn't Bitcoin migrate to proof-of-stake?
After reading a little bit about different consensus algorithms, I am just trying to understand why Bitcoin still uses proof-of-work. This consensus algorithm being exponentially expensive, and resource intensive, doesn't it make more sense for Bitcoin --the most expensive cryptocurrency out there-- to migrate to proof-of-stake?
Currently, Bitcoin transactions are so expensive that day-to-day transactions, like buying a cup of coffee, can be more expensive than the good/service itself in some parts of the world, which fails to deliver one of the original goals of Bitcoin. That is to be the common person's every-day money.
Why does Bitcoin stick to the proof-of-work consensus algorithm?

Was everyday use ever really a goal of Bitcoin? The number of transactions it can process per hour is hard-limited by its design. Either Satoshi Nakamoto didn't understand the order of magnitude of the world financial system or replacing it was never the intention.

According to the whtepaper, everyday use was the goal. At the time when the limit was introduced the number of transactions was order of magnitudes lower; and the code was basically in the alpha/prototype stages. I'm sure replacing the limit was the intention, but Satoshi didn't know of a viable solution.

@Philipp Scaling to everyday use is clearly a difficult task, but its worth noting that on-chain transactions per second =/= payments per second. Finding nuanced ways to create bitcoin transactions which allow us to pack a huge number of payments into a single on-chain transaction is an interesting approach that may be viable. The lightning network is an example of this.

Oh, I thought micro transactions are the most important application of Bitcoin.

@VolkerSiegel: In the past few years, the store of value use case has been emerging as the dominant application. Small payments are in the process of moving to second layer systems.

https://www.google.com/amp/s/techcrunch.com/2022/09/15/ethereum-switches-to-proof-of-stake-consensus-after-completing-the-merge/amp/

Proof of Stake is basically a case of having your cake and eating it, too.
PoW is a simple work-around to a coordination problem that was previously thought to be unsolvable. It sort of "cheats" by providing an economic solution to a distributed systems challenge, by introducing a real cost as a disincentive to unwanted behavior as well as using a reward system both to bootstrap itself and to incentivize security. The advantages of Bitcoin's PoW system include that the group of block authors is truly open to anyone with computational resources, that the system converges on one ground-truth because there is a real cost in producing a competing chaintip, and that it is simple enough for its security model to be well understood.
PoS is more similar to the approaches that were pursued before the publication of Bitcoin. PoS is naturally divergent as there is no real cost in staking. The "Nothing at Stake problem" allows stakers to work on multiple chaintips and only publish the next block from the chain most favorable to them. There are different ways of approaching the vastly different security model of PoS.

Source: Bram Cohen describing ETH's PoS research
For example, ETH's effort to switch to PoS has been in research since at least 2015.
The latest I've read, ETH's current PoS proposal piles multiple layers of complexity on top of the staking to achieve convergence. Stakers have to register as "Validators" of which there are a limited number, put up a sizeable collateral that can be slashed in retaliation for misbehavior, and additionally maintain frozen capital to stake in the first place. More mitigations are in place to punish validator malfunction and recover the system from such breakdowns.
Other approaches to and issues with PoS include:

Some systems introduce a central party that rubberstamps the latest block (e.g. Peercoin). A central coordinating party costs the system its censorship resistance.
It's difficult to fairly launch a PoS system since stakers have to hold funds in the system to author blocks. Many PoS systems get either started as airdrops, Initial Coin Offerings (ICOs), or a proof of burn auction.
Staking requires some representation of the private key to be online at all times, which may mean that it is easier to redirect some of the staking power (in early PoS systems it had to be the actual private key, so not only staking power but actual funds could get stolen). Not participating in staking means that your share in the monetary supply is being inflated away.
Some systems require coins to have a certain amount of confirmations before being allowed to be used for staking, so spending funds interrupts your staking revenue.
Some people expect that staking revenue will be taxed differently than mining revenue.
Some PoS systems can be gamed for profit by trying a vast number of block candidates to cause the staker to get blocks more often than their stake should qualify them for. Such an incentive may turn such PoS systems just into PoW schemes under the hood.
Some researchers argue that "by depending only on resources within the system, proof of stake cannot be used to form a distributed consensus, since it depends on the very history it is trying to form to enforce loss of value".

So, while the Ethereum Foundation keeps giving (and missing) new delivery dates for an incomplete research project, there seems to be less interest among Bitcoin contributors to discuss Rube Goldberg contraptions.
And then, beyond the general skepsis for PoS, it wouldn't be feasible to just switch to it:

"Even if there somehow was a workable solution that had desirable
properties and security proofs, it would be working under a vastly
different security model than PoW… and nobody can just decide to make
such a change without enormous community consensus for such an
invasive change."  –Pieter Wuille

Thanks a lot for the great explanation! So, for what I can conclude from your post, PoS is interesting in theory, but very hard to implement into practice because of its divergent nature, which leads to the need of extra layers on the protocol, which also means more complex mechanism and therefore less secure/efficient?

I still think there is something the Bitcoin community has to do about the high cost for transactions. This specially true for small-amount transactions due to the way that the transaction cost is calculated.

@OscarSerna that's about it. I think the answer could have emphasised that POW is also the only way to bootstrap the system. Proof of stake would not work at the start when there's nothing of value to stake.

@OscarSerna to reply to your second comment. Proof of stake doesn't solve high transaction costs; that is controlled by the transaction limit and desire of people to have their transactions finalised soon. To fix that you need to get logarithmic scaling with transactions. Ethereum's solution to that is sharding, which is a different beast than POS; but equally complex.

Thanks a lot for your answer. Very interesting topics to study.

@OscarSerna The cost of transactions is solved by increasing block size to allow more transactions to fit into a block. The cost of mining is nearly constant regardless of block size, so allowing more transaction in a block means each transaction can have a smaller fee without changing the reward for mining the block. However, increasing the block size requires a hard fork, which is why Bitcoin Cash (BCH) was created.

@PedroLobito: I've turned the example paragraph into a bullet list instead. That might make it a bit clearer.

OscarSerna: The transaction cost is not closely related to the consensus mechanism as csiz explained.

@OscarSerna Lightning networks solves transaction cost issue for small transactions so much so that it makes transactions at the Wei level economically feasible. But it comes with its own set of issues. Lightning network is live now though and you can use it to send real Bitcoins

@slebetman As far as my understanding goes, the lightning network only solves the problem for a small segment of the cases of use of Bitcoin since it's only useful when you are planning ahead on transacting several times with the same peer in the future. The lightning network is very good, but doesn't solve the problem of high fees on transactions for the most common scenarios like dealing with mostly unrepeated peers, or simply not having the funds to lock up in a channel for future use. I agree that it is a good step forward though.

The lightning network allows you to send payments to any other participant it can find a route to. It does work better for small payments, though. See for example https://bitcoin.stackexchange.com/q/43700/5406

@OscarSerna Your understanding is wrong. You are focusing too much on the mechanism (debt passed to your neighbor in the lightning network) instead of the actual transaction (payment reaching your target). Lightning network works by passing debt around and then consolidate all debt transactions into a single bitcoin transaction when you close the network. As such as long as you are on the lightning network payments cost almost nothing (which is why payments of merely 1 Wei makes sense on Lightning). You don't need to plan ahead, all you need is just both you and the receiver be on the network

@OscarSerna .. there's nothing that says you need to open the lightning network when you want to do the payment and close the lightning network once you've done the payment. You can open it as long as you like. You can spend bitcoins on the lightning network for as long as you haven't closed the network but those bitcoins cannot be spent on the main bitcoin blockchain. Once you close the network you can no longer spend those bitcoins on the lightning network but you can now spend it on the bitcoin blockchain. Think of it like a prepaid card for bitcoin

Ok got it. Thanks a lot for your reply @slebetman . I guess I had it all messed up about the lightning network. I am currently developing my own tools for Bitcoin in Python, and I haven't made it there yet, so now I'm looking forward to start coding the lightning network as my next step.

Passing by, i wanted to make an edit mentioning you may also be penalized for not being available. It's worth mentioning given of the pervert incentives this may create. Source: https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/#penalties. (But for some reason i cannot edit this answer.)

I think there are at least four reasons:

The miners are stakeholders in the bitcoin ecosystem. Mining solves a problem for them. Taking away PoW mining would make bitcoin no longer work for one of its most important group of stakeholders.
Non-miners are in bitcoin because they like what bitcoin is. If they want some other consensus scheme, they know where to find it. There is certainly room in the market for at least one PoW chain and that's what bitcoin is.
Major changes impose costs on every participant in the ecosystem. Every implementation has to implement the new rules. Everyone has to test that the new stuff doesn't break anything they're relying on.
There isn't a consensus in the community that PoS can provide the same level of security as PoW at lower cost. That's the claim PoS advocates make, but it's far from an accepted truth.

A thing that is not clear still to me is why in PoS, forks occur? I would appreciate any comment or answer to this related question: https://ethereum.stackexchange.com/q/87553/23024 Thanks

I think there are some very convincing theoretical arguments to be made, but there is also just a very practical consideration:
Right now, a very large portion of BTC is being held in the cold wallets of popular exchange platforms. Hardcore bitcoiners will shake their heads and declare "Not your keys, not your coins!", but this apparently has not stopped traders and normal users alike from keeping their coins stored with a custodial third party. Looking at the 'bitcoin rich list', we can confirm the huge number of coins held by exchanges.
This fact would put exchange operators in an undue position of power over the network: by staking coins owned by their users, the exchange operators can obtain a large, centralized point of control over the network's consensus operations.
There are already risks present when allowing a third party custodian to manage your coins/private keys, but switching to a POS system adds an entirely new and very serious type of risk! This is a very serious risk because it is existential in nature: if an exchange operator were to abuse their control of this huge number of coins somehow (by staking maliciously in some way or another), it would affect every user of the system, not just the users of that exchange.
This problem is only amplified by the fact that you have to not only trust the exchange operators to not act maliciously, you also have to trust them to secure their system against theft and intrusion. It is bad enough when hackers steal funds, giving hackers the ability to attack the network consensus as well is, in my opinion, an untenable addition of risk.
In case you aren't convinced: This risk is not theoretical, an attack like this recently happened on an altcoin network (Steem, mid-late Feb 2020). It appears that exchanges colluded to stake the coins they held custody of, in an effort to disrupt network consensus. A quick websearch brings this article about it up.

I do not think that the Steem scenario is very realistic for BTC; it started with a single exchange being dominant, and the Steem story highlights that this would ultimately kill the entire ecosystem of the coin in question. BTC had a similar problem in the past, where a majority of miners would in located in China; after some discussion, the Chinese miners agrees to stay well below 50% because they knew that BTC could break down anytime if they continued to grow, losing more than they could gain from growing.

This is a really interesting theory. I also think that toolforger is right about ecosystem regulating itself. Some good game theory applied here. Thanks for enriching the thread.

@toolforger right, it is a different situation, but I think this is still a foundational problem that is slightly different than miner centralization: With PoW, every effort is made to ensure the protocol does not favour or promote miner centralization. With PoS, centralization of coins seems unavoidable (exchanges hold a huge portion, and the fact that 'the rich get richer' under PoS only exacerbates this). Additionally, a hacker that steals coins could attack and incur almost no cost (other than lost value of the stolen coins), the same cannot happen in PoW.

I am not so sure about that "the rich get richer" aspect of PoS. If it's proportional to the amount held, the minting reward will be distributed accordint to the current money distribution and relative wealth remains unchanged. This changes if you have to allocate your money for PoS - the poor won't be able to allocate anything, and the rich will want to keep their money in cold wallets; I don't know how this plays out in practice.

Bitcoin should switch to BFT (Byzantine Fault Tolerant) PoS which is secure by definition. Most people that don't like PoS are thinking in "vanilla" or "chain based" PoS protocols which are certainly more insecure than PoW.
Ethereum 2.0 is using Casper currently in the Beacon Chain, and other coins are also using BFT PoS protocols. I will try to resume BFT PoS in a few lines:

Each block must be signed by 2/3 of validators based on staking power. That provides absolute finality in just one block.
There is a penalty system that punish evil behavior or validator inactivity which makes it MUCH MORE secure than PoW. If you sign 2 blocks with the same height, that's evil behavior and your staking deposit is burned automatically. If 1/3 of validators are inactive and the network halts, the penalty system start to burn slowly the deposits until the network can restart.
Even if you have 99,9% of staking power you can't censor transactions for free because as far there is a single honest validator in the network he will include the transaction you want to censor in his block. If the attacker doesn't want to sign the block of the honest validator, his staking deposit receives a small percent of penalty, but a small percent of millions of dollars is too much money. The honest validator receives also a penalty, but his deposit is small so it's not a problem.
If somehow the attacker has ALL staking power and start to censor for free and don't allow other validators register their staking deposits to create blocks, the community as a whole would agree to burn all staking deposits and restart the network, which makes every coin holder much richer than before.

Regards

re: "Bitcoin should switch to BFT (Byzantine Fault Tolerant) PoS which is secure by definition." - that is a bold claim, for example see this review of the CBC Casper protocols: https://medium.com/@muneeb/peer-review-cbc-casper-30840a98c89a. Quote from their conclusion: "Importantly, it remains unclear if the definition of the Casper protocol family provides any meaningful safety guarantees for blockchains, or if this approach is applicable to scaling blockchains at all."

Casper is a mix of of 2 protocols: a BFT PoS protocol (Casper FFG) and a "chain based" PoS protocol (Casper CBC). It looks this paper ignores completely Casper FFG, which is the most important part of the protocol as it provides absolute finality. The protocol could be even simpler: a classic BFT consensus (2/3 of validators must sign each block), with the typical penalty system for inactivity (light penalty) or evil behaviour like double-signing blocks with the same height (burn the deposit of the attacker). If the network gets halted due to many nodes being unavailable the network can ...

... automatically revert to PoW  consensus after a timeout. This is very simple and could be implemented in Bitcoin without any risk. There are variations about this concept like using commitees of validators, but the simplest version could work very well with Bitcoin.

Note also that Bitcoin has 10 minutes blocks, so the bandwidth overhead of using so many signatures per block is not important. Using a protocol like this we could have 1 minute blocks, and absolute finality in 1 block. It's too good to be ignored, I hope Bitcoin developers finally implement it.

re: ”...if the network gets halted due to too many nodes being unavailable the network can automatically revert to proof of work” - it is perhaps quite telling that PoW is the proposed solution to the shortcomings of PoS.

Not at all, this is optional. Whatever "chain based" protocol, no matter if it's  PoS or PoW can be used as a fallback protocol to automatically restart the network in "non-BFT mode" in an extreme situation like that. But this is optional, using committees (a random subset of validators to validate each block) even if 99% of validators go offline the network still can continue in "BFT mode" because at some point there will be a subset of validators in which 2/3 of them are online. Inactivity penalties will drain the deposits of the other validators so the network self-heal automatically.

In addition to other answers, Bitcoin investors would also like to have a very conservative approach to updating bitcoin. Messing with the core idea will increase the perceived risk for something wanting to be a store of value.

Proof of stake just doesn't work the same as mining from an economic incentive standpoint.
Miners make real-world investments, in advance, in equipment that becomes less valuable as difficulty increases.
Miners have no guarantee that their investment will pay off, they merely have a probability of finding a good proof of work.
Staking chains are vulnerable to new attacks, like "long range" attacks, "fake stake" attacks, etc.  Staking is just as easy to pool and manipulate as mining.
Proof of stake systems have some good solutions, but they aren't all solved. Until they are solved, Bitcoin definitely won't transition.
A more realistic transition would be to a proof-of-burn, where a p2sh burn is locked to a height, and gets you a decaying probability of being able to mine some future block.


text:
why is my p2sh raw transaction not being mined or erroring ERROR: 64: NON-MANDATORY-SCRIPT-VERIFY-FLAG (EXTRA ITEMS LEFT ON STACK AFTER EXECUTION?
I created this 2-of-2 multi-signature address for testnet following the instructions on the book Programming Bitcoin. I tried to spend the funds in this address following the standard forms (OP_HASH160 1060f2fd6058cd100fe4e485455badf453bd63e1 OP_EQUAL) Everything passes the verification tests in the code, but when I try to broadcast my transaction it never gets mined or it is rejected with ERROR: 64: NON-MANDATORY-SCRIPT-VERIFY-FLAG (EXTRA ITEMS LEFT ON STACK AFTER EXECUTION).
here is my raw transaction:
01000000011af3ab90a1c274ecb1f5e6e499ed2d0b5b2ebc6bbcbab751836ea70c90656e9f00000000dc00483045022100e9a2b73ff95e3395034e910d5d69dd3e18e12a28e9dacfd5f3b2894afd5fbf3f022035b50d48506932020fcea1781a0c58e9011918bd2a9cbbb5693027035ca9502b01483045022100f7621bb014d53d8a97c0b5605317dd4a92b53e03dd22e71b1db85c12e92218ff02204b77ff2a5bc9f7921d8a17d36d04ca29cbe25b2061f7c2f5e227e449ba614ee5014847522103e07f96e5ba598431c0c994493a4ae988c9854c171d5d4bb140db0a27a4c853e421031b63f964d8c65d1d1136dcfe5033dedea88c2d411934ea48c9708410be84e5ee52aeffffffff0140f60e00000000001976a91452903efc1004de01883ba3687be2a8ea4f6b1b1988ac00000000

I have only one input, and I am spending it all. The commands for the script signature for this input are built following the standard (OP_0, Sig1, Sig2, Redeem_script):
0,

3045022100e9a2b73ff95e3395034e910d5d69dd3e18e12a28e9dacfd5f3b2894afd5fbf3f022035b50d48506932020fcea1781a0c58e9011918bd2a9cbbb5693027035ca9502b01,

3045022100f7621bb014d53d8a97c0b5605317dd4a92b53e03dd22e71b1db85c12e92218ff02204b77ff2a5bc9f7921d8a17d36d04ca29cbe25b2061f7c2f5e227e449ba614ee501,

47522103e07f96e5ba598431c0c994493a4ae988c9854c171d5d4bb140db0a27a4c853e421031b63f964d8c65d1d1136dcfe5033dedea88c2d411934ea48c9708410be84e5ee52ae

which are encoded in the transactions as:
dc00483045022100e9a2b73ff95e3395034e910d5d69dd3e18e12a28e9dacfd5f3b2894afd5fbf3f022035b50d48506932020fcea1781a0c58e9011918bd2a9cbbb5693027035ca9502b01483045022100f7621bb014d53d8a97c0b5605317dd4a92b53e03dd22e71b1db85c12e92218ff02204b77ff2a5bc9f7921d8a17d36d04ca29cbe25b2061f7c2f5e227e449ba614ee5014847522103e07f96e5ba598431c0c994493a4ae988c9854c171d5d4bb140db0a27a4c853e421031b63f964d8c65d1d1136dcfe5033dedea88c2d411934ea48c9708410be84e5ee52ae

My redeem script follows the standard (OP_M, pubkey1, pubkey2, OP_N, OP_CHECKMULTISIG):
OP_2 03e07f96e5ba598431c0c994493a4ae988c9854c171d5d4bb140db0a27a4c853e4 031b63f964d8c65d1d1136dcfe5033dedea88c2d411934ea48c9708410be84e5ee OP_2 OP_CHECKMULTISIG

The input I am trying to spend is under the transaction:
9f6e65900ca76e8351b7babc6bbc2e5b0b2ded99e4e6f5b1ec74c2a190abf31a

By looking at the error, it seems like my public_key_script and my redeem_script are not consuming all the data in the stack, but I have checked everything, and I can't find what it is. HELP!
Ps: I do not think this is a relevant detail, but the input of the transaction was sent by one of the two public keys that generated the multi-signature address. Just trying to be thorough.

Your redeemScript contains the length byte for it. The redeemScript is really just a script without any prepended length byte. So for your script, it is
522103e07f96e5ba598431c0c994493a4ae988c9854c171d5d4bb140db0a27a4c853e421031b63f964d8c65d1d1136dcfe5033dedea88c2d411934ea48c9708410be84e5ee52ae

Note how it begins with 52 and not 47.
How P2SH works is that it takes the top stack element and executes it as a script. Since you began your redeemScript with 47, this script just pushes the next 0x47 bytes to the stack instead of executing the multisig that you wanted.
It is perfectly valid to do this, even if that is not what you intended. A non-empty and non-false stack means that the script succeeded, so your transaction is consensus valid and could be included in a block. It is not standard because you have more than one stack element left on the stack after script execution, which is why this does not relay.

The correct version of your transaction is
01000000011af3ab90a1c274ecb1f5e6e499ed2d0b5b2ebc6bbcbab751836ea70c90656e9f00000000db00483045022100f7621bb014d53d8a97c0b5605317dd4a92b53e03dd22e71b1db85c12e92218ff02204b77ff2a5bc9f7921d8a17d36d04ca29cbe25b2061f7c2f5e227e449ba614ee501483045022100e9a2b73ff95e3395034e910d5d69dd3e18e12a28e9dacfd5f3b2894afd5fbf3f022035b50d48506932020fcea1781a0c58e9011918bd2a9cbbb5693027035ca9502b0147522103e07f96e5ba598431c0c994493a4ae988c9854c171d5d4bb140db0a27a4c853e421031b63f964d8c65d1d1136dcfe5033dedea88c2d411934ea48c9708410be84e5ee52aeffffffff0140f60e00000000001976a91452903efc1004de01883ba3687be2a8ea4f6b1b1988ac00000000

but this is not valid. The redeemScript no longer matches the scriptPubKey of the output being spent (script execution stops here). But the signatures would also be invalid because they have signed a different redeemScript.
Because your transaction does not require any signatures, just pushing the script (that does nothing) that matches the hash in your scriptPubKey,
01000000011af3ab90a1c274ecb1f5e6e499ed2d0b5b2ebc6bbcbab751836ea70c90656e9f00000000494847522103e07f96e5ba598431c0c994493a4ae988c9854c171d5d4bb140db0a27a4c853e421031b63f964d8c65d1d1136dcfe5033dedea88c2d411934ea48c9708410be84e5ee52aeffffffff0140f60e00000000001976a91452903efc1004de01883ba3687be2a8ea4f6b1b1988ac00000000

is a valid, relayable, transaction spending your output.

Thanks a lot! I overlooked the length of the hash. Now I have to fix my code to make it work. This error means I have the wrong multisignature address as well, so I'll have to start over . I will definitely let you know how it goes. I still don't understand, however, how you were able to build a valid transaction without the 2 signatures, and only using the redeem script? Is it because I am using 2-of-2? This means that basically everybody could spend the funds in this address by only knowing the redeem script which is now public due to this tx.

I just fixed my code, and it worked! Thanks a lot man!! I'm still wondering why you say "Because your transaction does not require any signatures, just pushing the script (that does nothing) that matches the hash in your scriptPubKey". I thought I had set it up to require 2 signatures out of 2 possible. However, your transaction without these signatures got broadcasted with no sweat. What exactly am I missing to actually make this address a truly multi-signature address that will require 2 of the 2 signatures?

Oh! is it just because I have that extra OP_72 at the beginning of the script that makes it non-standard and therefore makes it totally useless? So if I have no extra OP_72 my address will actually require both of the signatures to transact?

Yes, it's because of the OP_72. The script that is actually run is just "push 72 bytes onto the stack" and those 72 bytes are the script that you wanted to run with the checkmultisig. But because that is never executed, no signature checks ever take place.


text:
How much data traffic does participating in Bitcoin mining cause?
I have a limited amount of data included in my internet plan. If I exceed that limit I get charged extra. So, before signing up for Bitcoin, I'd like to know whether Bitcoin mining causes a lot of internet traffic. Does it involve a lot of downloading and uploading throughout the day?

Will you be solo mining or joining a pool?

If you make enough from mining you might still make a profit and be able to pay for the extra charges :p

If you use a light wallet like Electrum, definitely not.  But even if you run a full node, it is unlikely.  You could also use a web-based wallet like blockchain.info which would mean that nothing at all is running on your local computer and you can access it from anywhere.

OP is not asking about running a wallet, but about mining he could probably benefit from knowing statistics on bandwidth utilization.

If you mine with a pool, your actual internet activity will be fairly small.  I just took a look at my network statistics and BFGMiner used 9MBytes down and 11 MBytes up over the previous 24-hour period.
The Bitcoin-Qt application on the other hand maxes out my upload bandwidth since I always seem to get 2-3 peers who want to download the entire 12 GB blockchain from me.  Other than that, the main Bitcoin-Qt network usage occurs when you are receiving or relaying the latest block (blocks are typically 100-400 KBytes).
Since you have limited internet bandwidth, your best bet would be to run a lightweight client such as Electrum or Multibit.  If you are mining in a pool, you don't need a local Bitcoin-Qt.

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


text:
Litecoin - Is better use a good CPU or good GPU?
I heard in some forums that mining Litecoin is better using a good CPU (Processor), different from Bitcoin that's better mine using a good GPU (Videoboard).
I want know, this is true? For litecoin, is better buy some good processor like i7 instead a good GPU? Litecoin really is better mined using CPU's?

Any CPU can still be used to mine Litecoin, although much less effectively as a modern AMD GPU could.
Mining with a CPU gives you very bad hashrate therefore I wouldn't recommend it.
Even a high end CPU will not give you the hashrate of a mid range GPU.
You should use a graphics card (GPU) to mine litecoins or switch to another coin
Additional Information: If you decide to buy a GPU specifically for mining go for an ATI GPU as its much more effective than its nVidia counterpart.

CPU is virtually useless for scrypt based coins like litecoin, stick to GPUs, for now.
Here is a comparison of the top GPUs you can buy for mining, with user submitted settings.
http://coinpolice.com/gpu/

is that a site from 1997? http://i.imgur.com/ukdD0ii.png

No. A GPU will almost certainly always be faster than a CPU for Litecoin mining.
See the Litecoin Mining Hardware Comparison chart.

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


text:
Where can I find a full list of all Bitcoin mining hardware ever used?
I want to know where I can find a full list of Bitcoin mining hardware. I don't want a list of the most profitable hardware, I just want a list with the greatest number of Bitcoin miners (don't care if it mine at low hashes p/ second or is very old).
The objective is to include this list in a tutorial where I explain mining to newbies and where I can show the viewers a "complete list of Bitcoin mining history".
Have some ideas about that?

https://en.bitcoin.it/wiki/Mining_hardware_comparison and https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison are the canonical lists. I'm not sure that will be useful to you; there's approximately 940 products across the two lists.
If you're making a visual presentation of how mining hardware evolved, you might also find this thread useful.


text:
What license is used for the content of Bitcoin.org?
What license is used for the content of Bitcoin.org?
In the footer of the website we can find that the website is licensed under the MIT license, but the MIT licensed is used only for code, right? I also have looked at Legal disclaimer and the Frequently Asked Questions section, but I couldn't find the answer.
Under which license is the content of Bitcoin.org available? CC BY 3.0? CC BY 4.0? MIT?

I've posted this question on Bitcoin.org GitHub repository and I've got the answer.
According to @harding, from Github, the content of Bitcoin.org is commonly licensed under MIT, only not when specified. Here is his full answer:

the MIT license, as stated. You can also check the COPYING file in the repository, which says;
The intellectual property rights in the files are owned by the respective authors. Some of the files can be licensed under MIT License (MIT) available on http://opensource.org/licenses/MIT or other licenses. Appropriate licensing information can be found in the header of the file or in the folder containing the file.
In general, text files have the license information near the top and image files have the license information in a file in the directory.

@saivan commented:

[FAQ] certain pictures listed on the page are not MIT licensed (see the COPYING file here: https://github.com/bitcoin/bitcoin.org/tree/master/img/faq). This being said, although I am not a lawyer, I think you can easily use screenshots like this without much copyright issues

Thanks for your replies, guys, but I will elect this one as the best answer cause this is the response I really wanted.

but MIT licensed is used only for code, right?

Typically, but it's also used for documentation too.
As far as I can tell, all of the content on bitcoin.org is MIT licensed. Source.

Thank you, but I need a precise answer (I mean, linking to an official document on Bitcoin.org that tells me which is the license).

@FernandoPaladini I've linked to the document that I based my opinion on.

The github repo for the site has this 'COPYING' licence terms:
https://github.com/bitcoin/bitcoin.org/blob/master/COPYING

The intellectual property rights in the files are owned by the respective
authors. Some of the files can be licensed under MIT License (MIT) available on
http://opensource.org/licenses/MIT or other licenses. Appropriate licensing
information can be found in the header of the file or in the folder containing
the file.

TL;DR; It's MIT, except where it is not

authors: Катерина Данько


text:
Running poclbm miner in Ubuntu 13.04 without ATI card
I am running Ubuntu 13.04 64bit with 16GB RAM and this is my VGA card:
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor     Graphics Controller (rev 09) (prog-if 00 [VGA controller])
Subsystem: Lenovo Device 2200
Flags: bus master, fast devsel, latency 0, IRQ 45
Memory at f1000000 (64-bit, non-prefetchable) [size=4M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
I/O ports at 6000 [size=64]
Expansion ROM at <unassigned> [disabled]
Capabilities: <access denied>
Kernel driver in use: i915

When I try to run poclbm miner, it doesn't list any openCL devices and says nothing to mine on ?
Is there any other miner that I can use on Ubuntu to use and maximize the performance from my VGA card ?

Your VGA card has no performance to maximise. Your CPU is more powerful for this kind of computation. I know, I have the same card.


text:
Moved Bitcoin-Qt wallet to blockchain - can see my funds but can't send them?
It all started the other day when I sent some coins to Bitcoin-Qt, a 'safer' wallet ... was so slow to sync and was crashing et cetera.
Anyway, I imported the wallet.dat to blockchain.info opening up a mywallet(blockchain) there. I can see the coins in the wallet now, but I can't send them (no access to send option), which is what I have to do.
How to resolve this?

Is the address on blockchain marked as 'watch only'?

I don't know. I can't see anything to indicate it is. It allows me to receive (an address)but no option to send. Ive completeled all security tasks , email verification and sms verifiction but no joy

Try importing the private key string directly into a blockchain wallet.

Ok..this makes me nervous. I'm no techie and am afraid ill f it up

How should I get the private key?

OK. I worked out how to extract the priv key. I did so and then exported( drag and dop) into blockchain mywallet. It says it already has that 'address' Now what?

i have blockchain.info "My Wallet" wallet on iphone. i didn't pay any attention to it for about a month until a couple of days ago. when i opened the app it showed a balance of 0.00 BTC. A momentary shock. Then i noticed that the "identifier" i.e., the string of letters and numbers in the top field. This is your public key for that block. For some reason in its wisdom blockchain created a new identifier that now by default fills the identifier field, whereas my old correct identifier used to show in that field, and a positive BTC balance associated with that idedentifier showed as well. Now when I hand enter the old correct identifier, it shows my correct BTC balance.

I do not appreciate having the functionality of the app change like that without notice to me first.
Contacting support from blockchain is impossible if there is any support from blockchain.

To answer your question: hand enter your original identifier and your correct account will show. I have no idea why they change one's identifier.


text:
Is there some resourses where I can sell pc time for mining?
is there some resourses where I can sell pc time for mining. I'm not talking about project where people set "some software" on pc and recive 1$ per day, that was popular on time low cost mining of bitcoin and where people even don't know that they mine bitcoins. I`m talking of market where people fully understand what they do. I know about cex.io, but there you buy and sell power of hoster, not your personal calculating power. The only place what I found is ebay, where from time to time people sell their calculate power for hours or days. Anything similar?

Are you talking about mining Bitcoin or another currency?

Not only bitcoin.

A PC's general purpose CPU is so far outclassed by specialized mining chips (ASIC's) that its value for mining is almost null. Perhaps the only instance where a PC could be useful for mining is at the very beginning of a crypto-currencies life cycle, when has just been launched, and very few are mining it. But when ASIC mining hardware joins the coin's network, difficulty will rise and render CPU miners inconsequential.
If you expand the definition of PC to include ASIC mining hardware, then the idea of selling hash power is interesting though. I found the following reference to this idea: https://en.bitcoin.it/wiki/Hash_Market

I ran some calculations and found that running an average (4MHash/s) PC for 24 hours gives you slightly better odds of mining a block than winning the Powerball lottery with a single ticket.. Save some money(in electricity) and buy a lotto ticket instead.

Goes to show how low the odds of winning the lotto are... I read that the chance getting into a car accident while driving a few miles to buy a ticket for the MegaMillions, is about 8 times greater than hitting the jackpot. So, I guess you've got a good point. If one does not mind the electricity cost, CPU mining is a good lottery to play ... http://www.durangobill.com/MegaMillionsOdds.html

Yea, personally I think it's worth it /in the winter/..  because the electricity isn't wasted, it just turns into heat, which makes me heater run less. Really makes me look at computing as a zero-cost activity heh

Yes, I know about CPU mining and current situation, there are too many advisers that try to look forward for me, but not answer question. Dan K seems like there was such idea, but adress didn`t work now. May be you know why?


text:
Obelisk servers
Obelisk servers are implemented by several libraries like Pybitcointools and Libbitcoin's SX/BX tools; there also appears to be shared(?) repositories between Spesmilo and Libbitcoin.
What is the benefit and differences offered by Obelisk servers?

the libbitcoin framework is definitely meant for back-end development. If you don't want to compile the source from bitcoin-server, you can download the binaries for Windows, Linux and the Mac.  See this slide presentation for an overview about libbitcoin.
Obelisk, now called bitcoin-server (bs), is build upon libbitcoin framework that is built on top of the zeromq and sodium packages. This means connections between bitcoin-server and clients such as bitcoin-explorer (bx) can be made scalable and secure the confidentiality of data in transit between bx clients and bitcoin-servers. The communication ports between bx and bs are different from regular bitcoin clients and their nodes.
However, bs still uses ports 8333 (mainnet) and 18333 (testnet) to communicate to the rest of the Bitcoin network nodes.  When runnings bs, you can see easily see how the height of the local copy of the Bitcoin Blockchain is via watching the stdout.  Transactions also start to appear on the stdout channel when the bs node is almost complete.
The Spesmilo repository for Obelisk is now deprecated by bitcoin-server. Similarly, the sx repository is also deprecated by bx. The latest code for bs and bx have very fast moving branches. Beware that bitcoin-servers tend to require a little over 3x the disk space than bitcoin-core servers for retaining the blockchain. I suspect an 8x increase in the max Bitcoin block size will require the blockchain format used by bs for storage to undergo a redesign.
Can't speak Pybitcointools other than locating this find concerning Python functionality. To round out a description of the libbitcoin functionality which leads to this documentation.

"Obelisk is a scalable blockchain query infrastructure. A pure Python library is great because it can be deployed easily without requiring dependencies. This allows code to be ported across many platforms such as the mobile phone with Kivy, desktops or any platform running Python."
So it could be conveniently implemented in development of a processing service/backend.

What are you quoting from?

@NateEldredge
Quoted from this developer:
https://github.com/genjix
https://bitcointalk.org/index.php?topic=354607.0


text:
Armory 0.93 on Testnet: consistent unconfirmed Txs sent from connected Bitcoin-cli (log attached)
Running Armory (0.93.0.82) on Win7 x64 with the following flags:
"C:\Program Files (x86)\Armory\ArmoryQt.exe" --testnet --datadir=d:\data\armory\testnet3 --satoshi-datadir="d:\data\bitcoincore" --rpcport=8332 --debug --netlog --mtdebug --logfile=d:\data\armory
You'll find the log file throws a recurring error...
    -WARN  - 1427685617: (..\Blockchain.cpp:47) Somehow tried to add header that's already in map
    -WARN  - 1427685617: (..\Blockchain.cpp:48)     Header Hash: 00000000ad4e4c886567776c89e752614f251cca28b7dfcaf16867677ba0245a

FYI, those times/blocks correspond to the most recent blocks, as validated by Bitcoin-CLI.
It's worth noting that the "current block" field in Armory shows a block ~6000 old (stuck on 323060), and mouse hover says "last block received 1.5 minutes ago" (or something similar) and updates with the block discovery.
Bitcoincore (v0.10 btw) gives this screenshot (the top 2 Txs - TxID 706b60a90510e8db0186be5980819931127110e300ce10c5a5b3f5fb04667dc2 - are labelled ? however they are confirmed in Bitcoincore eventually)
I've tried numerous wallets instances in Armory, updating, ensuring the client is connected, using the rescanning/rebuilding database option, etc. EDIT: Rescanning the database has actually erased all record of the Txs in Armory
What is wrong here?

This seems like it might be a question better suited for Armory developers, maybe you should file an issue here: https://github.com/etotheipi/BitcoinArmory/issues.

OK, I solved this by numerous trial and error CMDs. The problem lay in the Armory implementation, specifically, the --datadir flag.
The working CLI flags:

ARMORY: -qt.exe --testnet --datadir=d:\data\armory\testnet3 --satoshi-datadir=d:\data\bitcoincore --rpcport=8332
BITCOIN-QT: bitcoin-qt.exe -datadir="d:\data\bitcoincore" -testnet -rpcport=8332

Contradicting Armory's FAQ (in the FAQ itself) is the requirement to explicitly identify the testnet3 directory for the --data-dir flag (--data-dir==SOME\DIR\Armory\testnet3). If the testnet3 directory isn't identified, Armory confuses the mainnet blockchain data with the testnet chain data.
The bitcoin.conf contents were:
listen=1
daemon=1
server=1
rpcconnect=127.0.0.1
rpcport=8332


text:
Is it faster to retrieve bitcoins from exchanges than fiat?
Quite often there are threads on various forums and complains on IRC channels that this or that exchange is not "playing nice" and has withdrawals (to a fiat currency like USD) taking a very long time. Very often invariably the excuse is that there has been a problem and that "employees are processing the backlogs" or something like that.
What about transferring bitcoins from the same exchange to your own bitcoin wallet? Is it something that also takes weeks and where the same excuses about backlogs are used? Or are the bitcoin transfer from exchanges to the wallet of your choice something that happens quite fast?

Just to give this a direct answer:
Yes, it's possible for coin withdrawals from an exchange to be processed instantly, and as far as I know most exchanges actually do so.

Withdrawing fiat from exchanges take longer time because in most cases it is manually processed. If the transaction is dependent on bank then it take a couple of manual transactions before it reaches you.

Yea, removing fiat from many exchanges is quickly becoming a pain. Higher fees, longer waits, and more regulation. I recommend moving coins in and out of accounts. If you want to trade between fiat and bitcoin, I recommend using https://localbitcoins.com/ and exchanging with cash. Less paper trail, no waiting, and fewer scams.


text:
Transaction malleability and Bitcoind
I've been trying to get my head around the process that stops transactions from being malleable on a system built using Bitcoind. I'm pretty sure, that out of the box, right now, I'm not doing anything to solve this problem.
So I thought I would look it up, but could not find any tutorials, or even a good explanation of the technical steps you need to take in order to stop or prevent transaction mailability.
Are there any protocol level tutorials on the subject?
Or, do you have any personal experience with this that you could share with me?
Thanks in advance for your help.

You'll have to be more specific as to what you mean by "transaction malleability". Changing the meat of a transaction is essentially impossible. Changing things like the transaction id, which is really a checksum (it's not even guaranteed to be unique, though it's highly unlikely to be repeated) is possible, though practically difficult. Or perhaps you could be more specific as to what you're worried about?

I apologize for being vague.

Here's what I'm doing. I'm putting up an instance of bitcoind that users can drop money into, and make transactions with other users, who also put money in the system.
What I want to make sure of is that there's no way to game bitcoind into putting money into the system where it gets logged and spent, and then taken out retroactively by the same user that put it in (if that's even possible). I'm not clear on this.

There's no take-backs in BitCoin. The amount and who it's coming from and to can't be changed once the transaction is broadcast. The transaction malleability problems being talked about, like MtGox is where people modified something else in the transaction, calculated a new TxID - MtGox problem was keeping track of account balances only by the individual transactions; they'd never recalculate the balance of an address (eg lookup all transactions to/from an address).

So as long as you keep a running total, by auditing accounts and all transactions in your system, you're okay?

What's more important than your method of keeping accounts, is that you have a different method available for verifying accounts. The source and destination addresses in a Bitcoin transaction are immutable (without invaliding the transaction), so either your primary or secondary accounting methods should rely on that information.

possible duplicate of How is the transaction malleability issue being fixed?


text:
How to start multiple altcoin rpc daemons at once?
I'm building an ecommerce website where I want to do my own payment processing in seven different ctyptocurrencies. I want use the separate versions of bitcoind for each currency, because I feel like that's the most straightforward way to do it (unless I'm wrong). I've even come up with some dog simple interface code to use once I get them all running!
So I've compiled each one, and I've got my rpc config files ready and raring to go, but whenever I start one of the rpc servers... it doesn't exit to the command line. It either just sits there, or depending on whether or not I'm printing to the console, it tells me everything that's happening.
When I hit cntrl+c, it exits to the command line, without stopping the daemon, which is what I want, but I can't seem to figure out how to write a script that will start all of the different rpc servers at once.
I have to be missing something stupidly basic.
I've looked everywhere on this stack exchange, and have not been able to find a solution to this problem.
HELP!
Thanks in advance for your time and attention.
Edit: I'm attempting to do this from the Linux command line with the standard compile parameters.

You need to change your conf file to include
server=1
daemon=1
Or you can also pass these in at the command line
You can see these on the Wiki
https://en.bitcoin.it/wiki/Running_Bitcoin

in seven different ctyptocurrencies

Not a good idea. Trust me. Bitcoin is enough, and for that you don't need any daemons. Bitpay or blockchain.info can handle it for you.
Well, here is what I do to start Litecoin daemon:

"C:\Program Files (x86)\Litecoin\litecoin-qt.exe" -server -rpcallowip=127.0.0.1 -rpcuser=user -rpcpassword=password -rpcport=1488

Right on. Actually, I'm not accepting bitcoin at all. The whole thing is an exercise in building altcoin economies. I have some theories about the nature of speculative assets that I want to prove or disprove.
I actually did try what you're outlining. It still hangs after I start it.

In Windows 7 after I run it waits for two seconds and starts the client.

I'm using Ubuntu with no ui. Just using the daemons.

Use Windows. Most altcoins don't even have clients for Linux.


text:
How much are accepted shares on GUIMiner worth?
I have just started Bitcoin mining and am using GUI Miner. I have an AMD 7870 OC edition that is mining for me. Currently i'm getting 380 mhash/s, is this good? Also how many of the accepted shares are worth 1BTC?

I have just started Bitcoin mining and am using GUI Miner. I have an AMD 7870 OC edition that is mining for me.

Welcome to mining. It's a blast.

Currently i'm getting 380 mhash/s, is this good?

For Bitcoin, it's unlikely to be profitable unless your electricity cost is very low. See How much Bitcoin will I mine right now with hardware X? for more information.

Also how many of the accepted shares are worth 1BTC?

None. It is unlikely that you will see 1 BTC total mining on that card during its lifetime. See the above link for why.

You may want to try out a calculator first. It is usually easiest to calculate your mining rate by comparing your hashing rate with the current difficulty rate, and then just remove the 1% fee from the pool.
http://www.bitcoinx.com/profit/

Or, put in another way, you're probably spending in power more that you're earning. Bitcoin is currently dominated by ASICs. I suggest moving to ASIC-resistant altcoins.

kaoD means Scrypt coins - use Coinwarz.com and mine anything with Scrypt.  BTC mining utilizing GPUs has been Dead since July  2013


text:
Question about mining algo
Lets say mining block is generated in 18:00, next block is generated after 10 minutes in 18:10 by user GENERATOR_18_10
As I understand, all transaction fees (for transactions included in 18:10) will come to the user GENERATOR_18_10?
Or, in other words, user GENERATOR_18_10 can point all fees in his wallet?

Yes, see http://bitcoin.stackexchange.com/questions/17999/how-exactly-do-new-bitcoins-come-into-existence/18003#18003

thanks, just checking :) And difficulty is just count of zero at start? :)

Difficulty started out at 1. See How is difficulty calculated?

The creator of the block will describe how to allocate the block reward, currently 25 bitcoins, of the discovered block.
They write this in the coinbase field of the block. Sometimes, the block reward and fees are sent to multiple addresses, like in P2Ppool mining operations.


text:
Can any current consumer grade computers mine any alt coins?
I'm interested in mining and would like to know if there are any consumer grade computers available that can mine any of the alternative coins. If so, what computers and which coins do you think would work fairly well?

As mentioned almost any is able to mine coins - the question just arises about profitability.
There are some mining pools, that offer to switch the coin mined automatically depending on which coin is the most profitable at any point in time.
Examples of those pools are:

Multipool.us
Middlecoin.com

Simply put all consumer grade computers "could" mine bitcoin and other altcoins, the question you're probably interested in is regarding profitabiltiy.
At this point in time people are still mining scrypt based altcoins with specially built machines with multiple high performance GPU's. Whether this is profitable depends on your circumstances for example power price per kW/h, the price of the coins you're mining and the cost of the rig you build/buy.
A good place to read about which coins are scrypt/SHA256 is List of alternative cryptocurrencies and a good place to find out about price/market cap is coinmarketcap.com.

If you have an AMD Radeon HD you can mine scrypt coins.  Nvidia GPUs aren't as good at mining.  There are also coins that are CPU only, but many of those have a difficulty that is too high, such as PTS, QRK and Primecoin.


text:
cgminer settings [ ati / amd radeon HD6870 GPU ] scrypt
I'm found that speed of my cgminer should be around 320kh/s:
https://litecoin.info/Mining_hardware_comparison
ati / amd radeon HD6870 GPU
The wiki recommend use this -I 19 -g 1 -w 256 --thread-concurrency 8192
However, I can not use -I more than 11, because hardware errors HW
My current success is ~ 150Kh/s:
./cgminer --scrypt --gpu-platform 0 -T --no-submit-stale --queue 4 --scan-time 1 --intensity 11  --thread-concurrency 2048 --load-balance --url stratum+tcp://
(5s):141.5K (avg):141.3Kh/s | A:631234  R:0  HW:0  WU:118.9/m
(5s):153.7K (avg):147.4Kh/s | A:1261234  R:0  HW:0  WU:141.2/m

When I set --intensity more than 11, i'm always get a hardware error and no accepted shares:

12 - only errors - HW, no accepted shares:

(5s):145.5K (avg):145.0Kh/s | A:0  R:0  HW:12  WU:9.1/m
(5s):145.9K (avg):145.1Kh/s | A:0  R:0  HW:12  WU:8.2/m
(5s):147.0K (avg):145.4Kh/s | A:0  R:0  HW:13  WU:7.5/m
...

16 - speed growth, but no accepted shares, only HW :

(5s):179.4K (avg):279.3Kh/s | A:0  R:0  HW:39  WU:27.2/m
(5s):226.5K (avg):269.4Kh/s | A:0  R:0  HW:54  WU:13.7/m

18 - very huge desktop lag, no accepted shares, and HW growth very fast:

(5s):188.2K (avg):296.4Kh/s | A:0  R:0  HW:52  WU:0.0/m
(5s):230.4K (avg):295.9Kh/s | A:0  R:0  HW:82  WU:0.0/m
(5s):256.3K (avg):295.9Kh/s | A:0  R:0  HW:106  WU:0.0/m
(5s):271.9K (avg):295.8Kh/s | A:0  R:0  HW:126  WU:0.0/m

20 - good bye Desktop. HW

(5s):273.9K (avg):287.7Kh/s | A:0  R:0  HW:194  WU:1.3/m
(5s):285.6K (avg):289.4Kh/s | A:0  R:0  HW:224  WU:1.1/m
(5s):264.7K (avg):292.4Kh/s | A:0  R:0  HW:325  WU:1.6/m
This is around declared in Wiki 320ks/s, but it is not a workable state, there are only errors - HW.
However, there is another mistake in wiki: --thread-concurrency 8192, my card have no enough RAM:
 [2013-12-02 17:02:00] Maximum buffer memory device 0 supports says 134217728
 [2013-12-02 17:02:00] Your scrypt settings come to 13428326

This told me cgminer, when I make +1 to  --thread-concurrency 2049

What is the magical border between 11 and 12 intensity?
I do not touch default Core and Memory Clocks:
$ amdconfig  --odgc

Default Adapter - AMD Radeon HD 6800 Series
                            Core (MHz)    Memory (MHz)
           Current Clocks :    300           300
             Current Peak :    915           1050
  Configurable Peak Range : [400-1100]     [500-1260]
                 GPU load :    8%

How can I achieve workable 320 kh/s, as wiki told?

Optimum hash rate depends not just on the parameters sent to cgminer but also on how was this program compiled, if it's 32bits/64bits, and the OS configuration.
The best results I've seen are with Gentoo Linux - as you may know, with this distro you first stablish your specific hardware configuration and then compile everything from code, thus optimizing all our software for the hardware you have to extract the most value off of it.
Something you do can do without going the esoteric route of OS tweaking, you could try modifying the GPU's mem clock as well as (slightly) overclocking. Usually, once you hit the point of diminishing returns with the intensity, thread-concurrency and work unit those are the next values to tweak.
If you haven't read the "README" file from Con Kolivas himself, when discussing Litecoin he delineates an optimizing algorithm in which you first find a sweat spot with intensity, then with another value, then another... finally going to mem clock and overclocking, he says you'll extract the best performance that way - such approach is valid for all scrypt-based coins.

I had same kind of problems with --thread-concurrency with my three R9 290 cards. The problem was that I had only 4GB of ram, I bought 8gb more ram, total 12GB and now everything works just fine. After that I also had problems with intensity but I worked it out with correct fan and temp-target settings.

I had only 4GB of ram, I bought 8gb more ram, total 12GB and now everything works just fine. Are you sure? 1714m  31m  12m S  42.8  0.2  91:12.71 ./cgminer My cgminer doesn't take more than 31 megabytes of resources, however, it takes a 1714m virtually.

I have two HIS 6870's and they are both hitting 270kh/s at 77c with these settings: intensity 14, worksize 64, thread-concurrency 6720, gpu-memclock 900, gpu-powertune -20.  Running on default litecoinBAMT1.3
sgminer version 4.0.0 - Started: [2014-02-10 20:31:11]
--------------------------------------------------------------------------------
(5s):551.1K (avg):543.6Kh/s | A:314368  R:3072  HW:0  WU:524.5/m
ST: 6  SS: 0  NB: 2039  LW: 38388  GF: 1  RF: 0
Connected to useast.middlecoin.com diff 1.02K with stratum as user ME
Block: f91ee7b2...  Diff:110M  Started: [06:46:06]  Best share: 325K
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  77.0C 3012RPM | 272.5K/273.3Kh/s | R:  0.6% HW:0 WU: 275.4/m I:14
 GPU 1:  77.0C 2826RPM | 272.7K/270.4Kh/s | R:  1.4% HW:0 WU: 249.1/m I:14
--------------------------------------------------------------------------------

There are probably problems with ATI-drivers or AMD-APP-SDK versions, please try the SMOS distribution which has tested versions.
http://www.smos-linux.org/
It worked for me :)

Having HD6870 set up today as well, the best result I was able to achieve experimentally was around 200.6Kh/s at those settings:

cgminer.exe --scrypt -o url -u user -p pass --intensity 11 -g 1 --worksize 104 --thread-concurrency 2048 --auto-gpu --gpu-engine 1100 --gpu-memclock 1200 --temp-target 80 --auto-fan --temp-overheat 85 --temp-cutoff 90

Currently the system is running at 74-C with 0HW
Indeed it seems you can't go upper than i11 and concurrency has to be 2^11 i.e. 2048. Otherwise you will get err message about insufficiend memory.
Better speed is achieved through increasing GPU and memory clock frequencies.

My setting:
--scrypt -I 19 -g 1 --lookup-gap 2 --thread-concurrency 6720 -w 64

I get:
cgminer version 3.7.2 - Started: [2014-02-14 21:28:07]
--------------------------------------------------------------------------------
 (5s):314.1K (avg):301.2Kh/s | A:79264  R:1440  HW:0  WU:270.0/m

I am using Ubuntu minimal install and it is not being used for Desktop. This is the best I could squeeze out so far.


text:
I bought a bunch of 2009 Bitcoins the actual coin. How can i cash the coin in?
I bought several 2009 Bitcoins and they came in a nice case but that is all the info I have on them.  How do I cash them in?

Sorry, I think you got scammed. Bitcoin was just barely starting in 2009. There weren't any physical coin merchants back then.

The actual Bitcoin coin is digital. Any physical item is a distinct thing, privately manufactured, and may or may not contain an actual bitcoin. As pointed out, if it was bought in 2009, it probably does not.

possible duplicate of How can one redeem a Casascius Physical Bitcoin?, Where can I safely sell a Casascius version 1 physical bitcoin (with hologram error) for cash?

That's not a whole lot of info to go on.  I guess there should be a way to open them or remove a sticker to uncover a private key.
On the other hand you might be better off selling them on ebay as they can be worth a bit more too a collector than the bitcoin value. Although you have to be careful with chargeback fraud I guess.

2009 physical bitcoin? Unless someone actually minted a physical bitcoin back then and loaded them with bitcoin as the casacaus mintages from 2011 -2013 did and they have a private key which is protected somehow until it is redeemed and acts like a digital wallet when the private and public keys generate valid transfer  data and update the bitcoin network with the new data to maintain a constant and redundant database which the exchange relies on to validate and verify every bitcoin and the key generation process and prevents the possibility of a counterfeit bitcoin key being able to successfully create valid data if a transfer is attempted, and also secures the exchange of a bitcoin by only allowing the senders public key to be accessible since the private and public key are used in the calculation to generate a unique string which is only accessible to the recipient because his public key is used to encrypt the transfer and only his private key can generate a valid transfer string, which contains the data relevant to the bitcoin I'd, the amount, and the public key of the sender. The use of the private keys in the calculations is to generate the valid data, but cannot be extracted from any of the data. The physical bitcoin  is the same, except the private key is the physical coins wallet key, and most wallets are digital and used as personal wallets instead of a container that can be held and traded physically. You should be able to look up the bitcoin value with the public key if the coin has one, otherwise, it's probably just a promotional token or a fake. Is like to see a photo, email me at erikwanberg@hotmail.com if you can. Good luck!

Here's what I dug up:

DIY coins

There is another way of getting your hands on a physical bitcoin – make one yourself. We are not suggesting that you set up a foundry and mint in your garage; a simple 3D printer will do the trick.
There are a number of print-ready 3D designs out there and they are just a Google search away, usually on 3D print marketplaces like Shapeways.
The trouble with this approach is that most designs are relatively expensive, even before you include the cost of actually printing them. While it is relatively cheap to do a few plastic prints on semi-professional fused-filament printers, making a proper metal coin on an expensive laser-sintering printer tends to cost a lot.
Image via Shapeways
In any case, 3D printing is an alternative way of producing unique physical coins by tweaking existing designs or developing your own.
One example of an affordable design that relies on nylon plastic with a matte finish is the Bitcoin Address Keeper by Ayame Deude. The 3D model costs €8.50 and, if you have access to a printer, the actual cost of printing a single coin should be low.
3D printing fulfilment services are another option, but in many cases the cost of shipping a single coin would be higher than the cost of printing it.


text:
Is it possible to definitely lose bitcoins?
The maximum number of Bitcoin is 21 000 000.
However this number of Bitcoin may never exist.
Supposing someone have 5 BTC in their wallet. In order to protect them, they encrypted it and then forgot the passphrase, or die (sorry, this example is sad).
In this case, the real maximum number of usable Bitcoin would be 20 999 995...
Is that understanding correct? What do you think about this?

You need to make clear that you understand difference between "lost" and "forgoten" bitcoins.

In his example, they're both the same - they're not directly usable anymore by the community at large.

related: http://bitcoin.stackexchange.com/questions/484/why-doesnt-bitcoin-return-lost-coins-back-into-the-block-reward

Yes it's possible to lose bitcoins forever.  There are even ways to "provably destroy" them by sending them to an address that can't possibly have a private key.

Interesting. Have you got a document about such cases?

https://blockchain.info/address/1BitcoinEaterAddressDontSendf59kuE

I was under the impression that all valid addresses had a corresponding private key, even though it may not be feasible to look up for it among the quadrillions of possibilities. Could you please expand on this?

Generate address, destroy private key. Now, where is the private key?

@TomTom that's not "provably" which was what the answer talked about. The BitcoinEater address is impossibly unlikely to have come from a random private key.

I think that 'lost' coins will only increase the value of Bitcoin (good for holders). Less coins = more competition for those coins that are still in circulation. All in all, the bitcoin cap is simply a number. The price of bitcoin in USD is completely relative to the demand of bitcoin since bitcoin can be broken up indefinitely. There could only be 10 bitcoins in circulation and the network would behave the same, we would just be working in milli, micro, and nano-bitcoin.


text:
How to recover an electrum wallet from seed
A service I used some years ago is shutting down. I withdrew some coin but it went to an old address. I believe it was my old electrum wallet that I only have the seed for. How to recover my bitcoin?

First download Electrum, try to get a version closest to the one you were using. Get the portable version because you may need to get a higher version if it doesn't work.
Open the program, File -> new/restore -> enter in your seed when asked.
When it asks for a password, it means a new password to save this wallet with encryption.
Then wait for the syncing to happen.

When you enter the seed the password is required to encrypt the seed on your disk. The seed itself is the password that unlocks everything - this is why it needs to be encrypted on the disk. The password is not required when recovering from seed you can enter any password you want.

Maybe that's true in newer versions. You need the original seed and password in the 1.x versions. Please don't overwrite old passwords .-.

@Eddie that's not true. Also you shouldn't be using 1.x anyway. It is unsafe to use such an old version. Always use the latest version of electrum.

This was written for people with wallets from 2017, if you have an updated answer just post it!


text:
How is time encoded (BIP65) in scripts?
BIP65 has several examples where OP_CHECKLOCKTIMEVERIFY interprets the time value underneath it in the stack, for example:
<expiry time> CHECKLOCKTIMEVERIFY DROP DUP HASH160 <pubKeyHash> EQUALVERIFY CHECKSIG

How is the time value encoded in this script? It's a CScriptNum object, but I'm unsure if that equates to little endian bytes

From the bitcoin wiki:

The stacks hold byte vectors. When used as numbers, byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Positive 0 is represented by a null-length vector. Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero.

What this doesn't say is how more than one byte is combined into an integer. For example, to represent the integer 278, the stack would have:
0x02 0x1601

And to represent the integer -278:
0x02 0x1681

The most significant byte (0x01) was just XORed with (0x80) to change the sign to negative.
Now that we know how script integers are encoded, we just have to understand how they are interpreted. This is shown in the BIP65 code:
// There are two types of nLockTime: lock-by-blockheight
// and lock-by-blocktime, distinguished by whether
// nLockTime < LOCKTIME_THRESHOLD.
//
// We want to compare apples to apples, so fail the script
// unless the type of nLockTime being tested is the same as
// the nLockTime in the transaction.
if (!(
      (txTo.nLockTime <  LOCKTIME_THRESHOLD && nLockTime <  LOCKTIME_THRESHOLD) ||
      (txTo.nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD)
     ))
    return false;

Where LOCKTIME_THRESHOLD is the UTC time:
LOCKTIME_THRESHOLD = 500000000; // Tue Nov  5 00:53:20 1985 UTC

So, basically, you can set the time that OP_CLTV will verify against in the scriptPubKey. If it is below LOCKTIME_THRESHOLD, then it is compared based on block number of the block containing the transaction. If it is above LOCKTIME_THRESHOLD, then it is compared based on block time of the block containing the transaction. Note that this relies on the consensus rule that transactions cannot be included into a block with a lock-time (nLockTime) in the future.