text:
How to configure bitcoind in Arch Linux
Ok, well I've been watching the Bitcoin trend with some interest for several years. And I've finally decided to get involved myself. So yesterday and today I've been reading for several hours from the many resources in this question and this great answer. I read this blog post in its entirety and think I understood it completely. I understand that in order to pay someone or be paid in BTC, I need a bitcoin ID and that this goes hand-in-hand with getting a BTC "wallet". I understand that there are essentially two distinct options for my BTC wallet:

a locally-stored (on my computer) copy of the entire block chain
a remotely-stored (on someone else's computer) copy of the entire
    block chain that is encrypted with credentials such that only I have
    access to it (although Mt. Gox failure and so many others seem to
    show that this is less secure than the former)

I think a synonym for option 1 above is "cold-storage" although I'm not certain of that.
I realize that mining for BTC is a different thing altogether that is really only worthwhile with an ASIC or similar hardware, so I'm not at all interested in mining at this point. I just want to get myself an ID and wallet and understand Bitcoin well enough to be able to keep my own copy of the block chain on my local machine and keep it up-to-date. Maybe eventually I'll look into mining, but I'm not interested right now.
From Erik Voorhees blog post, I think I understand that if I want option 1 above (which I do as it seems more secure to me, and convenience is not at all important to me), then I need to install either bitcoind or bitcoin-qt. (I suppose that both of these are considered to be part of "Bitcoin Core" below?) This is reinforced by my review of the software tools I see at bitcoin.org:

Bitcoin Core:

Control over your money
Full validation
Complete transparency
Vulnerable environment
Improved privacy

whereas the best that any of the others for Linux there:

Electrum
mSIGNA
MultiBit
Armory
Green Address

can offer regarding transparency is "Basic Transparency".
I understand from this answer that although it's possible to have them both installed on the same system, one cannot have both bitcoind and bitcoin-qt running on the same system at the same time. So my question is about how to configure and get started running bitcoind in Arch Linux; but there are several specific issues I feel like I need to understand better.

Using bitcoind, at exactly what point will I be generating my ID? I guess it would have to be after I've completed downloading the entire block chain?
bitcoind.conf wants me to insert an in-the-clear, plaintext, unencrypted username and password into it that I guess bitcoind will read on startup. Exactly what will those credentials be used for by bitcoind? I know the options are named pretty transparently (rpcuser and rpcpassword) and the man page explains that they are  for JSON-RPC connections. But I have only one binary in my Arch bitcoin-daemon package (/usr/bin/bitcoind), so what client is connecting to my running instance of bitcoind using JSON-RPC connections?
Using bitcoind, at exactly what point will the software begin downloading a copy of the entire block chain? I know that's a big file and may take hours or days to complete.
If I want to interact with my locally-stored block chain after it is downloaded, then it seems that I must include at least one uncommented line in ~/.bitcoin/bitcoin.conf:
server=1

...but what will the simplest bitcoin.conf file that I need look like? For example, will I need to uncomment settings for any of these:
addnode=
connect=
maxconnections=
rpctimeout=
rpcssl=
rpcsslciphers=
rpcsslcertificatechainfile=
rpcsslprivatekeyfile=
keypool=
paytxfee=
min=
minimizetotray=

What are other people using for paytxfee, and aside from what bitcoin.conf says, ("Transactions with fees are more likely than free transactions to be included in generated blocks, so may be validated sooner."), why would I set this value to something other than 0.00 (and what is that number anyway? a percentage? so if I set it to 1.00 that is 1.00%)?

My main problem in understanding now is just connecting the specific settings in bitcoin.conf to my abstract understanding of how the Bitcoin network functions. I think I have a general understanding of the latter, but how to implement the specific concepts of the latter using the settings of the former is not at all obvious to me and after many hours of study, I don't see a clear explanation of it anywhere.
So I'm hoping someone here can shed some light on these issues. After all the questions I've seen on this site, I'm sure I can't be the only one wondering these things.
I considered breaking up this post into 5 or so separate posts and I hope the community will pardon my deciding not to do that. I see all of the several questions above as essentially pieces of the subject question: "How to configure bitcoind in Arch Linux". That's why I left it as one long post. Again, I beg the pardon of the community if that is regarded as a regrettable decision.

Still reading other questions after posting, I ran across this one. But when I do that, I see the following: "Error: There is no RPC client functionality in bitcoind anymore. Use the bitcoin-cli utility instead." But I have no bitcoin-cli binary from my having installed the bitcoin-daemon package in Arch.

The maintainer of the Arch Bitcoin packages, Timothy Redaelli, appears to have split what you need across bitcoin-daemon and bitcoin-cli, and I can't figure out why.

And, honestly, it would have been better to split this into multiple questions. As it is, I'm not really sure where to start.

After reading this, it appears to be the case that this split is present upstream.

Also, it isn't necessary to list all of the things you do understand when asking a question about something you don't understand. Try to be as brief as possible and as detailed as necessary.

@NickODell in addition to the official upstream page I referred to above, I just wanted to point out an answer on this SE site that also shows your comment above (about Timothy Redaelli having split Bitcoin Core into bitcoin-daemon and bitcoin-cli packages) to be misleading. I didn't realize before today that bitcoind could previously (before v0.9) be run as either server or client, but since v0.10, bitcoind is the RPC server only, and bitcoin-cli is the RPC client only.

@02019 upstream split them into different binaries, sure. But to my knowledge, they never recommended that package creators package them separately. If the answer you linked shows my comment to be misleading, I'm afraid I don't understand how.

Although I think it's too early to tell for sure, it appears that I now have a good deal more informative reading that I've found here. I suspect that these documents will eventually help me understand the correct answers to all my questions above. I hadn't realized that my questions were essentially developer questions before now.
I'd still enjoy seeing more user-oriented documentation that would help me understand my questions, so if anyone has any thoughts to share, I'd still welcome them. I do not by any means consider this to be a definitive answer to my several questions above.
UPDATE:
These words (though currently not quite complete as they do not mention bitcoin-cli): "There are two variations of the original bitcoin program available; one with a graphical user interface (usually referred to as just “Bitcoin” [or bitcoin-qt]), and a 'headless' version (called bitcoind). They are completely compatible with each other, and take the same command-line arguments, read the same configuration file, and read and write the same data files. You can run one copy of either Bitcoin [aka bitcoin-qt] or bitcoind on your system at a time (if you accidently try to launch another, the copy will let you know that Bitcoin or bitcoind is already running and will exit)." from this page were also extremely helpful to me. They helped me see that to get started, I don't even need to worry about the settings in the bitcoin.conf config file. I can install both bitcoin-qt and bitcoind, start up with bitcoin-qt initially, and then shut it down later in favor of bitcoind.
So for Arch Linux at least, I now think it's best to install all three packages:

bitcoind
bitcoin-cli
bitcoin-qt

And these are all part of the upstream software called Bitcoin Core used for complete transparency and a wallet stored locally (arguably the best security) on my computer rather than on someone else's computer.
But one really valuable tip I just discovered a few minutes ago is that there's a fairly recent copy of the (21 GB) entire block chain available as a torrent file. And in light of that discovery, it's clear to me that to get started as quickly as possible with a local wallet, I should completely download this torrent of the block chain first. And then and only THEN should I fire up bitcoind or bitcoin-qt to have that 21GB block chain validated or verified or whatever the correct term is for that. This saves me download time and it saves the Bitcoin network bandwidth from direct downloads via bitcoind or bitcoin-qt.
UPDATE2:
I wrote a detailed procedure for this in the Arch Linux Bitcoin wiki page that I've reproduced below to improve this answer.

Verify at least 80GB (22GB * 3 copies + 14GB worth of additional blocks via bitcoind/bitcoin-qt) of free disk space is available
Install gnupg, deluge, bitcoin-qt, bitcoin-daemon, and bitcoin-cli from the official repositories
Using a browser, download README.txt, bootstrap.dat.torrent, bootstrap.dat.torrent.gpg, and bootstrap.txt
Using gnupg, verify the downloaded files as having good signatures (you'll need to first import the signer's public key ID A2DB9CCA)
Using deluge, download the 22GB bootstrap.dat (perhaps hours depending on your download data rate)
When bootstrap.dat download is complete:

leave deluge running until seeding is complete (optional but it helps the community; may require hours or days depending on your upload data rate)
copy (don't move or you'll interrupt seeding) bootstrap.dat to ~/.bitcoin (don't use a symbolic link as this file will get renamed by bitcoin-qt after it is fully imported, and that too will interrupt seeding)

start bitcoind for background import or bitcoin-qt for import with feedback on progress
bitcoin-qt begins importing the block chain from bootstrap.dat, giving visual and text feedback as to import progress ("Importing from disk..." and eg. "4 years and 24 weeks behind", etc.; this import from disk may require more than one hour)
the import process duplicates the 22GB bootstrap.dat file into ~/.bitcoin/blocks/, thus roughly doubling the size of ~/.bitcoin from 22GB before starting Bitcoin Core to 44GB after import is complete.
After import from disk is complete

bitcoin-qt will show "Synchronizing with network..." and eg. "22 weeks behind..." (a wired network connection here will speed this part of the process but several hours to complete synchronization with network is typical)
the bootstrap.dat file gets renamed to bootstrap.dat.old
it should now be safe to remove bootstrap.dat.old from ~/.bitcoin, but a cautious approach would be to wait until your locally stored block chain is fully synchronized with the network

quit bitcoin-qt
then remove ~/.bitcoin/bootstrap.dat.old
After bitcoin-qt indicates that the local copy of the block chain is fully synchronized with the network (~/.bitcoin/blocks filled 34GB in Feb 02015, then consider quitting bitcoin-qt and do either one of the following:

start bitcoind to keep the block chain synchronized; feedback as to block chain status can then be had using bitcoin-cli without the additional memory required of bitcoin-qt.
restart bitcoin-qt running as a minimized window ($ bitcoin-qt -min). Note however that some people have found this commandline argument does not work as advertised.

Consider making a backup of your wallet.dat file using bitcoin-qt.
See the official Bitcoin wiki for additional guidance.


text:
Ubuntu bitcoin PPA
Since bitcoin is a software package that involves "real" money (inasmuch as any currency is "real"), I know there are major incentives for unscrupulous people to build backdoors into software related to bitcoin. For example, consider the current warning in IRC#bitcoin: "...All keys generated with brainwallet.org should be considered compromised" (a backdoor was apparently built into that software though I don't have specific details).
So as I consider building a second bitcoin node for myself (my first was in Arch using an official package), this time in Linux Mint 17.1 (based on Ubuntu 14.04) using an unofficial bitcoin PPA, I'm taking careful note of the warning that I usually dismiss without much of a second thought for using Debian/Ubuntu/Mint PPAs: "You can update your system with unsupported packages from this untrusted PPA by adding ppa:bitcoin/bitcoin to your system's Software Sources." (emphasis not in original)
And so before I use this PPA myself, I thought I would ask here if anyone else has used this PPA (that was only recently revised by Matt Corallo on 2015-02-18), and if you found any specific problems with it?
As I think about using it myself, I wonder if I should look at the MD5 checksum and/or diff of the source files used in the PPA as compared with those of the original Bitcoin Core sources. I don't know; maybe that's being too paranoid, but I'm wondering if others have used this PPA and if so, if they compared it with the original upstream sources.
I considered asking this question at https://askubuntu.com/, but I think it's better suited to this Q/A community because it's less about Ubuntu (I think this PPA could be used in many different distros that are all based on Ubuntu like my Mint distro) and more about Bitcoin.

Any particular reason you don't want to build the binary yourself using the github source?

Matt Corallo is one of the top contributors of Bitcoin, so if he's the one that maintains the Bitcoin PPA, I would count that as a positive signal. ;)

@jimmysong that's a great question, and I am considering it, but from a software maintenance perspective, I've found that every time I do something like that, I end up regretting it months later because I have a lot more work to do when I want to upgrade to the next release. I may end up doing that in spite of that logic because as I wrote above, bitcoin is special. I'm still on the fence, honestly.

@Murch I didn't realize that. Thanks for mentioning it. Matt, if you're reading, no offense intended with my question. Just trying to be duly diligent is all. :)

Yikes. I'd heard rumours about brainwallet.org using a compromised key generator. Have we got a link to any of the discussions?

https://bitcoin.org/en/download has binaries you can download and verify.
They're probably the safest to use, apart from building from source.
Building bitcoin from source also has become a lot easier with the past releases, I've had similar horrors as you with building other software from source and upgrading, but looking at how it has evolved for bitcoin I'd say the future looks bright.
PS. That PPA is also recommended on https://bitcoin.org/en/download and I've used it in the past, without any problems, though I can't say anything about how safe it is, but like @Murch pointed out he's at least not a completely random person but someone who worked a lot on bitcoin core.

It's been some years since the original question was asked, so I thought it's useful to point out that building from source is a lot easier nowadays.  One can simply use Docker and not worry about bungling something on your system.
Most Docker solutions I've seen use the Ubuntu PPA because it's much faster.  Building from source seems slower in Docker, on a Mac at least (and possibly Windows).  I expect it would be much faster on Linux.
In any case, I put together a Dockerfile following the official Bitcoin Core install guide.  It also is careful to git clone the latest release version.
https://github.com/chanhosuh/docker-bitcoin

source: Stack Exchange

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

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

sort: votes


text:
Parsing a SegWit transaction, what are stack items in witness data
For every input we can have multiple stack items, what do these represent?
As a reference this question is helpful
Are these defined here?
For eg. P2WPKH would have a signature followed by a pubkey, (so two stack items)

BIP141 defines requirements for witness stacks as follows:

In P2WPKH, the witness stack must consist of exactly 2 items (signature and public key).
In P2WSH, the witness stack must have at least one item (witness script), while the remaining items are used as the initial stack for script execution.

Are you sure there is a check (requirement) for P2WPKH that exactly 2 elements are in the witness data? Pieter Wuille did not mention that requirement for P2WPKH in his answer.

Yes. From the specification: "The witness must consist of exactly 2 items (≤ 520 bytes each). The first one a signature, and the second one a public key."

In his answer, Pieter interprets P2WPKH as a P2PKH script with the witness stack as the initial stack, with the requirement that the resulting stack must have exactly one element. That implicitly requires that the witness stack has exactly two elements, because any other length will either fail the script or result in more than one item on the resulting stack.

Yes, I completely agree with you that there is an implicit check if 2 items are in witness data, because if it is not, the script will not pass. We did not understand. I meant whether there is an explicit check, like for example: witness_data.count == 2. Something similar to how P2WSH has a check to see if the witness data is empty.

That depends on the implementation, as there are multiple equivalent ways of implementing the specification given in BIP141. Specifically, Bitcoin Core has an explicit check that the stack size is 2 and then feeds it into a P2PKH script.

So there is an explicit check. I guess that should be added to Pieter's answer.

I proposed an edit that includes this check.

Pieter's answer already requires that the resulting stack has exactly one element, so a requirement that the initial stack has exactly two elements is redundant. Again, there are multiple algorithms that equivalently implement the specification.

Yes, I absolutely agree that Pieter by that implicitly said that there must be exactly 2 elements, however, I don't think it's bad to state it explicitly since such an explicit check exists. I also agree that there are several different ways to properly implement the spec, but I think we should only look at the referent, which is bitcoin core. However, in the end, whether it's an implicit check (the script simply won't work if there's a different number of elements than 2) or an explicit one, or both (case in bitcoin core), it boils down to the same thing in this case.

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


text:
Bitcoin Core keeps crashing
I have Bitcoin Core v0.11.0 installed on a machine that's running Windows XP.  After waiting several days to completely synchronize, I decided to update the bincoin.conf file.  I didn't see one where it was supposed to be, so I created a new file that had nothing but the following line it it.
txindex = 1
I saved the file in the appropriate directory and restarted Bitcoin.  Upon starting, it basically said that I had to start synchronizing from scratch (it said I was over 6 years behind).  It then crashed.
Finally, I decided to get things back to the way they were before.  I simply deleted the bitcoin.conf file that I had created, thinking that everything would go back to normal.  It didn't.  Now the program crashes every time I try to start it.  A window pops up that says
"Bitcoin Core (GUI node for Bitcoin) has encountered a problem and needs to close.  We are sorry for the inconvenience."
So what do I do now?  How do I get Bitcoin Core to stop crashing?
Thanks for your time.
%%%% UPDATE %%%%%%%%%%
As for the debug log, the first line to show an error is the following:
2015-10-30 02:56:56 Error: Couldn't open socket for incoming connections (socket returned error An address incompatible with the requested protocol was used.  (10047))
I've tried saving the bitcoin folder (the one that has the huge blockchain) as a backup and then re-installing The entire program.  After re-installation, if I let it create its own new "Bitcoin" folder, everything is fine.  Then when I try to put the blockchain folders inside the bitcoin folder, that it created, I get the error message.
I hope re-installation wasn't a mistake.  I have the blockchain.  I'd hate to have to re-acquire the whole thing again.
Either way, I really appreciate your speedy responses.  That's excellent!

Bug reports go to https://github.com/bitcoin/bitcoin/issues

When you enable txindex it has to create that index by going through the entire history starting 6 years ago. So at least that part makes sense.

Can you post the last few lines of debug.log after a crash to find out what it's barfing on?

As for the debug log, the first line to show an error is the following:
2015-10-30 02:56:56 Error: Couldn't open socket for incoming connections (socket returned error An address incompatible with the requested protocol was used. (10047))

I used to work at Microsoft - testing code - good luck with that - you will likely NEVER get it stable as to the machine you described - it is just too CPU and swap intensive because the XP platform cannot handle the memory the program will actually need and the hard drive - assuming you are NOT running SSD hardware - will never hold up for long

While this may be sound advice, it doesn't really answer the question about what's causing the crash in this specific case :)


text:
A "Hello World" of bitcoin?
I would like to write a very simple program in bitcoin. I thought a simple C program that accepts the mined blocks would be appropriate. So I assume, the program would open a socket connection to some fixed relay node and start accepting the blocks. Could someone show how it could be done. Thank you.
[Edit:] I have since discovered what is probably best suited for the purpose. There is a minimal bitcoin networking stack implemented in python by Dr Christian Decker of ETH Zurich. It was used to gather results for some highly cited research papers on the bitcoin network but at the same time it is extremely readable too.

The easiest way if you come from web development and or you want to put a system in production is to use the most stable and updated implementation/API of Bitcoin Core
note: after downloading it it's best practice to check the md5/sha of the file you downloaded on bitcoin.org to be sure your installer is genuine

1) Install Bitcoin Core
2) Use it's CLI or JSON rpc APIs: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
there's no step 3!

