text:
what is exact meaning of some field of response of `getBlock` rpc api
I refer to this document for using getBlock rpc api.
https://bitcoin.org/en/developer-reference#getblock
{
  "hash" : "hash",     (string) the block hash (same as provided)
  "confirmations" : n,   (numeric) The number of confirmations, or -1 if the block is not on the main chain
  "size" : n,            (numeric) The block size
  "strippedsize" : n,    (numeric) The block size excluding witness data
  "weight" : n           (numeric) The block weight as defined in BIP 141
  "height" : n,          (numeric) The block height or index
  "version" : n,         (numeric) The block version
  "versionHex" : "00000000", (string) The block version formatted in hexadecimal
  "merkleroot" : "xxxx", (string) The merkle root
  "tx" : [               (array of string) The transaction ids
     "transactionid"     (string) The transaction id
     ,...
  ],
  "time" : ttt,          (numeric) The block time in seconds since epoch (Jan 1 1970 GMT)
  "mediantime" : ttt,    (numeric) The median block time in seconds since epoch (Jan 1 1970 GMT)
  "nonce" : n,           (numeric) The nonce
  "bits" : "1d00ffff", (string) The bits
  "difficulty" : x.xxx,  (numeric) The difficulty
  "chainwork" : "xxxx",  (string) Expected number of hashes required to produce the chain up to this block (in hex)
  "nTx" : n,             (numeric) The number of transactions in the block.
  "previousblockhash" : "hash",  (string) The hash of the previous block
  "nextblockhash" : "hash"       (string) The hash of the next block
}

I want to know meaning size and bits

What is size field mean?? block size as byte??
What is bits field mean?? block size as bits??

May I use chainwork diff for calculating hash power for each block?
According to this doc, https://bitcoin.org/en/developer-reference#getblock, chainwork means
 "chainwork": "xxxx"           (string) total amount of work in active chain, in hexadecimal

For example, let's assume that chainwork of block 12345 is 1111 and that of block 12344 is 1100.
Then may I consider that hash power for block 12345 is 11 since 1111 - 1100 is 11?

size refers to the size of the block, which is 80 bytes for the header + sum(tx_sizes). As pointed out in the comments, this includes the segwit data and is meant to match the actual, on disk size of the block.
bits refers to nBits, which encodes the target difficulty for the block. You can see an explanation of the encoding scheme here.
chainwork represents the sum total of the expected hashing operations required to product the chain up to this block - this means that you cannot use it for calculating the hash power for the current block, as it is the sum of all the hashing required to produce every block from the genesis block up until the current block.
In fact, you can never get a precise measurement of the active hash power based on a single block. However, there are ways to calculate the average/expected hash power on the network at a given point in time, as described in this question.

As per my understanding the size reflects the actual size of the block on disk including the witness. I think what you are referring to is strippedsize.

@UgamKamat You're right, I somehow completely missed the introduction of the stripped size field! I've edited the answer


text:
spend balance using master key
We can spend balance of an address if we have private key. is it true for master private key too? I mean, we could spend spend balance using master private key? or we should use child private key?

A Bitcoin transaction to an address has to be spent using the specific private key that corresponds to the public key whose hash is the address.  In this case, that's the child private key.
Of course, if you have the master private key, you can compute the child private key from it.  Your Bitcoin wallet client might even do that for you.  But at the last step, it's the child private key that is used.

what about generating addresses from child public key not child private key? then I have no child private key

@max: I don't understand.  Your question was about spending balances.  You can't spend a balance without a private key.

source: Stack Exchange

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

sort: votes


text:
Is it possible to delete received or sent transaction in your mobile btc wallet
Please help me to delete transactions from my wallet. I looked everywhere and cant find any help

What wallet app are you using?  What do you mean by "delete"?  Do you want to actually undo the transactions (normally not possible) or just not have them show up in your app?

I use bitcoin wallet 5.17 on my mobile. I just want to delet some transactions. Not undo i just don't want to see them anymore. Is that possible cause i don't see any option in settings

Why would you want to do that?

Because i have so many and i wanted to "clean" my wallet  thanks

The Bitcoin Wallet App doesn't have the option to delete or hide transactions from the list.

Perhaps you could expand this answer to make it a little better.  For instance, you aren't even mentioning which wallet doesn't support these features.  Someone would have to look to the comments of the question in order to determine what you are referring to, and even then it's not clear.

@Jestin: I agree that the answer is pretty short, but to be fair, the tag "bitcoin-wallet-app" is referring to a specific wallet software of which Andreas is the maintainer. ;)

Actually does anyone of you know of any wallet that supports deleting/hiding transactions? Or, for that matter, any bank account? If not, I think we can make this a generic question, agnostic of any specific wallet.

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


text:
Have the early mined coins been moved/transacted?
Has anyone done an analysis of the early coins mined by Satoshi and Hal Finney? Have those coins been moved/spent/transacted?
I wonder whether Satoshi has been cashing in on his collection or does he just let it sit there?

Related: http://bitcoin.stackexchange.com/questions/20565/which-wallets-belong-to-satoshi-nakamoto

The earlist blocks have not been spent (except for block 9). You can be alerted by email when new transactions occur here http://bitcoinwhoswho.com/address/12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S/

You can watch the movement of coins on blockexplorers. Usually beside an output there is a spent/unspent designation.
If you look at block #10 for example
https://blockchain.info/block/000000002c05cc2e78923c34df87fd108b22221ac6076c18f3ade378a4d915e9
you see that the output (addr: 15yN7NPEpu82sHhB6TzCW5z5aXoamiKeGy) remains unspent.
You can look through other blocks in the same manner.

authors: ชินกฤต ฮ้งเจริญ


text:
Is it possible to create a blockchain network which will not increase in difficulty?
I would like to create a blockchain network which will stay at the same level of complexity, meaning it won't take longer or need stronger hardware to mine.
Is such a thing possible?

If complexity does not increase, then miners will be able to mine faster and faster as new hardware becomes available.  I'm sure it is possible, but it may not be desirable.

You might for instance consider what Bitcoin would be like if the network were creating 1 billion new valid blocks per second.  That's what it would be if the difficulty had never gone up.

The plan is to raise the level of difficulty as hardware progresses, my point was that I don't want the size of the blockchain to affect the speed of mining.

@EliahuHorwitz: The size of the blockchain does not affect the speed of mining.

Then why does Bitcoin become much harder to mine? Is that by design?

I've invited you to join us in the Bitcoin chat, but I guess your question is answered here already:  https://bitcoin.stackexchange.com/q/855/5406 https://bitcoin.stackexchange.com/q/5838/5406

Great thanks! Write it as an answer and I'll upvote

@Murch thanks, what exactly is Bitcoin chat? I'm new to this tech stack forum...

@EliahuHorwitz: You should have a notification in the top bar (look for a red box with a number in it).

@Murch I have another question, when a wallet connects it needs to sync, is that right? Is it the same for a miner? If so, is there a way to make this a matter of milliseconds and not hours?

Let us continue this discussion in chat.

@EliahuHorwitz: Did that work for you?

@Murch ya, give me 5 minutes to open up my pc and I'll get on the chat

It is possible, but very stupid to do. If you keep the difficulty the same, hardware will get better and better over time (or just more of it is used to mine your altcoin) and this will cause blocks to be produced faster and faster and faster. This makes attacks much easier to take place too.

The network would quickly melt down and become unusable as blocks were created faster than they could be propagated across the network.


text:
How to purchase and send bitcoins
I tried Blockchain in 2015 through an account with Laissez Faire, but could not get help signing up, so I just let the account go. Now I decided to try it again and I am still lost.  How can one send bitcoins to others if you haven't purchased any? Please, I cannot learn without asking questions whether the questions sound dumb or not.  Please help educate me.

I am not sure what your question really is?  I only see one question mark in your post and the answer is you cannot send bitcoins until you have some, which most people do by purchasing.

In addition to asking, you can also learn by reading what's already been asked.  Perhaps http://bitcoin.stackexchange.com/questions/91/how-do-you-obtain-bitcoins will be helpful.

There is no credit in Bitcoin. Therefore, you cannot send any bitcoins until you have either purchased or earned some.

How do you purchase bitcoins?

@Precious: As Nate already linked above: How do you obtain bitcoins?


text:
How was transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b mined?
The OP_HASH256 puzzle transaction described here was mined in block 211997. But I read that only standard transactions (with outputs one of P2PK, P2PKH, bare multisig, P2SH, OP_RETURN) get relayed. So how did this transaction get relayed and mined?

"Relayed" and "mined" are completely separate processes and should not be conflated.
The transaction is valid, so it was perfectly fine to mine it (i.e. include it in a valid block).
"Standard" is a more restrictive requirement, and as you say, this transaction is not standard.  That means that a default version of Bitcoin Core will not relay it, i.e. will not transmit it to other nodes on the Bitcoin peer-to-peer network.  But if the transaction reaches a miner some other way, they are perfectly free to include it in a block.
We can only speculate as to how that occurred in this case, but here are some possibilities:

Some people were running a modified version of the Bitcoin client (or alternative Bitcoin software) that does relay non-standard transactions.
The creator of the transaction sent it directly to a miner, by some means other than the peer-to-peer network.  Some miners or pools have web sites where anyone can submit a transaction.
The transaction was created by the miner herself.

Thanks for the fast answer! I had in fact assumed that "valid" and "fit to relay" were the same thing. And good to know about various ways to get a non-standard transaction mined.


text:
Is there developer documentation for the Bitcoin Core source code?
Is there a documentation somewhere to understand the C++ code of Bitcoin Core (available on Github) "from a to z" and being able to recreate it ?

You mean other than the source itself (https://github.com/bitcoin/bitcoin) or the developer documentation (https://bitcoin.org/en/developer-documentation)?  Also, this SE site is a wonderful resource for specific questions :)

@Jestin: That should be an answer, not a comment. ;) Perhaps add in the Princeton Bitcoin Book.

I wasn't sure this was precisely what @smoumou was looking for, but I'll post it as an answer just in case.

To understand Bitcoin Core, the best resource is probably the source code itself:
https://github.com/bitcoin/bitcoin
To help understand what is going on in the code, try the developer documentation and the Princeton Bitcoin Book.  Keep in mind that the code gets updated faster than the documentation, so the code should be your source of truth.
Some interesting places to start:
https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp - this is the source file that contains the code for interpretting script, and therefore checks for transaction validity
https://en.bitcoin.it/wiki/Protocol_documentation - the docs for the network protocol, such as message definitions and data structures
https://bitcoin.org/en/developer-reference#transactions - transaction reference describing the content and construction of transactions
For any clarifications and questions, I highly recommend this very StackExchange site :)

