text:
What does nonce mean?
I'm trying to learn how litecoins work (and learn new programming language at same time by writing a crappy little miner).
I'm stuck with getdata. Here http://litecoin.info/wiki/Scrypt
it says that data is 160 characters long. But its not. Its quite a bit longer than that.
So my questions are:

1.) What is nonce and how do I use it?
2.) What is bits?
3.) What are all the 0's after the bits.

EDIT: Ok, I think I have to use just first 160 characters of data and ignore the rest. Correct?

A nonce is just a value that you keep changing in the hope that after you hash all the data the hash will be less than the target value. See https://en.bitcoin.it/wiki/Block_hashing_algorithm (litecoin is similar only uses scrypt instead of sha256 hash function.)

It's also worth noting that nonce is a general term in cryptography, referring to any number or bit string used only once. The word "nonce" is still in use outside the U.S. as a simple English word meaning "time being." Of course in certain parts of the world it's also slang for a pedophile, so maybe it's better if we leave etymology out of this one...

Okay, so when I try to resolve a block, I use first 160 hex chars from data in getdata and than have worker try to resolve it doing scrypt hashing of it. So my nonce starts with 1 and goes up by one till I rich the value specified in bits? I hash little endian version of previous block hash+merkleroot+timestamp+nonce? Correct me if Im wrong, Im just trying to figure out how this works.


text:
How is the encoding of extraNonce done in the genesis block?
You can see here the coinbase of the genesis block
txNew.vin[0].scriptSig = CScript() << 486604799 << CBigNum(4) << vector<unsigned char>((const unsigned char*)pszTimestamp, (const unsigned char*)pszTimestamp + strlen(pszTimestamp));

Broken down into hex it looks like this
Size of nBits as varint
0x04

nBits themselves
0xffff001d

Satoshi's message in HEX
0x5468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73

And between the nBits and Satoshi's message we have these three bytes which should be the extraNonce
0x010445

Which correspond to the code CBigNum(4), since 4 is an integer, it's 4 bytes, if this was encoded as a varint, it's value is < 253 as such it would've taken only 1 byte, but as you see there are three bytes.
Upon asking the bitcoin developers on IRC, they told me it's because the BigNum library encodes bits differently.
I started poking around in the Bitcoin source code, specifically the Bignum wrapper, I found many overloaded constructors and operators, but ultimately failed to find how these three bytes are calculated and returned because of my little experience with C++.
However, I believe it's this function
void setulong(unsigned long n)
{
    if (!BN_set_word(this, n))
        throw bignum_error("CBigNum conversion from unsigned long : BN_set_word failed");
}

However it's still not returning these bytes. So my question is, how is the integer 4 which should still be 0x04 in hex encoded to be this sequence of bytes 0x010445(big-endian) so that I can do it in C?

Looks like you're misinterpreting the code.
CBigNum is just a class that stores numbers. CBigNum(4) simply stores the number 4, and CBigNum(SHA256(block)) would store the hash of a block as a number (after all, SHA256 gives us numbers). CBigNum does what it says: it stores a big number. As it has a function that exports the number as big endian, it's useful here, and the Bitcoin source will often use it to concatenate numbers in a data stream.
Let's take a quick look at the genesis block's script, without looking at the code. Please open the relevant wiki page: Script
04FFFF001D0104455468652054696D65732030332F4A616E2F32303039204368616E63656C6C6F72206F6E206272696E6B206F66207365636F6E64206261696C6F757420666F722062616E6B73

Part of this can be interpreted as :
04 -> PUSH 4  bytes (FFFF001D)
01 -> PUSH 1  byte  (04)
45 -> PUSH 69 bytes (The Times 03/Jan/2009 Chancellor on brink of second bailout for banks)

Thanks. You have to understand though, the code is hardly documented inside. The protocol is documented mostly well, but the code not so much. CBigNum is said to be a wrapper to be a C++ wrapper to BigNum and nothing more. I could not have known what it does.

I've never even looked at that code, for this exact reason. The answer I gave you is based on information I found on the wiki only.

source: Stack Exchange

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

sort: votes


text:
How do I create the coinbase from the genesis block?
I wanted to write an application that given a timestamp(text basically) and a public key will generate a merkle hash for the creation of a new genesis block. So I decided to first try and re-create the one from Bitcoin.
Unfortunately, I am failing somewhere. This is my code http://pastebin.com/sVmZgMt8
So, I should be getting this result, which is available on the Genesis Block wiki article.
04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73

However while the text in hexadecimal form is there, there is another problem I am getting. This is the output.
1d00ffff000104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73

The first thing wrong is that the nBits are displayed in an endianness different than the one above, and skimming through the Bitcoin source code a lot I failed to see how and where it was swapped, as the only line is this one
txNew.vin[0].scriptSig = CScript() << 486604799 << CBigNum(4) << vector<unsigned char>((const unsigned char*)pszTimestamp, (const unsigned char*)pszTimestamp + strlen(pszTimestamp));

Also, there is an additional 0x04 byte in the Coinbase of the Genesis Block that I am also failing to get, and nowhere did I see it being added OR what it represents.

Did you try to compare your implementation to the original Bitcoin source code (line 1613)?

Yes I did, but unfortunately, it was hard to track the source code once it went into object serialization and the many overloaded constructors/member functions. But so far this is the best result I got, aside from the problems described above.

The nBits don't exactly get swapped. The notation on the wiki is in big-endian notation, which is basically the notation you'd use when displaying it, similar how the number twelve is written 12 and not 21 (different number order) but can be stored as 21 by a computer.
Your modern computer uses little-endian, which means that if you write something like :
int myInt = 0x1d00ffff;

It will actually store that in the RAM as 0xff 0xff 0x00 0x1d
Because of that, when you take the pointer of that int, and convert it to a unsigned char*, you get the little-endian order of it. Which happens to be what the reference client does :
(const unsigned char*)pszTimestamp

So, to put myInt in a char[], all you have to do is copy it there:
char tx[4];
int myInt = 0x1d00ffff;
memcpy(tx, &myInt, 4);
// tx now contains 0xff 0xff 0x00 0x1d

The only things that bitcoin actually swaps are network port numbers, which are stored in the memory as big endian numbers. Anything else doesn't really get swapped by bitcoin, it just stores them in the CPU's native endianness.

Ok, got it to work. However what is the extra 0x04 byte in front?

Oh got that as well, all Coinbases are prefixed with a byte indicating the length of nBits, in the genesis block's case it's 0x04 :)

Judging by the article on the genesis block, it's part of the scripting. Judging by the article on scripting, it tells the interpreter to push the next 4 bytes onto the stack

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


text:
What are all the payment channels implementations?
I know the Lightning Network (which Electrum wallet experimentally supports) is an implementation of a payment channel, but Mastering Bitcoin (2nd ed.) ch. 12, § "Routed Payment Channels (Lightning Network)" says:

The Lightning Network was first described by Joseph Poon and Thadeus Dryja in February 2015, building on the concept of payment channels as proposed and elaborated upon by many others.

What are the "many others"? Is the Elements Project's "pegged sidechains" "building on the concept of payment channels" too?

The Lightning Network is much more than an implementation of a payment channel. It is a peer-to-peer network whose core purpose is to route payment through a set of multiple payment channels.
Then, I think you are confused with regard to the quote: "many others" here refers to
people not projects. See the Payment Channels wiki page for mentions of some of them.
Finally, as you mention Elements is defining sidechains (a peer-to-peer network whose core purpose is to update a block chain that is somehow pegged to Bitcoin) which are not "building on the concept of payment channels".
However, payment channels may (not yet deployed) be a good abstraction for interconnecting sidechains with Bitcoin or in-between them.

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


text:
Are bitcoins with more confirmations more valuable?
Are bitcoins with more confirmations more valuable, or does the number of confirmations not add a sort of "time value of money (TVM)"?

Not really. A 0.2 BTC "bitcoin"† with ten million confirmations has no more value than a 0.2 BTC "bitcoin" with one million confirmations.
The exception might be that a "bitcoin" with less than six confirmations might be regarded as slightly less desirable for up to an hour.
Bitcoin generally meets the fungibility expectations of currencies. Just as banknotes (bills) with serial numbers do. A fresh new banknote is not worth more or less than an old one when you spend it in a shop.
In both cases, there is the case that money that can be traced to crime might be less acceptable - but that has nothing to do with the age of the banknote or of the "bitcoin".
† An unspent transaction output (UTXO).

