text:
Addresses field in ScriptPubkey
"txid": "055f9c6dc094cf21fa224e1eb4a54ee3cc44ae9daa8aa47f98df5c73c48997f9",
"hash": "055f9c6dc094cf21fa224e1eb4a54ee3cc44ae9daa8aa47f98df5c73c48997f9",
"version": 1,
"size": 433,
"vsize": 433,
"locktime": 0,
"vin": [
    {
        "txid": "b187426f2fdd5a7ac2f49d822f68e07f48486ee53a8a45de2494f12acb37a0d8",
        "vout": 3,
        "scriptSig": {
            "asm": "3046022100d78c31a20fa11533475be893b229eb4d252e600dcc2a0735d360c541b6aec813022100e3eaa72c915ef47d94ccbd18c2ba6d9ae5b98be6e9fbf968d4bbbb003e06d687[ALL] 030e001332b43924be343986cca3df669f57b0dedd120990e727787f8dea50fdbc",
            "hex": "493046022100d78c31a20fa11533475be893b229eb4d252e600dcc2a0735d360c541b6aec813022100e3eaa72c915ef47d94ccbd18c2ba6d9ae5b98be6e9fbf968d4bbbb003e06d6870121030e001332b43924be343986cca3df669f57b0dedd120990e727787f8dea50fdbc"
        },
        "sequence": 4294967295
    }
],
"vout": [
    {
        "value": 0.00010860,
        "n": 0,
        "scriptPubKey": {
            "asm": "1 030e001332b43924be343986cca3df669f57b0dedd120990e727787f8dea50fdbc 20434e545250525459000000140001a9e0e85838b5000000174876e800010053b6 2 OP_CHECKMULTISIG",
            "hex": "5121030e001332b43924be343986cca3df669f57b0dedd120990e727787f8dea50fdbc2120434e545250525459000000140001a9e0e85838b5000000174876e800010053b652ae",
            "reqSigs": 1,
            "type": "multisig",
            "addresses": [
                "1FrbMcddiM1v3HMpUqygjZYCamBykWCWao"
            ]
        }
    },
    {
        "value": 0.00010860,
        "n": 1,
        "scriptPubKey": {
            "asm": "1 030e001332b43924be343986cca3df669f57b0dedd120990e727787f8dea50fdbc 20a3c3000000000000000000000000000000000000000000000000000000000000 2 OP_CHECKMULTISIG",
            "hex": "5121030e001332b43924be343986cca3df669f57b0dedd120990e727787f8dea50fdbc2120a3c300000000000000000000000000000000000000000000000000000000000052ae",
            "reqSigs": 1,
            "type": "multisig",
            "addresses": [
                "1FrbMcddiM1v3HMpUqygjZYCamBykWCWao"
            ]
        }
    },
    {
        "value": 0.00010860,
        "n": 2,
        "scriptPubKey": {
            "asm": "1 030e001332b43924be343986cca3df669f57b0dedd120990e727787f8dea50fdbc 100000000000000000000000000000000000000000000000000000000000000000 2 OP_CHECKMULTISIG",
            "hex": "5121030e001332b43924be343986cca3df669f57b0dedd120990e727787f8dea50fdbc2110000000000000000000000000000000000000000000000000000000000000000052ae",
            "reqSigs": 1,
            "type": "multisig",
            "addresses": [
                "1FrbMcddiM1v3HMpUqygjZYCamBykWCWao"
            ]
        }
    },
    {
        "value": 0.01061564,
        "n": 3,
        "scriptPubKey": {
            "asm": "OP_DUP OP_HASH160 a2f2d251cc06ec1e789800127e3fa6ed9e515651 OP_EQUALVERIFY OP_CHECKSIG",
            "hex": "76a914a2f2d251cc06ec1e789800127e3fa6ed9e51565188ac",
            "reqSigs": 1,
            "type": "pubkeyhash",
            "addresses": [
                "1FrbMcddiM1v3HMpUqygjZYCamBykWCWao"
            ]
        }
    }
]

In the above transaction, each scriptpubkey has addresses array and it  has 1 address. I guess this address is derived from the public key of asm. In this example each asm has 2 public keys. So addresses array should contain 2 addresses. But it has only one. Can someone explain this?

Have a look to https://blockchain.info/tx/055f9c6dc094cf21fa224e1eb4a54ee3cc44ae9daa8aa47f98df5c73c48997f9?show_adv=true
At the bottom of the page you can see "disassembled" output scripts. Yes, outputs 0, 1 and 2 have the form of 1 pushdata33 pushdata33 2 CHECKMULTISIG so these outputs are 1-of-2 multisig outputs. But you should look even deeper! The compressed form of public key is 33 bytes long and must start with 02 or 03 in hex representation. What do you see on that page? The lines
20434e545250525459000000140001a9e0e85838b5000000174876e800010053b6
20a3c3000000000000000000000000000000000000000000000000000000000000
100000000000000000000000000000000000000000000000000000000000000000

do not start with 02 or 03 so they are not public keys. It may be some garbage or another protocol layer like a counterparty. I do not know.
The modern Bitcoin Core client does not try to convert these chunks of bytes to a public keys and does not try to create human readable addresses. So, you see only one address 1FrbMcddiM1v3HMpUqygjZYCamBykWCWao in console. This is not a bug, this is a feature.


text:
What computations does Btcoin perform during mining?

Possible Duplicate:
What exactly is Mining?

What are the exact computations dies Bitcoin is performing during the mining?
I understood that it has to do something with hashes and proof-of-work.
And as far as I got, here is an idea:
SHA-256(something) = specific string

where specific string starts with some zeros, but what is this something?

Do you mean when mining? Could you please edit your question to clarify that

I edited the question a bit to clarify the problem and conform with Higly Irregular's comment. I hope it is more acceptable to the community now.

Bitcoin hashes the block headers through SHA-256(SHA-256(header)) hashing. The result of that hash has to be smaller than the current target, which is commonly represented by difficulty.
Those computations are performed many, many times during mining, so there are some slight optimisations for the process. Namely, the use of midstate. Generally, before the header can be hashed, it needs to be split in half due to the SHA-256 algorithm (which operates on data smaller than the header). Half of that data does not change with iterations over the nonce, so it is useful to calculate the midstate of that half of the hashing to use in the algorithm, saving you some computational time during each check.
Asides from that, there is more complexity to it (ah, the damned endianness and so forth), but this should make things clearer for you.

source: Stack Exchange

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

sort: votes


text:
how http://blockchain.info/, http://blockexplorer.com/q or http://www.bitcoinmonitor.com/ works

Possible Duplicate:
How can I read information from the blockchain?

Can anyone tell me from where exactly sites like

http://www.bitcoinmonitor.com/
http://blockchain.info/
can't post more links

take their information.
How bitcoinmonitor knows what transactions have been done right now?

They monitor the public blockchain from multiple Bitcoin servers. There's a very simple rule for which chain is valid -- whatever chain has the most work is the valid one.

So if for instance I want to create a service, similar to above mentioned, to what servers I have to connect. As far as I know all the information is stored in .dat files on the computer, where bitcoin is installed.

@SalvadorDali: You could just connect to a random set of nodes, but there's an advantage to connecting to the nodes closest to the large mining pools. You can find them by looking at which nodes tend to be first to announce a newly-found block. It doesn't matter that much so long as you are well connected as the mining pools are careful to keep themselves well connected too.

You can get most of the information provided by those services through the use of the Bitcoin API. You might need to do some bookkeeping (for tracking transaction details and so forth), but it shouldn't be too hard. Other information needs to be extracted using additional tools, for example some packet sniffers for discovering transaction's relaters' IPs and so forth.

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


text:
how to start mining with FPGA
I found that in my university there are some FPGA's available to test and to play with. I am a software/web programmer and I have never been working with verilog or whatever is used to program FPGA.
So is there a nice tutorial which explains how to start mining using FPGA. I do not want to create a fancy 2 - 10 connected FPGAs to run mine for profit, but I just want to start one FPGA and to see how it is working and what speed it is giving me.
I have checked the question: What software/hardware is required to mine with an FPGA?, but it does not provide information, I needed.
P.S: I also have seen this post: https://bitcointalk.org/index.php?topic=9047.0 , but I hope to hear from someone who started to mine by himself and can share his experience.
So is there an easy to use tutorial for a not microsystem guy who wants to test mining. Or this is so complicated?
P.S. The vendor is Xilinx.
I have two different models:

The model for the simple one is Spartan 3E
The model for the advanced one is Virtex5

The bitstream that gets loaded is not universal among FPGAs.  Bitcoin StackExchange might not be a great place to get pointed in the right direction.  Perhaps try the Custom Hardware board on the forum? http://bitcointalk.org/index.php?board=76.0

What vendor/model of FPGA are you using?

Thanks @NickODell I updated the question with FPGA details

possible duplicate of How do I mine with FPGAs?

So is there a nice tutorial which explains how to start mining using FPGA.

Not really, not a "starting from scratch" one.

Or this is so complicated?

Yes, it is quite complicated - in order to work with FPGAs, some additional skills on top of software are required.  You need to understand logic design and some (fairly basic) electronics in order to make a successful FPGA.
However, as a learning project, if it's something that interests you, I'd say it's worth a go - you'll learn a lot, but it won't be a quick-and-easy learning experience :)
But start small - first off, write an FPGA which just flashes an LED on and off slowly - that enables you to learn lots of the low-level details without a complex logic design going on.  The FPGA equivalent of "Hello World"!

EDIT:
If you've already done some FPGA work, then "all" you need to do is build a SHA implementation, some method of getting data to and from it and a little control logic.  I haven't done it myself, but I got about that far along a "thought-design" before deciding I wasn't sufficiently interested to pursue it further.

The idea is to learn, not to mine. I have already done some work with FPGA, like playing a song and working with colour. Have you tried to mine with FPGA?

There is a laptop-integrable FPGA board here, could you learn FPGA with it and also some bitcoin mining?


text:
Is it ok just to save wallet.dat from multiple altcoin clients and remove the client?
I have the following situation: I have mined few coins from different alt crypto-currencies and I do not want to run them any more on my machine. As far as I understood from this question, I can just copy wallet.dat from each of these altcoins, encrypt them, remove the clients and this is it.
If then someone will send me some coins and after some time I would like to use them, I can just download the client, wait for synchronization, change wallet.dat with my stored wallet and continue using coins? Am I correct?

Yes, just make certain you do not make any more transactions with that wallet or you could lose coins going to a change address (an address that is used to send back extra coins. it is not the address you sent coins from).
also make certain that you remember your password and the most imperative part: shutdown your coin client before you copy the wallet
also id suggest you back up the wallet and then remove the wallet, and finally try to copy the wallet back over, if you see it load up and your coins are there you are golden.
another way would be do dump the privkeys and encrypt a file with just those keys in it.
source: Me, I'm an altcoin pool op

Knowing that you are a pool operator, I am sure that you know what are you doing :-). Thank you. As I understood it is ok, if the only transactions which are going to happen will be people sending me coins. Regarding the password: I do not remember setting up any password for a wallet. Can you please elaborate on this?

You are correct. When you receive coins they always go to the address you gave them and no additional addresses are used.
re password: on bitcoin QT go to "Settings"-> "encrypt wallet" that should get you where you need to be ;)


text:
Where can I read more about the fields of the transaction returned by listtransactions API
I am looking at the results returned by listtransactions API and I do not understand the difference between blocktime, time and timereceived. Help tells me the following:

"blocktime": xxx,         (numeric) The block time in seconds since epoch (1 Jan 1970 GMT).
"time": xxx,              (numeric) The transaction time in seconds since epoch (midnight Jan 1 1970 GMT).
"timereceived": xxx,      (numeric) The time received in seconds since epoch (midnight Jan 1 1970 GMT). Available for 'send' and
'receive' category of transactions.

Can anyone explain these fields in a little bit more details?

The Bitcoin developer reference has a section on the listtransactions call:
The blocktime is the timestamp of the block that confirmed this transaction on your local best blockchain. It is not returned for unconfirmed transactions.
The time field tracks the time that your wallet started tracking this transaction.
The timereceived field tracks the time that your node learned about the transaction, or alternatively the time of the block that included this transaction.


text:
How does an individual access the Bitcoin Core repo and contribute to it in the case that GitHub boots Bitcoin Core or the individual off GitHub?
It is not looking like Bitcoin Core will be moving from GitHub anytime soon (unless forced to).
How does an individual access the Bitcoin Core repo and contribute to it in the case that GitHub boots Bitcoin Core or the individual off GitHub?
What should an individual do in advance to prepare for this scenario?

Nothing interesting happens if github bans bitcoin, the repository will be uploaded on a different host. Git is a decentralized application and several mirrors exist already. The contributors also have local copies of the repository so no code will be lost.
The biggest problem would be that the github issues and comments will be lost since they are a github feature (not part of the git repository).

It is unlikely the issues and comments would be lost as long as some contributors have used Andrew Chow's full GitHub downloader tool. https://github.com/achow101/github-dl

Wladimir van der Laan posted this on Mastodon.

My personal bitcoin Git repository, which mirrors upstream branches
and tags is available through a TorV3 service on
http://nxshomzlgqmwfwhcnyvbznyrybh3gotlfgis7wkv7iur2yj2rarlhiad.onion/
(instructions for cloning are on the website)
I'm also mirroring it to the radicle (https://radicle.xyz/) P2P code
collaboration platform:
rad:git:hwd1yreyfmyg5my7kskrsc5r33h5jr9anra9635hpncfs9f1wsk1eaf8f9w

Some additional guidance is on Wladimir's blog.
Note there have been recent consensus issues with Tor v3 addresses.

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


text:
How would new jets for Simplicity be soft forked in? What prevents a miner from mining a new jet?
What is the current thinking on how new jets for Simplicity would be soft forked into Bitcoin (in a speculative future where Simplicity was already itself soft forked into Bitcoin)? What would happen if a miner mined a block with a new jet with a lower resource cost?
This question was asked by sanket1729 on IRC and has been paraphrased.

This was discussed by Russell O'Connor, the author of Simplicity on IRC. The following has been paraphrased, any errors are my own.
Jets would be written in Simplicity so that everyone agrees on the functionality of the jet. While jet functionality could be specified in any language, Simplicity is an obvious candidate specification language.
In v0 Simplicity it won't be possible to soft fork in new jets. You would need a new encoding scheme to support the new soft forked jets.
For later versions of Simplicity the current plan would be to incorporate the resource cost into the jet "name". There would be a certain kind of malleability where anyone can spend a UTXO by providing a proof (a branch) that there is a commitment to an unknown discounted jet. Old nodes would be presented with such a proof and new nodes would require a proper program. It is not clear what would go into the block's witness Merkle root at this point.
This plan would require new (as yet undesigned) P2P support rather than just using OP_SUCCESS. Peers would negotiate which version of the set of jets that they know about and the Simplicity fragments they know about. Hence you wouldn't necessarily need to (re)transmit common Simplicity functions that your peers already know about.

What prevents miners from maliciously mining an unknown discounted jet to DoS the network as peers would now need the entire program?

There is no encoding for new jets. Discounted jets are explicitly encoded. Illegal encodings cannot be legal because there is no way to validate that a program you cannot decode matches the commitment Merkle root.
Under this scheme miners can't mine an unknown jet. In order to do so they have to either prove that there is an output that is committed to such an unknown jet, and if no one has any commitments then they cannot be used, or they have to provide an encoding of a program that uses a new discounted jet, but my encoding scheme has no such encodings.
Unless a "this is an unknown jet with identity root" was added to the encoding scheme it would never be acceptable to have old nodes operate on discounted jets by running the undiscounted Simplicity code. The option was "I see an unknown discounted jet I ignore the entire script and just succeed". While that works well for Bitcoin script, it is problematic in the presence of disconnect / delegation and it could be a problem for Bitcoin Script too if it ever had direct delegation. If Bitcoin Script had OP_EVAL, and then you try to OP_EVAL something with an OP_SUCCESS in it what do you do? Hence the current plan is to require a new Tapleaf version or Simplicity version to change jets.

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


text:
What are the scriptPubKey, scriptSig, redeem script and witness for the various output types?
scriptPubKey, redeem script, witness script, witness program are defined in this StackExchange post.
What are the scriptPubKey, scriptSig, redeem script and witness for the various output types (P2PKH, P2SH, P2WPKH, P2WSH etc)?

This was answered during the Bitcoin Core PR review club on July 7th 2021 hosted by Gloria Zhao (who also provided this table).

The <public key> in the P2TR (key path) and P2TR (script path) scriptPubKey column is the tweaked public key rather than the internal key (assuming they aren't the same and the tweak is being used as recommended by BIP 341).

The first row should be labeled "P2PK".

I thought it would be useful to have a text version of the image of a table in Michael Folkson's answer. If only for accessibility reasons.
(it initially proved rather too hard to edit into his answer due to the table's markup complexity and stackexchange having different rendering of the edit preview and final answer!)

Output type
locking script
unlocking script
redeem script
witness

P2PK
<pubkey>OP_CHECKSIG
<signature>
—
—

P2PKH
OP_DUPOP_HASH160<pubKeyHash> OP_EQUALVERIFYOP_CHECKSIG
<signature><public key>
—
—

P2SH
OP_HASH160<scripthash>OP_EQUAL
<data pushes><redeem script>
<arbitrary>
—

P2WPKH
0<pubKeyHash>
—
—
<signature><public key>

P2WSH
0<witnessScriptHash>
—
—
<data pushes><witness script>

P2SH-P2WPKH
OP_HASH160<redeemScriptHash>OP_EQUAL
<redeem script>
0<pubKeyHash>
<signature><public key>

P2SH-P2WSH
OP_HASH160<redeemScriptHash>OP_EQUAL
<redeem script>
0<scriptHash>
<data pushes><witness script>

P2TR (key path)
1<public key>
—
—
<signature>

P2TR (script path)
1<public key>
—
—
<data pushes><script><control block>

Note that the redeem script for P2SH-P2WPKH is inside the unlocking script and its notation might be clearer as, for example <0 <pubKeyHash>> to show the nesting ("wrapping") of the data pushes.
The serialisation of unlocking script <0 <pubKeyHash>> would be

Hex
meaning
notes

16
push 22 byte wrapper
-

00
0
first wrapped item inside wrapper

14
push 20 byte pubKeyHash
-

...
pubKeyHash
second wrapped item inside same wrapper

Essentially, the wrapped types (P2SH-P2W..) require recursive parsing, though only to depth 1, so maybe it shouldn't be regarded as recursive.
The table currently omits some interesting types such as multisig as well as some trivial types such as OP_RETURN.


text:
How do I obtain a checksum for a Taproot descriptor so that I can import it using importmulti?
I tried to import an example Taproot descriptor using bitcoin-cli importmulti
tr(c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5,{pk(fff97bd5755eeea420453a14355235d382f6472f8568a18b2f057a1460297556),pk(e493dbf1c10d80f3581e4904930b1404cc6c13900ee0758474fa94abe8c4cd13)})
I got the error "Missing checksum". How do I generate the checksum and where do I append it to the descriptor?
A checksum was added to descriptors in this PR.

You can obtain the checksum using:
bitcoin-cli getdescriptorinfo insert_descriptor_here.
This outputs the descriptor with the checksum appended at the end under "descriptor" and a separate "checksum" field with the checksum on its own.
{
  "descriptor": "tr(c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5,{pk(fff97bd5755eeea420453a14355235d382f6472f8568a18b2f057a1460297556),pk(e493dbf1c10d80f3581e4904930b1404cc6c13900ee0758474fa94abe8c4cd13)})#2rqrdjrh",
  "checksum": "2rqrdjrh",
  "isrange": false,
  "issolvable": true,
  "hasprivatekeys": false
}

You can then use bitcoin-cli importmulti on that descriptor.
More guidance is in the descriptor doc.
Thanks to darosior for answering this on IRC.

As an aside, I think that if you call getdescriptorinfo on a descriptor that contains a privkey, it will return the descriptor with the corresponding pubkey in the descriptor field. But the checksum verifies this modified descriptor, not the one you passed (with privkey). The checksum for the descriptor containing the privkey would be in the checksum field.
I was confused by that at first (and is still very confused by descriptors so far).


text:
What is in the Bitcoin Core LevelDB dbcache? Is it full records or metadata?
What is in the Bitcoin Core LevelDB dbcache? Is it full records or metadata?
This question was asked on IRC by Anonymous.

The Bitcoin Core documentation describes dbcache as the cache for the UTXO database.
Wikipedia describes a cache as a:

software component that stores data so that future requests for that data can be served faster; the data stored in a cache might be the result of an earlier computation or a copy of data stored elsewhere.

Greg Maxwell added on IRC:

There are basically two separate uses: the block index which is
essentially metadata and the UTXO database.
The dbcache is not really a cache, it's a write buffer and it prevents
needing to sync the disk or make random writes. As a cache it doesn't
do much and isn't needed for that. It does also act as a cache, but
if you nullify that benefit it's only approximately a 10% slowdown
even with a huge dbcache.
With a fast SSD (e.g. NVMe) I think the difference between a 400MB
cache and a 5GB one is "only" a halving of IBD time (when syncing from
LAN peers).
To prevent corruption the database updates must involve synchronizing
writes.
We changed how dbcache flushing worked with the explicit intention of
making background flushing possible so that it could be concurrently
flushing and processing blocks constantly rather than inserting these
bubbles where it waits on the disk. Even though the consistency
requirements make that possible now (the UTXO database doesn't have to
be consistent except there is a record that states that all blocks
before it have absolutely positively been applied to the database),
actually making the change is still extremely complicated.
Every time you process a block, once the cache fills you could flush
out to disk the remaining dirty entries for the oldest remaining
blocks until it's back under the limit again.. So essentially flushing
every block in the background.  Then every once in a while, you do a
disk sync and update the record that says where the completely
consistent point is, without having to flush anything additional out.
So almost no latency spikes at runtime.
This would be good for mining but doing that requires a bunch of
machinery to efficiently track things and probably would make sense to
replace the dbcache's map with an open hash table of some kind at the
same time to cut the malloc traffic down by 10x. I expect there is a
factor of 2 IBD speedup waiting from these changes. I'm not sure if
it'll ever happen though, it's a big complicated task and any mistake
is a consensus bug.
You can even do neat stuff like resolve collisions in the open hash
table by displacing the oldest UTXO and once you've gone "far enough"
flush. The table could run extremely close to completely full at all
times.
I'm personally fond of cuckoo tables. Where every item has a small
number of possible locations like two random buckets which each hold 4
items and if those locations are full you pick one, insert the item
there, bump what was in that slot into one of its alternative
locations.
If the table has a little slack  (no more than ~95% full for 2 buckets
of 4 items for example) then it's always successful at finding an
empty slot after a few kicks. Lookup is extremely fast since you only
need to do two random memory accesses. There are a bunch of different
designs though most are best when you can keep the table <50% full but
the cuckoo design is easy to take up to arbritarily high fullness.
The STL sets that Bitcoin uses are a hash table, but collisions are
resolved by having each entry in the hash table be a linked list, so
every access involves several pointer chases and every insertion takes
a malloc.


text:
What is cs_main? Why is it called cs_main?
What is cs_main? Why is it called cs_main?
This question was asked during the May 12th 2021 Bitcoin Core PR review club hosted by John Newbery on a Carl Dong PR to de-globalize ChainstateManager.
(The lock on cs_main was discussed in this StackExchange question.)

What is cs_main?

cs_main is a recursive mutex which is used to ensure that validation is carried out in an atomic way. It guards access to validation specific variables (such as CChainState and CNode) or mempool variables (in net_processing). The lock of cs_main is in validation.cpp.

Why is it called cs_main?

cs_main was the mutex ("critical section") that protected data in Satoshi's original main.cpp file. (main.cpp was entirely removed in PR 9260 in December 2016.) In theory cs_main could be renamed today as main.cpp has since been refactored into smaller files but every time you rename something in a header file, everyone needs to recompile any file that includes that header.
A long-term goal is to separate out those different bits of data that are protected by cs_main, so that eventually cs_main only protects the data inside validation.
These were answered by John Newbery and other participants of the May 12th 2021 Bitcoin Core PR review club.


text:
Estimated number of hashes
This is not a duplicate of previous, similar questions I've read on StackExchange, since none of those questions, nor the answers, go into the difficulty theory, as espoused on the Bitcoin Wiki.
Basically, I'm trying to calculate the number of attempts a miner needs to find a hash less than the target difficulty, through using some of the technical docs' on the Bitcoin Wiki. Hence, my answer is based on examples on that Wiki, but some of the explanations there are somewhat ambiguous. For example, I'm uncertain if the writer means difficulty1Target (they use difficulty_1_target), or difficulty 1. Therefore, I would be grateful if someone much more knowledgeable than I could run through my reasoning and also check my answer at the end.

The difficulty is calculated thus:
difficulty = difficulty1Target / currentTarget
Where target is a 256-bit (32-byte) number and difficulty1Target
  represents a hash where the leading 32 bits are zero and the rest are
  one. That is known as pool difficulty or pdiff. Floating point
  targets with limited precision allow clients to approximate
  difficulty. Such approximations are known as bdiff.
Each block stores a packed representation of the hexadecimal target.
  Supposing a target of 0x1b0404cb, the hexadecimal target is:
0x0404cb * 2^(8*(0x1b - 3)) = 0x00000000000404CB000000000000000000000000000000000000000000000000
Where 0x0404cb is a signed value. The largest legal value for that
  field is 0x7fffff and the smallest value is 0x008000.
The highest possible target, difficulty1Target, is defined as
  0x1d00ffff. That gives a hexadecimal difficulty target of:
0x00ffff * 2^(8*(0x1d - 3)) = 0x00000000FFFF0000000000000000000000000000000000000000000000000000
Pooled mining often uses non-truncated targets, giving a
  difficulty1Target of:
0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Hence, the bdiff difficulty at 0x1b0404cb is given by:
0x00000000FFFF0000000000000000000000000000000000000000000000000000 / 0x00000000000404CB000000000000000000000000000000000000000000000000
  = 16307.420938523983
And the pdiff difficulty is:
0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF / 0x00000000000404CB000000000000000000000000000000000000000000000000
  = 16307.669773817162
The following formula shifts the target difficulty so that it is
  offset against the difficulty1Target:
0xffff * 2^208
And to offset for difficulty D, we have:
(0xffff * 2^208)/D
Since a calculated hash to test against the target will be a random
  number between 0 and 2**256-1 (SHA-256 is a 256-bit value), for any
  given difficulty D, the algorithm for estimating the average number of
  calculations needed before finding a solution, is as follows:
D * 2^256 / (0xffff * 2^208), or just D * 2^48 / 0xffff [@BitcoinWiki_Difficulty_2018].
Hence, the estimated number of calculations needed to find a hash
  given the  bdiff difficulty at 0x1b0404cb is:
16307.420938523983 * 2^48 / 0xffff = 7.0040908e+13

Many thanks!

Possible duplicate of How many hashes create one Bitcoin?

That question, nor the answers, go into the theory regarding difficulty targets, so this is not a duplicate. Having said that, I like, very much, one of the answers that use the published hash rate. Nice!


text:
P2SH signature verification in python
I am trying to understand and verify P2SH script by writing a python code to parse real transaction in blockchain. I have chosen below Transaction randomly.
TxID: 7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45
I am getting BadSignatureError.
Raw transaction:
bitcoin-cli getrawtransaction 7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45
0100000001c8cc2b56525e734ff63a13bc6ad06a9e5664df8c67632253a8e36017aee3ee40000000009000483045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001455141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51aefeffffff0120f40e00000000001976a9141d30342095961d951d306845ef98ac08474b36a088aca7270400

Decode above Raw transaction and get Transaction ID of locking script:
bitcoin-cli decoderawtransaction $(bitcoin-cli getrawtransaction 7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45)
{
  "txid": "7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45",
  "hash": "7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45",
  "version": 1,
  "size": 229,
  "vsize": 229,
  "weight": 916,
  "locktime": 272295,
  "vin": [
    {
      "txid": "40eee3ae1760e3a8532263678cdf64569e6ad06abc133af64f735e52562bccc8",
      "vout": 0,
      "scriptSig": {
        "asm": "0 3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b790[ALL] 5141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae",
        "hex": "00483045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001455141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae"
      },
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 0.00980000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 1d30342095961d951d306845ef98ac08474b36a0 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9141d30342095961d951d306845ef98ac08474b36a088ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "13fLLox43yXYvfoZadXpGbkTUXkW8bhqut"
        ]
      }
    }
  ]
}