This in the case your target is to run an app connected to most of the updated nodes, have the latest code with security fixes to at least sign and broadcast transactions, and obviously, query the blockchain!
glhf

You should looks at the existing C implementations (SPV node, incomplete):

https://github.com/jgarzik/picocoin
https://github.com/bit-c/bitc

Thank you for that information. Something even better would be just 40-50 lines of code doing some basic thing, like accepting blocks or smthn like that.

Accepting blocks means validating them, which is a huge amount of work and must be bit-for-bit identical with Bitcoin Core. It's not possible with a small codebase, or at least not for now until libbitcoinconcensus is stable.

Whilst not C, libbitcoin is written in C++ and is a full implementation. It should let you do everything.
If you're not limited to C, bitpay has a very straightforward p2p library here: https://github.com/bitpay/bitcore-p2p
I do not accept the answer of using the RPC, since you have to use a whole other 30mb application just to get your data, and it's not a great start for a scalable application or learning the inner workings of the network.

Depends on the area. In any case i suggest you to only use test network to avoid losing funds.
If you are interested about the crypto stuff, study how to turn random number  into wallet address, or how signatures are made.
https://github.com/keeshux/basic-blockchain-programming


text:
Is the whole idea of proof of work or proof of stake quite unnecessary and superfluous for cyptocurrencies?
I only have a vague idea of proof of stake, but I think I reasonably understand proof of work. In the case of bitcoin, the whole hash thing business has to be combined with a mechanism to increase the difficulty according a certain time calculation. Now this difficulty/time calculation is merely a matter of good faith, and hope that a majority abides by it. If you look a bit deeper, the whole hash function itself relies on good faith, also called the 51% risk/attack whatever.
And hence you have currencies like ripple, which are just faith (maybe one degree higher compared to bitcoin and ethereum) as far as I can see, without any hash or other garnishing. This does seem to be equally functional. So did Satoshi over-design bitcoin? Does this suggest that a whole new generation of minimalistic cryptos will completely sweep away bitcoin, ethereum and the likes?