First thanks for the answer, I have to say I was looking for a documentation about the C++ code available on Github, I already looked at the developper documentation and read the book "Mastering bitcoin" wrote by Mr. Andreas Antonopoulos and it gave me detailed explanations about the protocols but my purpose is to go as deep as I can taking the source code to understand each line to be sure of what this software  really does with my computer and I really don't know how to start (I am currently ready all classes starting from bitcoin-cli.cpp but it is not really efficient).

I've edited my answer to specify a few of the places I recommend diving into.  This is basically just my opinion of what's interesting, so keep in mind that others would tell you to start elsewhere.  Personally, I think the encumbering and unencumbering of transaction outputs are the heart of Bitcoin, so I've pointed you to the script part of the code.  I've also singled out the network protocol, since communication between peers is another fundamental aspect.  Again, just my opinion.

@smoumou: Please also edit clarifications back into your original question, so that other answeres don't have to check all answers before adding one.

Couple of years ago, i created a few articles on bitcoin core code analysis. It is here:
http://embedded-design-vic.blogspot.com/2017/07/bitcoin-core-tutorial-and-source-code.html

Articles aren't noob-friendly at all; they're kinda bardly formatted too; you use jargons I've never heard about before and don't explain any of them. I'm not saying these blog entries are unuseful, I believe you know a lot about it too, but you can't call these a "From A to Z Bitcoin Core", more like a "indepth Bitcoin Core for experts" probably.

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


text:
Best simple linux cmd tool for offline transaction creation and signing?
I tried to use sx, but it no longer works since bip62 (malleability fix). Nodes don't accept generated transactions, saying "high S signature".
What offline command-line tool would be the best?

Please don't use the "edit" function to vandalize your own post.  There is a "delete" button; use that instead if you really want to.  But three people have found your question useful, so you might consider leaving it.  If you wanted to delete the question because you found the answer, consider adding your own answer, so that it can be of use to others.

There are many command line tools for creating and signing raw transactions offline, most of them written in Python: pycoin, python-bitcoinlib, pybitcointools and others.
If you use Electrum wallet, it has command line tools for offline transaction creation and signing:
$ ./electrum help createrawtx
$ ./electrum help signtransaction


text:
Why is the block size limited to 2mb?
bitcoin is experiencing mass gross. Even some local businesses around me are starting to accept bitcoin payments. Of coarse, with new growth availability problems arise; and one is the slow and high transaction fees.
It seems the reason to this is because there is only one block every 10 minutes, and each have a 2mb size limit. Why is this? Why don't we remove the size limit? It sounds like a simple problem that has a easy solution. Wouldent miners make more coins from the extra fees from the extra transactions in each block? What our are other solutions?

Remove the block limit today, and tomorrow someone will mine a block that is 500 TB.  Have fun storing / relaying / verifying that, all you full nodes out there.

(Actually that's a deep, political question, but I'll answer it neutrally)

Why is this? Why don't we remove the size limit?

As Nate Elredge said, miners can create free transactions. RIP Blockchain.
The limit also protects the blockchain from spam attacks - the dust transactions stay in the mempool.

It sounds like a simple problem that has a easy solution

Hard forks. It may take until forever to wait for people upgrading their nodes compatible with the HF. Also SegWit is a clever trick: "block size increase as a soft fork". In the future, the witness blocks' size can be increased so that Bitcoin won't need a block size increase anymore. (Actually this needs another complex trick, like SegWit)

Wouldn't miners make more coins from the extra fees from the extra transactions in each block?

Nope. If blocks were bigger, the users would set lower fees and the miners would earn the same.

What our are other solutions?

Schnorr. A signature system that is much more size (bytes) efficient. This would require a hard fork (or another soft-fork trick), but would work. Or as I said above, a newer version of SegWit that increases witness block size. Or maybe FlexTrans, a compressed transaction format (It looks like Bitcoin won't have it.) Or the most likely one: Layer two solutions: Lightning network, Liquid... They'll allow low fee instant payments, while keeping blockchain size low.

hm, interesting post. I like the abstract ideas you shared.

Signatures take up a large portion of the transaction data, but the rest of the data still has to fit in the 1mb limit, right? So, it looks to me like there is a upper bound on how much you can increase the size limit of the witness data.

@surjikal Exactly! There's no difference between 1 MB + 20 MB Witness and 1 MB + 40 MB Witness. Even worse, SegWit will be inefficient when Shnorr comes. More information on https://www.deadalnix.me/2017/02/27/segwit-and-technologies-built-on-it-are-grossly-oversold/ under the title of "Schnorr signatures will provide addition capacity"


text:
Why is the Bitcoin Core HWI written in Python? If it was rewritten in Rust should the Python HWI still be maintained?
Why is/was the Bitcoin Core HWI written in Python?
What have the challenges been of having the HWI written in Python?
There seems to be interest and rationale(s) to write another HWI in Rust. Would there be a strong rationale to continue to maintain the Python HWI if there was a Rust HWI? MicroPython is a popular Python implementation (optimized to run on microcontrollers) for hardware wallets. Does Rust have an equivalent and is it widely used?

Why is/was the Bitcoin Core HWI written in Python?

The biggest factor was that, at the time, every the major hardware wallet vendor provided a Python library to interact with them. Over time, this has remained true - as new hardware wallets have been created, they usually come with Python libraries (e.g. Bitbox02, Coldcard), but this is potentially attributable to the fact that HWI exists.
Additionally, HWI started out as some scripts for experimentation and mostly as a toy project. Given that I am familiar and comfortable with Python, and Python is very convenient for experimentation, it made sense to use it
However, as with any open source project, some decisions made at the beginning for the sole author's convenience can come back to bite us.

What have the challenges been of having the HWI written in Python?

One of the targets for HWI is to have standalone binaries that can be called by other software. This is actually rather difficult to do in Python. It requires the use of other tooling like PyInstaller to produce those binaries. These binaries are rather inefficient as well since they are self extracting archives that contain a full Python interpreter. This has been problematic on some systems, and some downstream consumers of HWI have opted to repackage the binaries differently in order to better suit their users.
Additionally, none of the tooling to create standalone Python binaries can "cross compile". They can only create binaries targeted for the OS and CPU architecture that the program is being run on. While for Windows this can be worked around with WINE, it is not possible to do so for MacOS, thus requiring the builder(s) to spend a large sum of money in acquiring hardware to create those binaries.
Another major issue has also been reproducibility. One of the objectives for HWI was to make the binaries reproducibly built. This has been rather difficult because of how PyInstaller repackages the running Python interpreter, so Python itself needs to be rebuilt reproducibly on each system that we want to support. This is majorly annoying, given that Python itself is not reproducible on all systems.
Python also has some issues around dependencies. A user may be missing a dependency and never notice it until they decide to run some part of the code that requires a dependency. Then it will start mysteriously failing. This can generate several unnecessary support tickets.
With dependencies are also issues with the dependency graph. Since it's really easy to install a dependency with pip, it's very easy to run into issues where a minimal dependency actually isn't so minimal since it pulls in a ton of other dependencies. This makes it hard to audit the entirety of the code that's actually being run. However this is not unique to Python, as NodeJS and rust can have a similar problem.
Lastly, since Python is an interpreted language that is weakly typed, it's really easy to accidentally write bugs related to types or incorrectly assuming that a particular value will be of some type when it is not. Since the code may be syntactically correct, Python will not give an error until the buggy code is executed, which may not always happen. An example of this is using a[key] for a list. This will raise a KeyError when it is executed, but otherwise Python won't tell you that it's wrong.

There seems to be interest and rationale(s) to write another HWI in Rust. Would there be a strong rationale to continue to maintain the Python HWI if there was a Rust HWI? MicroPython is a popular Python implementation (optimized to run on microcontrollers) for hardware wallets. Does Rust have an equivalent and is it widely used?

No, there would not be a strong reason to continue to maintain a Python HWI if a compiled language version sufficiently replicated all of its functionality. This doesn't even require things that use MicroPython or other Python interpreters to really change (also I don't think HWI works in MicroPython).
Compiled languages produce machine code binaries. These can be libraries that have an external API which have bindings in every language. This allows such a project to be used with any other language. These can be automatically generated, and there are several projects that can do this pretty well. They can also be handwritten. If a rust HWI reproduced HWI's Python APIs exactly, it could be used as a drop in replacement. There doesn't need to be a rust equivalent for MicroPython, there just needs to be Python bindings for the rust library.
However, it also wouldn't make sense to have HWI run in MicroPython. It's software for the host, not the hardware wallet.

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


text:
What's the difference between the anti klepto protocol and anti exfil?
What is the difference between the anti-klepto protocol (also here) and Anti-Exfil? Is it the same thing just with different names or are there differences? It seems they are both addressing the nonce covert channel attack?

Is it the same thing just with different names [...]?

Yes.
This became known as "anti-klepto" initially (full disclosure: I suggested this name). Later, a decision at Blockstream was made to refer to the project as "anti-exfil", for the simple reason that the word "kleptography" is a very rare term that probably only cryptography experts have heard of (as opposed to "exfiltration", which is understandable to a wider audience).


text:
Why do some Bitcoin Core "good first issues" require scripted-diffs?
I am looking at a good first issue on the Bitcoin Core repo to find and replace a string. But it appears I need to write a scripted-diff and the examples look complicated. What is the point of the scripted diff? Why is it required for such a simple change?
This question was asked by prayank23 on GitHub and has been paraphrased.

From the Bitcoin Core developer notes, when the bash script is included in the commit message the "Travis CI job checks that the result of the script is identical to the commit." It also makes it more efficient to review for reviewers if they can review and run a bash script rather than needing to do additional checks that the PR covers all the cases it should.
With regards to the scripted-diff examples looking complicated you can look through other examples in the Bitcoin Core repo by running:
git log --grep="-BEGIN VERIFY SCRIPT-"

Alternatively here is a simpler example that you can start from if you are trying to do a basic find and replace exercise.
For more information on scripted-diffs see Jon Atack's personal notes on scripted-diffs.
If you need help writing your bash script you can ask questions on #bitcoin-core-pr-reviews on IRC.


text:
How to verify Bitcoin Core Release Signing Keys
I use Gpg4win but I don't know the step to verify the Bitcoin Core Release. can you give me the instruction how to verify released?
I got this result
C:\WINDOWS\system32>gpg2 --keyserver pgp.mit.edu --recv-keys 0x90C8019E36C2E964
gpg: conversion from `utf-8' to `CP720' not available
gpg: requesting key 36C2E964 from hkp server pgp.mit.edu
gpg: key 36C2E964: "Wladimir J. van der Laan (Bitcoin Core binary release signing key) <laanwj@gmail.com>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