Moreover, the "time value of money" is due to the fact that if you have money earlier, you can invest with it to gain more. Just leaving the money (whether it's fiat or bitcoin) be isn't going to make it increase.

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


text:
Why does my wallet size increase over time?
Why does the size of the output of
     bitcoin-clibackupwallet
or, equivalently, wallet.dat
increase over time?

The current wallet.dat file increases because you add new keys when you refill your keypool (get new addresses) or if you receive or send transactions. Mind that every wallet-relevant transaction is stored (together with some metadata) in your wallet.dat.


text:
How do I spend bitcoins from multiple wallets in a single transaction?
Using, e.g., the Bitcoin Core command line, how could I spend bitcoins from multiple wallets in a single transaction?
This comment says:

instead of sending the transaction to the network, you send it to the next person who will add their inputs and outputs and sign them as well, and so on. The last person would then broadcast the transaction on the network.

I assume I use createrawtransaction and signrawtransaction somehow, but how exactly do I actually do this?
cf. Mastering Bitcoin (1st ed.), §"Using Bitcoin Core’s JSON-RPC API from the Command Line", §§"Creating, Signing, and Submitting Transactions Based on Unspent Outputs"

There are currently three different ways to do this: raw transactions, PSBT in 0.17, and PSBT in 0.18. I recommend that you use PSBT in 0.18 as it is the least hassle, but I will describe all three here for you.

Traditionally, you would do this with createrawtransaction, fundrawtransaction, and signrawtransactionwithkey/signrawtransactionwithwallet. One person would have to know all of the inputs that were being used in the transaction or have all of those stored in their wallet (i.e. they have imported everyone else's public keys and/or redeemScripts into their wallet) and then they can use createrawtransaction or fundrawtransaction to create the raw transaction.
createrawtransaction just takes inputs and outputs that are specified by the user and gives the resulting transaction as is (so you need to be careful about fees and change). fundrawtransaction can choose the inputs to use for you using your wallet and it will handle fees and change outputs itself. However fundrawtransaction needs to know all of the information necessary to construct the final transaction (except for the private key, it can just use a dummy signature) in order to correctly estimate the transaction fees, which is why you need to import the public keys and scripts into your wallet.
Once you have the raw transaction, you then send it to each of the other people involved in the transaction. They then sign it using signrawtransactionwithwallet (if the keys and scripts are in their wallet) or signrawtransactionwithkey (if their keys and scripts are not in their wallet). Most people will use signrawtransactionwithwallet. They then send the result back to you where you have to combine all of the signed transactions into the final transaction using combinerawtransaction. Then you can broadcast it with sendrawtransaction.
Instead of sending the transactions out to everyone to sign at the same time, you could send to one person who signs, who then sends to the next person and so on. This would not require combinerawtransaction. The last person would sign and then use sendrawtransaction to broadcast.
This process is kind of bulky and requires that one person knows some (or all) of the information for the inputs being used (except for the private keys).

Since Bitcoin Core 0.17, you can use the various *psbt RPCs to achieve the same thing. With 0.17, the flow is fairly similar to the the raw transaction flow described earlier. You would have to have all of the information for creating the final transaction in your wallet (except for private keys) so that fee estimation can be properly done for coin selection, or you need to know which inputs to use. Either way, you use walletcreatefundedpsbt and specify the inputs you want and the outputs you want. Bitcoin Core will then automatically choose additional inputs if there is not enough to cover the output amount and create a change output for you. Because it needs to also conver transaction fees, it needs to have the same information that you need for fundrawtransaction to be able to estimate fees for the inputs it chooses.
Then you would send the transaction to everyone else who would add their signatures (and other metadata) using walletprocesspsbt. You can also do walletprocesspsbt first before sending the transaction to everyone so that various metadata needed for signing (like the UTXO that is being spent for each input) is added beforehand. Once signed, everyone would send the transaction back to you and you combine them together using combinepsbts Then you create the final transaction for broadcast using finalizepsbt and send the result using sendrawtransaction.
Of course using PSBTs you can do the same thing described above where each person sends the transaction to the next person to be signed instead of sending back to you to be combined.
Again, this process is kind of bulky and requires that one person knows some (or all) of information for the inputs being used (except for the private keys). But it is slightly less likely to result in an error than the raw transaction method. PSBTs also allows you to use other non-Bitcoin Core wallets that support PSBT, and you can use this method with wallets which are not connected to the internet or otherwise do not have the blockchain or the UTXOs that are being spent in the transaction.

However, Bitcoin Core 0.18 actually makes this whole process a lot easier. Bitcoin Core 0.18 introduces a couple of new *psbt RPCs which make it so that one person does not need to know all of the inputs being used and all of the information for each input. The only caveat is that this method assumes that each person has their own outputs that they want to create instead of multiple people pooling together their Bitcoin to make one large output.
With 0.18, everyone would create their own PSBT using walletcreatefundedpsbt. They specify any of their own inputs that they want to use and all of their outputs. Any change outputs will be added, and additional inputs from the wallet will be added to cover the output amount and transaction fee if not enough were specified by the user. Since every user does this with their own wallet, no one person needs to know anything about what the other users have in their wallets.
Then each person would send the PSBT to a designated coordinator who uses joinpsbts to join every PSBT into one large PSBT. This PSBT will have all of the inputs and outputs that each person wants to spend and create. So instead of having many individual PSBTs with their own inputs and outputs, there is now one large PSBT with everyone's inputs and outputs.
This PSBT is then sent back to each person who uses walletprocesspsbt to update the PSBT and add their input information to the PSBT and signs it. Even if a user has an airgapped setup where their private keys are somewhere that does not have access to the blockchain, they can update the PSBT from an online watching only wallet and send the PSBT to the offline machine to be signed.
Once everyone has signed the PSBT, it is sent back to the coordinator who uses combinepsbt to combine all of the signatures and input information into the same PSBT, then creates the final network transaction using finalizepsbt and broadcasts it using sendrawtransaction.
Again, this can be done serially like the other methods described earlier and thus omit the need for combinepsbt.


text:
Why do first bitcoin transactions receive most confirmations?
My very first Bitcoin transaction has 740 confirmations, the next have 239, 212, 70, 43, 5, and 5, respectively. Is this just because my first transaction has had more time to get more confirmations, or do first transactions always receive the most confirmations, even if the subsequent transactions follow immediately thereafter?
Viz., does the first bitcoin transaction need the most confirmations, such as to verify the legitimacy of a new user?
thanks

related: What are bitcoin “confirmations”?

Once a transaction has one confirmation, it gets a confirmation whenever the network creates a new block (roughly every 10 minutes). If one of your transactions gets a confirmation, the rest will also get a confirmation if they have at least one confirmation already. So the difference in non-zero confirmations between your transactions will always remain the same (except in very rare cases when the block chain gets reorganized).
Going from 0 confirmations to 1 works differently.
https://en.bitcoin.it/wiki/Transactions
https://en.bitcoin.it/wiki/Blocks
https://en.bitcoin.it/wiki/Block_chain


text:
Mining with one GPU
How do I GPU mine with only one GPU, which I'm currently using for graphics? Does that require going headless? How do I go headless?

I would recommend first checking this list to see what your expected hash rate will be:
https://en.bitcoin.it/wiki/Mining_hardware_comparison
And then see how much you will make from that rate:
http://www.alloscomp.com/bitcoin/calculator
Please factor in power consumption. After you have made a decision to mine armed with those facts, I'd join a mining pool and download GuiMiner.
http://guiminer.org/
http://mining.bitcoin.cz/
The pool operator will be happy to address your questions on how to setup the mining client as you are making them money.

I'm aware of GPUs' limitations for mining; I'm only doing this for testing purposes. thanks for the links, though

head over to bitcointalk.org and ask around. It sounds like you need a discussion to answer your question. The mining community there is second to none


text:
When / how frequently do miners get paid for transaction fees?
When or how frequently do miners get paid for transaction fees?

This seems like a subset of this question: http://bitcoin.stackexchange.com/questions/9895/who-gets-bitcoin-transaction-fees

@NickODell The selected answer says "The fee goes to the miner who mines the block that includes your transaction." So, the miner gets it right away, then.

With every block the successful mining entity reaps all the included transaction's fees. So, in the case of solo mining, a miner gets paid transaction fees every time he finds a block, in the case of a mining pool a miner's payouts depend on the mining pool's policies.


text:
Who pays me when pool mining?
When I pool mine, do my payments come from the pool operator's personal account? From the pool's wallet? Or from somewhere else?
When using P2Pool, the payments appear in bitcoin-qt as though I had mined the block myself.

Broadly speaking, there are two ways of paying pool miners. The first way is to have a wallet and send payments to miners through that when they ask for them.
The second way, which both eligius.st and p2pool use, is to keep track of how many shares people get, and set the coinbase transaction to pay the block reward directly to them once a block is found. This has the advantage that you never have any Bitcoins to steal on your pool server.

This has the advantage that you never have any Bitcoins to steal on your pool server. But non-P2Pool pool managers still have complete control over the payout queue, viz., who to include in the next block's generation transaction and how much to pay them. So, P2Pool is more secure against pool manager fraud, even than Eligius.

@Geremia Well, sure. If someone can control what address(es) you mine to, they can steal future mining payouts. It doesn't require compromising the mining server, just intercepting traffic.

Why do you say it "just [requires] intercepting traffic"? No traffic has to be intercepted when a single pool operator has full control over creating the generation transaction.

@Geremia Intercepting traffic is, generally speaking, easier than taking control of a server.


text:
Theoretical minimum # of logic operations to perform double iterated SHA256?
What is the theoretical minimum number of logical operations an ASIC needs to perform to compute double iterated SHA256, i.e., sha(sha(•))?

Is this the best way to phrase the question? It seems like you'd want to know 1) the number of gates required to implement it, and 2) how much it can be pipelined (probably quite a lot.)

SHA256D, which is what Bitcoin uses, is 128 rounds, comprising
768 additions,
640 ORs
896 XORs
And a bunch of bit shifts but bit shifts are free on an ASIC.

(source)

Those numbers don't seem correct. I count 522 additions across one iteration of SHA256, for example. (1044 across two) http://en.wikipedia.org/wiki/SHA-2#Pseudocode

...and I'm counting 600 additions for one SHA256 block: 48*3 + 64*7 + 8. Honestly I think this should be closed as off-topic and re-posted to http://crypto.stackexchange.com/ where you could attract the attention of a crypto expert.


text:
Is the Bitcoin rewards formula flawed?
This paper argues that

the bitcoin 4-year reward halving system very disturbing. We see
  absolutely no reason and no benefit of any kind to have this sort of
  mechanism built in a crypto currency. On the contrary, we claim that
  this mechanism is unnecessary and harmful. It somewhat discredits
  bitcoin as a stable currency which could be a reliable store of value.
  At the very least it can seriously limit a wider adoption of bitcoin.
  Therefore we propose to change it as soon as possible and propose a
  modified reward formula.

Is the "4-year reward halving system" flawed?

Do they also give supporting arguments or do they leave it at that assertion? Also, do they enlighten the valued reader what exactly they think is flawed about it? Please give us a bit more to go on, asking us to read a 48 page paper to get their point of view is a bit too much in order to properly answer your question. ;)

Section 13 starting on page 39 discusses the reward schedule.

From "The Unreasonable Fundamental Incertitudes Behind Bitcoin Mining" (page 40):
  With current bitcoin software [6, 7], at certain moments in time the reward for mining is divided by two in one single step. This is NOT compensated by the fact the the diffculty of mining increases all the time. It just adds sudden adjustments every 4 years to a diffculty curve which typically goes systematically up due to a steady increase in the production of new hashes. We predict that in the future the difficulty curve will have a discontinuity at the moment of the 4-year halving. Until now it has not happened because apparently only very small percentage of active mining devices were switched off on 29 November 2012.
  Inevitably, on one day many devices will stop being profitable and many people may lose their interest in bitcoin. We are talking about the human factor. Investors may decide that they are no longer going to give lots of money to a high-tech industry which has just decreased production of hashes per second and is binning many mining machines at a massive scale due to a strange rule which has no justification and could easily be modified. They might move their money elsewhere and invest in another cryptocurrency. Overall we expect that a sudden slump in profitability of mining is likely to provoke some sort of a much larger ripple in the bitcoin markets, potentially lasting up to 4 full years.

The paper appears to make the argument, that the miner compensation is already decreasing through the rising difficulty, and that the reward halvings will cause sudden drops in mining power which in turn will "provoke some sort of a much larger ripple in the bitcoin markets, potentially lasting up to 4 full years." As "people may lose their interest in bitcoin", when their devices stop being profitable. This is because "We are talking about the human factor.".
The presented argument is weak and thinly supported. While the taking effect of the reward halving is sudden, it is well-known and predictable years in advance within a reasonably small timeframe. Professional miners can easily plan their mining capacity and purchases to factor in the reward halving. There is likely to be a reduction in mining capacity, but it is not obvious, let alone inevitable, why the halving event should turn away people. Also, the mining equipment which will be obsoleted would mostly be comprised of less efficient older models, likely to present a smaller portion of the total mining power.
Further, it seems likely that corporate entities with a sufficient stake in Bitcoin would consider either some in-house mining or subsidy of global mining an acceptable cost to protect their previous investments by supporting the network, should the security of the network be in serious doubt.
Should Bitcoin become sufficiently pervasive, we might actually see Bitcoin mining financed as a public good, similar to other networks such as electricity and roads.
Conclusion: The paper does not comprehensively discuss potential effects of the halving, but rather asserts a specific scenario, which it supports unconvincingly.

That being said, a smooth reduction of the mining reward, or a flat mining reward would have had its merits.


text:
Non-Bitcoin Uses for Old ASIC Miners?
Can I use an old ASIC Bitcoin miner for other applications? For example, quickly reindexing the blockchain on my computer? Or quickly hashing every file on my hard-drive?
(I really wonder if the hard-drive could even supply the data to the miner fast enough, and the computer's CPU would probably have to be involved, translating the data for the miner, so that would be a bottleneck…)
(Note: My question differs from "Reusability of ASIC miners" because I am only asking about hashing-specific applications, not whether ASICs can do other mathematical operations.)

Fantastic question. Perhaps consider broadening to include Scrypt miners as well as Bitcoin SHA256 too? I'll flag a couple of the people I know who were designing these ASICs to get their input

ASICs hash the same data over and over with a slight modification looking for a hash with a low value. They're not general-purpose hashing machines.

Anything that makes ASICs suitable for applications other than the Specific Application the Integrated Circuit was designed for would probably slow it down or make it more power hungry or expensive.
One side effect they do have (along with anything else electronic) is that they convert 100% of the electricity into heat. So you could use them instead of an electric heater.
Note that heat pumps are actually more efficient, so it's not optimal. And in a lot of countries burning natural gas for heating is cheaper too.

authors: พิทักษ์ สุวรรณวงค์


text:
Do miners prefer RBF transactions over non-RBF transactions?
Given a replace-by-fee (RBF) transaction and a non-RBF transaction with equal fees, do miners prefer the RBF transaction over the non-RBF one? Or is this entirely up to the particular miner?

It is up to the miner, but typically they do not care whether it is RBF or not. There's no difference to the miner whether they choose one or the other; the miner still earns the same amount in transaction fees.


text:
When does Bitcoin Core allow you to "Abandon transaction"?
Right-clicking on an unconfirmed transaction pops up a contextual menu that has the option "Abandon transaction". It is usually grayed out. How much time needs to pass for Bitcoin Core to allow one to choose "Abandon transaction"?
When I run abandontransaction on my transaction, it says:

Transaction not eligible for abandonment (code -5)

From the source:
src/wallet/wallet.cpp:1290:
return wtx && !wtx->isAbandoned() && GetTxDepthInMainChain(*wtx) == 0 && !wtx->InMempool();

Basically, it's abandoned if it's dropped out of one's own node's mempool.

@MichaelFolkson Sure, the TXN could be in someone's mempool. (And technically a miner could mine the pre-RBF transaction…)

The last sentence would be more precise if it were something like: “it can be abandoned only if it has been dropped from your own node’s mempool”.

The option to abandon a transaction is only available if a) it has not been abandoned before, b) neither the transaction or a conflicting transaction is confirmed, and c) the transaction is not in your own node’s mempool.
Note that even when you abandon a transaction it might still be retained by other nodes. The only way to be sure that your original transaction cannot be mined in the future is to create a conflicting transaction that spends some of the same inputs and get it confirmed in the blockchain. This is exactly the intent behind abandontransaction. You inform your wallet that you are no longer pursuing confirmation for the abandoned transaction which instructs the wallet to permit reuse of the inputs used in it.