Can you explain what you mean by "time calculation is merely a matter of good faith"? What makes you think that it is a matter of good faith?

@AndrewChow Well, it is a matter of faith, in that it relies on the gaurd against the 51% attack to safeguard it. If people say, well, let us increase the difficulty a lot slower, then it assumes that more than 50% of the network will say no. Please contrast what I say with Ripple. Bitcoin is just fine. I am just curious whether it is over-designed.

Can you elaborate some of your statements a bit?

Now this time calculation is merely a matter of good faith, and hope that a majority abides by it.

When you have a look here you will see that the average block times is 9m 4s. Not too far away from the ten minutes the protocol tries to enforce.

If you look a bit deeper, the whole hash function itself relies on good faith, also called the 51% risk/attack whatever.

Why does the hash function rely on good faith?
You're example ripple is in no means a replacement for bitcoin or ethereum. It is a completely centralised currency / system. We could use SWIFT banking instead.

My understanding is that Ripple is presently centralized, largely for business reasons, but that its protocol works equally well in a decentralized setting. On the time calculation, yes I agree the majority has acted in good faith and kept to the original intentions. But one could reason 'if you are gonna have faith anway, why not have it all the way'. That seems to be the basic philosophy behind ripple and the likes. In the case of bitcoin, the protocol assumes that the majority of the participants will be honest in judging the first successful hash solution

In the bitcoin protocol it is not only necessary that the majority of the nodes are dishonest but they must also work together. Otherwise the honest network will still be larger. There's no reason to act dishonestly if you're not part of a group capable of controlling 51 % of the network. You will just burn electricity. IMHO it is safe to say that the majority would rather act honestly and eventually get a reward than act dishonestly just to try to disrupt the network.


text:
Why are arithmetic script opcodes limited to 4 byte operands?
The Bitcoin wiki script page says that:

Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.
If any input value for any of these commands is longer than 4 bytes, the script must abort and fail.

Does anyone know the reason behind this limitation? Why are arithmetic opcodes limited to 4 bytes?

From the source code:

Numeric opcodes (OP_1ADD, etc) are restricted to operating on 4-byte integers. The semantics are subtle, though: operands must be in the range [-2^31 +1...2^31 -1], but results may overflow (and are valid as long as they are not used in a subsequent numeric operation). CScriptNum enforces those semantics by storing results as an int64 and allowing out-of-range values to be returned as a vector of bytes but throwing an exception if arithmetic is done or the result is interpreted as an integer.

This does not explain why overflowing is allowed, but I guess this has to do with preventing errors (say, 3 billion + 3 billion resulting in a negative number).
As for the 4 byte limitation, I assume this is for safety. If there was no limitation, then because CScriptNum stores numbers as signed int64_t values, overflowing that limit (not the stack item overflow described in the previous paragraph) would result in undefined behavior according to the C standard. This is bad practice in general, but very bad in consensus-critical code. Most nodes run x86 Intel processors, but could you imagine how deeply in trouble we would be if a transaction was valid on Raspberry Pi based nodes and invalid on miner nodes, or valid locally on your smartphone and not on the network? All kinds of bad stuff would happen: hard forks, double spends, you name it.
You could also have problems with very large numbers being added to increase their size past the 520 byte push limit, then hashed repeatedly to consume as much CPU time as possible, resulting in a DoS attack.


text:
Does block validation get more difficult as the blockchain grows?
I just downloaded Bitcoin 0.5 and started downloading the blockchain from scratch. The process was rather fast early on but slowed down noticeably later. That could of course be related to network conditions (or I could be mistaken altogether), but it got me thinking if the cost of block validation (which apparently is the driving factor in determining how long importing new blocks takes) somehow depends on the length of the chain before it?

Validating hashes and signatures for transactions is the most costly process. So the amount of time it takes for CPU to verify a block depends on number of transactions in the block.
Number of transactions per block tends to increase as bitcoin economy grows, therefore it takes longer to verify more recent blocks.

+1 Is it just the cryptography or is there also the cost of tracking down the ancestry of the transactions in the block (to see if the amounts are valid)? But I suppose that there a single step back would be sufficient, since any previous blocks have already been validated.

Thilo: exactly, it must a) verify syntactic integrity of the transactions b) find the previous outputs it references (one level deep) c) verify those previous outputs haven't been spent d) verify the signatures. b) and c) require disk seeks, d) requires CPU

Is step c) dependent on the age of the previous output (i.e. the block chain length) because a sequential search takes place or does the Bitcoin client maintain an index of spent outputs?

There are just more transactions per block. The cost of verifying a block doesn't depend on previous blocks at all.


text:
How can I control which coins to spend in a transaction?
When creating a bitcoin transaction, you have to choose which coins to use in them. The standard client does this in a way to avoid unconfirmed inputs and minimize the number of inputs and amount of change involved. Since not all coins are created equal, I may have other preferences (like spend unconfirmed coins first to get rid of them, or not cross inputs between different trading partners). Is there any way I can have more control over the process?

I suppose a workaround/partial solution is to use multiple wallets. Then you can keep coins apart, but also cannot make "large" spends.

related: What does Bitcoin Core's "Coin Control Features" do and how do I use it?

Currently this is not possible with the standard client, other than making separate wallets. There is a patch for coin selection on github, which was very promising. So this feature may make it into a future version.

This answer is outdated. Bitcoin Core has had a Coin Control feature for more than five years which allows manual input selection.

Old question, so answers are outdated. Anyone reading this now: bitcoin-qt has coin control features that let you choose whichever txin you want to use.

Check out Armory, a new client that

uses an algorithm for coin selection which can be optimized for
  anonymity or minimal transaction fees.

armory looks pretty awesome. still pre-alpha though.


text:
Bitcoin Client says transaction is unconfirmed for 2 days now

Possible Duplicate:
How to debug a long “0/unconfirmed” status in the bitcoin client?

I made a transaction two days ago, but blockexplorer.com doesn't show the recipient address.
Also there are zero confirmations yet and I start wondering if something went wrong.
2 days and my transaction does not show up in a block. Also I'm not able to resend the coins to give it another try.
Thanks in advance guys.

okay, it seems like I only had to ask this question. Just 5 mins. later transaction was confirmed one time!

Was the client running the whole time? Maybe you posted the transaction and then closed the client before it had a chance to broadcast it.

Bitcoin Charts is a great place to check and see if your transaction is out there.  It displays unconfirmed transactions that have been broadcast to the network.  If a transaction does not show there, then running bitcoin with the -rescan option should fix things up.


text:
How does a range proof bound lower at 0 and not -1?
From the confidential transactions article:

C' = C - 1H Then I provide a ring signature over {C, C’}.
If C was a commitment to 1 then I do not know its discrete log, but C’
  becomes a commitment to 0 and I do know its discrete log (just the
  blinding factor). If C was a commitment to 0 I know its discrete log,
  and I don’t for C’. If it was a commitment to any other amount, none
  of the result will be zero and I won’t be able to sign.

What if C and C' are commitments to 0 and -1? Then if I can sign, that means the ring signature is a proof is over {0,-1}. I'm probably missing something, so please tell me, why can't the amount be -1 in this proof?

I don't understand your question. The quote literally states what happens if C is a commitment to 0.

Just edited it, maybe clearer? May also be showing my misunderstanding. I'm wondering why C, C' proves a commitment to 0 or 1 and not -1, 0.

What if C and C' are commitments to 0 and -1? Then if I can sign, that means the ring signature is a proof is over {0,-1}.

To create a signature, the public key must be a known multiple of G. That multiple is known as the private key. When a point has a nonzero H term in it, no signature with that point as public key can be created. In order to write rG+vH as a multiple k of G, k = r + v*(G/H). H is constructed in such a way that nobody knows the ratio between G and H. As a result, rG+vH can only be a known multiple of G when v = 0.
As a result, you can only sign for public keys that are points which are commitments to the value 0.
A ring signature means you're picking multiple points as public key, and signing for 1 of them, without revealing which one.
So if C is a commitment to 0, and thus C' a commitment to -1, you absolutely can create a ring signature with {C, C'} as public keys. But it's due to the presence of C there.

I'm probably missing something, so please tell me, why can't the amount be -1 in this proof?

There is no 'value' in the proof. There is a choice of two values. The signer only proves he can sign for one of them, and verifiers cannot know which one he meant.

I get this part. I'm not getting why a ring signature over {0,1} is known to the verifier as a signature over {0,1} and not {-1,0}. When the signer gives C, how does the verifier know it's a commitment to 0?