This answer depends on that you are using Bitcoin Core 0.13.1 and you have downloaded bitcoin-0.13.1-win64.zip, this answer will also work with any other bitcoin version or download with only change signer public key, checksum file and bitcoin download name.
First you need to import public key of the signer, in this case the key with id: 0x90C8019E36C2E964, you do that by --recv-keys command line argument.
gpg2 --keyserver pgp.mit.edu --recv-keys 0x90C8019E36C2E964

Or you can manually download it from: http://pgp.mit.edu/pks/lookup?op=get&search=0x90C8019E36C2E964
Next you need to download the signature file from her: https://bitcoin.org/bin/bitcoin-core-0.13.1/SHA256SUMS.asc, and store it in same folder where bitcoin core download is stored. Then you need to check that the SHA256 checksum is valid.
sha256sum --check SHA256SUMS.asc

Don't care about FAILED open or read or No such file or directory messages, you are looking for something like this:
bitcoin-0.13.1-win64.zip: OK

If the checksum is valid, then you validate that the signature is good (checking that the checksums file is not tampered with). This is done by:
gpg2 --verify SHA256SUMS.asc

This should output something like this:
gpg: Signature made Thu 27 Oct 2016 08:21:11 PM CEST
gpg:                using RSA key 0x90C8019E36C2E964
gpg: Good signature from "Wladimir J. van der Laan (Bitcoin Core binary release signing key) <laanwj@gmail.com>"

EDIT:
If you get following message:
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 01EA 5486 DE18 A882 D4C2 6845 90C8 019E 36C2 E964

You have problems with trust, in other words, the public key for Wladimir J. van der Laan is not marked as a trusted key in gpg. You can mark it with some easy steps.
gpg2 --edit-key 0x90C8019E36C2E964 ↵
trust ↵
5 ↵
quit ↵

You don't need to use 5 as trust, you can choose 1-5:
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately

The key for Wladimir J. van der Laan has since expired? Their new one is 71A3B16735405025D447E8F274810B012346C9A6 which can be found at https://github.com/bitcoin/bitcoin/blob/master/contrib/builder-keys/keys.txt

This answer is valid for old versions of Bitcoin Core. See @kajoseph's answer below for instructions for verifying Bitcoin Core download starting from 22.0: https://bitcoin.stackexchange.com/a/110517/101498.

As of Bitcoin Core v22.0, the signing and signature verification procedure has changed. See "Verify your download" on bitcoincore.org/en/download for the official documentation.
Basically, the difference is that instead of a single signer there are now multiple signers that you can choose from. SHA256SUMS has the checksum hashes of the binaries, and then several key signers signed SHA256SUMS and stored their signatures in SHA256SUMS.asc. So to verify, you'll need to verify any signatures that you trust and then verify the checksum.
To verify v22.0+:

Download a GPG key of at least one of the Bitcoin Core devs you trust (multiple is better). A list of keys is listed at the bottom:

Find a GPG fingerprint
gpg --keyserver keys.openpgp.org --search-keys <email address or GPG key fingerprint>

At the prompt, enter the number of the key you want to import.

Note: keys.opengpg.org is a good keyserver but you can also try pgp.mit.edu or keyserver.ubuntu.com. You can also manually download the key file by going directly to the keyserver in your browser and import the key by using gpg --import <file>.

Download the SHA256SUMS.asc, SHA256SUMS, and bitcoin-<version>-<architecture>.<tar.gz|zip|exe> from the official source (link to v22.0)

Verify the signing signatures

gpg --verify SHA256SUMS.asc SHA256SUMS

You might see some "Can't check signature: No public key" if you're missing keys, but look for "Good signature from ..." for the keys you have imported. On linux you can also append  2>&1 | grep "Good signature" to the end of the above command to filter out the noise.

Verify the checksum hash in SHA256SUM that corresponds to your binary.

On Windows, you can right click on the binary > CRC-SHA > SHA-256 to view the hash and compare to what you see in SHA256SUM.
On linux, you can use the following command:
grep " bitcoin-22.0-x86_64-linux-gnu.tar.gz" SHA256SUMS | sha256sum -c

That's it!
List of signers' keys:
0xb10c@gmail.com: 0CCBAAFD76A2ECE2CCD3141DE2FFD5B1D88CA97D
Andrew Chow achow101@gmail.com: 152812300785C96444D3334D17565732E08E5E41
Ben Carman benthecarman@live.com: 0AD83877C1F0CD1EE9BD660AD7CC770B81FD22A8
Antoine Poinsot darosior@protonmail.com: 590B7292695AFFA5B672CBB2E13FC145CD3F4304
Duncan Dean duncangleeddean@gmail.com: 28F5900B1BB5D1A4B6B6D1A9ED357015286A333D
Stephan Oeste stephan@oeste.de: 637DB1E23370F84AFF88CCE03152347D07DA627C
Michael Ford fanquake@gmail.com: CFB16E21C950F67FA95E558F2EEB9F5CC09526C1
Oliver Gugger gugger@gmail.com: 6E01EEC9656903B0542B8F1003DB6322267C373B
Hennadii Stepanov hebasto@gmail.com: D1DBF2C4B96F2DEBF4C16654410108112E7EA81F
Jon Atack jon@atack.com: 82921A4B88FD454B7EB8CE3C796C4109063D4EAF
Wladimir J. van der Laan laanwj@gmail.com: 9DEAE0DC7063249FB05474681E4AED62986CD25D
unknown: 9D3CC86A72F8494342EA5FD10A41BDC3F4FAFF1C
Will Clark will8clark@gmail.com: 74E2DEF5D77260B98BC19438099BAD163C70FBFA

It is documented on the website. See "Verify your download" on https://bitcoincore.org/en/download/

Ah yes, indeed it is! I incorrectly looked at the community website bitcoin.org. Thanks for the correction

bitcoin org hasn't even updated to list 22.0...

Signers keys can be verified here: https://github.com/bitcoin/bitcoin/blob/master/contrib/builder-keys/keys.txt

To verify the build/downloaded file see the bitcoin core website: https://bitcoincore.org/en/download/.
They have a step by step for each platform under "Verify your download"


text:
Where can I find actual official documentation for bitcoin.conf?
As in title, where is actual bitcoin.conf docs?
Protocol is evolving, and many articles are not accurate regarding do bitcoin.conf.

An example bitcoin.conf file for the current Bitcoin Core version (25.0 at time of writing) is here and a tool for helping you generate a config file is here.


text:
Why is Bitcoin Core using LevelDB instead of Redis or SQLite?
Why did Core move from BDB to LevelDB? Why don't they use SQLite or move to Redis now? Is there a technical reason for this choice?

The bdb->leveldb change was made to increase speed while validating blocks and during initial block download. Also, doesn't redis require that you load your entire dataset into memory? Pretty painful for a 60GB blockchain.

but redis uses LZF light data compressor , this won't help to reduce the data volume in memory? and i thought leveldb was chosen because it supports high caching data.

LevelDB also supports compression. We explicitly disable it in Bitcoin Core because it does not help (almost all the data in the database consists of uncompressible cryptographic material anyway: hashes, keys, signatures).

@Nick We wouldn't store the entire blockchain in the database anyway.

as i know we store only the blocks and the state of validation < blockchain

Not even the blocks. Those are stored on disk, but not in a database. The only data of significance in the database is the UTXO set.

Redis and LevelDB solve very different problems. We tried using SQLite and its performance was abysmal.
Bitcoin Core needs a database to store the set of unspent transaction outputs (UTXOs). This means we need fast simple reads, and fast batches of random updates.
We don't need a server/client architecture, as we can't have multiple applications accessing the database at once anyway: inconsistencies in the database would lead to forking risks (every node in the network needs to make exactly the same judgement about what is valid and invalid).

Has LMDB been considered?

@Pieter Wuille Do you consider that moving from BDB to LevelDB was a correct decision? Or LevelDB is causing major problems that didn't happened with BDB? (ex: file corruption, bugs ...)


text:
Looking for a serious alternative to Nicehash... can you please help?
After the collapse of Nicehash I am trying to find an alternative that will let me mine Monero/XMR algorithm ONLY and get paid in BTC just like Nicehash used to do.
In other words, I don't need any service that will decide for me the coin to mine, but I NEED to be in control of what coin/algo to mine, and that algo must be Monero, as it is very energy-efficient for the kind of rigs I have.
I know that Minergate does this, however I am very reluctant to use them as I have strong suspicions that they steal most of my shares for what I can see.
Do you guys know and could recommend for me such a service?
Thanks so very much for your help!

Suggest you just mine Monero in a pool and then sell the coins for BTC yourself

Thanks but I am looking for a FULLY AUTOMATED solution like Nicehash used to be.

Technically questions about service provider availability are off topic on this site by the way


text:
Non-witness P2SH spending using C++ libbitcoin
I am trying to spend an UTXO (non-witness P2SH) using libbitcoin. I've look at libbitcoin-system wiki documentation (https://github.com/libbitcoin/libbitcoin-system/wiki) but haven't found a solution for my problem. Unfortunately, the page only provides guide to nested-segwit P2SH spending.
The redeem script is the following =>
<expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

Below is the C++ code I wrote to spend =>
    int main() {
        wallet::ec_private privateKey1("secret for obvious reason");
        wallet::ec_public publicKey1 = privateKey1.to_public();
        data_chunk pubKey1 = to_chunk(publicKey1.point());

        short_hash KeyHash1 = bitcoin_short_hash(publicKey1.point());
        data_chunk locktime;
        extend_data(locktime, to_little_endian<uint32_t>(1713352486));

        script redeem_script = script({operation(locktime), operation(opcode(177)), operation(opcode(117)), operation(opcode(118)), operation(opcode(169)), operation(to_chunk(KeyHash1)), operation(opcode(136)), operation(opcode(172))});

        wallet::payment_address from_address1("p2sh-cltv-address");
        wallet::payment_address to_address1("p2pkh-legacy-address");

        hash_digest prev_txid1;
        decode_hash(prev_txid1, "prev-txid-in-hexadecimal-format");

        uint32_t input_index1 = 0;
        output_point vin1(prev_txid1, input_index1);

        //make Input
        input input1 = input();
        input1.set_previous_output(vin1);
        input1.set_sequence(0xfffffffe);

        uint64_t output_value1;
        decode_base10(output_value1, "0.00999770", 8);
        script output_script1 = script().to_pay_key_hash_pattern(to_address1.hash());
        output output1(output_value1, output_script1);

        // Get current time as a time_point
        auto now = std::chrono::system_clock::now();
        auto epoch = std::chrono::system_clock::to_time_t(now);
        auto unix_time = static_cast<uint32_t>(epoch);

        chain::transaction tx = chain::transaction();
        tx.set_version(2);
        tx.set_locktime(unix_time - 100000);
        tx.inputs().push_back(input1);
        tx.outputs().push_back(output1);

        endorsement sig1;
        if (script::create_endorsement(sig1, privateKey1.secret(), redeem_script, tx, 0u, sighash_algorithm::all, script_version::zero, 1000000))
        {
            std::cout << "Signature: " << std::endl;
            std::cout << encode_base16(sig1) << "\n" << std::endl;
        }

        operation::list scriptSig1;
        scriptSig1.push_back(operation(sig1));
        scriptSig1.push_back(operation(pubKey1));
        scriptSig1.push_back(operation(redeem_script.to_data(0)));
        script unlockingScript1(scriptSig1);
        std::cout << unlockingScript1.to_string(0) << "\n" << std:: endl;

        //Make Signed TX
        tx.inputs()[0].set_script(unlockingScript1);
        std::cout << "Raw Transaction: " << std::endl;
        std::cout << encode_base16(tx.to_data(true, true)) << std::endl;
        return 0;
    }