How do I drop the transaction from my own mempool in Bitcoin Core?

Hi @LOST, if you have a new question, please start a new topic.


text:
clDevicesNum returned error, no GPUs usable
I get this error with BFGMiner, when running "bfgminer -D -d?:"
 [2013-04-25 09:47:31] ft232r_scan: Found 093a:2510 - not a ft232r
 [2013-04-25 09:47:31] ft232r_scan: Found 1d6b:0002 - not a ft232r
 [2013-04-25 09:47:31] ft232r_scan: Found 1d6b:0002 - not a ft232r
 [2013-04-25 09:47:31] ft232r_scan: Found 8087:0020 - not a ft232r
 [2013-04-25 09:47:31] ft232r_scan: Found 8087:0020 - not a ft232r
 [2013-04-25 09:47:31] Started bfgminer 3.0.1
 [2013-04-25 09:47:31] Loaded configuration file /home/geremia/.bfgminer/bfgminer.conf
 [2013-04-25 09:47:31] CL Platform 0 vendor: Intel(R) Corporation
 [2013-04-25 09:47:31] CL Platform 0 name: Intel(R) OpenCL
 [2013-04-25 09:47:31] CL Platform 0 version: OpenCL 1.1 LINUX
 [2013-04-25 09:47:31] Error -1: Getting Device IDs (num)
 **[2013-04-25 09:47:31] clDevicesNum returned error, no GPUs usable**
 [2013-04-25 09:47:31] Not a ZTEX device 093a:2510
 [2013-04-25 09:47:31] Not a ZTEX device 1d6b:0002
 [2013-04-25 09:47:31] Not a ZTEX device 1d6b:0002
 [2013-04-25 09:47:31] Not a ZTEX device 8087:0020
 [2013-04-25 09:47:31] Not a ZTEX device 8087:0020
 [2013-04-25 09:47:31] Devices detected:
 [2013-04-25 09:47:31]   0. CPU 0  (driver: cpu)
 [2013-04-25 09:47:31]   1. CPU 1  (driver: cpu)
 [2013-04-25 09:47:31]   2. CPU 2  (driver: cpu)
 [2013-04-25 09:47:31]   3. CPU 3  (driver: cpu)
 4 devices listed
Here is my output of "lspci -nn | grep VGA":
00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [**8086:0046**] (rev 18)
Can I not mine with an Intel Integrated Graphics Controller? thanks

I solved this error by running cgminer as root.

Bitcoin mining is principally an integer maths task, not a graphics task.  It just so happens that the hundreds of processors found on modern graphics cards can sometimes be suitable for parallel calculation of the bitcoin task, at upwards of a hundred times the best available rate from four cpu calculations.
See wiki reports on bitcoin hardware for comparison figures.
Unfortunately for you, Intel copied some parts of modern GPU designs into their system on a chip, but to save money they left out some transistors here and there which might not get used in direct X 11 graphics but would be necessary for parallel calculations for bitcoin.
So, you have on-chip graphics suitable for screen display and a few other specifically graphics tasks, but you do not have a general purpose massively parallel GPU for bitcoin calculations.
The error message "clDevicesNum returned error, no GPUs usable" appears on one of my systems which does have a suitable graphics card for bitcoin mining and does find openCL drivers for it when configured before compile.  I'm trying to find out what is incorrect in my configuration.

Add --gpu-platform 1 to the start of the config line in order for it to ignore the Intel card.


text:
BTC/hashes/second rates for various pools
Do all pools have the same average BTC/hashes/second rates (for individual members of the pool)?
For example, this profitability calculator says 4 Th/s hash rates will produce 0.04 BTC per day, yet I've seen pools awarding 0.1 BTC every few days for 4 Th/s mining rates.

"Every few days"? Like, every 2.5 days?

This is an interesting question, but also a very difficult one to answer.
No, all pools don't pay exactly the same.
But looking at how much a pool paid out over a few days is pointless due to variance. Another mistake common with beginners is to try to find some magic ratio between your hashrate and the pool's hashrate that will let you earn more. In reality this ratio has zero influence on your earnings. I will try below to tell you what actually influences your mining income in the real world.
The best data currently available is probably the BTC Mining Pool List at Bitcointalk. Note that the profitability graphs at the bottom do not (at the time I write this) take into account pool fees, merged mining and rejected work (the last one being very individual).
Which pool is most profitable to mine for you depends on a lot of factors. I'd say there are two main influences on how profitable a pool will be for you: variance and expected average income.
Variance is determined by pool hashrate and reward system (PPS, DGM, others). The more variance the more luck will influence your profits. The variance tells you how far the income is likely to vary from the expected average over the short term.
Expected average income is determined by a lot of factors, which many miners probably don't realize:

Which ratio of rejected work are you getting? Some pools have a higher average reject ratio than other pools. On some pools your individual reject ratio may be especially low. Some pools artificially lower your reject ratio by paying rejected work. This is not actually an improvement. It means people with low reject ratio (good setup) are forced to give some of their income to people with high reject ratio (bad internet line, bad equipment).
What ratio of orphaned blocks does the pool have? (ignore for pps pools)
What's the average income from a block in the pool?  (ignore for pps pools) Some pools will have a higher income from transaction fees. Some pools keep the transaction fees and don't pay them out to miners.
How much of a bonus do you get from merged mining? This depends on which other coins are merged mined, their difficulty, their current value compared to bitcoin, in addition to all the factors listed here but for the merged coin (average income per block for the pool, orphan ratio for the merged coins, etc.)
What is the pool fee?