The verifier knows that C is a commitment to 0 or to 1, because if C was anything else, neither of {C, C' = C - H} would be a commitment to 0, and thus nobody could have signed for it. The presence of the signature proves that one of pubkeys in the ring was actually a commitment to 0 and nothing else.

ok, I think I got it. It's because the verifier calculates C-H, and it's not from the signer. That's the part that I was missing. I thought the signer gave C and C-H. Thanks!

Indeed! The verifier computes C'. Glad it got cleared up.


text:
Why are p2sh and CHV forward-compatible but not backward-compatible?
The OP_EVAL BIP says that "Avoiding a block-chain split by malicious OP_EVAL transactions requires careful handling of two cases:

An OP_EVAL transaction that is invalid for new clients/miners but valid for old clients/miners.
An OP_EVAL transaction that is valid for new clients/miners but invalid for old clients/miners"

The later p2sh and CHV BIPS list only condition (1).
It sounds to me backward compatibility (avoiding situation 1) is more important than forward compatibility (avoiding condition 2).
Question: what would be the disadvantage of making OP_EVAL/p2sh/CHV a totally new opcode, so that any "old client" would immediately reject any transaction using the new opcode?
This would ensure that situation 1 never happens since all OP_EVAL/p2sh/CHV transactions are invalid for old clients/miners.  Old clients/miners would reject new transactions they haven't been taught about, which is pretty much what you expect to happen when you upgrade your software -- old software might not be able to read data files created by newer software.
You might say "well, then we have to force all the clients to upgrade instead of just the miners"... but the alternative is basically transferring trust from the clients to the miners, so avoiding a client upgrade doesn't come "for free" even though it might seem like it at first.
Right now the clients do all their own validity checking of the blockchain and do not rely on the miners' validity checks at all.  If 75% of the hashpower decided to change the validity rules they couldn't -- the clients don't rely on their checks.  The clients (exchanges included!) would promptly proceed to ignore the mutinying miners.  But OP_EVAL/p2sh/CHV end that clear separation: with "forward compatibility" we are asking people who use these new transactions to consent to a state of affairs in which old clients receiving coins from them will (unknowingly) transfer validity-check responsibility to the mining pool.  Nobody seems to be talking about that.

Requiring everybody to upgrade is just not realistic for such a small feature.
And clients must already rely on miners to fully validate transactions, because it is always possible a transaction they think is valid is actually half of a double-spend. Never accept 0- or 1-confirmation transactions unless they are from somebody you can trust.

I'm not talking about clients like mybitcoin.com who are dumb enough to consider 1 confirmation "enough".  Of course those dumb clients are trusting the miners!  I'm talking about the other 99% of the bitcoin universe that waits for a lot more than one confirmation.

If you are giving out a P2SH address to someone, it means you are willing to accept such transactions, and implies you're ready to do the necessary verification for it. It is true however that during the transition phase, old clients will be accepting coins that passed through a P2SH transaction somewhere, and they are indeed relying on the network to do the extra verification required.


text:
Can bitcoin node startup be secure without validating the entire blockchain?
One of the largest hurdles in my mind to increasing the number of full nodes operating is the startup cost related to downloading the blockchain.  A similar but less important (in my mind) issue is the amount of disk space required by the full blockchain.
At Pruning the branches in Merkle Tree Nick ODell writes "[Bitcoin Core] was built on the assumption that you download and validate all blocks."  In Would moving a transaction from an old block to a new one allow more pruning? Murch suggested that some assumptions be checked, and I think one of them was my assumption that it isn't necessary to parse the entire blockchain.  Thanks to Murch, this question is intended to address that assumption.

Full nodes serve several functions on the network:

Validating the blockchain on behalf of their owner
Supplying previous blocks and transactions to other nodes
Relaying transactions and blocks to other nodes

Not validating the blockchain independently sacrifices each of these functions to a degree.

If the node does not independently validate the blockchain, the owner of the full node is still relying on trusting the peer nodes
If the node does not store previous transactions and blocks, it cannot supply them to other nodes that are catching up with the network
If the node hasn't validated the blockchain, it could be tricked into relaying invalid transactions and blocks.

So yes, a node can skip the important step of downloading and validating the blockchain, but I don't think I would consider it to be a "full node" anymore.  It would not be helping the overall network health, nor could it be completely trusted by its owner.  At that point, I would suggest simply running an SPV node.

In general, there are policies and there are rules in Bitcoin. Every full node works independently to enforce rules by checking each received block, transaction and etc... Once a received block has been checked and verified, a full node will then update its UTXO set to reflect the latest state in the Blockchain which is stored in Memory.
What to do with the block, is left as a policy decision to the owner of the Full Node. As the owner, you may elect to have your full node run in Prune Mode. That being, you get rid of all transactions with its UTXO spent to relieve storage usage as these transactions do not add value to maintain the current state. Note that your policy decision does not affect the capability of your full node in enforcing the rules of Bitcoin.
To address your question directly. No. Bitcoin cannot start securely without downloading the entire blockchain. As a full node it is part of its functionality to independently verify the sequence of state transitions leading to bitcoins current state. Therefore the trust model forbids it from trusting some UTXO set shareable by some other independent node. Of course there may be other node implementations which may relax this requirement but I'm not aware of any.


text:
What are test_bitcoin.exe and test_bitcoin-qt.exe?
These two binaries appeared in Bitcoin Core a few versions ago, but I don't remember ever seeing an explanation of what they are and what you would use them for.

These executables are used to run Bitcoin's unit tests, so that developers can verify that various parts of the code work as designed.  They are not needed by end users.
From the file src/test/README.md:

The sources in this directory are unit test cases.  Boost includes a
  unit testing framework, and since bitcoin already uses boost, it makes
  sense to simply use this framework rather than require developers to
  configure some other framework (we want as few impediments to creating
  unit tests as possible).
The build system is setup to compile an executable called
  "test_bitcoin" that runs all of the unit tests.  The main source file
  is called test_bitcoin.cpp, which simply includes other files that
  contain the actual unit tests (outside of a couple required
  preprocessor directives).  The pattern is to create one test file for
  each class or source file for which you want to create unit tests.
  The file naming convention is "_tests.cpp" and such
  files should wrap their tests in a test suite called
  "_tests".  For an examples of this pattern, examine
  uint160_tests.cpp and uint256_tests.cpp.
For further reading, I found the following website to be helpful in
  explaining how the boost unit test framework works:
  http://www.alittlemadness.com/2009/03/31/c-unit-testing-with-boosttest/.


text:
Is there a shortcut for a synchronized bitcoin core after txindex?
I have downloaded the whole blockchain, but I was curious about the working environment after enabling txindex=1 and calling the -reindex command.
Now that I decided not to reindex the blockchain (didn't want to develop anything extreme and to wait that long), I disabled txindex=0 and bitcoind is downloading again all the blockchain!
Is there a shortcut to avoid it?
*I think the debug.log file is growing twice the initial size

Thanks. Now it's finished. This process took me about the 1/3rd of the blockchain download time.

When enabling or disabling txindex the blocks you already have are used, they are not re-downloaded. There is no shortcut, once you start you have to wait for it to finish. The process of re-indexing throws out the state you already have and rebuilds it completely from the block files where possible.


text:
On public keys compression, why an even or odd y coordinate corresponds to the positive / negative sign respectively?
This is a paragraph from Andreas' book on compressed/uncompressed public keys.
Chapter 4 - Section - Key Formats

Whereas uncompressed public keys have a prefix of 04 ,compressed
  public keys start with either a 02 or a 03 prefix. Let’s look at why
  there are two possible prefixes: because the left side of the equation
  is y^2 , that means the solution for y is a square root, which can
  have a positive or negative value. Visually, this means that the
  resulting y coordinate can be above the x-axis or below the x-axis. As
  you can see from the graph of the elliptic curve in Figure 4-2, the
  curve is symmetric, meaning it is reflected like a mirror by the
  x-axis. So, while we can omit the y coordinate we have to store the
  sign of y (positive or negative), or in other words, we have to
  remember if it was above or below the x-axis because each of those
  options represents a different point and a different public key. When
  calculating the elliptic curve in binary arithmetic on the finite
  field of prime order p, the y coordinate is either even or odd, which
  corresponds to the positive/negative sign as explained earlier.
  Therefore, to distinguish between the two possible values of y, we
  store a compressed public key with the prefix 02 if the y is even, and
  03 if it is odd, allowing the software to correctly deduce the y
  coordinate from the x coordinate and uncompress the public key to the
  full coordinates of the point. Public key compression is illustrated
  in Figure 4-7

What I don't get is that bold text.
Why an even or odd y coordinate corresponds to the positive / negative sign?
For example, are all even public keys below the x-axis?

There is no such thing as a negative or a positive value when you're talking in a finite field.
For example, in Z7, the field of integers modulo 7. There holds:

0 = 7 = 14 = -7
1 = 8 = 15 = -6
2 = 9 = 16 = -5
...

So you can't say that the number 2 is positive, because it's equal to -5.
Despite that, the square root still has two solutions. For example, 3^2 = 9 = 2, 4^2 = 16 = 2. Thus both 3 and 4 are square roots of 2.
So we need a way to say which solution we want. Turns out, that when reduced to a range of 0-6, the two solutions of the square, one is odd and the other is even.

+1 for clarifying that pos & neg are not meaningful in modulo fields

@Pieter Wuille, i am getting confused with the powers of 2s. I tried the exercise with y² mod p = (x³ + 7) mod p , for p = 5, x = 3, i get 2 solutions as you explained, and it happens that you can find the odd/even solution (2² mod 5 = 3² mod 5) for y². I had to force this to come up with 2 and 3 as square roots of 4 although it makes sense as the real roots are2 and -2, and -2 mod 5 = 3. What if x=4? We get 1² mod 5 and ... 2.44948974² mod 5. A fractional number can't be odd or even.

Square root here does not refer to the classical real square root. It refers to the inverse function of x^2 mod p. So we say y is the square root of x mod p iff y^2 mod p = x.

@PieterWuille  i got it now!!! Thank you. Sorry for my misconception.
Lastly, why does one need to know if s*2>N at:  is_high_s = s*2 > N and   v = 27 + ((y % 2) ^ (1 if is_high_s else 0)) ?

Because every number that has a square root has in fact two (negating a number does not change its square). Thus we need a way to convey which of the two square roots is the one meant.

Elliptic curves are of the form y^2 = f(x).
This means there are two roots to the equation. i.e. if we know an x there are two possible y values that satisfy the equation (y & -y). Because we are using a modulo type number field, it happens that the even and odd translate to y and -y
https://en.wikipedia.org/wiki/Quadratic_residue#Prime_or_prime_power_modulus
This confused me too, until I figured out modulo type fields are not as normal as we expect.

Why not just transmit the y value instead as 2s complement.

See Pieter's answer above (very good detail). Basically a 2s complement is the modulus of the word size (in bits); so we need to use a Ns complement - where N is the modulus of the field. So a modulus of 2^n - we can use 2s complement


text:
Chainstate database for download
Is it possible to download a recent snapshot of the chainstate database?
I'm running bitcoind (v. 0.11.8) on a machine with ~1mb/s download speed. After my client reached 300000 blocks, the synchronization is going insanely slow. I suspect it's because verification is very slow. The bitcoind processs is using nearly 100% CPU. However, for my purposes I only need a reasonably recent (i.e., up to 30 days old) chainstate database.

I can give you a copy if you want to contact me privately.  You can find my email address on my website, via my profile.  I don't really want to spend the time/bandwidth to keep it public and updated, though.  Obviously you can't be sure that I won't try to falsify it, but it sounds like this is just for testing purposes so maybe that's okay.

@NateEldredge Don't full-node bitcoin clients keep their chainstate database updated automatically?  If A. does (did) contact you privately would (did) you just recursively compress the "chainstate" folder and send that to him?  I ask because if that's how simple it is, I have an idea to make that concern you mentioned ("you can't be sure that I won't try to falsify it") go away.  And if that idea works really well, there could be a lot more validating nodes because they wouldn't need the full blockchain.

Yes, that was my plan.

A 30 days old chainstate database does not make sense. Either you have the chainstate completely, and are able to do full validation, or you don't, and you can't validate at all. There is no middle ground of only validating recent transactions, as any transaction you encounter with unknown inputs could either be fraudulent or created more than 30 days ago, and you'll have no way to tell without a full chainstate.
So, either you don't need full validation, and you can use a number of lightweight clients instead, or you do, and you'll either need to build the chainstate yourself by synchronizing history, or copying from a source you trust.
Please don't go download a chainstate from a random place on the Internet though. They can introduce arbitrarily many coins assigned to themselves, and your client would accept them. If many people started running nodes using the same chainstate 'copy' such transactions could even get into blocks, and cause forks in the best case, and theft in the worst case.

I'm working on a prototype/PoC of the protocol client for my thesis. In the long run, the software will run on full blockchain, but first I quickly want to run some performance tests and test the general idea. Believe me, I have analyzed my needs, and ATM a reasonably recent chainstate is all I need.

How do you know OP wants to transact? He clearly stated, "for my purposes". Could be "count average block time which isn't provided by blockchain.info"


text:
How to reward mining in a blockchain that doesn't store currency?
I understand the bitcoin blockchain motivates mining because there's a bitcoin reward for the miner who solves the pending block.
What if a blockchain doesn't store currency data but some sort of ownership data that cannot be represented by currency, e.g. tweets or land and stock ownership.
It would probably be too much to reward a miner with the ownership of land. And even if it were appropriate, there could also be other cases in which the blockchain doesn't store data regarding any kind of asset ownership.
Is it possible to offer reward that is not coupled to the data of the system?

So, your question is "How could one incentivize mining on a non-currency blockchain?"

@Murch yes, please edit my question if you feel that was not clear.

There are several blockchains that already do this. Colored Coins (on bitcoin blockchain), Counterpary (on bitcoin blockchain), NXT, BitShares, Ethereum and others allow to represent any asset you wish like land, cars, consultancy hours, etc., using digital tokens (e.g. the "data" of the system as you called it) which is irrespective/decoupled of the reward they get.
See Colored Coins for how you can use metadata in a bitcoin transaction to achieve that result. It is especially easy to implement using Counterparty.
So, you can already store the kind of data you want in parallel to a digital token that rewards the miners.
If you meant, only having the asset in the blockchain and no reward then the answer is no, you cannot: you always need something in digital form that can be securely shared to the contributors**.
Hope this helped.
**For an internal reward, you have to give something of value to the contributors within the system. Say, that you don't want to give money/currency but instead some service. In order to keep a proper count of the rewards for each contributor you would need a digital way of representing the reward, ie. by using a digital token. To securely keep track of the rewards you need to also put them in an immutable structure, ie. the blockchain.
Thus, whether you want to give money or chickens or some kind of service to the contributors you have to digitally represent it (tokens) and secure it (blockchain). The token represents the reward and it does not need to be money. However, it is very practical to think about it as money since this is the unit of exchange that most of us are used to.

I've also learned the reward has to be easily quantifiable so it can be regulated to match the complexity of the hash.

I am not sure what you mean with 'quantifiable' for the reward. In blockchain implementations that I know of, the reward is fixed per successful proof of work (e.g. finding a hash for the next block gives a fixed number of the tokens used to reward).

The mistake of my previous comment was pointing out that the complexity of a block hash (difficulty) increases depending on the amount of miners, the reward has to be quantifiable so it can be tuned just so. See: http://bitcoin.cex.io/what-is-bitcoin-difficulty/

But when it comes to chickens or some kind of service, how can you guarantee it will be delivered?

@HenriqueBarcelos you cannot guarantee it. You will have a digital token that represents the service (or chicken) and you depend on the honesty and reputation of the person (who issued the token) to deliver as promised. If that person doesn't deliver his reputation declines and with it the value of his token. Some examples of these token were issued through the LetsTalkBitcoin platform (which uses Counterparty behind the scenes): e.g. Adam sells one hour consulting tokens here.

Currently the Bitcoin blockchain uses coinbase transactions to reward miners when a block is found.  There is no reason this functionality can't be changed. It is also worth nothing that there are other ways to secure blockchains besides Proof of work, which is what the Bitcoin blockchain implements to come to consensus on who owns which assets.  If someone were to implement a different consensus model in their own blockchain any kind of reward that the developer could conceive of could be implemented.  Consult with several  software engineers if you have an idea that you are unsure of how you could implement such a system.

I think that the asker was aware how the Bitcoin mining reward works but was actually requesting input on how to incentivize mining in a non-currency blockchain.


text:
How scalable is a Blockchain-based system?
This question as stated above is a bit vague, but let me make it a bit more clear:
Recently, I have seen many services pop up that state that they are secure, fault-tolerant, trustless and scalable because they use a blockchain (often the Bitcoin block chain, the Ethereum blockchain or one of many other or proprietary 'block chains') to store the important parts of the data the services handle.
Now, security and fault-tolerancy I can understand, because (after a few more blocks are mined):

Everone can check the integrity and authenticity of a transaction because ECDSA-signatures are used, giving the system non-repudiation as property.
Everyone has a copy of the block chain so-far stored locally, making it virtually impossible to destroy data. ❦
it becomes virtually impossible to alter a previously-made transaction, because this means that all hashes of blocks after that need to be re-calculated.

Now, because of ❦, the system is also trustless, assuming everyone can read/understand the data from the blockchain directly (i.e. the service's interface to the block chain is released as open-source software). This is where quite a few services claims fall short.
However, the final claim: scalability. I cannot understand how a system can be scalable if it involves the copying of all the (trans)actions its users did to all other users' computers (again, this follows from ❦): It will
both take a lot of time and a lot of disk space to do all this copying, and at some point a physical limit will be reached in which more actions are taken than can be written to the blockchain and in which it takes longer to catch up to the head of the chain than that new transactions appear. In both cases the system will break down (?).
I can see only one ways to resolve this, which is to use 'light wallets' for the end users, in which case the system is no longer trustless, as these users need to trust that the parties they talk with are honest in the version of the block chain they show, so this breaks the other claims.
I don't believe all of the systems that state 'Blockchain inside' use this approach.
So my question: What other techniques are used to make a Blockchain-based system more scalable, and how scalable (in transaction throughput) is a system as a result?

I have a pruned bitcoin node. It's validated every bitcoin transaction and is up-to-date, but only takes up about 6 GB of disk space. It doesn't have knowledge of any spent transactions once it has validated them, it only keeps track of unspent ones, which is all it needs to validate future transactions. If there is a bottleneck to blockchain scaling, it is network bandwidth, not disk space.

I feel reminded of this question: What is the Lightning Network proposal? What problem is it trying to solve?

Blockchains are not really scalable. For the most security, blockchains need to be replicated on as many devices as possible. Those devices are full nodes and must download and verify every single block and transaction. In order to increase the number of transactions, transactions have to become smaller and blocks have to become bigger. Unfortunately increasing block size and transaction capacity will result in more resources required to verify and store them all.

Yes you're right but with the prune feature in bitcoind makes the space needed smaller and even if you don't want to use the prune feature with technology advancing HD is becoming cheaper and cheaper.

The prune feature is not a solution. Yes it reduces disk space, but you are also throwing away the vast majority of the blockchain. This means that you can't help new nodes start nor can you lookup historical transactions. It still requires the entire blockchain to be downloaded and verified, so pruning does not really help with scaling at all.

I agree. I was just throwing it out there that it is possible.. but can be not recommended depending on what you're actually doing with it.


text:
Does my client accept inbound connections?
How can I verify that the Bitcoin client is well connected to the network and is able to receive incoming connections?

Just wait 10 minutes or so. If you have more than 8 connections, you are receiving inbound connections.

And if I only have 8 connections, I'm not accepting inbound connections? I have UPnP turned on + matching router, I thought this would be enough and that I am accepting inbound connections ... but I only have 8 total.

Is UPnp turned on in router settings (many come w/ UPnp off by default)?

There is a port checker tool that is not browser based that will allow you to to check to see if the port 8333 is open.  I had a situation with my windows 2008 R2 VPS where i was stuck at 8 connections.  I went into the bitcoin client and unchecked "map using UPnP", shut down the bitcoin client, then went into windows firewall and added bitcoin to accept incoming TCP, UDP connections for the bitcoin-qt.exe.  Then I restarted the bitcoin client, and I had 20+ connections after 10 minutes or so.
I didn't even have to use the port checker tool.


text:
Web API to retrieve difficulty changes
I am looking for a website that allows me to retrieve the time at which each difficulty change happened. The time doesn't need to be accurate so a time stamp from the block will do. I want to fetch this information automatically every now and then, but I can't seem to find a webpage that provides an API for this.

http://blockexplorer.com/q/nethash/2016 provides the necessary information and shouldn't be too hard to parse. Every row corresponds to the first block at a given difficulty.

You can also use http://blockexplorer.com/q/nethash/2015

This should probably be http://blockexplorer.com/q/nethash/2016 . The interval between successive retargets is 2016 blocks, and this also gives the correct offset - every row is the first block of every difficulty. I've edited the answer to use this improvement.

Actually, I think that the last block of each difficulty is at 2015. This means that http://blockexplorer.com/q/nethash/2015 has the correct timestamp, but I have to use the difficulty of the following block. It's a little tricky...

/2015 isn't good because it's not the right interval. If you want the last block of every difficulty you need 2015, 4031, 6047... But /2015 will give you 2015, 4030, 6045... . Unless there's a parameter for nethash to control the offset (or theymos is willing to add one) it can't be used for this. But you can query each block separately with e.g. http://blockexplorer.com/b/155231 .
Anyway, why do you want the timestamp of the last block of a difficulty rather than the first block of the next difficulty?

Hum.. I thought that difficulty actually changed when block 2015 came out because the next block will be mined with the new difficulty. No? Anyway, it's probably a 10min difference so it isn't worth the trouble. Thanks for the help.

@nmat: This makes sense, you do want the block at the -1 offset. But you still need a 2016 interval, which /nethash/2015 doesn't provide. If you don't need it very accurate you can just use /2016, and to gain a bit more accuracy you could subtract 10 minutes which is the average difference between this block and the previous one.

This link no longer works (404)


text:
any way to recover lost qt bitcoin wallet?
Hi is there any way to recover my Bitcoin-Qt wallet with only an address and the wallet password? Unfortunately my disk was formatted.

Hi is there any way to recover my Bitcoin-Qt wallet with only an address and the wallet password?

No. I can't think of a secure way for the Bitcoin developers to add recovery method like that, either.

Unfortunately my disk was formatted.

Do you mean that the space containing your wallet was overwritten, or that the space at the front of the disk that tells your computer how to read the disk was changed?
If it's the second one, your Bitcoins might be recoverable.

I can't think of a secure way for the Bitcoin developers to add recovery method like that, either. If it were a deterministic/HD wallet like Armory, Electrum, etc. then you could. But the way Bitcoin Core works, no, you can't recover it without the wallet.

As nick said, if it's just that the FAT (file allocation table, like an index) is formatted STOP using the HDD immediately and seek backup services


text:
Bitcoin core server error when requesting data
I'm trying to interact with the bitcoin network with Bitcoin Core server and the JSON RPC PHP library found on the wiki here: https://en.bitcoin.it/wiki/API_reference_%28JSON-RPC%
My setup:
I installed the Bitcoin core client, created the bitcoin.conf file with the settings:
rpcuser=finder
rpcpassword=AcdfghHBTfYHTFytBG526
server=1
rpcport=8332

the wallet is synchronised with the network.
I tried the example on the wiki like this:
require_once 'jsonRPCClient.php';
$bitcoin = new   jsonRPCClient('http://finder:AcdfghHBTfYHTFytBG526@127.0.0.1:8332/');
print_r($bitcoin->getwork()); echo "\n";

When running the code I'm getting the error:
 Warning:  fopen(http://...@127.0.0.1:8332/): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found
 in D:\xampp\htdocs\p\jsonRPCClient.php on line 132

Fatal error:  Uncaught exception 'Exception' with message 'Unable to connect to http://finder:AcdfghHBTfYHTFytBG526@127.0.0.1:8332/' in D:\xampp\htdocs\p\jsonRPCClient.php:140
Stack trace:
0 D:\xampp\htdocs\p\index.php(9): jsonRPCClient->__call('getwork', Array)
1 D:\xampp\htdocs\p\index.php(9): jsonRPCClient->getwork()
2 {main}
  thrown in D:\xampp\htdocs\p\jsonRPCClient.php on line 140

I'm running the server with the batch command bitcoin-qt.exe -server
Is there anything else I need to do to get the data from the network?

Is the firewall allowing connections? Try your browser with http://127.0.0.1:8332 ... It should popup with credentials if all is well. Otherwise you may need a bitcoin.conf with rpcallowip

The credentials window shows up.In the meantime I've made some JSON requests without the library, I tried several API methods and all work except the 'getwork' method, was it removed completely? When I call it I'm getting the response  {"result":null,"error":{"code":-32601,"message":"Method not found"},"id":"anything"}

Are you using the latest version of Bitcoin? getwork has been removed in favor of getblocktemplate. Does getblocktemplate work?

Yes I'm using the latest version of Bitcoin, getblocktemplate works perfectly. Thank you for clarifying that.


text:
Bitcoin Address generation
The bitcoin wiki  says this:

How to create Bitcoin Address
0 - Having a private ECDSA key
18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725

1 - Take the corresponding public key generated with it
0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6

2 - Perform SHA-256 hashing on the public key
600FFE422B4E00731A59557A5CCA46CC183944191006324A447BDB2D98D4B408

but when I run a sha256 on
0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6

I don't get
600FFE422B4E00731A59557A5CCA46CC183944191006324A447BDB2D98D4B408

What I get is
32511e82d56dcea68eb774094e25bab0f8bdd9bc1eca1ceeda38c7a43aceddce

what am I doing wrong?

echo -n  "0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6"
| sha256sum

Gives: 32511e82d56dcea68eb774094e25bab0f8bdd9bc1eca1ceeda38c7a43aceddce
echo "0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6"
| xxd -r -p /proc/self/fd/0 | sha256sum

Gives: 600ffe422b4e00731a59557a5cca46cc183944191006324a447bdb2d98d4b408
Conclusion: You hashed an ASCII representation of the public key in hexadecimal rather than the public key itself.

Use must use SHA256 on array of bytes, not on a hex-string representation.


text:
What exactly were the novel contributions of Bitcoin?
When Satoshi Nakamoto published the original white paper describing the Bitcoin protocol, they referenced Hashcash and B-money. B-money is a proposal for an electronic cash protocol, similar to Bitcoin. Hashcash is the proof-of-work algorithm used in Bitcoin.
P2P, digital signatures, proof-of-work and electronic cash protocols existed before Bitcoin. What exactly were the novel contributions of the Bitcoin protocol?

B-Money didn't use PoW for consensus. It suggested either a syncronous unjammable channel, or a set of trusted servers that would put up a deposit to allow them to be fined (presumably by a vote of the other, honest, servers.)

b-money proposes to pay for money minting by means of proof-of-work. The minted money then has the value of the expended computational power.
For value transfers it either relied on a synchronous unjammable channel and arbitration, or on a set of trusted servers that had to be regularly audited by the other network participants.
In other words, b-money used POW to create monetary scarcity with manual supervision.
Bitcoin instead introduced the use of proof-of-work to create scarcity in the truth source: By electing only one network participant to extend the blockchain through the mining lottery, Bitcoin manages to forgo arbitration or trusted servers, yet manages to create convergent synchronization of the network's state in an asynchronous manner.

It's late and I'm tired. Please don't hesitate to point out the mistake I've surely made in the above. ;) Good night.


text:
Bitcoin investment vehicles
I've heard of at least 2 financial products which enable people to take positions on bitcoin in the stock market. Here's a Reuter's article on one. Can anyone explain what the purpose of these investment vehicles is? Why would someone want to pay a financial institution ~2%/year to hold their bitcoin for them? Not to mention the counterparty risk...

"By listing the ETI on the Gibraltar Stock Exchange, which is an EU-regulated market, we are able to bring a high level of transparency and liquidity to investors", said Revoltura CEO Ransu Salovaara.

Transparency? How is an opaque financial product - which may or may not be backed by actual bitcoin - going to provide more transparency than trades on a public blockchain?
Is this simply a money grab to exploit the people who don't have a clue or am I missing something?

Regarding audience: ETIs are regulated. Not just regulated, but they are marketed for sophisticated investors. In fact regulation prevents marketing these for general audience, so there shouldn't be issues having investors who do not know what they are doing. Investors in this case are banks and pension fund like actor, though I am not sure what's the definition of the sophisticated investor in EU.
Regarding cost: There is a premium cost bringing a new investment vehicle to market. Mainly, because to have something regulated it should be insured. Bitcoin is very new. Financial market operators are not familiar with all risk models yet. Thus, insurance carries a high premium. BitcoinETI is audited by PriceWaterhouseCoopers and needs to pay various fees to stock markets, exchanges and such. For comparison, Digital Currency Group's Grayscale Bitcoin trust carries 2% maintenance fee.
Regarding transparency: BitcoinETI prospectus is public, vetted by regulators and all fees are clear up front. The ETI must publish it Net Asset Value (NAV) continuously. Public blockchain doesn't include fiat nominated (USD, EUR) transactions of traded Bitcoins. These are internal to Bitcoin exchanges. Some exchanges choose to publish this data independently. Even if it's published, it is suspected that many Chinese exchanges manipulate this data. As virtual currency exchanges companies are not regulated, this practice cannot be confirmed or stopped.

I can understand the need for creating a more secure exchange to buy/sell bitcoin. I don't understand the need to hold customers' bitcoin at 1.75%/year. All they do is make 1 transaction to cold storage once. It costs $0 to maintain the bitcoin in cold storage. Since the actual trading is done over the stock exchange, and paid separately by the clients to the stock broker, they're literally providing no service at all for this fee.

What fees you pay to bring your product to stock markets? Who holds the access to your cold storage? Is it insured? What happens if you lose the key? What guarantees your cold storage service provider is not going to disappear with your Bitcoins? These are some of the questions you might want to think of. Whether or not the price is right is up to the markets to decide.

The costs of converting fiat to bitcoin and back are paid by the fund managers; the commission on trades goes to the brokers, not the managers.  So the management costs have to cover that.  Also, it costs significantly more than $0 to maintain Bitcoin in cold storage securely.  And you can't just keep it there; investors are buying and selling constantly.

For comparison, Grayscale Bitcoin Trust (from Digital Currency Group, DCG fame) has a management fee of 2%: http://grayscale.co/bitcoin-investment-trust/

@Nate Eldredge: there is no fiat-to-bitcoin-and-back trading going on. They buy bitcoin once and put it in cold storage. The only thing that's being traded is investors' claim to the ownership of those bitcoins - on the stock exchange, for a separate fee.

@Mikko Ohtamaa: you're right, there are SOME ongoing costs. I can't imagine anything to justify the 2% price point, though. I see this in the same category as door-to-door salesmen selling vacuum cleaners to old ladies for 4000€. They can also claim there is a "demand for their product" and that it's a fair rate if the market is willing to pay it.

If you think the price is hugely unjustified there there must be room for market disruption.  You can always launch your own ETI product with better price point and make a lot of money there. It's public market after all.

Right, why don't I set up my own bank while I'm at it? Sorry if I provocated you to the point where you felt that was an appropriate response. I appreciate your earlier posts.

Yes. There must be a cost of setting up a bank :) The fee is below the management fee of comparable products. It's a high compared for maintaining Bitcoin cold storage yourself, but instead you should compare it to other similar products, which is difficult in this case as there are only few of them currently.

Technically, I could set up my own bitcoin fund in 1-2 days. I wouldn't have to charge people millions in fees. But we both know it's not possible due to regulations and lack of connections and marketing capital.

Here's a comparable product for you: stock index funds. They typically charge 0.5%/year and their operations (trading to match the index, book keeping, etc.) cost more to maintain than bitcoin in cold storage.

Let's see when SolidX and Winklevoss's ETFs come out, so there is more data points in the same category.

Cleaned up the answer.


text:
is it possible to decode block height from a blockhash?
I'm creating a bitcoin network client and I'm wondering if it's possible to decode the block height from a blockhash whenever I receive a new block inventory vector.

No.
The block hash is a hash of the block header... but even if you could reverse the hash function (which is impossible, or Bitcoin would be broken), you wouldn't know the height, as the height is not stored in the header.
The header does contain a hash of the transaction Merkle root... but even if you could reverse the hash functions in the transaction Merkle tree, you wouldn't know the height, as the height is not stored in the transaction Merkle tree.
The Merkle tree does contain transaction ids... and if you could reverse the hash function used for computing the transaction ids, you would could learn the height, as since BIP34, the block height is stored in the input of the first transaction of a block (the coinbase transaction).
So, if you want to know a block's height for sure, you need to request at least its coinbase transaction, the Merkle path from the coinbase to the root, and the full block header. If they all match, you can be pretty sure.

No.  The whole point of a hash is that it's a one way function.  You can't "decode" any of the header data from the block hash.
Moreover, the block height isn't even contained in the block header.  You're supposed to calculate the block height by looking at the previous block hash in the header, which hopefully refers to a block whose height you already know; if not, get that block and recurse.  (For sufficiently recent blocks, the block height is contained in the scripts of the coinbase transaction, but that's not part of the header.)


text:
Fine tunning a Rapsberri Pi 2 B+ full 0.12 node
I'm running a 0.12 Raspnode (raspberri Pi 2 B+ full node)
I've made the full node syncing in a laptop to speed up the process. Then, after moving all the files successfully and starting the full node in the rPi I have noted that it cannot completely sync and it is most of the time a few blocks away from 100% height.
The rPi is running only bitcoind and I've modified with renice the priority to its assigned PID.
I would like to know what are the parameters and values I need to change in order to get a fully synchronized node (100% height).
The following options comes to mind:

Increase the relayfee parameter? (current value
minrelaytxfee=0.00005)
Decrease the memory assigned to the UXTO? (current value
maxmempool=150)
Increase or decrease the prune value? (current is
prune=30000)
Decrease the free-tx limit? (current at limitfreerelay=10)

If you need any additional info feel free to ask for it, I would gladly provide it.
Edit: seems that blocks are being produced faster than the processing power of the Rpi 2 B+ can handle.. so it never gets sync'ed.. its always behind the last block.

Which version of the Pi do you have?

Raspberry Pi B+

Yeah, I've read before that the first generation Pis don't have enough computing power to keep up. I'm running a node on a Pi 2B, and even that took almost four weeks to catch up to the network (I tried. For science.). ;)

Im sorry , its a 2B+

You do need to store data on an external SSD disk (USB).
If your data and swap are on SSD media, you can use all those options (they won't matter much).
I don't recommend to use Pi 2 (any version), it's a waste of time. It can barely keep up, it becomes useless for anything else and each time you restart the OS or bitcoind you need to wait several hours for it to catch up.


text:
How to update my RaspNode? no GUI only CLI
I would like to know the best way to update my RaspNode (rPi 2 B+) to the 0.12.1 bitcoind version.
I did

sudo apt-get install bitcoind

I also did this:
Erased /bin/bitcoin folder
then into /bin/
git clone https://github.com/bitcoin/bitcoin.git
./autogen.sh
./configure --enable-upnp-default --disable-wallet
make -j2

but it's still the same version 0.11.2

You should uninstall the installed version first completely with sudo apt-get remove bitcoind before manually building the binaries from source. Make sure that you backup your wallet (and eventually Blockchain) first (so Keep your data-directory).
Don't run the build in teh bin folder! The sudo make install command will install more than just the binary on your machine! Use e.g. /home/git/bitcoin/ to clone the repository and run your configure and make commands there.
Then instlall bitcoin like described on github. after your make -j2 command you should run sudo make install to install bitcoind on your computer. (Binaries are intalled under /usr/local/bin/).
I have installed it on my raspberry Pi a week ago. Works fine :-)
Blockchain-sync lasts almost forever ....
If didn't use the --disable-wallet flag. You could use the wallet with bitcoin-cli


text:
How do I use multisig transactions?
I want to create an joint "address", made of 3 individual ordinary addresses, such that any combination of 2 addresses can move the bitcoins stored at the joint address.
What is the way to do this using current tooling? Please be as detailed as possible, specify tools, specific command line argument, etc.

How do I create the 3 addresses? (They should each be created on a separate computer, to increase security)
How do I send money to the joint address?
How do I spend money from the joint address?

@eMansipater - now it does.


text:
Can you use the same seed for normal BTC and Lightning wallets?
If I generated 24 words from a Ledger Nano, can I import these to a lightning network wallet e.g. Eclair?

A lightning network wallet can be compatible with a Ledger Nano generated wallet, but doesn't have to be.
Ledger nano generates seeds (the 24 words) using BIP 32/BIP 39/BIP 44.
I checked to see what format eclair uses, and it seems to use BIP 49 instead of BIP 44. This seems to suggest that the seeds are incompatible, but I haven't confirmed this.
If you want to do so, you can try importing your Ledger seeds into eclair, which is a non-descructive action (i.e. it won't affect your wallet/funds).

They should be compatible, BIP49 is the segwit extension of BIP44 (which is necessary for ln). The ledger seed should work fine

It depends on the wallet. Currently, most lightning wallets use different methods for backing up and restoring your funds, as it's a little bit more complex than a regular bitcoin wallet.
But Phoenix for example does support BIP39 seeds so far.
It is also important to note that you should never use your seed from a hardware wallet in a software wallet. Moreover when it comes to lightning wallets you will still need channel backups to make sure you can restore your funds properly.

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


text:
Is there a documentation of the first altcoins timeline?
Meaning, which altcoin was created one, in a chronological order.
It's interesting, from a historical perspective, to collect such an archive.

When posting I forgot about this cool site that does exactly that!


text:
How do I ensure that the multisig transaction that's signed by multiple parties is the same?
In multisig 2-3 escrow, what is best approach from below ?
1- Say I want to sign a rawtransaction from a customer and send it to escrow to sign so that 2 of 3 sigs are there to release fund.
But how do I ensure that rawtransaction is the same one that I created and not modified or created from customer ?
createrawtransaction '[{"txid":"564876",
"vout":0,"scriptPubKey":"8645231554",
"redeemScript":"2315454"}]'
'{"d5adf5sdf5s45":0.00015000}'

0df0sd0fsdfsdfs11dfs

signrawtransaction
'0df0sd0fsdfsdfs11dfs'
'[{"txid":"txid":"564876",
"vout":0,"scriptPubKey":"8645231554",
"redeemScript":"2315454"}]'
'["erwerw8e888"]'