The broadcast of the created raw-transaction returned an error (Signature must be zero for failed CHECK(MULTI)SIG operation), which indicates that something went wrong with the signature part. I checked every (at least I think so) details, from scripts to values but I can't tell exactly what is wrong. Can somebody help?

The issue is no more now. The problem was with the script version (which was set to zero in the code presented above). Instead of "script_version::zero", the correct configuration in this case was "script_version::unversioned".


text:
Help understanding OP codes on multisig redeem script (hex)
I was reading this gist and am not sure I am understanding/reading the hex of the multisig's redeem script correctly (line 14). It is:
52410491bba2510912a5bd37da1fb5b1673010e43d2c6d812c514e91bfa9f2eb129e1c183329db55bd868e209aac2fbc02cb33d98fe74bf23f0c235d6126b1d8334f864104865c40293a680cb9c020e7b1e106d8c1916d3cef99aa431a56d253e69256dac09ef122b1a986818a7cb624532f062c1d1f8722084861c5c3291ccffef4ec687441048d2455d2403e08708fc1f556002f1b6cd83f992d085097f9974ab08a28838f07896fbab08f39495e15fa6fad6edbfb1e754e35fa1c7844c41f322a1863d4621353ae
So I see the three public key pairs, beginning in bold text. I understand that the last byte (0xae) is OP_CHECKMULTISIG. But I am confused about the bytes (0x53, before 0xae) and the 5241 at the beginning. I am under the impression that before the public keys there should be two variables pushed onto the stack; one because of the checkmultisig bug and another to identify the m of n required signatures to unlock the bitcoin. And then n should come right before the last opcode (3 in this case).
What am I not understanding correctly? What's up with those fives and the 41 at the beginning? Thanks for the help!
Link to gist if broken: https://gist.github.com/gavinandresen/3966071

You are on the right track. 0x52 and 0x53 are the multisig elements ("2 of 3"), and 0xae terminates the structure. The "off by one error" comes before the signatures, which is in lines 58-60 of the gist. A good explanation of the multisig is (of course) in Andreas' book "Mastering Bitcoin". I have decoded the structure below:
    52: OP_2:                the number 2 is pushed onto stack
    41: OP_DATA_0x41:        uncompressed pub key (65 Bytes)
        0491BBA2510912A5:BD37DA1FB5B16730
        10E43D2C6D812C51:4E91BFA9F2EB129E
        1C183329DB55BD86:8E209AAC2FBC02CB
        33D98FE74BF23F0C:235D6126B1D8334F
        86
        MultiSig's uncompressed Public Key (X9.63 form)
        corresponding bitcoin address is:    139FpKh63Vn4Y73ijtyqq8A6XESH8brxqs
    41: OP_DATA_0x41:        uncompressed pub key (65 Bytes)
        04865C40293A680C:B9C020E7B1E106D8
        C1916D3CEF99AA43:1A56D253E69256DA
        C09EF122B1A98681:8A7CB624532F062C
        1D1F8722084861C5:C3291CCFFEF4EC68
        74
        MultiSig's uncompressed Public Key (X9.63 form)
        corresponding bitcoin address is:    1PNvbXZFysxvx3252w9JHMa7zbG95snqnm
    41: OP_DATA_0x41:        uncompressed pub key (65 Bytes)
        048D2455D2403E08:708FC1F556002F1B
        6CD83F992D085097:F9974AB08A28838F
        07896FBAB08F3949:5E15FA6FAD6EDBFB
        1E754E35FA1C7844:C41F322A1863D462
        13
        MultiSig's uncompressed Public Key (X9.63 form)
        corresponding bitcoin address is:    1jqo3ptYSnUhCJq75MMyRuwC2zNyQqRy3
    53: OP_3:                the number 3 is pushed onto stack
        ##### --> 2-of-3 Multisig
    AE: OP_CHECKMULTISIG:    terminating multisig

        corresponding bitcoin address is:    3QJmV3qfvL9SuYo34YihAf3sRCW3qSinyC

Ok, that makes sense. I was unclear on how OP_2-16 worked but your answer I believe clears that up. Hypothetically then if this was a  m=10 and n=13 scheme then we would have 0x5a and 0x5d? Our highest possible value for field n being 0x60, no? Thanks for the help!

the codes are listed here: https://en.bitcoin.it/wiki/Script#Constants, and yes, 0x5a and 0x5d. Highest value = 0x60 (OP_16). Hint: multisigs have their limitations, you cannot easily create a 10-of-13 multisig, cause it exceeds verification limits / size. Pieter explained it here: https://bitcoin.stackexchange.com/questions/23893/what-are-the-limits-of-m-and-n-in-m-of-n-multisig-addresses - I think with segwit the limits are shifted higher.


text:
What percentage of mined nonces fail to join the consensus blockchain?
From Wikipedia:

The PoW requires miners to find a number called a nonce (a number used just once), such that when the block content is hashed along with the nonce, the result is numerically smaller than the network's difficulty target.

The fact that a miner found such a nonce does not guarantee that it will become part of the consensus blockchain though. What percentage of them fail to join the consensus blockchain?

Are you asking about the percentage of nonces tried that don't make it into the eventually-accepted chain, or the percentage of nonces which satisfy PoW that don't make it into the chain? And, you are talking about Bitcoin, right, because the numbers will differ wildly for different chains/designs.

@PieterWuille (1) The nonces that do NOT make it into the eventually-accepted chain, as a percentage of all nonces that satisfied the PoW (2) Bitcoin, but I'm curious about others also, I guess (optional)

The term for this is "orphan rate" or "fork rate", as each created block which doesn't make it into the eventually accepted chain is effectively a tiny chain fork that doesn't get extended. Such blocks are sometimes called orphan blocks (though that term is a misnomer).
These forks occur when two blocks are found nearly simultaneously, where the later miner was still working on the previous block. The better the latency between miners, the shorter the time between the blocks needs to be for this to occur.
It is very hard to get exact statistics on this, for the simple reason that nodes in the network do not relay blocks which aren't considered part of the main chain. If a node receives a block at height H, and then another one at the same height H, the latter will not be considered part of the main chain unless it is extended first. Thus, generally such a fork will involve a condition where one part of the network hears about one block first, and another part of the network that hears about the other one first. Nodes on the boundary between the two will generally hear about both immediately. Nodes that heard the losing block first will eventually hear about both. Nodes that heard about the winning block first - generally the largest subset - will typically not ever hear about the losing block.
Thus, the best we can do is gather statistics from forks that well-connected nodes saw, though even that will be necessarily an underestimate: the "worst" forks don't propagate at all, not even past the mining pool that created them, and thus will not show up in anyone's statistics.
On my own rather well-connected node, I've seen 13 forks in the past 4 months (since block 800000). The https://fork.observer website lists forks they see on their nodes, which currently shows a similar number over that timespan. I believe https://blockchain.info used to list forks somewhere in the past, but I can't find that anymore.
If we use that number as a lower bound, the answer to your question would be at least 0.07%. The number can change wildly over longer time periods though, as it depends on the composition of blocks, the geographic distribution of miners, their connectivity, and the technologies used to connect them (e.g. BIP152 compact blocks helped reduce latency between miners, and the public FIBRE network while it was still operational helped more).

One such site is https://fork.observer/.

The fact that a miner found such a nonce does not guarantee that it
will become part of the consensus blockchain though.

this is true because there might be multiple miners who find the correct nonce at the same time. the one who quickly propagates wins.
there is a term called orphan block:

Orphan block is a term used by the general public, but in technical
documents it is described as a stale block. An Orphan block is created
when two miners (or more) find the solution at the same time.
Since each miner will broadcast the solution to the network and the
network requires a couple of moments to synchronize, there will be two
blockchains for a brief period of time. Each part of the blockchain
will think that their solution was found first and is the solution
that should be used primarily. In reality, both solutions are valid.
Once the new blockchain is active, the “race” between both chains
begins. Whichever chain will have the longer chain will be the main
chain.

Thanks! That's helpful, but I cannot accept the answer in the current state, since I specifically asked about a percentage.

You should say Bitcoin, not just blockchain: Bitcoin is the basic reference model for all blockchains, but there may be protocol variations with other blockchains.

The fact that a miner found such a nonce does not guarantee that it
will become part of the consensus blockchain though. What percentage
of them fail to join the consensus blockchain?

The short answer is a vanishingly small percentage, i.e. almost zero, but not for the reasons you seem to imply.  Here is schematically how it goes:

a Bitcoin miner is associated (talks) to a Bitcoin node: it's the node that keeps track of the blockchain as well as, among other things, of the list of pending transaction (that it knows about at any moment: typically wallets and exchanges submit transactions to a node, to be then replicated to the entire network);

based on the list of pending transaction, a job is submitted to the miner in order to search for a new block;

At this point one of two things can happen:

the node receives a new block before the miner is done: in this case the miner's job is aborted and, possibly, a new job gets started with the updated list of pending transactions; otherwise:

the miner finds a block before any new block has arrived to the node: in this case the miner submits the block to the node, and at this point the block is part of the blockchain, which just means it has been accepted by the immediate node and will be progressively propagated to the rest of the network.

Propagation entails latency: time is needed for a new block to reach all nodes of the network.  Hence, when two miners find a new block almost at the same time, they both transmit it to their nodes, which accept the block since they don't yet know another block was created somewhere else.  In that case what is happening is called a "network fork": these are quite frequent but usually resolve themselves in a matter of minutes, rarely more, by the rule that the longest chain wins. (I am not getting into too many details for simplicity: more technical details can be found online.)
So, now back to your initial question: there is one and only one possibility for a valid block to literally not make it to the blockchain, and that is if the miner finds the block almost exactly at the same time the node receives a new block, in which case the miner might indeed try to submit its block to the node and the node would have to refuse the request.  And this is the event that I am dubbing vanishingly probable: based on my competence and experience, I am not aware of public statistics about this.
Incidentally, nonces are not the only element in a block that a miner can play with in order to vary the block content and get different hashes, indeed nonces are uint32 numbers, so there would not be nearly enough.  There is also the timestamp, as well as the coinbase attribute of the so called generation transaction, i.e. the one in which miners rewards themselves: plus a miner decides which of the pending transactions to actually include in the block and in which order.