Get Decoded Transaction of locking script:
bitcoin-cli decoderawtransaction $(bitcoin-cli getrawtransaction 40eee3ae1760e3a8532263678cdf64569e6ad06abc133af64f735e52562bccc8)
{
  "txid": "40eee3ae1760e3a8532263678cdf64569e6ad06abc133af64f735e52562bccc8",
  "hash": "40eee3ae1760e3a8532263678cdf64569e6ad06abc133af64f735e52562bccc8",
  "version": 1,
  "size": 189,
  "vsize": 189,
  "weight": 756,
  "locktime": 0,
  "vin": [
    {
      "txid": "42a3fdd7d7baea12221f259f38549930b47cec288b55e4a8facc3c899f4775da",
      "vout": 0,
      "scriptSig": {
        "asm": "3044022048d1468895910edafe53d4ec4209192cc3a8f0f21e7b9811f83b5e419bfb57e002203fef249b56682dbbb1528d4338969abb14583858488a3a766f609185efe68bca[ALL] 031a455dab5e1f614e574a2f4f12f22990717e93899695fb0d81e4ac2dcfd25d00",
        "hex": "473044022048d1468895910edafe53d4ec4209192cc3a8f0f21e7b9811f83b5e419bfb57e002203fef249b56682dbbb1528d4338969abb14583858488a3a766f609185efe68bca0121031a455dab5e1f614e574a2f4f12f22990717e93899695fb0d81e4ac2dcfd25d00"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.00990000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 e9c3dd0c07aac76179ebc76a6c78d4d67c6c160a OP_EQUAL",
        "hex": "a914e9c3dd0c07aac76179ebc76a6c78d4d67c6c160a87",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "3P14159f73E4gFr7JterCCQh9QjiTjiZrG"
        ]
      }
    }
  ]
}

We need to evaluate unlocking script + locking script.
unlocking script:
00483045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001455141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae

Evaluate unlocking script:
step 1: stack -> 0x00 (OP_0)
step 2: stack -> 0x00, 0x3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001
step 3: stack -> 0x00,
0x3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001,
0x5141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae

Copy this stack as stack_copy
locking script:
a914e9c3dd0c07aac76179ebc76a6c78d4d67c6c160a87

Evaluate locking script now with the stack:
step 4: 0xa9 (OP_HASH160)
stack -> 0x00,
0x3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001,
0xe9c3dd0c07aac76179ebc76a6c78d4d67c6c160a

step 5: 0x14 (pushdata 20 bytes) 0xe9c3dd0c07aac76179ebc76a6c78d4d67c6c160a
stack -> 0x00,
0x3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001,
0xe9c3dd0c07aac76179ebc76a6c78d4d67c6c160a,
0xe9c3dd0c07aac76179ebc76a6c78d4d67c6c160a

step 6: 87 OP_EQUAL
stack -> 0x00,
0x3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001,
0x01

Since OP_EQUAL returned True and it is P2SH we evaluate redeem script against copied stack
stack = stack_copy
redeem script = stack.pop():
0x5141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae

Evaluate redeem script:
step 7: 0x51 (OP_1)
stack -> 0x00,
0x3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001,
0x01

step 8: 0x41 (Pushdata 65 bytes) 042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf
stack -> 0x00,
0x3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001,
0x01,
0x042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf

step 9: 0x51 (OP_1)
stack -> 0x00,
0x3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001,
0x01,
0x042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf,
0x01

step 10: 0xae (OP_CHECKMULTISIG)
We have 1 sig and 1 pubkey. To check multisig we need to get transaction which was signed. We will come back to this step once we have transaction which was signed.

Signature from stack:
0x3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001

Parse Signature:
0x30 DER
0x45 Length
0x02 Type Integer
0x21 Length of r
00 (ignore) ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf883 (r)
02 Type Integer
20 Length of s
0b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b790 (s)
01 SIGHASH_ALL

Sig-type is SIGHASH_ALL so we replace only unlocking script with locking script.
r||s: -------------------------------------------------------------(1)
ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf8830b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b790
Parsing raw transaction of unlocking script:
01 00 00 00 Version
01 input count
c8 cc 2b 56 52 5e 73 4f f6 3a 13 bc 6a d0 6a 9e 56 64 df 8c 67 63 22 53 a8 e3 60 17 ae e3 ee 40 Previous transaction
00 00 00 00 Previous transaction out index
--------- replace this [
90
00 48 30 45 02 21 00 ad 08 51 c6 9d d7 56 b4 51
90 b5 a8 e9 7c b4 ac 3c 2b 0f a2 f2 aa e2 3a ed
6c a9 7a b3 3b f8 83 02 20 0b 24 85 93 ab c1 25
95 12 79 3e 7d ea 61 03 6c 60 17 75 eb b2 36 40
a0 12 0b 0d ba 2c 34 b7 90 01 45 51 41 04 2f 90
07 4d 7a 5b f3 0c 72 cf 3a 8d fd 13 81 bd bd 30
40 70 10 e8 78 f3 a1 12 69 d5 f7 4a 58 78 85 05
cd ca 22 ea 6e ab 7c fb 40 dc 0e 07 ab a2 00 42
4a b0 d7 91 22 a6 53 ad 0c 7e c9 89 6b df 51 ae
------------- ]
fe ff ff ff sequence
01 out count
20 f4 0e 00 00 00 00 00 value
19 script size
76 a9 14 1d 30 34 20 95 96 1d 95 1d 30 68 45 ef 98 ac 08 47 4b 36 a0 88 ac script pubkey
a7 27 04 00 lock time
---> Add SIGHASH_ALL here