{
"hex" : "0e0rw1e1rw1er1we1rw",
"complete" : false
}

It's possible the customer created his own rawtransaction and signed it and sent it to me, how do I ensure it is the same raw transaction that I created ?
2-Send sign rawtransaction to customer to sign 2-3 to release fund?
But how can I know if a customer made his own sendrawtransaction? Does there exist any bitcoin api rpc to test if customer already released funds?

Your server creates the transaction, so it knows what to compare it to. I create a json array of the outputs, hash and store the resut. Later when a user submits a partially signed, or fully signed transaction, I need to check it's valid.
First verify the inputs are the correct txid's, and that a signature was added by that user by doing ECDSA signature verification. This parts tough, look at http://en.bitcoin.it/wiki/OP_CHECKSIG. Then compare the hash of the outputs against what you're expecting, since if an address or amount changes, you'll get a different result.


text:
Creating Testnet Bitcoin Transaction with bitcoinjs-lib
I'm trying to setup a simple bitcoin testnet transaction using the bitcoinjs-lib npm module.  It seems like I'm building the transaction correctly, and I receive the hex code but I think I'm unable to broadcast my transaction for some reason.  Here is my code:
const address_1 = 'mzMVV43nRcdGdL9D6xuMez2GkHq8oN1965'; //balance: 130281960 satoshi
const address_2 = 'moCytanji9FNUsDJWVeDGdEFxtGT5psHM6'; //balance: 0 satoshi