My question used the term "consensus blockchain". I hope the meaning was clear - it's the blockchain that everyone eventually agrees on, not some ephemeral data structure that exists for a second. You are saying "these are quite frequent but usually resolve themselves in a matter of minutes" - it would be nice to have a numerical estimate. What percentage? (the topic of the question).

A blockchain, by definition, is just a data structure - a (particular) singly-linked list of blocks. Different nodes can hold on to different lists. The product of the consensus mechanism is a list that everyone agrees on. That's what I call a "consensus blockchain". The nonce that the miner found may or may not end up in it. The question asked about the probability of it not making it there.

Imagine that all of the Bitcoin network's hashing is being done on a single giant imaginary computer, that doesn't stop if it finds a successful block.
We can perform a calculation of the probability that it finds two valid blocks in one second using public estimates of the hashrate as well as the known target.
two_valid_blocks_in_1sec_probability ~= 100% * (hash_rate_per_sec * target  / 2**256 ) ^ 2
Now imagine that the hash rate is distributed across the network of miners. Whether a valid block fails is dependent on the time it takes a valid block to reach, and be accepted by, rival miners. As an estimate, we can use the time it takes a block to reach nodes covering half of network hashrate; the block propagation time. Adjusting the above formula, it becomes:
valid_block_failure_probability ~= 100% * (hash_rate_per_sec * mean_block_propagation_time * target  / 2**256 ) ^ 2
Note this assumes terms for ^3, ^4, ^5 ... (which, strictly, should be added on) are not significant. This also assumes that the time it takes nodes to validate and accept valid headers is << the mean propagation time.
Here's a python script to do that:
    # Block 809295

    hash_rate_per_sec = 405000000.0 * 10**12
    # approximated from https://www.blockchain.com/explorer/charts/hash-rate

    target = 0x00000000000000000004ed7f0000000000000000000000000000000000000000
    # from https://learnmeabitcoin.com/technical/target

    period_secs = 0.5
    # from https://bitcoin.stackexchange.com/a/114196/34190
    # mean block propagation time (a block will reach nodes responsible for half of network hashrate in this time).

    prob_per_period = hash_rate_per_sec * period_secs * target  / 2**256

    N = 2

    prob_N_hashes_in_period = prob_per_period**N

    print('The probability that the bitcoin network will produce',N,'valid blocks in', period_secs, 'seconds is ', prob_N_hashes_in_period, ' Based on hashrate and target at block 809295.')

Which gives the following printout:
The probability that the bitcoin network will produce 2 valid blocks in 0.5 seconds is  6.81306666296744e-07  Based on hashrate and target at block 809295.

Using this, in answer to your question, we can say that, if the mean block propagation time is 0.5s, at block height 809295:
If a miner has found a successful block, there is a 0.00007% (1 sig fig) chance that it will not reach the consensus Bitcoin blockchain

The probability is sensitive to the estimated propagation delay:

mean_block_propagation_time [s]
valid_block_failure_probability  [%, 1 sig fig]

0.5
0.00007

1
0.0003

1.5
0.0006

2
0.001

2.5
0.002

5
0.007

10
0.03

20
0.1

The idea of collusion amongst miners (tacit or overt gatekeeping) slowing acceptance was not considered.

You have computed the probability that in a given 1s interval two get computed, but that's not what OP is asking for. You need the frequency of that happening per block, not per second. Also, you need to divide by two because the order of the two found hashes within the 1s interval does not matter.

@PieterWuille Paraphrasing OP "Given a miner has found a valid block, what is likelihood it fails to reach consensus chain"? The per second  value can be modified to any period by multiplying by a number of seconds. I chose the mean block propagation time as a modifier as this approximates the time a rival has to "gazump" the successful block. You could well be right about the factor of 2; I'm thinking on it....

@PieterWuille I'd add that the per block aspect is included via the hashrate estimation and target values.

OP is asking for the percentage of successful PoW hashes that don't get included. You're computing the rate at which successful but discarded hashes happen per second, but you need to divide that by the rate of successful hashes per second, to obtain the ratio of discarded hashes per successful ones. 0.000007% is just far too low; with 1s propagation delay and 600s blocks, you expect a number with an order of magnitude close to 1/600.

@PieterWuille agree on OP, but forgive me, the valid_block_failure_probability value is not per second. The time units drop out on multiplication by the period, in this case the mean_block_propagation_time (units of seconds).

Hmm, yes, I'm wrong in my reasoning, sorry. Still, the number you obtain is clearly wildly off. You expect something in the order of 1/600 (or 0.5/600, for half a second propagation time).

@PieterWuille thanks, will check for rounding errors etc in the Python code.

The time between blocks is a Poisson process, so follows an exponential distribution (with lambda=1/600s). If latency is L seconds, and every block found within L seconds of an accepted block is discarded, then taking the CDF (1- exp(-lambda x)) in x=0 and x=L, we obtain the difference 1 - exp(-lambda L) discarded blocks per accepted block, or (exp(lambda L) - 1) / (2 exp(lambda L) - 1) discarded blocks per total blocks, which is 0.166% for L=1.

@PieterWuille neatly done, thank you. Perhaps you should add it onto your answer..

I'm wrong. 1-exp(-lambda L) is the probability that at least one PoW-valid block is found in a window of length L after a given accepted block. But that's not what we want; there could be multiple such blocks in that window, and their expected value is just lambda L. Therefore, the percentage of discarded blocks per total PoW-valid blocks is (1 - 1 / (1 + lambda L)). Still 0.166% for L=1 though.

You don't need the probability that N=2 are found in 0.5s. You need a conditional probability, that a block will be found within 0.5s, given that another block has just been found. And since they are largely independent, you basically need N=1. 0.5/600 seems like the correct estimate here, or very close to correct.