After replacing locking script with unlocking script:
01 00 00 00 Version
01 input count
c8 cc 2b 56 52 5e 73 4f f6 3a 13 bc 6a d0 6a 9e 56 64 df 8c 67 63 22 53 a8 e3 60 17 ae e3 ee 40 Previous transaction
00 00 00 00 Previous transaction out index
------- locking script [
17
a914e9c3dd0c07aac76179ebc76a6c78d4d67c6c160a87
------- ]
fe ff ff ff sequence
01 out count
20 f4 0e 00 00 00 00 00 value
19 script size
76 a9 14 1d 30 34 20 95 96 1d 95 1d 30 68 45 ef 98 ac 08 47 4b 36 a0 88 ac
a7 27 04 00 lock time
01 00 00 00 SIGHASH_ALL

Now performing OP_CHECKMULTISIG:
So we have transaction which is signed: ------------------------------(2)
0100000001c8cc2b56525e734ff63a13bc6ad06a9e5664df8c67632253a8e36017aee3ee400000000017a914e9c3dd0c07aac76179ebc76a6c78d4d67c6c160a87feffffff0120f40e00000000001976a9141d30342095961d951d306845ef98ac08474b36a088aca727040001000000

On stack we have:
0x00 ->
Signature ->
0x01 ->
Pubkey ->
0x01
pubkey :
    0x042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf
0x04 denote uncompressed. Removing that we have:
Pubkey : --------------------------------------------------------------(3)
0x2f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf

I used r||s as bytes of (1), raw_txn as bytes of (2) and pub_key as bytes as (3) for argument of below Python code to perform sigcheck:
def sigcheck(sig_b: bytes, pubkey_b: bytes, raw_txn_b: bytes):
        txn_sha256_b = hashlib.sha256(raw_txn_b).digest()

        prefix = pubkey_b[0:1]
        print('prefix = %s' % prefix)
        print('input pubkey = %s' % bytes.decode(binascii.hexlify(pubkey_b)))
        if prefix == b'\x02' or prefix == b'\x03':
                pubkey_b = getFullPubKeyFromCompressed(pubkey_b)[1:]
        elif prefix == b'\x04':
                pubkey_b = pubkey_b[1:]

        try:
                print("full public key = %s" % bytes.decode(binascii.hexlify(pubkey_b)))
                vk = ecdsa.VerifyingKey.from_string(pubkey_b, curve=ecdsa.SECP256k1)
                if vk.verify(sig_b, txn_sha256_b, hashlib.sha256) == True:
                        print('valid')
                        return 1
                else:
                        print('sigcheck: invalid')
                        return 0
        except ecdsa.BadSignatureError:
                print('sigcheck: Bad Signature')
                return 0

This program works perfectly to checksig in P2PKH scenario but it is failing here and I have no clue.
Running this program I am getting BadSignatureError.
I have given in great detail what I am doing.
Please help me understand and solve this.

I was using locking script (scriptPubKey) of previous transaction to replace unlocking script (scriptSig) of current transaction. Instead I needed to use redeemScript. Unlocking script is OP_0  .
So to get (2) we first get redeemScript from unlocking script.
Unlocking script:
90 Length of scriptSig
00 OP_0
48 Length of Signature
30
45
02
21
00 ad 08 51 c6 9d d7 56 b4 51 90 b5 a8 e9 7c b4 ac 3c 2b 0f a2 f2 aa e2 3a ed 6c a9 7a b3 3b f8 83
02
20
0b 24 85 93 ab c1 25 95 12 79 3e 7d ea 61 03 6c 60 17 75 eb b2 36 40 a0 12 0b 0d ba 2c 34 b7 90
01 SIGHASH_ALL
------ Redeem script ---->
45 51 41 04 2f 90
07 4d 7a 5b f3 0c 72 cf 3a 8d fd 13 81 bd bd 30
40 70 10 e8 78 f3 a1 12 69 d5 f7 4a 58 78 85 05
cd ca 22 ea 6e ab 7c fb 40 dc 0e 07 ab a2 00 42
4a b0 d7 91 22 a6 53 ad 0c 7e c9 89 6b df 51 ae
<-------------------------

We got Raw Transaction which was signed:
01 00 00 00 Version
01 input count
c8 cc 2b 56 52 5e 73 4f f6 3a 13 bc 6a d0 6a 9e 56 64 df 8c 67 63 22 53 a8 e3 60 17 ae e3 ee 40 Previous transaction
00 00 00 00 Previous transaction out index
------ Redeem script ---->
45 51 41 04 2f 90
07 4d 7a 5b f3 0c 72 cf 3a 8d fd 13 81 bd bd 30
40 70 10 e8 78 f3 a1 12 69 d5 f7 4a 58 78 85 05
cd ca 22 ea 6e ab 7c fb 40 dc 0e 07 ab a2 00 42
4a b0 d7 91 22 a6 53 ad 0c 7e c9 89 6b df 51 ae
<-------------------------
fe ff ff ff sequence
01 out count
20 f4 0e 00 00 00 00 00 value
19 script size
76 a9 14 1d 30 34 20 95 96 1d 95 1d 30 68 45 ef 98 ac 08 47 4b 36 a0 88 ac
a7 27 04 00 lock time
01 00 00 00 SIGHASH_ALL

Raw transaction which is signed: ------------------------------------(2)
0100000001c8cc2b56525e734ff63a13bc6ad06a9e5664df8c67632253a8e36017aee3ee4000000000455141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51aefeffffff0120f40e00000000001976a9141d30342095961d951d306845ef98ac08474b36a088aca727040001000000

Now (1), (2) and (3) gives Signature is Valid.

scriptsig from stack:

That is a signature, not the scriptSig. The scriptSig is what you are calling the unlocking script.

After replacing locking script with unlocking script:

Because you are trying to verify a P2SH transaction, you actually replace the scriptSig with the redeemScript, not the locking script (typically called the scriptPubKey).

I changed scriptsig to signature.
I didn't get your second comment as scriptPubKey of previous Transaction has
OP_HASH160  OP_EQUAL which I mentioned as locking script. The unlocking script is the redeem script which is like:
OP_0  OP_1  OP_1 OP_CHECKMULTISIG
So how else I should replace. Could you please explain how should I fix this issue?