I don't include pool hopping in this list, since most Bitcoin mining pools are not vulnerable to pool hopping. Things may differ in the altcoin world.
There are some factors that are the same for all pools, like bitcoin difficulty, bitcoin value and your expenses, like electricity. Bitcoin mining calculators seem to cover these well, but they don't cover most of the factors above that are individual to each pool.
All of that being said, there's a lot of other reasons for picking a pool than a small difference in mining income.

Yes, all forms of mining including solo have the same effective output (though some with more variance than others). Some pools charge fees however.


text:
What does DOA stand for?
What does DOA stand for?
I've seen this in the context of P2Pool stales, specifically here.

Dead On Arrival. The term is referring to about valid shares your miner discovers that were found too late to be included in the P2Pool internal block chain and therefor aren't paid to the miner. Counter intuitively a DOA share can still be a valid Bitcoin block.


text:
Does having a pruned node reduce its network score?
My node's network score (revealed by getnetworkinfo) is very low (<75). Most of the time there are no peers with incoming connections connected to the node. Is this because I'm running a pruned node? Would that reduce the network score?

What's the meaning of the score in getnetworkinfo?
When you look up getnetworkinfo in the Bitcoin Developer Reference, it says about score:

The number of incoming connections during the uptime of this node that have used this address in their version message

If I understand that correctly, this means that the score is the number of times incoming connections have been established with your node since it started.
Network services and pruning
Nodes on the network announce the services they offer by setting their network services flags.
There are currently five flags in use:

NODE_NETWORK (1)
NODE_GETUTXOS (2)
NODE_BLOOM (4)
NODE_WITNESS (8)
NODE_XTHIN (16)

Out of these, NODE_NETWORK indicates that your node will serve historical blocks. Currently there is no way to announce that you can only serve a subset of all blocks, so just like nodes that cannot serve blocks at all, pruning nodes don't advertise NODE_NETWORK.
Pruning nodes don't get referred by DNS seeders
This has a direct effect on the number of incoming connections pruning nodes get, as DNS seeders only refer nodes that advertise NODE_NETWORK when new nodes request additional peers to connect to. This means that pruning nodes only get incoming connections when they are referred by non-DNS seeder nodes.


text:
What does Bitcoin Core's "Coin Control Features" do and how do I use it?
What is Bitcoin Core's "Coin Control Features"?
How do I use it, and what can I do with it?

From the "Yet another Coin Control Release [CLOSED]" BitcoinTalk thread:

What is coin control?
  When you send bitcoins to someone else, the bitcoin client chooses kinda randomly which of your addresses will send the coins. With coin control you can exactly choose, which of your addresses will be the sending addresses. And even more specific which of your unspent outputs will be the sending inputs.

This is in Bitcoin Core, now.

Any idea how to use coin control features using the JSON RPC commands?

@VivekTeega Not automatically. When constructing transactions from scratch on the command-line, you have to choose addresses and compute amounts all manually. See Mastering Bitcoin (1st ed.), § "Using Bitcoin Core’s JSON-RPC API from the Command Line", §§ "Creating, Signing, and Submitting Transactions Based on Unspent Outputs".

When making a payment, Bitcoin Core will automatically pick an input set to fund the transaction. The Coin Control feature allows the user to perform the input selection manually instead. Explicitly selecting the input set can boost privacy by preventing undesired address linkage and allows simple UTXO management tasks.


text:
Solo Mine with an AntMiner
How do I solo mine with an AntMiner?
AntMiners use cgminer, which certainly supports GBT, but when I use http://<my_local_net_ip>:8332/ and my bitcoind username and password for "Worker" and "Password," respectively, on the "Miner Configuration" tab of my AntMiner's page, the AntMiner says my "pool" is dead. bfgminer can connect, via RPC, to my local bitcoind "pool" just fine, so the issue is with AntMiner/cgminer.

Check your rpcallowip configuration, you will need to explicitly allow connections incoming to your RPC port from the network. If your local network for example is 192.168.0.x, the rpcallowip configuation in your bitcoin.conf will need to be 192.168.0.0/24 (this is CIDR notation).

You have run the BFGMiner on the local machine starting it as a Stratum proxy listening on port 3333 adn then point your AntMiner to it.
Run BFGminer on the same computer as Bitcoin Core with the following configuation, it won't need any further settings altered or configured (it gets the RPC password automatically on launch).
bfgminer --stratum-port=3333
BFGminer will launch, and retrieve the information needed for solo mining.
Now using coinbase address 1PkNBPBGEmvoMFbwRT5ky3XXVNstJnJ4c1, provided by pool 0
Network difficulty changed to 49.4G (353.6P)
Pool 0 http://localhost:8332/#getcbaddr#allblocks alive
Long-polling activated for http://localhost:8332/#getcbaddr#allblocks (getblocktemplate)
Added local bitcoin RPC server on port 8332 as pool 0
Probing for an alive pool
Pool 0 http://localhost:8332/#getcbaddr#allblocks alive

You're now ready to solo mine against Bitcoin Core, you just have to point your antminer at the IP address of the computer running BFGminer, and the miner should show up in the top section of BFGminer with its hashrate showing as "PXY" (stratum proxy). Any blocks will be paid out to the coinbase address shown in BFGminer, which is a new one generated from your wallet.


text:
Are loans with enforced repayment possible on the blockchain?
Are loans with interest possible in Bitcoin, such that repayment is enforceably encoded with Bitcoin Script on the blockchain from the establishment of the lending contract?

Script is employed to encode the rules under which a Transaction Output may be spent. E.g. the most common Script requires just proof of control over an address. Thusly, scripts cannot determine circumstances beyond a single transaction.
As a consequence, it appears to be infeasible to set up an enforceable credit contract with interest, because the loan repayment would lock in an amount of bitcoins greater than the loan. Evidently, the borrowing party doesn't have that amount of money to render unspendable at this time, or otherwise they wouldn't be borrowing in the first place.
Lending offchain is possible, but very fraud prone due to it being hard to enforce repayment. Also see: Why there's no bank or institution lending Bitcoins?

So, a script is only tied to one transaction? A script cannot make new transactions for covering interest?

Correct on both counts. Actually, each transaction encodes a set of rules for each Unspent Transaction Output to be fulfilled in order to access the money.

Sidechaining would enable enable a script to "make new transactions for covering interest," right?

I don't think so. I think it could be evaded by the borrower by just not ever moving any money back into the address of the contract.

But a contract on a sidechain could be used to move money back, within the sidechain, couldn't it?

@Geremia: Only if the money were under the control of the borrower in advance. Otherwise, how would he bind it in a contract? I'm not sure if I'm getting your objection, I pretty much explained the same above already. Could you perhaps specify your scenario in another question or describe it in your own answer?

What do you mean by "loans with interest"? If you mean guaranteeing being
payed back the principal plus some interest that is not possible since
that depends on the external world (i.e. it is offchain).
On the other hand, if you mean just creating repayment links for the agreed amounts it is just following the instructions of BIP21.

"that is not possible since that depends on the external world." A script couldn't schedule new transactions for covering interest?

It's absolutely possible to loan money with Bitcoin. FairShareLoans is a subreddit where money is automatically loaned out in ~20$ increments.
Collecting on those loans, on the other hand, is more difficult. https://www.reddit.com/r/FairShareLoans/comments/35vc5s/the_current_loansheet/ They appear to have a non-repayment rate of about ten percent.

I clarified my question to specify that I'm talking about collecting interests on loans within the blockchain.

These are on the blockchain.

@NickODell: The Repayment contract isn't is it?

@NickODell: A hash of the contact may be, but that isn't a use of the blockchain to ensure or force repayment. That's really what I'm asking.


text:
Do I need to keep all blocks when running Bitcoin Core?
Do I need to keep all blocks, from block 0 up to the current one, when running Bitcoin Core, either as a full node or not? Or can I just keep the more recent blocks to save space?

related: How can I run bitcoind in pruning mode?

Full nodes keep all blocks by default, but this is not necessary to achieve full node security. Full nodes validate the complete blockchain and enforce all consensus rules regardless of whether a full history is kept.
Keeping all blocks is a service to the network, as you'll be able to provide all blocks for synchronizing nodes or requests of thin clients.
If keeping the full blockchain is a problem, you can reduce the storage-footprint by running Bitcoin Core in pruning mode. Just add prune=<n> to your bitcoin.conf, where <n> is the amount of youngest blocks you want to keep in terms of mebibytes storage. The minimum is 550 MiB.

Can I just delete the older *.dat files in ~/.bitcoin manually, or do I need to be in pruning mode for it to handle that?

Will my transactions in pruned blocks still appear in Bitcoin-Qt's list of transactions?

@Geremia: You need to turn on pruning and let Core sort it out. Otherwise, Core will discover that there are files missing.

Yes. The chain-state database and UTXO set are kept intact and completely. As Core has validated the full blockchain, it knows about the old transactions and stores the relevant UTXO data. It will also keep all information related to its own addresses.

"it knows about the old transactions and stores the relevant UTXO data." That's stored in the chainstate directory (currently about 1.6 GB), right? So, I could technically delete the blocks directory; but if I want traction info, I have to keep the chainstate one?

I don't get what you're asking. If you want to reduce the storage-footprint, just start with pruning mode. You'll still need the blocks directory, as you'll keep at least 550 MiB. I haven't tried, but I'd expect Core to start redownloading all blocks if you just delete the directory manually.

"I haven't tried, but I'd expect Core to start redownloading all blocks if you just delete the directory manually." Yes, that's what happened when I tried it.

@Geremia: Thank you for your commitment to science. ;)

Yes, reproducibility seems lacking these days. ☺

This is called pruning.
From here:

Since Bitcoin-Core 0.11.0 you can prune (trim) the blockchain in
  Bitcoin-Qt. But not from the UI. You need to add -prune=550 to your
  bitcoin.conf file and restart Bitcoin-Qt.