text:
Why do some P2SH spending transactions have data both in the ScriptSig and Witness field?
I wonder if the wallet screwed up or if I am missing something in my bitcoin understanding.
Here is the tx output being spent:
    "value": 0.00180675,
                "n": 154,
                "scriptPubKey": {
                    "asm": "OP_HASH160 771962306e72e479245d48e879dd2a1862225b4c OP_EQUAL",
                    "hex": "a914771962306e72e479245d48e879dd2a1862225b4c87",
                    "address": "3CYkk3x1XUvdXCdHtRFdjMjp17PuJ8eR8z",
                    "type": "scripthash"

Here is the spending Input:
    "txid": "d80ff02d0d9eb2da8c8a1c47ab099901f447dd197e34220ea13eca72d7d6d21d",
                    "vout": 154,
                    "scriptSig": {
                        "asm": "002044c55c1da36a576217259c3bc21b0c3943f7eb3ff4e3c381d9fd3502434b9e87",
                        "hex": "22002044c55c1da36a576217259c3bc21b0c3943f7eb3ff4e3c381d9fd3502434b9e87"
                    },
                    "txinwitness": [
                        "",
                        "304402202c3f94e5daf4057377d9f16d45b57e962de42fb42cb7e95a0382b7c66624980a02204098f6acd43b0391ea1b4a8102797e78895848fb7e883f98d207d14d45945a6901",
                        "30440220448460edd5291a548c571ccf3a72caf47b02364035dc84f420d311e3a0c5494802205bb1cc89f20dc1e2c1f6eadb74898f8eecc46fbf488b676636b45fafaeb96e0f01",
                        "5221021e6617e06bb90f621c3800e8c37ab081a445ae5527f6c5f68a022e7133f9b5fe2103bea1a8ce6369435bb74ff1584a136a7efeebfe4bc320b4d59113c92acd869f38210280631b27700baf7d472483fadfe1c4a7340a458f28bf6bae5d3234312d684c6553ae"
                    ],
                    "sequence": 4294967295

SegWit introduced a compatibility mode usually called wrapped SegWit or nested SegWit. It allows you to create a P2SH output spendable using SegWit rules, which include the witness discount and malleability fix. It's slightly more expensive than native SegWit (which uses a new output type whose addresses start with bc1) because of the extra data included in the scriptSig, but it has the advantage of being supported in older software (which was especially useful after SegWit activation as some exchanges and wallets took years to implement sending to native SegWit).

You are looking at a transaction that spends wrapped-segwit (2-of-3 P2SH-P2WSH) inputs. Wrapped segwit was introduced as a bridging technology with segwit, because other than native segwit addresses, any sender that could already send to P2SH addresses was able to pay to them without an update and it allowed the receiver to immediately benefit from segwit improvements such as a reduced blockspace weight and the transaction malleability fix. In wrapped segwit inputs, the redeem script just checks the pre-image of the P2SH hash in the output, and then forwards to the witness stack for further validation.


text:
Buying Bitcoins from different brokers
I am trying to buy bitcoins from Coinbase. However since there is a limit I am going to purchase from another broker.
How I can move those different bitcoins into one wallet? or shall I use different wallet? How would the process happen and does this introduce any conflicts?

It works fine.  Your wallet will have the option to create receive addresses.  When you withdraw coins from your broker, you give them this address, and they send coins there; after the transaction confirms, you can spend those coins any time you want, by sending them out to someone else's address.
You could give both brokers the same receive address if you want, but it is better to use different ones, as this makes it harder for people to track your activities.  Any decent wallet should be able to create as many receive addresses as you want, with no practical limit, and they will all work equally well.  When you spend coins, the wallet will automatically select coins residing in one or more of your addresses; so even if you receive coins from different parties via different addresses, you can still spend them all in one shot if you need to.


text:
How to setup Antminer D3 to solo mine to CANN wallet
I am trying to solo-mine CANN using my Antminer D3 directly to the full node wallet. I would really like to start adding decentralization to small coins just for the heck of it, but I am having some problems.
CANN wallet config:

server=1 listen=1 rpcuser=u rpcpassword=x rpcport=39347
  rpcallowip=10.0.0.* rpcallowip=* rpcallowip=10.0.0.214
  rpcallowip=127.0.0.1

I have bfgminer set up as a getwork to stratum proxy via the following command:

bfgminer -o 10.0.0.162:39347 -u u -p x --stratum-port=3333

However bfgminer is outputting this error:

SSM: No usable 2D work upstream!

and my miner shows the pool as dead!
I know the miner is connecting to the bfgminer proxy because it displays this a few seconds after i set the ip in the miner interface:

0            |   0.0/  0.0/  0.0 h/s | A:0 R:0+0(none) HW:0/none

Full bfgminer output:

bfgminer version 5.4.2 - Started: [2017-12-16 11:37:48] - [  0 days
  00:04:52]  Pool 0: 10.0.0.162          Diff:256k  -GWork
   LU:[11:41:48]  User:u  Block: ...9a1b9582e90dac52  Diff:256k (
  1.83Th)  Started: [11:41:48]  I:?  ST:2  F:0  NB:3  AS:0  BW:[ 20/  7 B/s]  E:0.00  BS:0  0            |   0.0/  0.0/  0.0 h/s | A:0
  R:0+0(none) HW:0/none
--------------------------------------------------------------------------------------------------------------------------------------- NO DEVICES FOUND: Press 'M' and '+' to add

cross posted: https://bitcointalk.org/index.php?topic=2598430.0

Stack Exchange doesn't allow payment to be offered for an answer.  I am editing that out of your question.

Also, your question would be much more readable if you use preformatted text for the config file excerpts and output, with line breaks in the correct places.

Try:(Change IP 192.168.1.147 to your and try same PC wallet and miner)
cannabiscoin.conf
server=1
listen=1
rpcuser=cannabisuser
rpcpassword=cannabispass
rpcport=39347
rpcallowip=192.168.1.147
addnode=seed.cannabiscoin.net
addnode=seed2.cannabiscoin.net
addnode=seed3.cannabiscoin.net
addnode=seed4.cannabiscoin.net
addnode=seed5.cannabiscoin.net
addnode=seed6.cannabiscoin.net
addnode=106.70.242.145
addnode=108.61.10.90
addnode=115.28.42.60
addnode=136.243.217.171
addnode=137.74.104.135
addnode=144.76.237.39
addnode=148.251.8.18
addnode=162.255.117.105
addnode=171.232.8.87
addnode=178.12.190.117
addnode=178.15.70.226
addnode=188.60.110.76
addnode=192.99.200.144
addnode=194.135.90.175
addnode=198.27.68.86
addnode=205.251.171.136
addnode=207.171.249.66
addnode=209.188.18.52
addnode=213.32.6.132
addnode=213.55.176.213
addnode=27.3.20.109
addnode=40.141.98.2
addnode=45.48.182.104
addnode=65.31.179.140
addnode=78.251.112.84
addnode=85.214.23.49
addnode=88.10.240.5
addnode=89.204.137.211
addnode=93.87.143.138

sgminer  https://github.com/sgminer-dev/sgminer

sgminer -o http://192.168.1.147:39347 -u cannabisuser -p cannabispass -I 13 -g 2 -w 256 --lookup-gap 2 --shaders 2048

cpuminer  https://github.com/tpruvot/cpuminer-multi/releases

cpuminer-gw64-core2 -o http://192.168.1.147:39347 -u cannabisuser -p cannabispass
pause

Welcome to the site.  I cleaned up the formatting in your post to make it more readable. See https://bitcoin.stackexchange.com/help/formatting for more info on using Markdown.  Also, it is not allowed to request payment in an answer so I edited out your coin address.  The asker shouldn't have offered payment and I am going to remove that also.

See for instance preformatted text.


text:
What makes HD wallets resistant to brute force attacks?
To be more specific, let's consider wallets that use 12 words as a seed.
Total bit width is 132, with 4 bits used as a checksum, so the actual seed size is 128 bits. I know 2^128 allows for LOTS of combinations.
I don't have a formal background in security, but here's what makes me think, as an amateur, that my bitcoins are not secure.

the attacker is not bruteforcing a specific password/seed - there is no username associated with the seed - all the attacker needs is a seed that is being used by someone who hasn't spent all of his bitcoins
with the bitcoin network and HD wallets becoming more popular, there would be more seeds that lead to non-empty addresses. Consider that if the BTC/fiat exchange rate goes through the roof with widespread adoption, even if bruting takes a lot of compute power, the rewards for successful bruting go up

Where did I go wrong with my thinking?

Basically, you're focusing on the relative size of the numbers involved and still not paying enough attention to their absolute size.  2^128 is really really big.  It's true that having more addresses means a greater chance that random search will hit an address that has funds.  But I recommend the exercise of estimating what that chance actually is, and how long it would take to achieve, given a generous but realistic assumption as to how much compute power would be devoted.

related: Is Each Bitcoin Address Unique?

You don't have access to all of a HD wallet's private keys and their corresponding addresses immediately and can't check them for funds immediately.
When generating the 128 bit seeds and then generating the first few addresses of those HD wallets, you will encounter duplicates. Even if we ignore this and assume every private key and every corresponding address to be unique (which makes the math easier so more people can understand it), it's an unfeasible endeavor.
There currently are about 4.67*10^7 UTXOs. The best-case scenario for stealing at least some money is that every UTXO is held by a different private key in a different address. Instead of thinking about how our chances of success are worse than that, let's just assume it to be true.
HD wallets only use their seeds after 10^5 rounds of sha256. We neglect the additional effort of creating a private private key, creating a public key from that, creating an address from that, praying to the Flying Spaghetti Monster that the user actually used the very first address in their HD wallet and the funds in that first address are still unspent, and doing the actual lookup. Because those are harder to determine the cost for and as it will soon turn out, it's infeasible even if we literally have zero cost for that.
Given the numbers above and our very generous assumptions, we have to calculate 2^128÷(4.67*10^7)*10^5 = 7.28656032*10^35 sha256 hashes to get access to 1 UTXO.
The current hash rate of the entire Bitcoin network is about 3*10^18 hashes per second. Of course, in reality we can't just use miners because those 10^5 hashes we need to calculate per seed aren't independent of each other. In fact, they all (but the very first) depend on the one before them. That's the worst possible scenario for calculating a lot of hashes.
But even if we assume that we have access to all of the world's Bitcoin miners, magical new means of running purely sequential calculations in parallel (which is impossible, of course), and get all of the electricity those miners for free because our uncle just happens to barely use his nuclear power plant, recently, anyways, we still need to wait 7.28656032*10^35 / (3*10^18) = 2.42885344*10^17 seconds per UTXO to be able to steal it.
Luckily for us, that's only 7'701'843'734 years which is hardly more than half the age of the universe. I think we got that 1 UTXO. Then, again, our assumptions were pretty generous. It might take us a little longer to get hold of that 1 UTXO. Most of the big UTXOs probably aren't even stored in HD wallets but in cold storage instead, so we have even less hope to get hold of them, but whatever.


text:
How to issue a CPFP?
I was reading about CPFP (child pays for parents) recently and I didn't completely get the concept of it.
Can someone please give me a brief explanation of how it should be done and what are the wallets that currently support it?
Is my understanding of CPFP even correct? A user sends a transaction to another, which is not confirmed, that user can send another transaction that is "connected" to it with a high fee, that when a miner mines it, they are forced to mine the first, unconfirmed transaction?

It doesn't really require any special wallet support - you just have to make a second transaction that spends at least one output of the first one, and has a sufficiently high fee.

From the glossary:

Selecting transactions for mining not just based on their fees but
  also based on the fees of their ancestors (parents) and descendants
  (children).

Thus, we understand that this is a policy that is implemented by a miner.
Now, the way we can ensure that our stuck transaction falls under this policy is by ensuring our stuck_tx has a child_tx with good fees.
For creating a child raw transaction, we just need the txid from the stuck transaction and new address to send it. Put the funds, the change, what's left is the fee. Sign it and broadcast it.
To determine the right fee and more details check this fee bumping page on bitcoin wiki.


text:
Unconfirmed Transactions From a Year ago
I have two unconfirmed transactions, one from one year ago and another from about 16 months ago.  I am not sure if they are gone for good or if I can try something like a 2x transaction etc.  I'm running bitcoin core, latest rev on a mac.  I don't have enough in my wallet to even cover a double transaction.  Any viable advice would be appreciated.
edit:  it appears when I tried to send two separate transactions at the time, I never sent enough for the transaction fees.

I can't believe that. 16 months unconfirmed is just crazy. I sent 0.2 BTC with a fee of ~0.14$ around 5 months ago and it went through within 4 days... Do you have the transaction IDs?

Here is one:  9679b7dc5b49e5584e1a2a38b21e11ee263311959b80eb67dfb8277a7eec71f4

There is no search result for this ID: https://blockchain.info/de/search?search=+9679b7dc5b49e5584e1a2a38b21e11ee263311959b80eb67dfb8277a7eec%E2%80%8C%E2%80%8B71f4&searchbar=search

What client are you using? You may need to keep it running to make it rebroadcast on the network.

hey guys using bit core on mac...

also cannot duplicate as I don't have enough in my wallet?

Just checked the tx number, and saw there is a problem with the length. It should be 32 Bytes hex (aka 64 chars). up to "9679b7...7a7eec" I have 63 chars, then is some formatting problem, but it would be too long with "71f4" at the end. Maybe get this corrected?

hmm, but that is a direct copy out of my wallet...what can I do?

I couldn't find the transaction on any explorer. You can do a "-zapwallettxes" to remove the two stucked transactions. Seems like a fomatting issue on stackoverflow's comments, 2 zero-width space are added before 71f4.
Seem fine when I divide them with a a space:
9679b7dc5b49e5584e1a2a38b21e11 ee263311959b80eb67dfb8277a7eec71f4

Just create one more transaction from your previous address with current fees per byte actual value, and be happy.


text:
What are seeds in the source code of bitcoin?
https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp
starting from line 132, I see the function vSeeds.emplace_back("seed.bitcoin.") and next to them there are real full names. What do seeds do? What are these lines for? What is the meaning of those names? Can someone give a technical detail please?

In order for a bitcoin node to start connections with other nodes, it first needs a seed node. A seed node can be any node (listening) connected to the bitcoin network. Once the node has connected to the initial seed node, it can then retrieve information about other nodes in the network and start connections with those ones as well.
The names you are seeing in the source code are the URLs of some of the bitcoin core developers that host seed nodes. If you don't trust these crazy cypherpunks, you can actually specify your own seed node in your bitcoin.conf under the option seednode=<your_seed_node>

so when creatign a new coin, i should probably change the links or just comment out the lines right

@turmuka probably!

Those hosts are DNSseeds.
When your node starts if it find itself unable to successfully connect to the network within 11 seconds it will query those DNS names which are run by technical people in the Bitcoin community, and get back a lists of recently working nodes.
The use of DNS improves your privacy somewhat since DNS caching can prevent the operator's name server from seeing the request at all and if it isn't cached they usually won't see your IP address, instead they'll see the IP of your ISPs recursive resolver.  (Of course, the fact that it skips the use of it entirely if it can get connected also improves your privacy).
You can disable use of these dnsseeds by setting -dnsseed=0.


text:
Debugging Bitcoin Unit Tests
I am running the unit tests from bitcoin source using make check, and would like to debug the tests using LogPrint in the bitcoin source files. I read in the Test Docs that logs are only output to test_framework.log, but I'm unable to locate this file. Where should I be able to find it? Or perhaps there is a better approach?

You are confusing the two kinds of tests. Unit tests are compiled into a separate binary and run by make check. Functional tests are testing the RPC commands and have to be run explicitly using the test_runner.py script. test_framework.log is only created by the functional tests. The documentation for the unit tests can be found here.
To print messages in the unit tests, you cannot use LogPrintf. Instead use BOOST_TEST_MESSAGE and BOOST_CHECK_MESSAGE to print messages from the tests. You will have to run the test binary directly (src/test/test_bitcoin) with --log_level=all to see the messages.
To print from the source files themselves, you could use fprintf() and print your messages to stderr.

Ok, that makes more sense, I think this will allow printing messages from the test files, but what about the source files?  Eg. net_processing.cpp

You can use fprintf. Updated the answer

nit: The test_runner.py script allows you to run all functional tests in parallel but you don't have to use it.


text:
Debugging Bitcoin Core with gdb - how to turn off compiler optimizations
I ran the configure script with the --enable-debug flag, then ran make. I am running unit tests:
gdb --args src/test/test_bitcoin --log_level=all --run_test=script_standard_tests
I'm trying to step through the execution of the source files using gdb, but I am still getting <optimized out> for many variables, and it skips lines here and there. I thought that the --enable-debug flag would turn off optimization, but am I mistaken? I'm wondering if the optimization is always on for the tests or if there is a way to turn them off.

Bitcoin Core disables -O2 and enables -Og when --enable-debug is set. -Og is intended for debugging; however, it removes some of the debugging information and is buggy. To disable it and to improve debugging experience, I suggest changing between L256 and L278 to:
CXXFLAGS="-ggdb3 -ftrapv"

-ggdb3 is more powerful than -g3, it uses a GDB-only, LLDB-incompatible dialect for debugging. This will also get rid of -O2, except in libsecp256k1.
Edit: Sipa suggests a more elegant way without altering autoconf files, which is adding args for configuring.
./configure CXXFLAGS="-O0 -ggdb3"

O0 is needed in this case.

Nice workaround, thanks. I'm still getting <optimized out>, though, I must be missing something.

Now it is showing all variables. I must've not recompiled the file correctly.

Glad that I could help! :)