No, the "unlocking script" is not the redeemScript. It is actually OP_0 <sig> <redeemScript>. The redeemScript is OP_  OP_1 OP_CHECKMULTISIG`. You want to replace the scriptSig with the redeemScript. What you are currently doing is replacing it with the scriptPubKey of the previous transaction.

I'll remove OP_0 and  from unlocking script and try.


text:
Signature verification in python using compressed public key
I am trying to learn bitcoin blockchain programming. I am trying to verify signature in Transaction with txid: 4269fdc239d027922dcec96f1ae283dbaff10e2d1bd49605661d091e79714956
I am getting BadSignatureError
Raw Transaction
./bitcoin-cli getrawtransaction 4269fdc239d027922dcec96f1ae283dbaff10e2d1bd49605661d091e79714956
01000000017f950ab790838e0c05e79856d25d586823fe139e1807405a3f207ff33f9b7663010000006b483045022100d8629403cd3b49950da9293653c6279149c029e6b7b15371342d0d2ce286c8f2022078787985a644e94fd9246f6c25733336c94af5f00d9d34a07dc2f9e0987ef990012102b726d7eae11a6d5cf3b2362e773e116a6140347dcee1b2943f4a2897351e5d90ffffffff021bf03c000000000017a91469f3757380a56820abc7052867216599e575cddd8777c1ca1c000000001976a914d5f950abe0b559b2b7a7ab3d18a507ea1c3e4ac688ac00000000

Decode Raw Transaction
./core/bitcoin-0.16.0/bin/bitcoin-cli decoderawtransaction 01000000017f950ab790838e0c05e79856d25d586823fe139e1807405a3f207ff33f9b7663010000006b483045022100d8629403cd3b49950da9293653c6279149c029e6b7b15371342d0d2ce286c8f2022078787985a644e94fd9246f6c25733336c94af5f00d9d34a07dc2f9e0987ef990012102b726d7eae11a6d5cf3b2362e773e116a6140347dcee1b2943f4a2897351e5d90ffffffff021bf03c000000000017a91469f3757380a56820abc7052867216599e575cddd8777c1ca1c000000001976a914d5f950abe0b559b2b7a7ab3d18a507ea1c3e4ac688ac00000000
{
  "txid": "4269fdc239d027922dcec96f1ae283dbaff10e2d1bd49605661d091e79714956",
  "hash": "4269fdc239d027922dcec96f1ae283dbaff10e2d1bd49605661d091e79714956",
  "version": 1,
  "size": 224,
  "vsize": 224,
  "locktime": 0,
  "vin": [
    {
      "txid": "63769b3ff37f203f5a4007189e13fe2368585dd25698e7050c8e8390b70a957f",
      "vout": 1,
      "scriptSig": {
        "asm": "3045022100d8629403cd3b49950da9293653c6279149c029e6b7b15371342d0d2ce286c8f2022078787985a644e94fd9246f6c25733336c94af5f00d9d34a07dc2f9e0987ef990[ALL] 02b726d7eae11a6d5cf3b2362e773e116a6140347dcee1b2943f4a2897351e5d90",
        "hex": "483045022100d8629403cd3b49950da9293653c6279149c029e6b7b15371342d0d2ce286c8f2022078787985a644e94fd9246f6c25733336c94af5f00d9d34a07dc2f9e0987ef990012102b726d7eae11a6d5cf3b2362e773e116a6140347dcee1b2943f4a2897351e5d90"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.03993627,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 69f3757380a56820abc7052867216599e575cddd OP_EQUAL",
        "hex": "a91469f3757380a56820abc7052867216599e575cddd87",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "3BMEXVvXXRFh2eJ9Eji115xfqJjWmLTCf8"
        ]
      }
    },
    {
      "value": 4.83049847,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 d5f950abe0b559b2b7a7ab3d18a507ea1c3e4ac6 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914d5f950abe0b559b2b7a7ab3d18a507ea1c3e4ac688ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1LWPbaYN2jqhv9oZvYHxYKXuaiR1qJn52i"
        ]
      }
    }
  ]
}

Here "asm" contains Signation and Public Key
  "vin": [
    {
      "txid": "63769b3ff37f203f5a4007189e13fe2368585dd25698e7050c8e8390b70a957f",
      "vout": 1,
      "scriptSig": {
        "asm": "3045022100d8629403cd3b49950da9293653c6279149c029e6b7b15371342d0d2ce286c8f2022078787985a644e94fd9246f6c25733336c94af5f00d9d34a07dc2f9e0987ef990[ALL] 02b726d7eae11a6d5cf3b2362e773e116a6140347dcee1b2943f4a2897351e5d90",
        "hex": "483045022100d8629403cd3b49950da9293653c6279149c029e6b7b15371342d0d2ce286c8f2022078787985a644e94fd9246f6c25733336c94af5f00d9d34a07dc2f9e0987ef990012102b726d7eae11a6d5cf3b2362e773e116a6140347dcee1b2943f4a2897351e5d90"
      },
      "sequence": 4294967295
    }
  ],

To obtain Signature
3045022100d8629403cd3b49950da9293653c6279149c029e6b7b15371342d0d2ce286c8f2022078787985a644e94fd9246f6c25733336c94af5f00d9d34a07dc2f9e0987ef990
=>
0x30 DER
0x45 Length
0x02 Type Integer
0x21 Length of R
0x00d8629403cd3b49950da9293653c6279149c029e6b7b15371342d0d2ce286c8f2 (R)
0x02 Type Integer
0x20 Length of S
0x78787985a644e94fd9246f6c25733336c94af5f00d9d34a07dc2f9e0987ef990 (S)

Removing 00 from R
Signature = R + S = d8629403cd3b49950da9293653c6279149c029e6b7b15371342d0d2ce286c8f278787985a644e94fd9246f6c25733336c94af5f00d9d34a07dc2f9e0987ef990

Compressed Public Key
02b726d7eae11a6d5cf3b2362e773e116a6140347dcee1b2943f4a2897351e5d90
Uncompressing Public Key
Code
def getFullPubKeyFromCompressed(x_str: str):
        prefix = x_str[0:2]
        print("prefix = %s" % (prefix))
        x_str = x_str[2:]
        x = int(x_str, 16)
        print("x = %x" % (x))
        p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F
        y_squared = (x**3 + 7) % p
        y = modular_sqrt(y_squared, p)
        y_str = "%x" % y
        print("y_str = %s" % (y_str))
        y_is_even = (int(y_str[-1], 16) % 2 == 0)
        if prefix == "02" and y_is_even == False or prefix == "03" and y_is_even == True:
                y = p - y
                y_str = "%x" % y
        print("y = %s" % (y_str))
        return "04" + x_str + y_str

prefix = pubkey[0:2]
if prefix == "02" or prefix == "03":
        pubkey = getFullPubKeyFromCompressed(pubkey)[2:]
elif prefix == "04":
                pubkey = pubkey[2:]
print("full public key = %s" % pubkey)

Output:
x = b726d7eae11a6d5cf3b2362e773e116a6140347dcee1b2943f4a2897351e5d90
y_str = cacc567dc3036f2fceb1b6f16676285b153821eb79825dae124b17b9e29479cb
y = 3533a9823cfc90d0314e490e9989d7a4eac7de14867da251edb4e8451d6b8264
full public key = b726d7eae11a6d5cf3b2362e773e116a6140347dcee1b2943f4a2897351e5d903533a9823cfc90d0314e490e9989d7a4eac7de14867da251edb4e8451d6b8264

Transaction single time SHA256 hashing as this will be done again signature verification
Code
hashval = binascii.hexlify(hashlib.sha256(bytes.fromhex(raw_txn)).digest())
txn_sha256 = bytes.decode(hashval)
print("txn_sha256 = %s" % (txn_sha256))

Output
txn_sha256 = fb0c792bfba8139654cffd2818bdd56f3541d11fb43ea46f646c3477de3d2e40

We have all three information to verify signature now
txn_sha256 = fb0c792bfba8139654cffd2818bdd56f3541d11fb43ea46f646c3477de3d2e40
pubkey = b726d7eae11a6d5cf3b2362e773e116a6140347dcee1b2943f4a2897351e5d903533a9823cfc90d0314e490e9989d7a4eac7de14867da251edb4e8451d6b8264
sig = d8629403cd3b49950da9293653c6279149c029e6b7b15371342d0d2ce286c8f278787985a644e94fd9246f6c25733336c94af5f00d9d34a07dc2f9e0987ef990

I execute check signature program
sig_b = bytes.fromhex(sig)
txn_sha256_b = bytes.fromhex(txn_sha256)
vk = ecdsa.VerifyingKey.from_string(bytes.fromhex(pubkey),curve=ecdsa.SECP256k1)
if vk.verify(sig_b, txn_sha256_b, hashlib.sha256) == True: # True
        print("Signature is Valid")
else:
        print("Signature is not Valid")

But I get BadSignatureError
Traceback (most recent call last):
  File "bitcoin_localapis.py", line 294, in <module>
    sigcheck(sig, pubkey, raw_txn)
  File "bitcoin_localapis.py", line 202, in sigcheck
    if vk.verify(sig_b, txn_sha256_b, hashlib.sha256) == True: # True
  File "/home/vizeet/anaconda3/lib/python3.6/site-packages/ecdsa/keys.py", line 101, in verify
    return self.verify_digest(signature, digest, sigdecode)
  File "/home/vizeet/anaconda3/lib/python3.6/site-packages/ecdsa/keys.py", line 113, in verify_digest
    raise BadSignatureError
ecdsa.keys.BadSignatureError

Please help me solve this issue.

Problem was with the Raw Transaction I used for signature verification.
Original Raw Transaction
./bitcoin-cli getrawtransaction 4269fdc239d027922dcec96f1ae283dbaff10e2d1bd49605661d091e79714956
01000000017f950ab790838e0c05e79856d25d586823fe139e1807405a3f207ff33f9b7663010000006b483045022100d8629403cd3b49950da9293653c6279149c029e6b7b15371342d0d2ce286c8f2022078787985a644e94fd9246f6c25733336c94af5f00d9d34a07dc2f9e0987ef990012102b726d7eae11a6d5cf3b2362e773e116a6140347dcee1b2943f4a2897351e5d90ffffffff021bf03c000000000017a91469f3757380a56820abc7052867216599e575cddd8777c1ca1c000000001976a914d5f950abe0b559b2b7a7ab3d18a507ea1c3e4ac688ac00000000

Parsing this manually
01 00 00 00 Version
01 Input Count
7f 95 0a b7 90 83 8e 0c 05 e7 98 56 d2 5d 58 68 23 fe 13 9e 18 07 40 5a 3f 20 7f f3 3f 9b 76 63 (32 Bytes of Previous Transaction ID)
01 00 00 00 Output Index (vout index)
6b Script Length (107 bytes) (Replace this)
48 30 45 02 21 00 d8 62 94 03 cd 3b 49 95 0d a9 29 36 53 c6 27 91 49 c0 29 e6 b7 b1 53 71 34 2d 0d 2c e2 86 c8 f2 02 20 78 78 79 85 a6 44 e9 4f d9 24 6f 6c 25 73 33 36 c9 4a f5 f0 0d 9d 34 a0 7d c2 f9 e0 98 7e f9 90 01 21 02 b7 26 d7 ea e1 1a 6d 5c f3 b2 36 2e 77 3e 11 6a 61 40 34 7d ce e1 b2 94 3f 4a 28 97 35 1e 5d 90 Script (and Replace this)
ffffffff021bf03c000000000017a91469f3757380a56820abc7052867216599e575cddd8777c1ca1c000000001976a914d5f950abe0b559b2b7a7ab3d18a507ea1c3e4ac688ac00000000 Remaing bytes
01 00 00 00 Append SIGHASH_ALL

Replace Portion of transaction marked above with scriptPubKey. There seems to be no reason why we do this. Refer this discussion:

https://bitcointalk.org/index.php?topic=102487.msg1123257#msg1123257

compressed pubkey = 02b726d7eae11a6d5cf3b2362e773e116a6140347dcee1b2943f4a2897351e5d90
Address from Public Key:
Code
def sha256d(bstr):
    return hashlib.sha256(hashlib.sha256(bstr).digest()).digest()

def convertPKHToAddress(prefix, addr):
    data = prefix + addr
    return base58.b58encode(data + sha256d(data)[:4])

def pubkeyToAddress(pubkey_hex):
        pubkey = bytearray.fromhex(pubkey_hex)
        round1 = hashlib.sha256(pubkey).digest()
        h = hashlib.new('ripemd160')
        h.update(round1)
        pubkey_hash = h.digest()
        return convertPKHToAddress(b'\x00', pubkey_hash)

Output Address
1LWPbaYN2jqhv9oZvYHxYKXuaiR1qJn52i

Hash160 of Address (from https://blockchain.info/address/1LWPbaYN2jqhv9oZvYHxYKXuaiR1qJn52i)
d5 f9 50 ab e0 b5 59 b2 b7 a7 ab 3d 18 a5 07 ea 1c 3e 4a c6

Adding size to hashed address
14 d5 f9 50 ab e0 b5 59 b2 b7 a7 ab 3d 18 a5 07 ea 1c 3e 4a c6

Input Transaction Hash = 63769b3ff37f203f5a4007189e13fe2368585dd25698e7050c8e8390b70a957f
This transaction has following out scriptPubKey. One of them is spent in this transaction which we will find out.
out index 0: 76 a9 14 89 df 43 9f 5e 48 c0 e7 ec d6 91 af fa 1f b8 39 15 7e 0a 71 88 ac
out index 1: 76 a9 14 d5 f9 50 ab e0 b5 59 b2 b7 a7 ab 3d 18 a5 07 ea 1c 3e 4a c6 88 ac

Decoding scriptPubKey
OP_DUP = 0x76 (first byte of both)
OP_HASH160 = 0xa9 (second byte of both)
OP_EQUALVERIFY = 0x88 (second last byte of both)
OP_CHECKSIG = 0xac (last byte of both)

So we need Hash160 of public key in scriptSig of transaction we are investigating. This we have already calculated. Adding script to hash160 from public key we get
76 a9 14 d5 f9 50 ab e0 b5 59 b2 b7 a7 ab 3d 18 a5 07 ea 1c 3e 4a c6 88 ac

Size of New script = 25 = 0x19
New script
19 76 a9 14 d5 f9 50 ab e0 b5 59 b2 b7 a7 ab 3d 18 a5 07 ea 1c 3e 4a c6 88 ac

So we found that this is equal to scriptPubKey of second out of input transaction. This out is marked spent.
Now after inserting this script to Raw Transaction.
We get new Raw Transaction
01 00 00 00 Version
01 Input Count
7f 95 0a b7 90 83 8e 0c 05 e7 98 56 d2 5d 58 68 23 fe 13 9e 18 07 40 5a 3f 20 7f f3 3f 9b 76 63 (32 Bytes of Previous Transaction ID)
01 00 00 00 Output Index (vout index)
19 76 a9 14 d5 f9 50 ab e0 b5 59 b2 b7 a7 ab 3d 18 a5 07 ea 1c 3e 4a c6 88 ac (New Script)
ffffffff021bf03c000000000017a91469f3757380a56820abc7052867216599e575cddd8777c1ca1c000000001976a914d5f950abe0b559b2b7a7ab3d18a507ea1c3e4ac688ac00000000 (Remaining)
01 00 00 00 Append SIGHASH_ALL

Which becomes New Raw Transaction
01000000017f950ab790838e0c05e79856d25d586823fe139e1807405a3f207ff33f9b7663010000001976a914d5f950abe0b559b2b7a7ab3d18a507ea1c3e4ac688acffffffff021bf03c000000000017a91469f3757380a56820abc7052867216599e575cddd8777c1ca1c000000001976a914d5f950abe0b559b2b7a7ab3d18a507ea1c3e4ac688ac0000000001000000

We need to just apply SHA256 once as signature verify method also applies SHA256.
Code
hashval = binascii.hexlify(hashlib.sha256(bytes.fromhex(raw_txn)).digest())
txn_sha256 = bytes.decode(hashval)
print("txn_sha256 = %s" % (txn_sha256))

Output :
txn_sha256 = 3d3b8997cc9c0e2275bd0f694b862f7d0bee4f7aee2456891e038322884070ad

Now we have all three variables required for signature verification
pubkey = b726d7eae11a6d5cf3b2362e773e116a6140347dcee1b2943f4a2897351e5d903533a9823cfc90d0314e490e9989d7a4eac7de14867da251edb4e8451d6b8264
sig = d8629403cd3b49950da9293653c6279149c029e6b7b15371342d0d2ce286c8f278787985a644e94fd9246f6c25733336c94af5f00d9d34a07dc2f9e0987ef990
txn_sha256 = 3d3b8997cc9c0e2275bd0f694b862f7d0bee4f7aee2456891e038322884070ad

Now execiting Signature Verification code
code
sig_b = bytes.fromhex(sig)
txn_sha256_b = bytes.fromhex(txn_sha256)
vk = ecdsa.VerifyingKey.from_string(bytes.fromhex(pubkey),curve=ecdsa.SECP256k1)
if vk.verify(sig_b, txn_sha256_b, hashlib.sha256) == True: # True
        print("Signature is Valid")
else:
        print("Signature is not Valid")

Gives Signature is Valid


text:
Is there any open source tool to verify segwit transaction without publishing it?
I have created below transaction:
020000000001016c6bb8dbaa1e6b25d1267487b22206275c90a5aa8c28eb3c3aa87c97d717cf460000000017160014b6f9a9a9f51190e22798f85983c4f53fab1385a4ffffffff01faba00000000000017a914d6894287b4a028cd75ee8649ea3d59dba76ee55487024730440220373a133c6cbb6086d3e6c7152b3dda362c54dd7b2cdee60f40b862bd4cc4e012022008f034ac4c955e78a33833e485590e7598a9a19cd2196901e2e6f4d147dac4030121029d7cf71205e62ff34ff56ccd695e073397bf3330879dad2d2ffeff703748feb800000000

This is P2SH-P2WPKH signed transaction created by my python program. My intention is to validate my code without loosing bitcoins in the process. I did not find an option in bitcoin-cli to validate it. If there is any open source bitcoin client or online tool i can use to validate it, it will help in my testing.

You can use the testmempoolaccept RPC command if you're spending an existing output.
But setting up a regtest to make fake transaction is preferable.


text:
How many channels can I create from a Lightning Node?
I am new to the Lightning Network / Bitcoin and am trying to get an understanding as to how it functions.
Basically, suppose I have a Lightning Node (created with "lightningd"). It is my understanding that this is a daemon that starts at a certain port: 9735. On my picture, it is the box with "My Node".

Question 1: is there only one wallet inside of this node? If so, is there a way to have additional wallets inside of the same node? Does one use the wallet address when one receives/sends funds (kind of like the way the Bitcoin address to receive/send funds)?
Question 2: Is there a limit to the number of Channels I can create from "My Node"?
Suppose I have some relatives that do not use Smartphones but want to send/receive money over the network. They are represented in my picture with "Grandma", "Grandpa", "Mom", "Dad", and "Aunt Wilma".
Since they are older, they do not know much about computers, I am running their LN Nodes for them on my own computer.
Question 3: In this case, would I need 6 extra Lightning Network daemons ("lightningd") on my computer?  If so, then would each daemon have to assign a different port address? Is there be a better way to do this?
TIA

Question 1: is there only one wallet inside of this node? If so, is there a way to have additional wallets inside of the same node? Does one use the wallet address when one receives/sends funds (kind of like the way the Bitcoin address to receive/send funds)?

A wallet is not the same thing as an address. A wallet is a collection of addresses and their private keys or scripts. A Lightning Node is also a wallet; there is only one wallet, but there are still multiple addresses and private keys.

Question 2: Is there a limit to the number of Channels I can create from "My Node"?

In theory, no. In practice, your computer could run out of resources to maintain open connections. Regardless, you can have multiple channels open and it should not be a problem unless you are trying to have hundreds or thousands of channels.

Question 3: In this case, would I need 6 extra Lightning Network daemons ("lightningd") on my computer?  If so, then would each daemon have to assign a different port address? Is there be a better way to do this?

No, one daemon can have multiple channels.

@@Andrew Chow - thanks for the response. Pls see comment section.

Please do not edit an answer as a reply to the answer. Any comments should be made as a comment.

The last answer is a bit short. I think the asker would like to know whether there is a way to keep funds for multiple parties separate on a single node. E.g. I thought you'd specify a node as the recipient in any invoice, not a channel. Then it would require a separate layer of accounting to keep track of who owns which funds and it would be difficult to give spending access only to the separate owners only.


text:
Using a programming API with blockchain
New to using BTC and the Blockchain.
My understanding is that (for the Bitcoin), one can download/install btcd.
Then, one has to use btcd to synchronize the "local" Blockchain with the "main" Blockchain(?)
If so, what is the best API that one can use to access the data in the Blockchain?
I saw this:
https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)
For example, I have seen blockchain.info - but - I am not sure that one can download this and have it "point" to one's local btcd.
Any suggestions, help or hints would be greatly appreciated.
TIA

blockchain.info API is not related to Bitcoin-core, you can send commands to Bitcoin-core without the need to blockchain.info
for example to get full details about non-wallet transaction enable txindex and call getrawtransaction for wallet transactions call gettransaction and so on.
You can find all RPC calls here and you can send RPC commands from PHP, Nodejs etc..
if you want to have the full blockchain synced locally you can use bitpay insight (open source blockchain explorer).
or simply as you suggested you can use blockchain.info API without installing Bitcoin-core.


text:
How to get raw block data?
I can use getblock json rpc method to get parsed block details, however I need the actual raw data.
Is there any way to get raw block data using Bitcoin Core?

You can read it directly from the blk*.dat files...

So to implement such method as getrawblock I need to create my own index with filename and offset for each block, right?

In principle you can use the existing leveldb database in the blocks/index directory to locate the block data within the blk*.dat file by its hash.  See https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_2):_Data_Storage or https://bitcoin.stackexchange.com/questions/28168/what-are-the-keys-used-in-the-blockchain-leveldb-ie-what-are-the-keyvalue-pair for the data format.

There's a boolean parameter to that RPC call that'll return it as a hex string representing the binary contents of the block.

If verbosity is 0, returns a string that is serialized, hex-encoded data for block 'hash'

getblock 'hash' 0 should return what you want.


text:
php call to getnewaddress through rpc gives isValid false address
I am using easybitcoin.php to make rpc calls to bitcoind running on my server.
When I call $result = $bitcoin->getnewaddress(); from the php code, I get back an address, however when I run that address through:
$result = $bitcoin->validateaddress('mwFXW37HgXTHwtigRyLZDCAohgabswktoF1');

The result is always isValid => false
If I create this from command line using bitcoin-cli getnewaddress, then validateaddress returns a json dump, as expected.
Why is the behavior different for both cases?
I am on -regtest and not mainnet.
My worry is that the getnewaddress through rpc is not creating a valid account somehow.
FYI, my wallet is encrypted with a passphrase.


text:
Wallet to wallet in congested periods
I have waited for nearly 24 hours for my BTC transfer to my new wallet.
Does the amount I sent fluctuate with the markets?
For example, If I send .01 BTC and while the transfer is in progress, the value of BTC goes up, will I still receive the profit when it arrives to me?

You sent X BTC, and you will eventually receive X BTC.
There is no profit or market condition involved here. You hold the same amount of BTC before and after.
You can of course choose to sell those BTC, and if the market value goes up, then yes you can sell at a higher price when expressed in another currency. But this is entirely independent from you transferring coins.


text:
Recommended fee for an 100 Euro deposit
What is a solid amount of fee for a 100 Euro transaction right now?
I have googled myself but the results were quite confusing to me.
I've had a bad experience with my last payment due to a low fee, so I don't want to go along that road again...

The euro value of the btc transacted does not affect the fee rate at all. What matters is the size in bytes of the raw transaction. Larger size = more fees, and vice versa.
What decides the size of a transaction? There are a few variables, but for basic transactions what will matter is the number of inputs, and the number of outputs.
You wallet software may provide a few different 'fee levels' to choose from, or it may allow you to choose a fee rate manually (this should be listed in satoshi/vbyte). At any given moment, the fee rate depends on how many other transactions are being processed, and what their fee rates are.
Think of it as a tour bus that only has room for a certain amount of people, when the demand is higher than there are number of seats, whoever pays most gets to take the bus trip first (where 'taking a trip' = having your tx confirmed in a block). Everyone else who offers to pay less will have to wait for the next trip (the next block, or longer, depending on how far back in the queue they are).
You can check to see what other people are currently willing to pay by looking at a website like Johoe's Mempool. The charts on that page show the number of txs currently in queue, and what the fee rate they are offering is. So to get your transaction confirmed right away, you will need to set a fee rate that is at the top of the chart (right now, it looks like 140+ sat/vbyte will work). Personally, I find looking at the mempool and manually estimating what the fee rate should be works better than the software solutions that just have a couple automatic options (I've tried a few different mobile wallets like this: usually they either give you an estimate that is probably higher than needed, or one so low that I know it won't confirm for days or more).
Keep in mind, if a lot of other people are looking at the graph and also submitting txs right now, there is a chance that what looks like a good fee rate now will not be enough in 10 minutes (because everyone else also sees 140 is the minimum right now, and so they all offer 200. Now your 140 is stuck in line behind them)!


text:
How to become bitcoin developer?
I am a PHP developer and want to learn about bitcoin development.
I've searched on Google many times, however I can't get any perfect links that explain what is the requirement to become a bitcoin developer.
I don't currently understand bitcoin terminology, so all the articles are above my comprehension level.
So my questions are:

To become a bitcoin developer, how much knowledge do I need to have and from where I can get?
I'm a PHP and JavaScript developer; what type of development on that I can try?
Where can I get knowledge about bitcoin, wallet and BlockChain terminology?
I've also checked bitcore, bitcoin, and bitcoincore websites, however there are no beginner type tutorials.

In short I'm a blank slate with regards to BitCoin and BlockChain technologies.  Can you provide any guidance to start in this new field?

what do you mean by bitcoin developer? do you want to become a developer of bitcoincore or do you want to learn how to develop bitcoin-/blockchain-related-applications?

The easiest way is the same as for other topics:
Search for an open source project where you can help. They often have a list of tasks, sometimes a list of jobs to be done in different categories, from translating their website over artwork to C++ programming or whatever they are using.
Another way is to create something that helps you. Maybe you want to check the blockchain size from your smartphone? Write some PHP program which checks the size of the file on your PC. Maybe you start reading about the format of the file and extract more interesting data and finally you created some useful project for others.
I do not know what interests you and what you can do, you need to find for yourself what you want to do.
For the knowledge part: There is documentation about the program, the protocol and BIP-documents for new (and existing) features. The client itself is open source and miners are as well. You will need to read some more technical documents or source code, but as a developer this will probably be not new for you.


text:
Mining Altcoin with hash rate bigger than average network hash rate
I am sorry if the question is off-topic but cannot find an answer to a simple question anywhere including btctalk.
So let's say a network hashrate of some coin using the X16R algorithm is 40 MH/s.  What happens if I start to mine with 2 8x1080 Ti rigs giving me about 200-220 Mh/s?
How can I calculate the percentage of total coins I get in 24h?
Suppose total number of coins mined in 24h is 7 million.

This depends on the altcoin-specific mining implementation.  However, assuming a mining model like Bitcoin, which runs on proof-of-work, you'd get the majority of coins mined in any given day if you have a higher hashrate than the rest of the network combined.
So, if there are 100 coins available to be mined per day, and before you start mining the network hashrate is 100 hashes per day, you'd mine 33 coins per day if you suddenly started mining at 50 hashes per day, assuming difficulty is adjusted on a per-block-basis.
Or, if the network hash rate is 40 MH/sec and you suddenly start mining with 220 MH/sec, and the number of coins issued stays stable, you'd get 84.6% of the coins mined, on average.  This assumes the proof-of-work required to generate a block of coins is recalculated continuously, which is not generally the case, but it makes the calculation easier, and at some point the network will adjust the difficulty to reflect the total hashrate.  If this was Bitcoin, where the difficulty is adjusted every 2016 blocks, you'd have a major advantage for up-to 2016 blocks, or whenever the next difficulty adjustment occurred.


text:
Is the nVersion=3 policy proposal introducing additional policy rules and going against the policy principle to only relax policy rules?
In the PR review club on "nVersion=3 and Package RBF" (February 22nd 2023) glozow stated:

But in policy we want to strictly loosen rules. Otherwise we could accidentally censor transaction relay for an application. So either we really really make sure nobody is using it currently, or just pick something that's nonstandard today. In a sense, we always want consensus changes to be soft forks, but policy changes to be "hard forks".

I was looking at the proposal for nVersion=3 transactions and that seems to introduce a new set of "additional rules" that don't seem to be relaxations. So is it the case that ideally this wouldn't be the case but the nVersion=3 proposal is ignoring this principle because they are needed for Lightning and multiparty protocols?

The PR review club notes state:

A “v3 transaction” refers to a transaction that has its nVersion field set to 3. These types of transactions are currently nonstandard in Bitcoin Core.

Because v3 transactions are currently nonstandard if you make them standard (even with a set of additional policy rules applied to them) then this is still essentially a relaxation as you are now accepting into your mempool (and relaying) a subset of transactions with the nVersion field set to 3 when you previously weren't at all.
The equivalent in consensus would be introducing a new SegWit version (e.g. SegWit v2) that had more relaxed consensus rules than SegWit v1. You might think "more relaxed" means it is a hard fork but because SegWit v2 were previously anyone-can-spend (no consensus rules) applying any consensus rules to SegWit v2 outputs is adding restrictions and hence still a soft fork.


text:
Did not recieved bit coin due to unconfirmed transaction since 2 days
I sent 0.305*** some bit from my block chain wallet to zebapy wallet.
Since 2 days I did not received any amount and also I can see in block chain information that 0 - pending confirmations. (0/6).
Can anyone help me how to get my money back?
https://blockchain.info/address/38QFMgBBTX8j8Zn36nuVJnaHWnWgmGmHdU


text:
Deposit of bitcoin
Could you tell me why i didn't get all my money (from 0,66 BTC i got only 0,26 BTC) on my Cryptopia account. You can see 5 transactions from bitins (each 0,13 BTC)
35290 - 81b5d7f84a230dc9350572e76853b6bdc9e48989ec26b7787b91fcf53181574a
35291 - 81b5d7f84a230dc9350572e76853b6bdc9e48989ec26b7787b91fcf53181574a
35294 - 7946f99c156212334a562aa28766e08c54e96a16c78341574ac6e62f8e82ea10
35295 - 7946f99c156212334a562aa28766e08c54e96a16c78341574ac6e62f8e82ea10
35296 - 7946f99c156212334a562aa28766e08c54e96a16c78341574ac6e62f8e82ea10

I searched for the transactions on the blockchain explorer and both have been added to blocks and have been confirmed more than enough times. The bitins site does have a comment on their redeem a voucher page which states that they are having problems with their transactions not being processed quickly on the bitcoin network. It does look like they are experiencing problems but not sure if that would explain why you are not seeing your full transaction amounts.


text:
Derive private keys from a HD key
HD (hierarchical deterministic) wallets contain master private key, from which all the private keys can be derived.
Is there a CLI tool that calculates the private keys out of a HD key?

You can use ku  utility provided in pycoin library.
example:
ku -s 0/0-2 xprv9xWkBDfyBXmZsA85GyWj9uYPyoQv826YAadKWMaaEosNrFBKgj2TqWuiWY3zuqxYGpHfv9cnGj5P7e8EskpzKL1Y8Gk9aX6QbryA5raK73p

will generate keys from index 0-2 on derivation path 0/x


text:
Procedure for Deriving Payment Addresses
I'm trying to understand the HD wallet payment derivation procedure, so assume:

Ownership of a Bitcoin HD Wallet on an external smart device
Exported account level extended public key (xpub....) from the first account.
Derivation Path "m/44'/0'/0'/0/0"

What is the step-by-step procedure that one would use to derive a valid bitcoin payment address that can be confirmed with the external wallet?
The process, according to BIP32 - Child key derivation (CKD) functions, seems simple and straight-forward enough that it should be able to be written as a single function in any programming language with two processes: Base58 and HMAC-SHA512, which are such standard functions that I don't believe that it's necessary to install a platform tool and a bloated spaghetti code library to perform the derivation.
UPDATE 20190718:
Here's what I've been able to cobble together from various sources. PHP code and reference source for the derivation process:
<?php

  // https://iancoleman.io/bip39/ - Downloaded and used offline.
  // Bip39 Test Mnemonic: abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about

 $Pub = "xpub6BosfCnifzxcFwrSzQiqu2DBVTshkCXacvNsWGYJVVhhawA7d4R5WSWGFNbi8Aw6ZRc1brxMyWMzG3DSSSSoekkudhUd9yLb6qx39T9nMdj";

 $Index = "00000000";

 $ExtPubKey = bin2hex(base58_decode($Pub));

 $Type = substr($ExtPubKey,0,8);

 $Depth = substr($ExtPubKey,8,2);

 $Fingerprint = substr($ExtPubKey,10,8);

 $Account = substr($ExtPubKey,18,8);

 $ParentChainCode = substr($ExtPubKey,26,64);

 $ParentPublicKey = substr($ExtPubKey,90,66);

 $PubChecksum = substr($ExtPubKey,-8);

 $PublicKey = hash_hmac('sha512',$ParentChainCode,$ParentPublicKey.$Index);

 $PublicKey = "04".$PublicKey;

 $PublicKeyHash = hash('ripemd160',hash('sha256',$PublicKey,False));

 $BaseAddress = "00".$PublicKeyHash;

 $PreChecksum = hash('sha256',hash('sha256',$BaseAddress));

 $Checksum = substr($PreChecksum,0,8);

 $Address = $BaseAddress.$Checksum;

 $PaymentAddress = base58_encode(hex2bin($Address));

 echo "Payment Address: $PaymentAddress\n";

?>

I'm using xpub to prove that the procedure works. Ultimately would like to be able to derive for ypub and zpub.
It seems like I'm just missing something important, like maybe variable typing, maybe binary something...I'm at a loss.
I've been told by Andreas that there's something about adding two numbers together, but I'm not finding the reference to it.
One source referenced something about elliptic curve and a mystical variable "G" but with no explanation.
According to BIP32, this process is supposed to be really easy.
Any assistance would be appreciated. TIA.

There are hundreds of open-source projects that do exactly this. Dozens that are trusted by experts, used in mainstream production by millions. Step through, parsing these libraries rather than expecting others to walk you through the process.

The method for deriving child keys from extended keys is specified in BIP 32.
Note that the specific derivation paths for xpubs, ypubs, and zpubs are not defined by BIP 32 but rather are constructions created by Electrum and SatoshiLabs. These have a specific meaning described in SLIP 132. Their encoding is the same as described for xpubs in BIP 32 but with a different prefix byte.

I'm looking for a clearly defined and documented, step-by-step procedure that will take ypub6Ww3ibxVfGzLrAH1PNcjyAWenMTbbAosGNB6VvmSEgytSER9azLDWCxoJwW7Ke7icmizBMXrzBx9979FfaHxHcrArf3zbeJJJUZPf663zsP and successfully derive 37VucYSaXLCAsxYyAPfbSi9eh4iEcbShgf as the payment address indicated by the derivation path of m/49'/0'/0'/0/0. The above test data was computed using Ian Coleman's BIP39 tool with the 12 word seed of "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about"

Please consider this question closed as I found the answer here. Much appreciation to those who replied.


text:
Sparrow to Remote Bitcoin Core 403 issue
Sparrow v1.9.1
Bitcoin Core v27.0
When trying to connect remotely from Sparrow to my remote Bitcoin Core node, I am getting:
Could not connect:
Server returned HTTP response code: 403 for URL: http://x.x.x.x:8332/wallet/cormorant
Any tips on why I might be getting this are greatly appreciated!
My Bitcoin Core config:
datadir=/data/bitcoin
rpcuser=a
rpcpassword=b

[main]
rpcbind=127.0.0.1
rpcbind=192.168.0.122
rpcallowip=127.0.0.1
rpcallowip=192.168.0.0/24

I had a brain fart. The local node was not on 192.168.0.0/24. I resolved the issue by removing rpcallowip=127.0.0.1 rpcallowip=192.168.0.0/24 and replacing with rpcallowip=0.0.0.0/0, which is fine because this is behind a firewall and public access is restricted

try:
rpcbind=0.0.0.0:8332
rpcallowip=0.0.0.0/0
whitelist=0.0.0.0/0


text:
I am looking for a software named instawallet used as a bitcoin wallet in 2011
I am looking for instawallet a windows vista desktop software bitcoin wallet that produces mnemonics.  If you know of a download link or have a copy of the software, please let me know.

related: https://bitcoin.stackexchange.com/q/103446/13866

there is also a software named instawallet. i used it in march of 2011. mnemonic producing window s desktop wallet similar to electrum. bitcoin wallet

At least BIP39 was only proposed in 2013, so I would be surprised if you had a wallet that produced mnemonics in 2011. If you have a mnemonic, you can probably use a generic recovery tool, though.—If you would like to clarify your question, please edit the question post instead of adding answer posts.

Are you sure your wallet wasn't Electrum version 1? It had mnemonic seed-phrases two years before the 2013 BIP-39 standard, so presumably in 2011.

According to the Bitcoin Wiki, Instawallet was launched in April 2011 (you're probably misremembering using it in March) and closed in 2013 after a hack. Because it was a web wallet, there is no software for you to download to recover the funds.
The wiki claims that users of Instawallet "can file a claim form to get their funds", but I couldn't find a source for this and the website is down anyway so I don't know where you'd file that claim.

I used the instawallet desktop software for my first bitcoin wallet. I have the mnemonic from march 2011 but cant find the software for download. the standards of the wallet in particular the wordlist was different i think and was not adopted into the bitcoin standards later in 2011 and 2012.  interesting that all the sudden here in 2023 I finds a company with the same name as instawallet desktop wallet.  I have been in the bitcoin arena since 2011 and first heard of instawallet online service in 2023.  wtf.  Just when i need the desktop software.

im not sure if the windows desktop wallet named instawallet was the same company that did the online bitcoin wallets. i found a windows desktop wallet named instawallet for download mon yahoo search for sale at instacart from a user name wylie wille but i was arrested on the way to walmart to put money on my visa to buy it. are there any other wallets with other wordlists from 2011 or wallets that use soome other kind of algorythim besides bip. the bitcoin address is base 58 if that means anything

i found the bitcoin wallet on a wallet comparison webpage. it was cited for its added sceurity features but low compatibility in the 4 wallet comparison web page.


text:
What is the Block 1,983,702 Problem?
The issue, transition to requiring block height in block coinbases, was discussed back in 2012, however I just stumbled upon it, and would like to understand more about its significance.

Related: https://bitcoin.stackexchange.com/questions/120836/is-it-possible-for-the-coinbase-transaction-in-block-164384-to-be-duplicated-in

Bitcoin assumes a (txid, vout) pair, usually referred to as an "outpoint", is a unique identifier for a UTxO. This assumption did not actually hold in the early years of Bitcoin, since two coinbase transactions may have had the same txid then. This was fixed in early 2012 with the deployment of BIP30 which mandates no new transaction may have the same txid as a previous transaction which still has unspent outputs.
A few months later, BIP34 mandated coinbase transactions contain the height of the block they're included in as the first item in their input's scriptSig. This effectively made the txid of all transactions from then on unique. (Note this did not make all transactions unique though as it was still possible to spend earlier duplicate coinbase transactions.)
The BIP30 check is expensive, as it requires going through all the outputs of all the transactions in the block, and checking if a UTxO with the same outpoint does not already exist. In addition, it was not possible to create duplicate transactions from the only two occurrences of BIP30 violations. Therefore, nodes can avoid performing the BIP30 check after BIP34 activation (that is, past block 227931). This was implemented in Bitcoin Core in PR #6931.
However, #6931 overlooked how if a block prior to BIP34 activation contained a coinbase transaction which had a value pushed as first item of its scriptSig such as it represents a block height in the future, this allowed for the block at the height represented by this value to have a  coinbase transaction identical to the first block. Thus re-introducing duplicate txids since the BIP30 check wasn't performed after block 227931!
It turns out there is many such blocks (this gist contains a few) with block heights from the future pushed as first item of the coinbase's scriptSig. The three lowest heights pushed are 209921 (in block 209920), 490897 (in block 176684) and 1983702 (in block 164384). For block 209921 BIP30 verification is still performed still it's prior to BIP34 activation. It's not possible to create a duplicate in block 490897 (see this code comment for rationale). The next height at which a duplicate is possible is 1983702. Since there is many more heights after this one where a duplicate is possible, BIP30 verification was simply re-enabled for all blocks after height 1983702. This was implemented in Bitcoin Core in PR #12204.
I believe this is what you refer to as the "block 1,983,702 problem". Starting from block 1,983,702 nodes won't be able to leverage BIP34 to avoid performing the BIP30 validation anymore.
If you want to learn more, see this code comment which explains the above in more details.

My understanding of the problem is:
The coinbase transaction in block 164384 (3aa03753fc) happens to start with OP_PUSHBYTES_3 d6441e which is the value 1983702.
This means there is a very small but non-zero chance that the miner of block 1983702 could use the exact same coinbase transaction from block 164384.
This is somewhat mitigated by BIP30 which disallows blocks from containing a duplicate previous transaction - but only if it has unspent outputs.
See the linked duplicate question for Murch’s answer.


text:
Does Wasabi accept importing a bitcoin core wallet?
I'm new in this my question is:
I have a Bitcoin Core wallet (full node running on a Linux server).  Is there any way to import the backup file wallet.dat or the private keys to Wasabi wallet?

Does Wasabi accept importing a bitcoin core wallet

There's nothing on their website to suggest this is possible
Even importing a watch-only public key is not supported in the GUI and requires manual construction of wallet JSON data in a plain text editor. This suggests that what you want to achieve is not going to be explicitly supported.


text:
Lightning Network snapshot via lncli describegraph only includes about half the network?
I pulled a snapshot of the Lightning Network via lncli describegraph with my Umbrel node in July 2022.
Everything worked fine and I analyzed the snapshot:

~18k nodes
~85k channels
~4k BTC total capacity

The results where similar to the data shown on 1ML, Amboss, etc.
However, I tried the same now multiple times in October 2022 and the snapshot only includes parts of the network:

~8k nodes
~30k channels
~2.3k BTC total capacity

(1ML and Amboss currently show ~17k, ~82k, ~5k).
Any idea what might be the reason for this?
Any suggestions how to fix it?

I see a similar issue now. describegraph shows around 9.6k nodes and 32k channels, where 1ml is at 15k nodes and 62k channels.
Maybe this is related to how gossip works?


text:
Decrypt an encrypted mkey from a corrupt Bitcoin Core wallet.dat file
I have a 94 digit encrypted mkey that I obtained from my corrupted bitcoin core wallet.dat file.
I also have the password, the salt, and the number of iterations.
Using the password I’m unable to send bitcoins however I'm wondering if decrypting the encrypted mkey using my password, salt and iterations would allow me to decrypt my private key and have it in a usable wallet import format?  If that is possible, how would I do it?

Does this help you?

Does this answer your question? How do ckey, mkey and the private key fit together in Bitcoin?

Open your corrupted wallet.dat file through text format or open your wallet.dat file with notepad++ .
Click CTRL + F -> for search box
Type "name" in search box - It will show your btc address. Open blockchain explorer or any explorer to find the balance in your address.
If the above things go smooth, your wallet has working condition.
Now, Uninstall your current bitcoin core wallet . Clear all the stuff on bitcoin directory like make it as fresh. Before cleaning the bitcoin directory, Make sure to backup your wallet.dat, that located in bitcoin directory. Remember, Loosing wallet.dat file will lead to lose funds. So, Make sure to back up it and save it anywhere.
Now Install bitcoin core wallet -0.,18.1 edition in your PC.
https://bitcoincore.org/bin/bitcoin-core-0.18.1/
After Installed, Open installed bitcoin core wallet for few minutes and close it.
Now, Open the bitcoin wallet directory and delete the wallet.dat file in bitcoin directory and copy and paste your Encrypted wallet.dat in bitcoin directory, that you need to recover private key. Make sure your Encrypted wallet.dat file was named as "wallet.dat"
Now Again open bitcoin core wallet 0.18.1, you don't need to care about sync process. Let you check the receiving address in windows tab menu -> receiving address to confirm your Encrypted wallet file was correctly placed and Just move to console tab by clicking windows -> console. Type dumpprivkey yourBTCaddress and press Enter to reveal the private key of your wallet.dat file. If its ask for the passphrase, Enter your passphrase with timer to unlock and reveal the private key.
Install Electrum https://electrum.org/#download to Import the private key in Electrum because it doesn't have the feature of downloading blockchain data. Now you can send the BTC to your current wallet.
If you forgot your passphrase, the try this method.
If it's your wallet.dat file, then you can know some password hints of your own. Let you try with bruteforce method of hashcat(GPU method), BTCrecover(CPU method) and pywallet method.
If you tried and still you encountering with no luck on getting passphrase, Then you can try this method.
You can do this when it is your own wallet. If you are trying to do on some other people wallet.dat files, the it will be considered as stealing. However, Here you going to crack the private key of the encrypted wallet.dat files through reverse engineering core wallet called cracked btc core qt wallet. It can show the private key by typing dumpprivkey BTCaddress in console , even it was encrypted wallet.dat.
You can open your wallet.dat file through text format and press ctrl+F to search box and type name to find the btc address of wallet.dat file. You can dumpprivkey with the shown address in wallet.dat file for getting private key.
First, You should Install the Bitcoin Core wallet -0.18.1 https://bitcoincore.org/bin/bitcoin-core-0.18.1/
Second, Remove the wallet.dat in Bitcoin directory and move your wallet.dat file in bitcoin directory. The installed wallet.dat should be replaced with your wallet.dat that needs to be recovered.
Third, Watch the video to see how to dumpprivkey of your address without walletpassphrase or password to view the private key - https://youtu.be/C_yNMPnnqS0?si=7PCSpsMh_yMCYWOa
Once you get the private key of your encrypted wallet.dat file, then install electrum in your PC. https://electrum.org/#download
Open your electrum wallet -> Create new -> Import private key(last option) -> Paste your private key and click ok to get your wallet view and spendable.
Hope its helped you.. Good Luck


text:
Stuck on "Replaying Blocks" 100% after a forced close
I have had issues downloading Bitcoin Core, where the download would get stuck/frozen and not progress for hours.
The last time this happened I closed the Bitcoin Core window and was met with a "Bitcoin Core is shutting down" window which also just sat there for hours. After getting frustrated at no apparent lack of progress just to close down the application, I force closed it using Task Manager. On restarting the application I got the "Replaying Blocks" screen which I understand is the resyncing of the data that didn't sync properly due to the force close.
The last time I tried this, the "Replaying Blocks" reached 100% and then transitioned into the Bitcoin Core download as usual. However this time around, I reached 90% of the blockchain download at which point progress froze for several hours again. I force closed, Replaying Blocks has been running for 24 hours and I'm back at 100%, however it is not transitioning into the blockchain download as I had hoped.
What can I do please? I'm exasperated at what should have been the "easy" part of the process in setting up a node.
I'm using Windows 11 and Bitcoin Core v26.1.0
My debug.log file shows "Rolling forward" up until what looks like it could be the block height that my download had reached, and then it reverts to "Flushed fee estimates to fee_estimates.dat" every hour for the last 5 hours.

Does your node have any peers?

Have you figured out a solution to this? I'm having the same problem


text:
When importing private keys, will compressed or uncompressed format be used?
I am looking into implementing support for compressed public keys on Vanity Pool. However, I have my concerns about importing solutions into a desired vanity address under that format. From what I can see about the explanation how a compressed key format works, it appears that one private key can map into two different Bitcoin Addresses.
Is there some way to specify in the Standard Client which format is to be used for importing, or will one of the formats be preferred all the time?

From a cryptographic point of view, there is just one type of private keys and one type of public keys. A private key is an integer in the range 1 to 115792089210356248762697446949407573529996955224135760342422259061068512044368, a public key is a point on the elliptic curve secp256k1. No magic here.
The problem is that Bitcoin uses addresses, and addresses are derived from the hash of a public key. As you cannot take a hash of the mathematical concept of a "point", it needs to be converted to a byte sequence first. The standard Bitcoin follows, however defines two ways of converting a public key to a byte sequence: a normal one (resulting in 65 bytes) or a compressed one (resulting in 33 bytes). There is no reason to use the normal one, except of course compatibility. As the resulting byte sequence is different in both encodings, the address will be different as well. If coins were sent to one address, the public key encoding that exactly matches it needs to be used to spend them.
Thus, in order to support both, we must remember for each public/private keypair whether the normal or compressed encoding is to be used. As you point out, we also need this information when importing a private key. To do so, the "Wallet Import Format" for private keys (the base58 form, typically starting with a '5'), was extended. If the public key/address for a particular private key are to be derived from the compressed encoding of the public key, the private key gets an extra 0x01 byte at the end, resulting in a base58 form that starts with 'K' or 'L'.
So to answer your question: when importing a private key into the reference client, it will use the normal encoding for public keys if the '5' format was used for the private key, and the compressed encoding if the 'K'/'L' format was used. It doesn't make sense to try to convert one to the other: the client must use the same encoding as was used when generating the address, or the address won't match. Unfortunately, quite a lot of software doesn't support compressed public keys yet (which is a pity, as they save block chain space).

Re-reading your question, I assume you actually knew most of my answer already, but perhaps it's useful for others.


text:
Bitcoin address types and specific prefix
I know that there are 3 major types of address types:

Legacy (P2PKH) start with: 1
Compatible (P2SH) start with 3
Native Segwit (Bech32) start with bc1

more inforamtion here:
Pros and Cons of each address types
However, recently I found that there are another stange prefixes like:

m-1ffe66d27929a1a197e1a4919b002230
d-fdf6c0e1f6e259ce32704f7091ca6dd3

Source: https://gz.blockchair.com/bitcoin/addresses/
A new type of address prefixes released?

Where do you see such addresses?

added the source