Explanation: -prune=<target in MiB> will tell bitcoin-core to remove blocks which are older than oldest block that can be kept with
  a chainsize (sum of block-sizes) of <target> (min. 550MiB as example
  above shows). A minimum of 550MiB ensures to keep at least 288 blocks
  (~2 days).
  (simple explanation not including undo-data)
Restriction: -prune does disable all wallet functions in version 0.11 (will work with a wallet in version 0.12).

Obviously, as a full node you can't serve historical blocks you don't have, so you're more like a P2P leecher.


text:
Is it worthy to use "bitcoin usb block erupter"
I was searching for Mining hardware on internet and found that a new technology is available known as "bitcoin usb block erupter" for mining bitcoins as 300MH/S
I just want to know if it is useful to use these hardware instead of GPU mining and how to calculate breakeven point for them.
P.S. : I've searched google for many things but there were mixed responses that's why I asked this question here

go for high-end miners or buy mining shares through groupbuys. Please check bitcointalk.org forum. Beware of scams..

A typical USB block erupter will get 333MH/s under realistic conditions. Today, a share is worth about 1/156 of a penny and 333MH/s will get you a share every 13 seconds. That comes out to 43 cents per day per erupter, not counting the cost of electricity. Difficulty is going up, and thus profitability going down, around 25% per month. So you can figure maybe $11 your first month, $8 your next, $6 the next, then $5, and so on. You might get about $50 before it becomes more trouble than it's worth.

+1 Pretty realistic evaluation. Buying Block Erupters right now might break even over the next several months. Under ideal circumstances they might even make a few bucks. But with BFL cranking out monster ASICs it's becoming a big players game.

Sadly, it now looks like profitability is going down by much more than 25% per month.

I guess you could mine other coins with this though?

@Neurofluxation Other SHA256d coins, yes. But if any of those ever get more profitable than Bitcoin, the bigger buys running big ASICs move over too, crushing the profitability instantly.

For anyone coming across this and wondering if USB miners are still profitable. Try this site. But short answer is not anymore. Bitcoin mining has become a big game for big players. Rather invest in big group buys, or convert to scrypt.
Scrypt mining is mining alt-coins (Litecoin, Feathercoin, WorldCoin, etc). You cant scrypt mine with the Bitcoin Asic miners, but just saying that if you want to mine are about to buy hardware rather look into scrypt mining with GPU's.

what is scrypt?

@Terix https://litecoin.info/Scrypt

But there are other SHA512 coins, like namecoin, peercoin, devcoin, freicoin, terracoin.

@andremo SHA512? Namecoin is SHA256 http://en.wikipedia.org/wiki/Namecoin. Also how sure are you that a block erupter can do "SHA512".

Realizing I'm very tardy to this post, I'd like to throw out this update for those currently googling this question.
Background:
I purchased 4 erupters back in November 2013- just to run beside my 4x5970s and 3x7950s, it was an experiment and at the time I was pretty new to mining in general.
Usage:
4-erupters with 92mm cooling fan and powered-USB hub. I've had a constant 1.3-1.4Gh/s with these USB erupters, peaking at 2.2Gh/s (but that's an anomaly and not constant) I use bfgminer and set them up to run @bitminter. They're super easy to use once you get the drivers set up and understand how to mine. I chose mining @bitminter because it seamlessly allows you to mine namecoin through the same port/pool.
Don't use bitminter's flash miner if you want to mine alt coins with your gpus while going after bitcoin with the ASIC cards (it doesn't play nice if you have wallets running or cgminer working and you'll get a lot of rejects)- but by using a command line miner for sha-256, I can also run guiminer-scrypt or cgminer to hash out alt coins.
Conclusion:
So is it all worth it? Well.... No. With the 4 erupters running 24/7, @2.5W/ea I use about $0.02/USD of electricity while generating on average $0.12-$0.16 in bitcoin per day. In addition to the BTC, I generated about $0.03 in NMC. Altogether, a daily profit of about $0.15 per day USD.
Here's the breakdown as of today:
4xUSB erupters @$14.87/ea + $42.94 (USB Hub & Fan) + S&H = $106.16
Electricity (@$0.0616/kWH) $0.03/day x 98 days = $2.94
Total Expenditures: $109.10
BTC Generated: .03048521
NMC Generated: .09160374 (currently 0.00053247 BTC)
Based off of the current NMC exchange rate, my erupters have generated a total of 0.03101768-BTC in under 100 days.
At the current BTC/USD exchange rate of $578.86, I've been able to generate $17.96 USD. So after nearly 100 days of mining with the block erupters,
I'm sitting at <-$91.14>USD.
Good luck to those who still try the USB-ASIC route, I'll be mining DOGE and MINT with the cool kids :D

Pretty much the only real hope is bitcoin going up in price, that is what I'm basing my mining on.
Taking the assumption that it goes way up in price there are two options: 1) buy bitcoin, 2) but a miner. In the first instance you will have, 1x your money. In the second instance you will have the 1x plus you will still be generation more coins.
It is all really a gamble on bitcoin going up. If it goes down the in either instance there is a loss. I am prepared to loose all in the hopes that bitcoin will survive.
My guess: If bitcoin survives another year, and I think it will, it will be substantially more valuable,

I would have to say substatiantly it will become the revenue of the future making money obselete. It will make everyone able to live a possibly better life if it is controled bitcoin mining then it will boost our economy not endanger it. Actually soon their might be a transition from money to bitcoin and the profit margrine will go up which means everyone on the planet will be rich wich is better for everyone.

Spelling atrocities aside, the asker is asking specifically about one piece of mining hardware, not bitcoin mining in general.


text:
What happens when someone dies?
Who keeps the bitcoins?
If he didn't left to anyone his private key, will the bitcoins be lost forever and ever?

Obviously they are lost, unless the owner left and unencrypted copy of his wallet somewhere.

they are lost, the person will have to put the key in their will

@Lohoris A useful link, but not a duplicate.

Yes, those coins would be lost.  It would be as if you buried a chest of gold out in the middle of nowhere and died without telling anyone about it.
Though it is possible (though mindbendingly unlikely.  Even if bitcoin keeps existing until the heat death of the universe, it will almost certainly never happen.) for someone to randomly recreate the keypair for those coins and thus take possession of them.

There is a solution for that in the market right now. There are Digital Legacy platforms that keep your Digital Data safe while you are alive and transfer them to your assigned beneficiaries when you are gone. What I mean by Digital Data is all your information and belongings you have on the web, such as - accounts, passwords, docs, pics, contact list, insurances as well as your online currencies (Bitcoins and other type of coins). I am currently using a platform called PlannedDeparture. It allows me to store all the information I want and assign beneficiaries with instructions with what I want them to do with that information or data. For example to close down my facebook account or to claim the money from my online banking and my Bitcoins too. The platform check your activity on social media (you choose which one). If you do not appear to be active they will send an email to verifiers that you have again assigned, to verify your current situation. Once they have confirmed your situation, They will transfer all the data to your beneficiaries with instructions. It is a very user-friendly platform that allows you to store many information under many categories. Check it out at www.planneddeparture.com if you dont like it there are others that may suit your preferences better.


text:
Solo vs Pool mining for new crypto-currencies?
I have a not-so-good miner in terms of mining, like with CPU mining with LTC, it goes to 15 kHash/s which is pretty low.
I thought nor pool mining nor solo mining will earn me much when at this speed. But what if when mining other crypto-currencies like NVC, TRC or PPC? They have a lower difficulty level and probably would yield more in solo mining.
Simple question is that, if I want to mine them, what should I do, solo or pooled? and Why?
Also, how much time approximately will it take to mine one block of any of these at this speed?

Yielding literally "more" units of one currency compared with another isn't necessarily a good thing. Would you rather have 5 Japanese Yen or 5 US dollars?
The choice between mining solo or pooled is mainly one of variance; would you rather take a chance on trying to solve a block yourself, trying for a full block reward, or would you rather earn an amount roughly proportional to the work done (and probably pay a small fee for the privilege)? Unless you have a large amount of mining capacity, you may end up with nothing if you mine solo. Most people choose to pool mine for that reason.
You may find this question of interest, discussing solo mining vs pooled.
When it comes to time to solve a block, that's a completely different question, but this might help you. It will differ depending on the currency you choose (difficulty and perhaps hashpower will be different for each).

What you should depends on your particular situation.
The advantage of solo mining is that there is no fees, so all the credit goes to you, but if the difficulty changes before mining one block, then you've wasted recourses. (so you need to look at the average block mining time versus the expected difficulty-change-period of the currencies you're considering mining and see how much wasted mining you expect to do, with your mining rig, and if that is higher or lower then the pool fees)
On the other hand if the average block mining time is very small (a few seconds for some currencies sometimes like fastcoin and others) then there are going to be a lot of blocks solved during the time it takes to transfer and confirm the results, in which case the mining rig with the fastest internet connection to (wherever the results are transfered to) will have the biggest advantage (which most of the time (if not always) is the pool created by the creators of the coin).


text:
Is there any difference in pool mining with gash.io over slush?
I am new to the crypto-coin mining. If I am mining with my own hardware, is there any difference if I join slush or gash.io? Any difference in payment? There are lot of posts that says to stay away from gash.io because of the 51% share but currently they contribute around 34% only. Should we worry about that? The thing about that is more like if everyone started to mine using gash.io it will become centralized which looses out the decentralized nature of Bitcoin right?
Also, there is the CEX.io which provides GH/s for certain BTC. But since the difficulty increases over time, the GH/s value reduces. The GH/s will mine forever but wouldn't there be a time where that power cannot do any significant mining? Isn't the case with custom hardware too? Can you elaborate on that.

You actually ask three questions, I will try to answer them separately. But next time, please divide them into multiple questions.

Slush has a 2% fee, and GHash.IO has no fee. So that's a 2% difference for starters. There would be no difference in GH/s, because that solely depends on your hardware and tweaks. There is a difference of paying between the two, Slush uses Score, and GHash.IO uses PPLNS. An explanation from these two from here. You can choose whichever you like.

Score - Score based system: a proportional reward, but weighed by time submitted. Each submitted share is worth more in the function of time t since start of current round. For each share score is updated by: score += exp(t/C). This makes later shares worth much more than earlier shares, thus the miner's score quickly diminishes when they stop mining on the pool. Rewards are calculated proportionally to scores (and not to shares). (at slush's pool C=300 seconds, and every hour scores are normalized)
PPLNS - Pay Per Last N Shares. Similar to proportional, but instead of looking at the number of shares in the round, instead looks at the last N shares, regardless of round boundaries.