If you want to avoid all ""s, you need to compile with "-O0" to disable all optimizations.

Also there is no need to modify configure.ac, you can override things on the command line by using ./configure CXXFLAGS="-O0 -ggdb3" ....

@PieterWuille the manual (https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html) says O0 is default in GCC, but agree about the second, will edit soon.

@MCCCS But --enable-debug will pass -Og which overrides the -O0 default.

Why doesn't --enable-debug use -O0?

As of PR #16435 --enable-debug is actually setting "-O0", so there should be no optimization at all anymore.


text:
The randomness of vanitygen is secure enough?
If two people running vanitygen 1abcdefg What is the chance that both of the person will get the same public key & private key?
I hope that the answer is less than 0.0000001. But for this vanigygen need to use random algorithm (not simple while(true){ i++; test()}).
My question is: Usually when I create wallet, using http://bitaddress.org I need to Move your mouse around to add some extra randomness, but vanitgygen do not do this method.
By inspecting the code of vanitygen in GitHub I see that they use random functions. Can I trust it? Is it really random? How it can be secure? Is it use the machine time or what?

http://bitcoin.stackexchange.com/questions/46538/vanity-generator/46540#46540

If two people running vanitygen 1abcdefg What is the chance that both of the person will get the same public key & private key?

If a billion supercomputers each tried a billion keys per second for a billion years, the odds of a key collision would still be less than one in a billion.

I hope that the answer is less than 0.0000001.

Yes, much less.

But for this vanigygen need to use random algorithm (not simple while(true){ i++; test()}).

It just needs a random starting place. You can increment from there if you want to. The number of possible starting places has 77 digits when expressed in decimal notation.

How computer can get genreate random starting place, that have 77 digits...?
If it is just new Date().valueOf() it is not real random

@Aminadav: You may want to read about cryptographically secure pseudorandom number generators.

@Aminadav This is a very well understood problem! Getting randomness right is hard and extremely important and the developers or crypto-currency software (at least, the competent ones) are very careful to get it right. Often sources of real physical randomness are used such as shot noise, microscopic zone temperature variations, and turbulent shear forces. (Real computers are not theoretically perfect machines, they meet the analog physical world in measurable ways.)

That my question if I can trust this open source software vanitygen. How the choose a random problem?  What is it based on?

@nate. I have read the wiki. It tally about security. It doesn't explain how machine computer can Behar the forest initial state random number

@Aminadav Vanitygen follows current best practices, including using the system's entropy pool on platforms that have one. The system's entropy pool mines physical randomness caused by things like jitter in the CPU clock signal caused by temperature variations in its quartz crystal. (Vanitygen didn't implement this themselves, that would have been foolish.)

@Aminadav It also uses multiple sources of randomness and an algorithm that ensures the result is as at least as strong as its strongest input. So you can mix in system memory information, disk timing, and all kinds of other things without fear that using too many weak sources will produce a weak result.

I have found that it is a real secret how those random number generators works.
But some people reverse engineer this:
https://en.wikipedia.org/wiki/CryptGenRandom#Method_of_operation


text:
Bitcoin and Smart Contracts
I have recently come across the features of ethereum and the idea of smart contracts.
I like the concept of smart contracts however as a currency, I much prefer the bitcoin to the ether.
Is there any way smart contracts could ever be utilised by bitcoin?

To read about the changes introduced by Taproot for smartcontracts, check out: https://bitcoin.stackexchange.com/q/96025/5406

Bitcoin has a scripting language built into it, which allows the creation of many kinds of smart contracts. Examples are atomic swaps, Lightning payment channels and zero-knowledge contingent payments (ZKCPs). This later paper by Banasik, Dziembowski and Malinowski (BDM16) improves the efficiency of these greatly. Threshold multisignatures are also easy to do, interestingly much more easily than in Ethereum.
ZKCPs are extremely general and can execute any contract in which the counterparties and terms of the contract are known at setup time, though it does require they use some new and slow crypto (done off-chain, Bitcoin is never exposed to it).
A more whimsical example is Peter Todd's bounty for anyone who can collide SHA1, SHA256 or RIPEMD160. The SHA1 collision bounty has been taken.
My guess is that the only thing Ethereum can do that Bitcoin actually can't do, is extrospect on the outputs being spent. This would be sufficient to implement covenants, which would be something of a mixed blessing.
Andrew Miller has argued that Ethereum's account model lets it do contracts in a more transaction-efficient way than Bitcoin's UTXO model, which may be true, but the examples I've seen of this (a) lose privacy by storing lots of unrelated state in one account and (b) exploit Ethereum's global key-value store, which is significantly more expensive to maintain than a UTXO set. Extrospection may be efficiently (efficient for verifiers, not for the transacting parties :)) attainable by creative use of ZKCP's, much how the BDM16 paper does atomic swaps with them, but I haven't worked out the details.
As a final note, it is easier, by design, to implement and deploy Ethereum contracts. However, I think the hard part of smart contracting is analyzing the contracts and proving correct behaviour under all inputs. (Both Ethereum's and Bitcoin's script languages fall short on this count, being difficult in general to efficiently reason about.)