const input = {
  sender_prev_txid: 'efc912c7ea9b6eafe129c5fcc64c76d8adc87120bf09196e56c39ced84e6eb36'
};

const output = {
  address: address_2,
  satoshi: 130200000
};

const createTestnetTransaction = (wif, input, output) => {
  const transaction = new bitcoin.TransactionBuilder(bitcoin.networks.testnet);
  const sender = bitcoin.ECPair.fromWIF(wif, bitcoin.networks.testnet);

  transaction.setVersion(1);
  transaction.addInput(input.sender_prev_txid, 0);
  transaction.addOutput(output.address, output.satoshi);
  transaction.sign(0, sender);
  console.log(transaction.build().toHex());
};

createTestnetTransaction(wif_1, input, output);

Using the following hex code:
010000000136ebe684ed9cc3566e1909bf2071c8add8764cc6fcc529e1af6e9beac712c9ef000000006b483045022100ce67916a053e94faf940e81ae665fc81daae226d1a70e7a5bc82adac302a290802207b564151889dd22b9e755297ca502b06f1345106296379762daeae2ac46d0af301210226a0c89db3a526fc5751606bf2592bd1477a4ac0d95616a4dd6b01ba65080a96ffffffff01c0b1c207000000001976a914545ad9c5df8da219b16f8c844498090aa88a764c88ac00000000