According to blockchain GHash.IO indeed has ±36% hashing power. But someone digged into the 'other' sources, and saw that some blocks came from IP-addresses owned by GHash.IO, but it doesn't mean that the block is indeed mined by GHash.IO. I think it is nothing to worry about for now, but GHash.IO shouldn't keep 51% of the hashrate for longer time. Then it indeed isn't decentralised, and the coin is vulnerable for a 51% attack.
I don't know how the CEX.IO works precisely, but you're right about the part the a certain amount of GH/s will return less BTC as the difficulty goes up. But as long as they upgrade the hardware, and get new equipment with a better GH/s/W ratio, it should still be profitable. If it isn't for a big company like them, it certainly isn't for individuals. They will stop, which makes the difficulty not increasing as much, and therefor new equipment will be more rewarding. If you mean that the GH/s you bought isn't worth it, you are right too. As the difficulty rises, the rewarded BTC is going down.

You said about the GH/s/W ratio. So that means my 1GH/s will mine same amount of BTC forever? Difficulty rise => less BTC but how does it compare to the GH/s/W?

No, it won't. But if the difficulty doubles, you'll need double the hash power to get the same amount of bitcoin. Because of the energy consumption increase this will result in a net loss. Therefore the GH/s/W should increase to stay profitable


text:
How to load bitcoin wallet from any wallet in regtest mode
I’m starting to code some stuff and need to get balance from wallets I generate using bitcoinjs-lib. When I hit my bitcoin server which is running in regtest mode it says that the wallet isn’t loaded or I need to specify the wallet on the jrpc request I’m making. Is there a way for the node to just return 0?
Are there better tools to help during development?
Thanks

Am I understanding right that you created a wallet with bitcoinjs, but you are trying to use Bitcoin Core’s wallet RPCs to get information on them? The Bitcoin Core wallet RPCs can only provide information on the Bitcoin Core wallet that is loaded. How would it know about a wallet that was created with bitcoinjs? To interact with wallets created by bitcoinjs, you should probably use bitcoinjs methods


text:
Why is Bitcoin defined as having 8 decimal places?
At the protocol level bitcoins don't actually exists, but rather base units (recently called “satoshis”). Bitcoins are defined as 108 base units, meaning that for a 50 BTC mining reward, you are actually earning 5 000 000 000 units.
So, why was 108 chosen as the value of one bitcoin relative to the base unit?

I think, 50 BTC mining reward, 10 minutes block confirmation time and 4 years reward halving were fixed first. 21 million bitcoins is just a result of those 3 parameters. 8 digit precision comes from gold ounce (XAU). End of mining (2140) is a result of this 8 digits precision. If you add 2 more digits, mining can continue another 24 years, or so..

When developing Bitcoin, Satoshi had already come with the idea that no more than 21 million of them will ever be made. However, there was an unsolved issue: how to accomodate all bitcoins in case it was actually used as a worldwide currency? Comparing to the current (2008?) world's M1 supply, it was determined that 8 decimal places was enough to cover the supply and still have the smallest division smaller than enough for daily usage.1
It's also worth noting that this decision means the total Bitcoin supply is approximately 250.89, which means it's smaller than the maximum value for a 64-bit integer (263-1), and smaller than the first integer that can't be exactly represented in a double-precision floating-point number (253 + 1), so that standard programming languages can deal with Bitcoin amounts without requiring custom implementations or dealing with overflowing.2

Ray Dillinger's response to: Why 1BTC should equal 10^8 satoshi ?
Satoshi’s Genius: Unexpected Ways in which Bitcoin Dodged Some Cryptographic Bullets

Additionally, the protocol can be easily extended to 16 decimal places with a hard fork.

Yes, but as far as I understand, this was planned in such a way that more decimal places would never be needed.

Also, more decimal places would break the Int64 and Double storages (see the second paragraph)

@ArturoTorresSánchez: "Never" is such a strong word. Whether it will be needed or not will depend on how Bitcoin is used. You can go up to 11 places within the confines of int64; double isn't really an issue since you shouldn't use double for exact amounts anyway; and in the future the cost of switching to int128 won't be prohibitive.

OK, I see your point.

@ZekeSonxx why 16 and not more? if you can do hard-forks, surely the new precision limit is arbitrary?

@JanusTroelsen read the comments above yours

The world GDP is $74 trillion footnote: a according to the World Bank in 2017. The max supply of Bitcoin with 108 base units is 2,100 trillion Satoshis.
If Bitcoin is to back the world's money, markets and real estate, not including debt nor derivatives, then the valuation of Bitcoin might be:
Global Stock Markets: $73 trillion
Global Broad Money: $90.4 trillion
Global Real Estate: $217 trillion
Total: $380.4 trillion footnote: b
With a $380.4 trillion economy and 2,100 trillion satoshis in existence there will be plenty to go around. Additionally, because of the scarcity model built into bitcoin (21 million max supply), we won't need additional bitcoins or more decimal places, the valuation of Bitcoin will naturally change with our economy.
I believe we will use Bitcoin as a form of digital gold to back other digital currencies and online marketplaces, allowing people and businesses to move credits from one online marketplace to another or from one currency to another.
a The $74 Trillion Global Economy in One Chart:
http://www.visualcapitalist.com/74-trillion-global-economy-one-chart/
b All of the World’s Money and Markets in One Visualization:
http://money.visualcapitalist.com/worlds-money-markets-one-visualization-2017/

Your argument assumes a $1=1 satoshi exchange rate

Dollar is not the smallest amount, but cent is. If world GDP is $74 trillion, that means we have 741E12 = 7.4E15, while bitcoin has 211E61E8 = 2.1E15.
That means we need to compare 7.4E15 and 2.1E15.

@PauliusK. I surmised that you replied to Travis rather than tried to provide a comprehensive answer. Since comments don't allow superscript, I've edited your comment to use scientific notation.


text:
How can I make GUIMiner use the CPU for mining?
I am trying to setup GUIMiner together with mining.bitcoin.cz. As I am working on a laptop with an Intel graphic card I am (probably?) unable to use GPU mining. So, just for a test, I tried to run GUIMiner without GPU support, that is as a CPU miner (if this is the correct word).
Clicking the start mining button doesn't seem to make anything run. I might be mistaken, but the lower right corner of the application keeps saying stopped.
The console tab says:

2013-04-03 17:51:51: Running command: poclbm.exe :@api2.bitcoin.cz:8332 --device=0 --platform=0 --verbose -r1`

But no error message, either.
So, I go to cmd.exe and copy poclbm.exe ***:***@api2.bitcoin.cz:8332 --device=0 --platform=0 --verbose -r1. This results in
No PyOpenCL
Not using OpenCL
Nothing to mine on, exiting

which can be taken as an error message. I believe that "OpenCL" indicates that the program wants to use a GPU (although) I am not sure. I just want to test the mining functionality and see if I can particiapte in the mining pool, at the moment without graphic card, only the CPU. Is this somehow possible?

If you start the bitcoin-qt client from the command line with the bitcoin-qt.exe -gen 1 command, then it will generate bitcoins using your CPU. Alternately, use cpuminer. (Builds)

I have started the bitcoin-qt how you stated it but guiminer still says it's stopped.

The solution I gave you doesn't involve guiminer at all, that's why it still says it's stopped.

But I wanted to involve guiminer.

The question was how to get GUIMiner to do the task.

Download the OpenCL drivers for the processor you have from the official links;
http://en.wikipedia.org/wiki/OpenCL#Drivers
I installed the OpenCL drivers for AMD and am now able to mine using my hex core AMD system CPU along with the GPU.   I installed the Intel OpenCL drivers inside of VMware fusion on my MacBook Pro and am able to mine using guiminer within VMware fusion in Windows 7.
For comparison,
I get 1Mh/s in VMware Fusion Win7 64BIT on my MacBook Pro Retina (early 2013) using the CPU.
I get 4.7Mh/s using GUIMiner inside OS X using the CPU and OpenCL.
I get 1.7Mh/s using GUIMiner and OpenCL for the CPU on my AMD X6 1045T.
I get 22Mh/s on my MacBook Pro using BitMinter and my GT 650-M GPU.
I get 17Mh/s on my AMD Win7 using GUIMiner and my nVidia 620 GPU.
I am a bit shocked that the 620 and 650 GPU results are so similar.

BitMinter's client might also just be slower.

Install Intel SDK for OpenCL* Applications. I'm gussing it's a framework for OpenCL. It worked for me.


text:
What is the number of transactions in a block?
What determines the number of transactions that can be validated in a block?

The absolute limit is the size of the block, which is currently hard-coded at 1,000,000 bytes.  Each transaction takes up a variable amount of space, but ~250 bytes is about right for a simple (one-input one-output) transaction.
However as soon as a block is solved it is not possible to extend the block by adding in more transactions, as the proof of work has to be redone, so broadcasting it immediately is the only sensible thing to do. So the number of transactions in a block is actually a function of the number of transactions being generated over a time period and the time taken to solve a given block.
Blocks used to contain fewer than 200 transactions and the largest number of transactions in a block was 1,976 at the time this answer was originally written (May 2013). In meanwhile (November 2017) the average number of transaction per block is well above 1500 with peaks above 2200.

If a block is solved you cannot add more transactions to it, as that would invalidate the proof-of-work you just created.

@jgm: Please consider editing your answer to better represent what happens after a block was found.

If blocks typically have around 2,000 transactions, and are only added every 10 minutes, isn't that an insanely low tx-volume?  Credit-card transactions number around 1/2 million per minute. Does this imply that bitcoin can never become a high-transaction currency?

@Abel many blocks can be solved simultaneously. It's a distributed system. But a single block takes 10 minutes by definition and enforced by the difficulty factor

The block size is limited to 1,000,000 bytes 4,000,000 weight units of data. Miners may arbitrarily decide from the available valid transactions which to include. The obvious selection policy would be to optimize for maximum fees collected in the block, for which a simple greedy approach would be to select by the fee rate of transactions, i.e. the amount of fee per data size of the transaction.
[April 2017:] Over roughly the past two months, the mean transaction size was about 506 bytes, and the average count of transactions per block was 1,956.
Current median and average virtual size for transactions can be found on transactionfee.info’s transaction size chart.

The average transaction is at least 250 bytes and the average block contains more than 500 transactions. Source: Mastering Bitcoin Chapter 7, page 164.
https://blockchain.info/de/charts/n-transactions-per-block

-1 Mastering Bitcoin is more than three years old and this information is severely outdated. Please don't give singular data points without providing a source to get current information.

Here is a plot of the 4-day mean for number of transactions per block, based on data from blockchain.com:

Over the last year, the mean number of transactions per block has been 2971 (4 sig fig), median 2993. Here's a plot of just the last year [now == March 2024]:


text:
Can someone explain nLockTime?
I'm having a hard time understanding how nLockTime works. The Bitcoin wiki has an explanation that is confusing to me:

nLockTime is a parameter that can be attached to a transaction, that mandates a minimal time (specified in either unix time or block height), that before this time, the transaction cannot be accepted into a block.

Can someone explain it in plain English, with an example?

The locktime is a transaction field that can be used to prevent a transaction from being included in the blockchain until some point in the future.
If every input’s sequence number is set to the maximum 0xffffffff, the locktime on the transaction is inactive. Regardless of the locktime value, the transaction can be included at any height.
If at least one sequence number in the transaction is 0xfffffffe (MAX-1) or lower, a transaction’s locktime will be enforced per the following consensus rules:
If the locktime is less than 500,000,000, the locktime is interpreted as a block height. The locktime defines the greatest block height that cannot include the transaction¹. The transaction may be included in any block with a greater block height than its locktime.
Example: A transaction¹ has a locktime of 800,000. The transaction is invalid until block 800,000 but may be included in block 800,001 or any later block.
If the locktime is at least 500,000,000, the locktime is interpreted as a Unix time (seconds since 00:00:00 UTC on 1 January 1970). A transaction may be included in a block if the MedianTimePast at the preceding block’s timestamp is greater than the locktime. The MedianTimePast refers to the median timestamp of the last eleven blocks.
Example: A transaction¹ has a locktime of 1,702,483,200 (i.e. 2023-12-13T16:00:00). Block 821023 (see table below) is the first block with a greater timestamp than this locktime, but only after a block is found where this timestamp is the median element of the most recent eleven blocks’ timestamps (including the new block), the transaction may be included in the following block. The considered transaction is valid for inclusion in block 821029 or later, as block 821023's timestamp is the median element of the timestamps from blocks 821018 through 821028 (both inclusive).

Height
Timestamp
MTP
May include Tx

821031
2023-12-13 17:45:16
2023-12-13 17:01:24
yes

821030
2023-12-13 17:35:38
2023-12-13 16:49:14
yes

821029
2023-12-13 17:35:24
2023-12-13 16:19:05
yes

821028
2023-12-13 17:33:46
2023-12-13 16:02:03
no

821027
2023-12-13 17:21:32
2023-12-13 15:56:00
no

821026
2023-12-13 17:01:24
2023-12-13 15:41:28
no

821025
2023-12-13 16:49:14
2023-12-13 15:29:58
no

821024
2023-12-13 16:19:05
2023-12-13 15:24:19
no

821023
2023-12-13 16:02:03
2023-12-13 15:18:50
no

821022
2023-12-13 15:56:00
2023-12-13 15:10:06
no

821021
2023-12-13 15:41:28
2023-12-13 15:04:59
no

821020
2023-12-13 15:29:58
2023-12-13 14:59:44
no

821019
2023-12-13 15:24:19
2023-12-13 14:51:59
no

821018
2023-12-13 15:18:50
2023-12-13 14:28:53
no

821017
2023-12-13 15:10:06
2023-12-13 14:25:51
no

821016
2023-12-13 15:04:59
2023-12-13 14:21:23
no

Since timestamps are only restricted to being greater than the MTP of the prior block and smaller than 2h into the future of the evaluating block’s network time, a sorted sequence of the timestamps may not necessarily have the same order as the corresponding blocks' heights.

¹A transaction is non-final if the locktime is active and not smaller than the current block height. From Bitcoin Core source code: src/consensus/tx_verify.cpp:17–37
bool IsFinalTx(const CTransaction &tx, int nBlockHeight, int64_t nBlockTime)
{
    if (tx.nLockTime == 0)
        return true;
    if ((int64_t)tx.nLockTime < ((int64_t)tx.nLockTime < LOCKTIME_THRESHOLD ? (int64_t)nBlockHeight : nBlockTime))
        return true;

    // Even if tx.nLockTime isn't satisfied by nBlockHeight/nBlockTime, a
    // transaction is still considered final if all inputs' nSequence ==
    // SEQUENCE_FINAL (0xffffffff), in which case nLockTime is ignored.
    //
    // Because of this behavior OP_CHECKLOCKTIMEVERIFY/CheckLockTime() will
    // also check that the spending input's nSequence != SEQUENCE_FINAL,
    // ensuring that an unsatisfied nLockTime value will actually cause
    // IsFinalTx() to return false here:
    for (const auto& txin : tx.vin) {
        if (!(txin.nSequence == CTxIn::SEQUENCE_FINAL))
            return false;
    }
    return true;
}

² As mentioned above, the example transactions must each have at least one sequence number lower than the maximum, or the locktime would not be active.

From the wiki it basically states that you can make a transaction to another bitcoin address and add nlocktime. The way that this would work in real life would be if you get paid on salary and are paid bi-weekly, the bitcoins will be on the network but won't reach you until the nlocktime is up
Edit: read example 1 from https://en.bitcoin.it/wiki/Contracts

"The bitcoins will be on the network" is false. nLockTime'd transactions are not kept in the mempools of miners nor are they relayed between miners, until the nLockTime has almost elapsed. It is your responsibility to keep the signed transaction and publish it when the time is right.

In order for the transaction to be final, i.e., not reversible, the transaction needs to be included in a block. The nLockTime parameter can be used to guarantee that the transaction cannot be mined prior to a certain block height or a certain unix time stamps. In other words, the protocol guarantees that a specific transaction cannot be finalized prior to a certain time.
Imagine that you deposit 1 BTC into a 2/2 multisignature account and you intend to use this to make incremental payments to some other party. One of the keys in the multisig account is held by you and another one is held by the other party. Each time you want to make a payment to the other party, you sign a transaction from the multisig to the other party and give the signature to them. The other party can then, at any time, choose to publish the transaction you just signed by adding their own signature and handing the transaction to miners, or they can wait to see if any more payments (i.e. signatures) come from you.
Before depositing the bitcoins to the multisig address, the other party should send you a signature of a transaction with nLockTime set to 1000 blocks in the future. This transaction transfers the entire deposit of 1 BTC back to you. If they do that, then you can always get your deposit back (after 1000 blocks) even if the other party for some reason dissapears or chooses to act destructively.
The parameter nLockTime makes it possible to create trust-free payment channels.

The payment channel I described here is the unidirectional payment channel that is explained in the first 10 minutes of this video:
https://www.youtube.com/watch?v=8zVzw912wPo

nLocktime is Time Locked Transaction, which means a transection cannot be verified until locked time passed.
you can take it as Future Date cheque (1st of next month) or Promise from friend to send you money next Monday. Now neither You receive funds or nor you can verify if funds are on the way until the time passed.
On Due Date might your cheque bounce or your friend make an ugly excuse. NLocktime allow double spending and Transaction with Nlocktime can't be verified by the nodes until time passed.
More Secure and trustless Time lock options are OP_CLTV and OP_CSV. They apply time lock on Script level, which means transection can be verified but script wont get verified until time passed.
This article helped me
https://medium.com/summa-technology/bitcoins-time-locks-27e0c362d7a1


text:
Why do outputs need to be spent entirely?
I understand what change is and how it works (and it's analogous to physical money change), but what I don't understand is why this is needed in the first place.
Given that this is all computer based, I thought that money could be sent just by saying “I will give you 0.5 BTC” and verifying that your addresses in fact contain more than 0.5 BTC, and then substracting the spent amount.
So, my question is, why does the protocol define that outputs must be spent entirely? Where's the benefit of doing that instead of just sending the fraction that is needed?

possible duplicate of How does change work in a bitcoin transaction?

In short, there are simply no "accounts". There are only unspent transactions that you have means to spent. And the system do not allow to spent transaction partially. Probably, to simplify internal logic (when verifying new transaction, you have to only check whether its inputs are valid, not go over whole blockchain looking for all transactions which spend money from every input).

I don't really consider it as a duplicate.

My question is more about why, not how.

It's in fact a little more advanced than you imagine it. (So expect this answer to be a bit more in-depth.)
There is no such thing as an accounts "balance". It only exists implicitly.
When people make transactions, they actually create outputs for a certain amount of bitcoins. Using a special script language, the person making the transaction can specify the requirement for spending that output. There's a whole range of options you have to specify this.
The most common output script is something that holds the following condition "to spend this transaction, the spender must sign this hash with the private key from this address". So this basically means that the owner of that address can spend it. This are the type of outputs that you will probably generate when you "send money to an address". They are called pay-to-pubkey-hash transactions.
Other possible output scripts can be stupid things like "anyone can spend this" to very complex things like "at least 3 of the private keys of the following 5 addresses must sign this hash", which is a so-called m-of-n transaction.
This brings us back to balances. When your wallet app says you have a balance of X btc, it just searches all unspent outputs that you are able to spend with your private keys; this are all pay-to-pubkey-hash transactions with one of your addresses in them.
Now, when you want to spend some of the money from your "balance" and send it to an address, you will need to make a transaction. The way transactions are created is as follows:

Take a number of unspent outputs from previous transactions and use them as inputs.
Make a new output of which the output amount is equal or less than the sum of all input values. Your wallet will most probably make this output a pay-to-pubkey-hash output to the address you wanted to send money to.
Because probably the inputs will not exactly match, you will add another output so that the sum of all new outputs is equal to the sum of the inputs. This output will also be a pay-to-pubkey-hash output to a new change address or to the same address as you are spending from (different wallet apps do this differently).
Note that if the total output amount is less than the total input amount, the difference is considered the transaction fee and this will go to the miner of the block your transaction will appear in.
Then lastly the wallet app has to prove it has the right to spend the inputs you used in the transaction. It can do this to provide an input script (technically it's called a scriptSig). For the common pay-to-pubkey-hash, this script will contain your public key and the signature you made with your private key. This input script is used by miners to verify if you have the right to make this transaction.
The transaction is then broadcast to the Bitcoin network.

After this transaction has been received by other clients and is verified by a miner, all clients will remove the outputs used in the transaction from their collection of "unspent outputs". So if you would try to spend it again, that won't be possible because miners will not accept it because the output you want to spend does not exist.
I hope you can understand that using this methodology, it is not possible to do a thing like "subtract the amount from person A's balance and add it to person B's balance". When making transactions, you basically destroy some outputs to generate new ones.

OK, so if I understand correctly, the script conditions are the ones requiring the whole output to be spent, right?

Well, not really. But it would just be very hard to allow partial spends. The current model only supports "spending a transaction" which implies that it's gone and can't be spend again. You could try to mimic partial spending by just adding a new output with the exact same script but a lower amount.

I see. Thanks for the very detailed answer. It's been very helpful.

Incredibly helpful - thank you for the clear explanation.

@Invader well, I think the original question just didn't understand outputs in general.

To me it does also not explain the why. I mean why should it not be possible to update balance of the output? Is it just because it is more beatiful to do it like that or is there a real reason?

@Invader There are two possible models, the UTXO model and the account model. Each has advantages and disadvantages. Bitcoin chose the UTXO model. XRP uses an account model. If you want, you can ask a separate question about the advantages and disadvantages of each model.

@David Schwartz: OK I open a new question. There is one quite similar question, but he/she asks not as generic as I do, so I think it's no duplicate and therefore ok. I'm looking forward to read your answer.
https://bitcoin.stackexchange.com/questions/74551/utxo-vs-account-model

@David Schwartz: Do you know an answer to WHY in the UTXO model you have to spend the entire utxo / WHY it is conceptualized this way? Do you think my answer here is correct?

@Invader That's how the UTXO model works. Transactions only consume UTXOs and create UTXOs. An UTXO either exists or it doesn't.

Minor correction. The input script technically is called scriptSig and not scriptPubKey. It is also known as unlocking script or witness. This should correspond to the locking condition of the input you are trying to spend which is technically called scriptPubKey or locking script or witness script.

Thanks for the correction, I just edited the post. This was written long before segregated witness existed, so there is of course no mentions of witnesses.

The original paper has this line, which I believe gets at why you have to spend outputs entirely.

It should be noted that fan-out, where a transaction depends on
  several transactions, and those transactions depend on many more, is
  not a problem here. There is never the need to extract a complete
  standalone copy of a transaction's history

If you didn't have to spend an output entirely, you would need to check every other transaction that also includes that output and make sure the sum wasn't more than it contained.
I'm not 100% certain why inputs and outputs were used rather than keeping balances directly. Ethereum and Ripple keep track of balances directly in the ledger. I suspect there are implementation pros and cons. The following answers list advantages to inputs/outputs. I'd be curious to hear an Ethereum dev's counterarguments to these.
Why does Bitcoin use the input/output system?
Why does Bitcoin store all transaction inputs and outputs, instead of just an "account/balance" ledger?

What does he mean with problem? Problem in regards to what?

@Invader: as in one does not need to worry about quasi-geometric growth (hence 'fan-out') in complexity of verifying transactions through a deep inspection of their history

As one of the people who made the decision to implement the XRP Ledger using accounts and balances, I can tell you that those answers explain how bitcoin implemented an input/output system but not why. I strongly suspect the reason bitcoin did so is that it's slightly simpler and there didn't seem to be any need for the significantly improved functionality that an account/balance system can provide. However, systems like ethereum and the XRP Ledger that use an account/balance system can do important things input/output systems really can't do.such as account management and delegation.

Outputs cannot be changed. They can only be created and spent. Since it is unlikely that you'll have the exact matching amount available when sending funds to a recipient, most transactions therefore need to send back change to the sender.
This ties into how transaction fees work: Miners can collect the difference between the input value and the output value as transaction fees. Thus, any funds not explicitly sent back to the sender become transaction fees.
Outputs are explicitly created by transactions and can then be uniquely tracked by means of their outpoint. The outpoint consists of txid:vout, i.e. the transaction hash of the transaction that created an output, concatenated by a colon with the position of the output in that transaction's output list.
Tracking outputs explicitly, e.g.

mitigates replay attacks and double-spend attacks (after confirmation)
makes it possible for multiple transactions from the same wallet to confirm in various orders, allowing for transactions to signal different priorities
allows updating of transactions
facilitates chaining transactions explicitly to each other (e.g. used for Lightning Network)
require little information for thin-clients to know about spendable funds
supports use of many unrelated addresses for better privacy

The main disadvantages of the UTXO-based design are that it is somewhat counter-intuitive compared to account-based designs, and that it requires more data to identify the spent funds.

That does not answer the question

@Invader: I don't understand why you think that. Since Bitcoin balances are stored in Unspent Transaction Outputs, and those can only be created and destroyed, but not changed, you can only spend UTXO in their entirety. I believe that my answer explains that (although I could probably explain it better by now).

The question is about the WHY. So the reason why it is designed that way. I guess to answer such a question somebody would have to point out pros and cons of different approaches.

@Invader: Thank you for your feedback. I've tried to improve my answer. What do you think?

I mean your answer is good, but I guess there is no real answer to this question, because we already have two approaches (UTXO and the account-model) and both seem to work. Maybe you can diviate slightly from UTXO and create another approach etc.. There are pros and cons to each method and Satoshi chose the UTXO design.

I'm not sure if this is true, but I want to help and so far I've seen no real answer to this question so far (the question is WHY) besides people say it is more beautiful this way.
- spv
By downloading the txs + merkleproofs + block-headers you know how much funds you have in case the full-node delivers you all your txs + merkleproofs + block-headers and of course given that you receive this from the longest chain.
When you would update the balance of an output in the memory of the node like this (somehow similar to an account-approach): balance_begin and balance_now (after the output was partly spend). The spv proof to know your balance would be much bigger, because it also needs to provide the txs + merkleproofs + block-headers that have spent parts of the output.
- privacy
Nobody knows if you spend the other output to pay for something else or if it is your change.
Can somebody confirm this or is what I'm writing simply not true?

You cannot update the balance of an output. Balances are only an abstraction to make Bitcoin wallet's easier to read for humans.

I did not say that UTXOs work this way. I brought an example with another approach to point of the benefits of the UTXO approach.


text:
Why is two hours the maximum acceptable offset for Bitcoin blocks?
As far as I understand, Bitcoin transactions include a timestamp, but the only requirement is that they don't differ for more than two hours.
But why two hours? For computers that are constantly synced via NTP, two hours seem like a very big difference. I would expect that a difference of 10 minutes should be enough.
Or, if this is about time zones and summer time, shouldn't they be using UTC time?

Transactions don't have a timestamp. Blocks have a timestamp. The difference is important, because the block timestamp on some of the blocks changes the difficulty.

Why is the maximum difference two hours?

It's not particularly important to have very accurate timestamps. Timestamps have two uses:

Difficulty retargeting
Calculating progress of synchronization. If the blockchain started in 2009, and the last block you saw was made in 2012, then you're about halfway done.

Or, if this is about time zones and summer time, shouldn't they be using UTC time?

They do. Of course, not all systems are set up correctly. For example, imagine a system that doesn't use NTP. The user doesn't know how to set up DST correctly, so they move their computer's clock forward/backward an hour every spring/fall.


text:
Could miners create a cartel to raise transaction fees?
Could miners with enough mining powers (say >95% of all blocks) form a cartel where they demand absurdly high transaction fees? Of course, I still could could hope for a miner not in that cartel to relay my transaction for a lower fee, but in that case I couldn't be sure when my transaction gets paid to the adressee.
Is this a plausible scenario?

Cartels are unstable due to members defecting for the economic benefit that comes from doing so.
See the Prisoner's dilemma.
Because miners are anonymous, the cartel would likely see defection immediately.

Good point that miners are anonymous. I hadn't thought of that.

Miners have huge investments in hardware that can only be used to mine Bitcoins. They have no incentive to do things that reduce the value and usability of Bitcoins. Any "mining cartel" with the power to get 95% of the hashing power to take collective action in non-emergency circumstances would create enough fears about 51% attacks and the like that it would drastically reduce the value of the Bitcoin system and greatly encourage competitors. So while this is theoretically possible, it's unlikely in the extreme.

The correct answer is yes, they can. And the claims about falling value in that scenario are borderline illiterate. Imagine they rise the fees, and you hold all your savings in BTC. What are you going to do? Sell? And who is going to buy? Some shady people for ridiculously low price to compensate for the risks. You will be locked within your “free” “decentralised” ecosystem with no one to intervene and no one to help. No courts, no government, no police.
But of course this won’t happen because miners are saint and will never harm another human being for profit. Right?
Etherium currently has a problem with insanely expensive gas. So? Is the cost falling down? No it isn’t.


text:
Is CheckSequenceVerify only a stop-gap measure?
The Lightning Paper v0.5.9.2 says that CSV "would permit further
abilities, including allowing a stop-gap solution before a more permanent
solution for resolving transaction malleability. A future version of this
paper will include proposed solutions."
This means that Thunder is still vulnerable to malleability attacks since it relies on CSV as a solution.
Since the Thunder readme does not mention malleability fixes as a TODO point, I guess the Thunder authors considers it fixed.
The cited Lightning draft is from January.

Transaction Malleability is fixed by Segregated Witness.

CSV is not a stop-gap solution. Before you can say that, you first need to define what the problem is.
CSV solves the problem that you can't use CLTV in contracts that need a spending delay where the output itself will not be broadcast for an unknown amount of time. This is a very abstract problem, but it does occur as a primitive inside more complex constructions.
However, the current Thunder implementation uses a stop-gap solution to transaction malleability, which just happens to rely on CSV.