Regarding the final note, the reader may be interested in Miniscript (http://bitcoin.sipa.be/miniscript/) which aims to give a framework to be able to analyze and reason about Bitcoin smart contracts.

Some options:
Bitcoin Computer (https://www.bitcoincomputer.io/):

Bitcoin Computer is an easy to use smart contract system for Bitcoin.

Elements:

Elements is a general purpose blockchain platform that can also be
“pegged” to an existing blockchain (such as Bitcoin) in order to
enable the two way transfer of assets from one chain to the other

Etlenuem (from etleneum.com):

On Etleneum you can write code that controls digital value, runs exactly as programmed, and is accessible anywhere in the world.

n.b.

...the Etleneum team may delete contracts if they consider them
wrong...

Interlay:

interBTC is a 1:1 Bitcoin backed asset that can be used to invest,
earn and pay with BTC across the DeFi ecosystem on Polkadot, Ethereum,
Cosmos and many more.

Internet Computer Bitcoin Integration:

The integration between the Internet Computer and Bitcoin will enable
developers to build canisters that:

Securely own Bitcoin
Interact with the Bitcoin Network

Liquid (https://liquid.net/):

Liquid is a sidechain-based, Bitcoin layer-2 settlement network
linking together cryptocurrency exchanges and institutions around the
world, enabling faster, more confidential Bitcoin transactions and the
issuance of digital assets

RGB (from https://rgbfaq.com/):

RGB is a scalable & confidential smart contracts system for Bitcoin &
lightning network. They embrace concepts of private & mutual
ownership, abstraction and separation of concerns and represent
"post-blockchain", Turing-complete form of trustless distributed
computing which does not require introduction of "tokens"

RSK:

RSK is the first general purpose smart contract platform secured by
the Bitcoin Network.

Stacks:

Stacks is an open-source blockchain network that leverages the
security and capital of Bitcoin for decentralized apps and smart
contracts.

Wrapped BTC
An Ethereum ERC20 token that maps 1:1 (minting controlled by custodian) to BTC. Can be utilised in Ethereum smart contracts.

Hi atomh33ls, please don't post multiple copies of the same answer across multiple topics. While some topics are closely related, they often ask about different aspects or facets of an issue. A copied answer usually fails to address the topic's unique parts, so perhaps you could edit each of these to make sure your posts address the questions of the topics you posted on.

@Murch thanks, have deleted others and will use this one for updates

If you re-enable all opcodes, as Bitcoin SV have done, Bitcoin smart contracts become Turing-Complete, meaning you can build arbitrarily complex smart contracts. For example, you can build oracles, vaults, derivative contracts, even Zero Knowledge Proof, the most sophisticated contracts in the entire blockchain space. All these can be done using a TypeScript DSL called sCrypt, which compiles down to opcodes/script.


text:
Why was Bitcoin Core in need of a fork of LevelDB?
Why did Bitcoin Core fork LevelDB? What special needs does Bitcoin Core have, which require a specialized version of LevelDB?

There are two reasons for having the fork in the first place:

Upstream LevelDB does not support Windows, and the branches that are available elsewhere don't support MinGW (which Bitcoin Core uses for its Windows release builds).
After the scare the project experienced with the BDB locks bug, which resulted in a fork between different versions (see BIP50), the developers prefer to have exact pinned versions of all libraries that may affect consensus rules. This means for example if a bug were found in LevelDB that affects every implementation equally, Bitcoin Core may be forced to not fix it, in order to not cause a diversion (depending on the nature of the bug).

Additionally, it permitted making some build system integrations easier, and disabling compression in the code (which does not help for Bitcoin Core's use case).

Sometimes LevelDB has bugs and those bugs sometimes are not fixed in a timely manner in the upstream LevelDB project. These bugs can be problematic for Bitcoin Core so a fork of LevelDB was created to handle these bugs specifically.
Additionally, to ensure security, we want to use a specific version of LevelDB at a specific commit. By having our own fork of it, we can control what version and what commit it is on so that we can control exactly what code we are putting into Bitcoin Core.


text:
Why are some BIP numbers missing from BIPs list?

If I understood correctly https://github.com/bitcoin/bips contains a list of change proposals that have been accepted as BIPs by the BIP editor?
Why are some of the numbers missing, for example 0155.mediawiki to 0158.mediawiki?

If I understood correctly https://github.com/bitcoin/bips contains a list of change proposals that have been accepted as BIPs by the BIP editor?

Correct.

Why are some of the numbers missing, for example 0155.mediawiki to 0158.mediawiki?

They haven't been assigned yet. The BIP editor sometimes chooses to reserve a range of number for BIPs around a common theme. When a BIP is proposed matching that theme, it is given a number from the range. Other BIPs get numbers outside of the range.

This is a good idea, but as I see not employed that much. As in some other specs, editors should have used ranges 01xx, 02xx, 03xx... would be better :).

Is BIP editor a software or do you mean luke-jr? (serious question)

It's a person :)

Because there is no central authority to assign numbers sequentially :)

Well there is a BIP editor.

Yes there is, the BIP editor assigns numbers.


text:
How do you get the balance of an address in your wallet using the rpc interface?
The current rpc interface only allows you to see either
1. The balance of the entire wallet
2. How much was received by an address (which is okay... if you never spend)
Basically, I want to know how to get the balance of a specific address in my wallet. I've searched high and low and cannot find anything.

If you are only using Bitcoin through RPC commands, you might want to look into accounts. Using those you can just call getbalance and you will know how much Bitcoins are in each of the accounts.
If you are using only addresses, you can only see how many Bitcoins you received with it through listreceivedbyaddress, which can be not reliable if you spend any money from them.
All in all, you ought to just use accounts, as they can encompass many addresses and provide a lot of functionality for separating your coins into many parts in the same wallet.

I think I will be using the multiple account suggestion. Thanks for your help!

The current rpc interface don't have a command to check balance of a address

getinfo also includes a "balance" field that encompasses all spendable Bitcoin. Getbalance and listreceivedbyaddress can do slightly more advanced things, including confirmation count, but you don't seem to need them.
Reference this: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

I had the same issue and searched high and low but finally found the exact answer needed
In the debug console type in the following command
￼
listaddressgroupings
This will return every address in that wallet and its balance
Hope this helps


text:
Handwritten paperwallet or hardwarewallet to store Bitcoins?
Most people I talk to are convinced that a hardware wallet is the safest place to hold your Bitcoins. But I'm not so sure if it's not safer if I create offline on a non compromised fresh system the keys and write it down on a paper (two copies at two safe places). Of course somebody could steal the keys. But looking on hardware wallets, I see those risks:

Seed words have to be written down - subject to theft
If I or anybody else wants to use the stick in 10 or 15 years the firmware will be outdated, the solution might be hacked or I could run into the problem not finding a safe computer with USB port or accepting the stick. This remembers me when I want to get the films from the 20 years old cameras.
The stick itself plus seed is more difficult to hide than a seed/key alone. If a criminal finds the stick he could force me to hand out the seed.
If not open source I need to trust the manufacturer. E.g. the selection of keys could be not random. If the manufacturer selects just out of fix selection of 10 Mio private keys I wouldn't realise but he could take over all Bitcoin credits from the clients after a few years.

What do you think, what's the best hodl strategy to store the coins safe?

True.
There is a standard algorithm for generating the keys from the seed words (BIP 39 / BIP 32).  Most hardware wallets follow this algorithm (check before you buy).  So even if the hardware device has failed or cannot be used, you can still use your written seed words with any other software or hardware device that implements the standard algorithm to recover your keys and spend your coins.
True.
True.  But if you are paranoid, you could generate your own seed words with some more trusted software, import them into your wallet, and check with some other software that the hardware wallet is correctly generating the keys from them.  That would guarantee that the keys are secure, though of course it wouldn't rule out the possibility that the hardware wallet is secretly sending them back to the manufacturer or another attacker.


text:
Wallet issues with bitcoin
i am new to this bitcoin universe and signed up on a website called genesis mining, a form of cloud mining. it asked for my bitcoin wallet address but can't find it no where in the bitcoin wallet app or the program i downloaded, does anyone whom have the app or software know where to go to find your wallet address? I search everywhere on both programs to no luck at all.

what is the name of wallet applications you are using?

i am using bitcoin core and the app as well but can't for the life of me find out where is my wallet infomation

In Bitcoin Core, go to the Receive tab and click Request Payment.  Make sure to back up your wallet.dat file.  As for "the app", please clarify which one; there are lots of wallet apps for Bitcoin.


text:
Ubuntu Says bitcoind not installed
My "best" friend Ubuntu 14 says bitcond is not installed type to install: apt-get install bitcond
I typed.
Succesful installed.
I try open whit this command in terminal/SHH: bitcond -deamon
But Ubuntu say bitcoind is not installed type to install:
apt-get install bitcond
WTF??
I did not know what the matter?
Please help me guys!

Run 2 commands: sudo updatedb; locate bitcoind

It sounds like you need to run sudo apt-get install bitcoind

Did you try running bitcoind before installing it, then installed it, and it still says it's not found?  If so, try hash -r in your shell.

It seems there is already a question on bitcointalk forum posted by you to which I have replied.
https://bitcointalk.org/index.php?topic=1843078.new#new

I think I may know your problem it is bitcoind not bitcond. Perhaps
  you are writing it as bitcond in your terminal. Try writing bitcoind.
  Also the deamon spelling is wrong it is daemon not deamon
If that is not the problem and you are typing it correctly in the
  terminal you might be running the GUI and the daemon at the same time
  using the same configaration directory.
If you are not doing that also then look the steps below. I followed
  it and it worked perfectly fine.
Note: Follow exactly the steps. Do not do step 2 before step 1
Step 1: Add the bitcoin ppa repository to your system.
sudo apt-add-respository ppa:bitcoin/bitcoin

Step 2 : Update your packages.
sudo apt update

Step 3 : Install the bitcoind core daemon
sudo apt install bitcoind

Step 4 : Run the daemon
bitcoind -daemon

You should recieve a message that bitcon server has started
  successfully.
To interact with the bitcoin core you will have to use the command :
  bitcoin-cli
To stop the bitcoin core daemon type : bitcoin-cli stop
A complete list of commands is avaliable here:
  https://bitcoin.org/en/developer-reference#rpc-quick-reference


text:
Bitcoin unconfirmed long Time no confirmations
Been forever my bitcoin hasn’t been confirmed can someone help me
3JHLiBT2Tu6uFotFRY1mF1bAnRdRS8XTqt

Both transactions involving that address are confirmed, as of a couple hours ago. https://blockchain.info/address/3JHLiBT2Tu6uFotFRY1mF1bAnRdRS8XTqt

Congratulations! Your transaction at the time of writing has 65 confirmations!
blockchain.info


text:
Why bitcoind/bitcoin-qt is imposing transaction fee?
bitcoind is imposing a transaction fee of 0.0001 BTC forcefully even though I have set "transaction fee" to 0. Is it possible to transfer BTC to an address without paying a fee? If so, how?

Upgrade to Bitcoin version 0.9 or later which removes the minimum relay fee. Just be warned -- the lower the fee you set, the longer it can take for your transaction to be confirmed. Zero-fee transactions can take days.

I've had 0 fee transactions confirmed in minutes. dont believe the hype.

@jaybny I didn't say they can't take minutes, I said they can take days.

I've never had to wait over 12 hours ever. used many wallets over many years.

Did you modify the code to set the transaction fee to zero? 0.9 hasn't been out for long and previous versions don't let you force a zero fee.

Thanks David, I have upgraded to 0.9 but it is still including fee, can you please tell me what's the problem ?

@user14632 It must be a very unusual transaction then. Perhaps it's gathering from a large number of small outputs? Perhaps it's transferring coins that were recently transferred?

No that's not the case, it is saying, "The total exceeds your balance when 0.0001BTC transaction fee is included


text:
What is prevTxHash?
I have some questions regarding transactions,
prevTxHash in Inputs of a Transaction, does this carry the hash of previous transaction in block or hash of the prev transaction by the same private key.

Welcome to the site.  It is best to use a descriptive title that explains what your post is about; titles that just say "please help" don't draw the attention of the relevant experts.  I made an edit; if you prefer something else you may also use the edit button.

I have some questions regarding transactions, prevTxHash in Inputs of a Transaction, does this carry the hash of previous transaction in block or hash of the prev transaction by the same private key.

No, it's the hash of the transaction whose output you are currently spending. Suppose I wanted to spend this transaction. I would include 961763d1c918e654c0ec922eb0aeb7f7e951e9bfae5398ec52e93fa0576c1f74 as the previous transaction hash in order to identify which output I am spending.

Thanx for the reply it helped me a lot, hopefully you have heard about SEGWIT soft fork, i just wanted to know that f signatures are not included in transaction how can they verify the transaction without it?

They're not hashed in the transaction ID. However, signatures are kept alongside the transaction when relayed or in blocks. The wtxid in the block commits to the signature.

thanx, but this arise a confusion in my mind, So as in segwit soft fork witnesses are kept in an extension block, so the software that is not updated it yet still accept the blockchain, so how can it understand and validate the transactions as it doesn't know the new rule that witnesses are in extension block not with the transaction?

@HamzaTahir Segwit outputs appear as anyone-can-spend outputs to nodes that do not understand segwit. Non-segwit clients do no meaningful validation of segwit outputs.


text:
I lost my computer, inside my hive wallet , I do have my adress and password can I recover my bitcoins?
Is it possible to login from other wallet with adress and password to get back my btc?

Platform? Details? We need much more info. What about your mnemonic?

Please add additional information. As it stands, we don't have enough information to know what your problem is.

The address is useless, the password insufficient. You need to have a backup of your wallet, or know the mnemonics for the seed. Otherwise you can't recover your coins.


text:
LTC Pool With Friends?
Is there a way I could set up my LTC mining pool so that my friends could join? I've been having really good luck lately!

P2Poolis a good way to do that. It can be hard to set up but is the best way to do it.