I receive the error: 'Error validating transaction: Transaction efc912c7ea9b6eafe129c5fcc64c76d8adc87120bf09196e56c39ced84e6eb36 referenced by input 0 of a7f8e0b48c77b5c192f301d655dffcedee1bd8aac2a5a058bb9552b4ff711002 has already been spent..'
If someone could help point out what I'm doing wrong and help my complete the transaction that would be great, thanks!

The input you are trying to spend appears to be vout 1 in the tx.
Your current code tries to spend vout 0, which has already been spent. Try changing transaction.addInput(input.sender_prev_txid, 0); to transaction.addInput(input.sender_prev_txid, 1);


text:
How does bitcoind find p2p hosts?
I read the bitcoin references but I can't find a description regarding how bitcoin clients find other host in the p2p network.
Would you please tell me?

There are several methods for a bitcoin client to find other nodes.
First of all they save a list of nodes from previous connections.
Of course this only works when they don't connect the first time.
If a client has no IPs stored it falls back to DNS-Seeds:

Bitcoin looks up the IP Addresses of several host names and adds those to the list of potential addresses. This is the default seeding mechanism, as of v0.6.x and later.

Once a client is connected to the network, it will ask for a list via the Addr-Message containing a list of IPs of known clients.
As you can see in the Bitcoin-Wiki there was another method, which is no longer used:

IRC
Bitcoin joins a random channel between #bitcoin00 and #bitcoin99 on irc.lfnet.org. Your nick is set to an encoded form of your IP address. By decoding all the nicks of all users on the channel, you get a list of all IP addresses currently connected to Bitcoin.

You forgot the list of inbuilt client seeds.


text:
How can I convert a bitcoin public key to a bitcoin address?
How can I convert a bitcoin public key to a bitcoin address?
Note: I am using PHP.
Is there an existing bitcoin API or PHP-API to do that converting ?

There is a step-by-step tutorial on the Bitcoin Wiki for converting Keys.
For testing there is a very good website, where you can put in a private or public key and its show you the result of any step: http://gobittest.appspot.com/Address
If you dont want to do those things on your own you could use Bitcore, a JavaScript API for Bitcoin. For a pure PHP Libary there are some custom user projects on github, but I didn't tested any of them.

I can't figure out how to go from 0 to 1 in the step-by-step tutorial :( Looks like a programmatic solution might be here, but I'm thinking there must be an easier way http://bitcoin.stackexchange.com/questions/28398/how-can-i-get-the-uncompressed-public-key-from-the-compressed-public-key-in-open


text:
I cannot see the expected OP_CODE in transactions
According to different answers on this site the format of the standard TX claim script should be [OP_PUSH DER(R+S)+HashType OP_PUSH PubKey]
The OP_PUSH code is 4C, 4D or 4E depending on push length.
However in this transaction I cannot see the expected code. I could not even find the definition of the one there:
https://blockchain.info/rawtx/db320e85d8bef3895052d9bf002aeb185fa12eeef8445e3e45f31b9a0c90f9f6?format=hex
01 00 00 00 is txin index, 8C is the scriptin length and then comes 49.
Instead of 49 I would expect 4C.
Is it because you can leave out the OP_CODEs or what am I missing?

[version]        01000000
[inputs]         01
[txid]           4f94da67fb56cf104850a03c3cbabdd4b0a38d7f47eadedaf670ee0d5fa296c8
[txout]          01000000
[in script len]  8c
[push signature] 493046022100e77bddaaae0f2e684776dff2e55f8d3654e78fbc9439fb53f4d73096eb1258c1022100aa4f0b33e1b99479a5a5a154773be244670d37ff6fd5da1bcc150e35c61fb51701
[push pubkey]    410485b6198b35faee9fb4f9ad6e809704057b930959fac62769858ed52b0cdf00015ad063612d2fe607e2b43f2f0bb4cf9169064872a971ae0be71e651412381d9e
[sequence]       ffffffff
[outputs]        02
[amount]         f44fc00200000000
[out script len] 19
[out script]     76a914fd69e5b61a949baf9c141e060b3c0c43f7637f5888ac
[amount]         9d7ded0600000000
[out script len] 19
[out script]     76a914fe1a0e4a6163053f76cba0a7053850f07b34a7c288ac
[lock]           00000000

It isn't clear how this answers the question.

[push signature] 49... and [push pubkey] 41... are the codes. Note: all codes from 0x01 to 0x4b are also pushes

Hehe I really just needed this comment, but thanks :D


text:
Where do transaction fees go in block #163368
The reward of the Coinbase TX  is only 50 BTC not including transaction fees. So who owned  these fees?

163369 includes transactions fees, you are meaning 163368 or 163370?

sorry. my mistake. I mean 163368

As you mentioned this Block and also some other ones in the blockchain as well failed to claim the fees. Some miners missed all fees other only  a few, this can happen for a variety of reasons, almost all of them are bugs in the mining software.

So who owned these fees?

These coins are lost, the miner failed to claim them and so they are gone.

Or rather, they were never created.

@Matthieu what do you mean with "never created"?


text:
What is the algorithm of block selection using Target Difficulty?
Suppose below is target difficulty:
0x0000CDEF0A000000000000000000000000000000000000000000000000000000

So result value must lower than target to select block.
So, If Miner 'A' found:
0x000000000000000000000000076898778ABEFDC34798734590349843BDCAE854

Will miner 'A' can satisfy target difficulty or not?
And if not then please tell me the reason.
Thanks

Yes.  The test is that in order to be a valid proof of work, the hash found must be numerically less than or equal to the target.  That is certainly true of the hash found by Miner A in your example.

Thanks, Still I am not clear.
I referred http://blockexplorer.com/ some completed blocks,and found "Hash Value" has same number of Previous zeros as target has. I mean if Target has 4 previous zero(0x000043AbC..),then found hash has same number of zero(0x000024C...).
Why all the Found hash same number of zeros? It may also generate more than 4 zeros and satisfy less than target.

@tushar: It certainly could have 4 more zeros, but this will only happen 1/65536 of the time, so it's not surprising we rarely see it.


text:
Restore wallet.dat on windows 8
How do I use my wallet.dat on my windows 8 bitcoin qt?
Someone posted this
C:\Documents and Settings\YourUserName\Application data\Bitcoin (XP)
C:\Users\YourUserName\Appdata\Roaming\Bitcoin (Vista and 7)
but I'm on windows 8, so i don't know what to do

Windows 8 is just like Windows 7.
But on a mondern bitcoin-core installation you will be asked where to put your data-directory. So if you changed the default path you need to consider that.
So if you found your data directory, your wallet.dat file is right there. Make a backup or restore it as you wish.
There is also a good tutorial video around for more visual explanation.
For a more detailed explanation on what steps are required to restoring your wallet.dat you can check out this post.

Can't you just search for wallet.dat?


text:
How do I trade at BTC-e?
I want to sell 1 LTC via BTC-e.
How does selling LTC for USD takes place at BTC-e? Most probably I'll firstly deposit 1 LTC in the BTC-e wallet and then go to LTC/USD and then enter 1 LTC under the 'Sell LTC' section and click on 'Sell LTC.' What happens after that?
I want to know because I don't want to waste any bit of my hard earned Litecoins!

When you place an order to sell LTC in btc-e it checks if there is an order to buy LTC at the same rate as you specified. If there is order to buy LTC at the same rate as you specified in your sell order it will fill your sell order up to the amount of the buy order. If the buy order amount is bigger than your sell order your sell order will be filled instantly and you will receive BTC and the buyer will receive your LTC. If there is no buy order at the rate you specified the system will wait for someone to buy LTC at the same rate. You can always cancel these orders before they are completely filled, but remember the 0.20% trading fee is taken when you place an order and not when you complete the order.

https://btc-e.com/tapi/docs#Trade
Does higher Trade Rate costs fee? The trade is all free no fee now on btc-e. Why not set higher Rate like 1000?
I don't know how much to set the Rate. I don't want to cost fee. If it's for free, I want to set it to 9999999.
Thanks for your reply

First of all, you need to deposit your Litecoins in the account. It is usually done in some Account deposit section. Once, your transaction is confirmed. You can move to the homepage and select the Litecoin -> Bitcoin page and enter the required numbers and hit the Buy button. That's it!


text:
Why one would need *extended* public keys for auditing a bip32 wallet?
(I am reading the bip32 for an altcoin development.)
In the bip32 specification, it is written that listing all incoming and outgoing payments of a hierarchical deterministic wallet would required the extended public keys.

In case an auditor needs full access to the list of incoming and outgoing payments, one can share all account public extended keys. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.

Wouldn't the (non-extended) elliptic curve encryption's public keys work too ?
Furthermore, if I understand the spec properly, sharing an extended public key isn't really safe since knowing a descending non-hardened private key would then expose all the keys descending from this first extended public key...and sharing a non-extended public key would avoid the problem.

Why one would need extended public keys for the auditing a bip32 wallet?

You don't need them. You could also just make a list of all of the addresses that have a balance, and send that to your auditor.
Auditing a Bitcoin wallet is not a very good example of what this is capable of. Here are some other uses of BIP32:

You could have a script on a server with an extended public key generate addresses for people to donate to, without having that same server be able to spend money sent to those addresses. Without BIP32, you'd have to make a long list of addresses, put them on your server, and replenish them whenever they ran out.
You could have an e-commerce app generate addresses like the above, and detect payments to those addresses without, again, having the ability to spend them.

Wouldn't the (non-extended) elliptic curve encryption's public keys work too?

No. You also need the chain code to calculate the subkeys. Collectively, these two things make up an extended public key.

Furthermore, if I understand the spec properly, sharing an extended public key isn't really safe since knowing a descending non-hardened private key would then expose all the keys descending from this first extended public key.

It's... debatably safe. I don't think there's a real-word situation where someone would compromise one of your non-hardened private keys without having access to all of them.

In my mind, you didn't need to calculate subkeys since you give all the (used) public keys (N(M/*)). But in this case you would need to store all the public keys.

you didn't need to calculate subkeys since you give all the public keys (N(M/*)) I don't understand. Could you clarify?

Well (I'm no expert at all so I may say something totally wong) each transaction related to the wallet use a public key (point on ec) so storing the used points should be enough to perform an audit without sharing the chaincodes, isn't it ?

@idkwptc You could store the used points or the addresses. Either would work, for an audit.

Ok, I wanted to be sure I understood the principle. Sharing the extended public keys as advised in the specs looked "debatably safe" to me given the way the keys were generated. Thank you for your time ! :)

Btw, I said something (partially) wrong earlier. The way the key are generated, the owner of the wallet "knows" the used key by the indexes (M/x/y/z) of the keys so no need to store explicitly the points/addresses sharing non-extended public keys...a great secure way to use hd wallets !

I have downloaded bitcoin core, do you happen to know where can I find the bip32 extended key for this wallet ?