text:
How to verify locking and unlocking scripts?
I've selected an arbitrary transaction id and retrieved its associated transaction details using the blockcypher explorer as follows:
from blockcypher import get_transaction_details
get_transaction_details('0db8ca471c0e0fd3ce6f24197d9a9cec9647fd3df5ab6aa2e174e0ea85949146')

The output is the following python dictionary
{'addresses': ['17uP1g6ppdKVonMQWJ2ojeUZ8r9AhH2tgf',
'19jaGQFE39oH71WdR1ZJjpajjnP8tWNZdv', '1PJwNGYympRP3kJ8hqkY2ayHDVHokrASrv'],
'block_hash':'0000000000000000032ba4f95d39b86b2cc24c27e3c0d3201070945faf890e0d',
'block_height': 419922,
'block_index': 1,
'confidence': 1,
'confirmations': 186323,
'confirmed': datetime.datetime(2016, 7, 9, 4, 3, tzinfo=tzutc()),
'double_spend': False,
 'fees': 311300,
 'hash':'0db8ca471c0e0fd3ce6f24197d9a9cec9647fd3df5ab6aa2e174e0ea85949146',
'inputs': [{'addresses': ['19jaGQFE39oH71WdR1ZJjpajjnP8tWNZdv'],
'age': 418553,
'output_index': 0,
'output_value': 44695270,
'prev_hash':'81b3bcc34490facea42a729ae166f599c7933501273010d0eb0c2a0efe190153',
'script': '483045022100e664861517c0ea91df7e4bde7001b7cda6b034a7f4c4c6e622b681a57bf72c4102207b02fa4046f6ca5c180aa60ee57e67fff4e82c09a7e60515b15a989cd4bd5d3a012103017e89c4294b1ca99533b424c367db4f18747c0cacad393e3fb103640bcdb2ce',
'script_type': 'pay-to-pubkey-hash',
'sequence': 4294967295}],
'outputs': [{'addresses': ['17uP1g6ppdKVonMQWJ2ojeUZ8r9AhH2tgf'],
'script': '76a9144bb8c253f24fa707f6796a0b3c542f78c94b4dcc88ac',
'script_type': 'pay-to-pubkey-hash',
'spent_by': '43a771f414804dcc5ef5b4a577961a1e694ce8f477b391da1a404a600a14c8e3',
'value': 18695900},
{'addresses': ['1PJwNGYympRP3kJ8hqkY2ayHDVHokrASrv'],
'script': '76a914f4b738bc3ee9ebad027381304b2b3e81a618a60488ac',
'script_type': 'pay-to-pubkey-hash',
'spent_by': '0ea2858001f752c4eb7d0bba88568e9dfb25cdcc76adab42bc1ccfbf27c8bda1',
'value': 25688070}],
'preference': 'high',
'received': datetime.datetime(2016, 7, 9, 3, 41, 4, 370000, tzinfo=tzutc()),
'relayed_by': '80.249.197.154:8333',
'size': 226,
'total': 44383970,
'ver': 1,
'vin_sz': 1,
'vout_sz': 2}

Now, from what I understand, the input script should be
<sig> <PubKey>

and the output script should be
DUP HASH160 <PubKHash> EQUALVERIFY CHECKSIG

In the above transaction details I see that there is one input script and two output scripts, which the blockcypher documentation says are raw hexadecimal encodings. However, when I put the encoding under the "scripts" fields into a hex decoder I get nothing that makes sense. My questions are:
1) How can I decode the strings in the "scripts" fields of the transaction details dictionary to see the actual scripts. When I do, will they follow the format I outlined above?
2) How can I verify that the unlocking (input) script, indeed works on the locked (output) scripts? Is that possible using only the transaction details I have generated above?

1) How can I decode the strings in the "scripts" fields of the transaction details dictionary to see the actual scripts. When I do, will they follow the format I outlined above?

Scripts are just raw bytes that follow a certain format that is somewhat explained here. In order to see it in the format you outlined (OP_DUP,...) you have to "decode" these bytes. Basically you start by reading the size of the entire script to know how many bytes should be read (when using an API that returns deserialized tx, you won't see this size). In this transaction the SignatureSCript size is 0x6b=107. Then start "interpreting" the script. To do that, you start by reading 1 byte, then based on that byte decide what to do next. For example in your SignatureScript the first byte is 0x48 (in the link above you see it in Constants table in the word column N/A), this value indicates size of a follow up data to be pushed onto the stack. So now you have a data push of size 0x48=72 bytes:
<3045022100e664861517c0ea91df7e4bde7001b7cda6b034a7f4c4c6e622b681a57bf72c4102207b02fa4046f6ca5c180aa60ee57e67fff4e82c09a7e60515b15a989cd4bd5d3a01>

In this particular transaction, this happens to be a signature. Then read the next 1 byte which is 0x21 and just like above you have another data to push with size =33 that happens to be a public key:
<03017e89c4294b1ca99533b424c367db4f18747c0cacad393e3fb103640bcdb2ce>

Do the same with other scripts. For instance for PubkeyScript the size of the script is 0x19=25 and the first byte in script is 0x76 (you'll find it under Stack) this value is OP_DUP (unlike previous two bytes, there is no follow up data to read, only an "action" to perform that is duplicating top stack item). Next byte is 0xa9=OP_HASH160 (find it under Crypto) and so on.

2) How can I verify that the unlocking (input) script, indeed works on the locked (output) scripts? Is that possible using only the transaction details I have generated above?

You'll always need at least 2 transactions. 1 is the current one you have and want to verify, and the other is the transaction output it is spending. Here it is the transaction with txid 81b3bcc34490facea42a729ae166f599c7933501273010d0eb0c2a0efe190153and outIndex=0. Now you use the PubkeyScript of previous transaction from the corresponding index (locking script) with the SignatureScript of this transaction (unlocking script) together and perform each operation. See this example for each step.


text:
How private key is generated from password in Bitcoin-clients
We all know that private address is a 256bit number. But is the process of converting your password to this 256bit number standard across different clients?
I can imagine that a "strong random 40 character password" after transformation/hashing et c might become the stupid 0...000000123 or something like this :)
If this process is standard, does this mean, that backup of wallet.dat is not required, you should remember only the password?

It's not standard across all clients. You mentioned wallet.dat, which I associate with the Bitcoin Core client; that does not use a password to generate private keys; it generates each set of private keys randomly when a new supply of them is needed for transactions.
Some other kinds of wallets, however, are known as HD, or hierarchical deterministic, wallets. When they are initialized they generate a random master key that they use as a basis for generating all of the wallet's subsequent private keys in a deterministic (non-random) way. And many HD wallets, the very first time they're used, display a sequence of natural language words known as a recovery seed. You write down the recovery seed word list on paper and keep it securely secret. If the wallet is lost or destroyed you can input the words into another one of the same type of wallet to re-generate your private keys and hence your coin balance. If you're interested in the technical details, look at the specifications for BIP32 (HD wallets) and BIP39 (recovery seeds).
An HD wallet which uses a recovery seed may allow the user to specify a passphrase, typically intended to be memorized rather than written down, which is used along with the recovery seed to (re-)generate the private keys. For the ones that I've encountered a passphrase is optional.

Those sequence of words (known as BIP 39 mnemonics) are not used for key generation. They are an encoding of some other random number (the seed) in a human memorable way. Furthermore, a wallet can be an HD wallet without using BIP 39 mnemonics. most follow the BIP 32 standard which does not mention BIP 39 anywhere.

From BIP39 - "The described method also provides plausible deniability, because every passphrase generates a valid seed (and thus a deterministic wallet) but only the correct one will make the desired wallet available."
Can someone explain what this means?

@Childishforlife It means you can have, in effect, multiple wallets in one file or device; the passphrase that is input unlocks only the one with which it's associated without disclosing the existence of any other(s). So if you're required to unlock your wallet under duress, you could provide a passphrase to a "sub-wallet" (my terminology) that is less valuable to you, and (hope that would) satisfy the party responsible for the duress.

Big thanks for the answer! That was a big surprise for me (does not use my password to generate private keys).

Actually, you are not 100% right. Yesterday, came across information that it is rather common to generate private key hashing some text with sha256. Of course, it is not safe, but transaction history shows many thousands of such addresses.

@Oleg Gritsak, I'd be happy to edit my answer to make it 100% right, but I don't see what's wrong. I didn't exclude any private key generation technique by answering with respect to Bitcoin Core's wallet.dat and to  "Some other kinds of wallets..."

source: Stack Exchange

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

sort: votes


text:
Is mining essentially just a way to randomly select the next winning miner?
I know it's not really a completely random selection because some miners have more hashing power so their odds are increased.
But let's assume for a moment that all miners are about equal in hashing power.
The way I see it, whoever solves the current block is (almost) completely unpredictable and thus mining is just a way to randomly select a winning miner.
I understand about decentralizing and the need for a decentralized way of selecting this winner without trusting a higher authority for this random selection.
Let's imagine for a moment that there was this "god-like" machine somewhere, completely trustworthy and incorruptible, impossible to bring down or shutdown and completely fair.
Let's say this machine would select the winning miner that would create and sign the next block and get the reward and fees.
Would there still be a need for mining in that case?

No, there wouldn't. The point of mining is to solve the consensus problem. Taking your logic further, if everybody believes in your god-machine, it might as well just clear the transactions itself.

Agreed; if the "god machine" can solve the blocks itself there would be no need for miners. But if the "god machine" only selects miners to compile the next block, the 51% attack would theoretically be possible. Only it wouldn't be called that..

@Adam That machine is not a singularity, it's a distributed machine made of 10000 full nodes - there are no miners since there's no mining anymore. The consensus problem can conceivably be solved without mining once every 10 minutes or so, even in the presence of many byzantine nodes, provided all good nodes use the exact same algorithm for it (which happens right now with bitcoin if no hard forks) and are somehow incentivized to behave. Electing a leader in short time is impossible with that many nodes and frequent node failures, but once every 10 minutes is easier (with restrictions).

Yes. You are not understanding the purpose of a miner.
Let us imagine this.
If someone wanted to broadcast a fraudulent transaction (Alice pays Bob 100 BTC without Alice's explicit approval), they would need to find the block before anyone else, place the fraudulent transaction in the block (very hypothetical), and broadcast the block to the rest of the network. Some people may accept this block, and some people may not depending on propagation time. At this point we will assume that due to conflict in block acceptance, there are two competing chains of blocks being mined simultaneously. If this malicious someone wanted to keep his/her blockchain authentic to all Bitcoin clients, he/she would need to find the following blocks before everyone else, again, each time. Bitcoin clients will, by default, trust the longest chain available to them. The chances of a malicious user finding all the blocks before everyone else until there are 6 confirmations on the malicious transactions is very unlikely.
3blue1brown has constructed a great, informative explanation to Bitcoin mining.

"Finding a block before anyone else" means "solving the hash puzzle before anyone else", which is just a way to randomly select a miner. If there is a "god-like" machine, then the chances of a malicious user solving the hash puzzle before anyone else 6 times consecutively are theoretically the same as the "god-like" machine selecting the same malicious user 6 times consecutively. Remember the assumptions that 1) every miner has equal hashing power, and 2) the "god-like" machine is completely fair. So I do not see the need for mining if such a machine is available.

If you are using the god-like machine to select miners to compile blocks, everyone is going to trust that block even if someone who randomly got selected put some fraudulent data in it. If, however, someone solves the block before everyone else, there is conflict in block acceptance. There will be two instances of the chain and the longest one will be accepted by the network. Watch the video I put in the answer.

No. Not everyone is going to trust that block. After the block is broadcasted, everyone else checks that block. That's what happens now, with any block, even in the absence of competing blocks. There is no trust just because you've found a good hash. EVERYONE checks your block in bitcoin. Just because you got lucky doesn't mean you are trustworthy. Just because some machine chose you doesn't mean you can be trusted. They all check the new block. The occasional splitting of the chain has nothing to do with verifying every transaction in every published block.

The malicious miner will, of course, have to match the block hash before broadcasting the transaction. Any exploits I mentioned are entirely speculative and have never been successful. But in the case that there is a malicious block, the presence of competitive miners can prevent the block from being accepted. Temporary chains won't be created globally, but locally. If, as a bitcoin client, you are listening for blocks and receive two different variations of the same block, you will accept the most extended chain available to you. Again, this is all theoretical.

Mining adds a certain level of commitment to the process.
If mining were free, a corrupt user could create thousands or millions of corrupt miners (for free) that would publish invalid blocks that made itself rich, and try to get even one of these blocks accepted.
The same is true of your "god-like" random selector:
Publish blocks, and hope you get randomly selected!
But mining is intensive: it costs money to setup a miner, and it costs electricity and networking to run a miner. You cannot fake thousands or millions of miners; each of them costs real money.
So the only way you can publish invalid blocks and hope to get rich is via a substantial investment.   The hash power of the network is so big now, that it is virtually impossible to setup a "evil" mining pool.  (If you succeeded, that would be a >51% attack)
The costs associated with mining ensure that there is a barrier to entry, and that "evil" miners cannot easily hope to overcome "honest" miners.  It ensures the integrity of the entire system.

Good answer. For the "god-like" machine to be able to replace mining, another assumption (besides the ones listed in the question) is necessary - that each mining node be owned by a separate entity and these entities not collaborate with each other (or equivalently, that each separate entity own an equal number of mining nodes, and not collaborate). Without this condition (which is very unrealistic... well, even a "god-like" machine is unrealistic), the "god-like" machine does not eliminate the need for mining.

@Ajoy LOL This is actually one of the worst answers possible. I don't think Mr. abelenky even understood the question. If there is no mining, nobody "publishes blocks that try to get accepted" since they would certainly be rejected - it's futile if you were not elected. It would be just spam. First you are elected, then you publish a block, not the other way around. The same way it happens now in bitcoin: first you find a small enough hash, then you publish the block. Otherwise you're just creating spam, easily rejected.

That's true. Thanks, @coinjoe. But the need to ensure that a single entity cannot set up any number of nodes and increase its chances of being selected, still remains. I guess the OP's assumption that "all miners are about equal in hashing power" should actually instead be that "any two or more publishing nodes (not calling them "miners") do not collaborate with each other".

Yes, that is a requirement. And there are various solutions to it. I didn't mention it intentionally because I didn't want to complicate the constraints set. Dash is very popular and they have masternodes, with reputations and with a lot of coins being deposited by each. And being rewarded (incentivized) to run those nodes. And with a voting system in place. And the coin is very popular. In these conditions, why they are still mining is beyond me... Probably because people are so used to mining as "something to do to get those coins" that they can't see a coin without it.

The idea that "the universal master rolls a dice and if it hits our number we win 12.5 coins" seems unthinkable to most people, because it seems completely out of their control. It's much more comforting to think that you're actually doing something to win that prize, spending some effort, working, putting some money down, and when you win it's because of that effort, not because of some random dice rolling. And thus, we mine...

See @Monstrum's comment under his answer. If a single "god-like" machine selects a node and then that node publishes a block, it could publish a fraudulent transaction, too. We forgot that the nodes are not necessarily honest. There need to be competing blocks and competing branches. Only then will fraudulent blocks be shut out of the main chain.

No. There is no such need. If there was, Cardano would not work. Have you seen their market cap? In fact no PoS based coins would work if there was such a need. And there are too many of them to list here. What you call "fraudulent transaction" is probably a double spending transaction, otherwise you would have to define it more clearly. Double spending can and has been solved in non-mining blockchains. Branching of the chain and acceptance of the longest one THAT IS CORRECTLY FORMED does not need mining, it just needs an honest majority, which is a requirement for any blockchain.

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


text:
Possible to transfer BTC via QR code?
Is it possible to embed an amount of BTC in a QR code to transfer to whoever scans it?
E.g. I create a QR code for .5 BTC from my wallet, send the QR code to someone (without knowing their BTC wallet address), they scan it using their wallet app and receive it?

Just add amount parameter to QR data:
bitcoin:1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv?amount=0.005

use google chart to generate QR
https://chart.googleapis.com/chart?chs=250x250&cht=qr&chl=bitcoin:1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv?&amount=0.005

if you are asking about auto sending bitcoin through QR so it's not possible.

That is to request an amount, not send an amount

Answer I received on Reddit:
Yes. Create a paper wallet at bitaddress.org; send any amount of bitcoins to the qr code on the left that has the word "SHARE" next to it. Then, you can send the qr code on the right, the one that says "Secret," to the person who you want to receive the bitcoins. If they scan that qr code, the one that says "secret," they can receive the bitcoins you sent to the "Share" qr code into their bitcoin wallet.

This answer isn't for this question. Giving anyone your private key of this address giving them the access to bitcoins in this address.

Yes, thats exactly what I want. You create a new wallet, transfer the BTC to it, embed private keys, then anyone can take that BTC.


text:
Altcoin fork tutorial
Is there any tutorial for altcoin fork creation?
I've found only tutorials for the very old versions, and any for the current ones.

You usually have to have knowledge of the programming language used to make various changes. The merkle-root, genesis block hash, and other coin info would need to be changed for the coin to operate as expected.

Will it work if i'm trying to generate a new genesis block? I've set a new timestamp, and all other values (including asserts) to 0x0.
I've set to 0x0 the following variables: genesisOutputScript, BIP34Hash, defaultAssumeValid Removed the seeds and asserts, and I've set a new timestamp (unix and the text one). After that I've run make and got the result below.

Which altcoin are you trying to fork?

The Bitcoin one.

Am I doing the right steps?

Hi, have you read this post? seems nice. https://bitcointalk.org/index.php?topic=3345808.0

I created an Altcoin based on this article. https://medium.com/@jordan.baczuk/how-to-fork-bitcoin-c39139506443
The article mentions 13 steps but I changed only the message prefix.
$ git branch
* v0.17.1

$ git diff
+++ b/src/chainparams.cpp
+        pchMessageStart[0] = 0xf1;
+        pchMessageStart[1] = 0xb2;
+        pchMessageStart[2] = 0xb3;
+        pchMessageStart[3] = 0xd4;

I started 3 processes; two forked bitcoind and one original bitcoind. forkA tries to connect to both original and forkB bitcoind.
# forkA
/home/zono/bitcoinA/src/bitcoind -server -listen -port=17591 -rpcuser=bitcoinrpc -rpcpassword=bitcoinrpcpass -rpcport=16591 -datadir=$HOME/regtest/A/ -connect=localhost:17592 -connect=localhost:17593 -regtest -pid=$HOME/regtest/A/.pid -daemon -debug -listenonion=0

# original
/home/zono/bitcoinB/src/bitcoind -server -listen -port=17592 -rpcuser=bitcoinrpc -rpcpassword=bitcoinrpcpass -rpcport=16592 -datadir=$HOME/regtest/B/ -regtest -pid=$HOME/regtest/B/.pid -daemon -debug -listenonion=0

# forkB
/home/zono/bitcoinC/src/bitcoind -server -listen -port=17593 -rpcuser=bitcoinrpc -rpcpassword=bitcoinrpcpass -rpcport=16593 -datadir=$HOME/regtest/C/ -regtest -pid=$HOME/regtest/C/.pid -daemon -debug -listenonion=0

As you can see, forkA is connecting to forkB (port=17593)
$ ./bitcoinA/src/bitcoin-cli -rpcuser=bitcoinrpc -rpcpassword=bitcoinrpcpass -rpcport=16591 -regtest getpeerinfo
[
  {
    "id": 2,
    "addr": "localhost:17593",
    "addrbind": "127.0.0.1:37256",
    "services": "000000000000040d",
  ...
  }
]

You can see that original bitcoind refused to connect from forkA. (INVALID MESSAGESTART)
# forkA
2019-02-14T14:52:33Z trying connection localhost:17592 lastseen=0.0hrs
2019-02-14T14:52:33Z Added connection peer=2685
2019-02-14T14:52:33Z sending version (102 bytes) peer=2685
2019-02-14T14:52:33Z send version message: version 70015, blocks=0, us=[::]:0, peer=2685
2019-02-14T14:52:33Z socket closed
2019-02-14T14:52:33Z disconnecting peer=2685
2019-02-14T14:52:33Z Cleared nodestate for peer=2685

# original
2019-02-14T14:52:33Z Added connection peer=2684
2019-02-14T14:52:33Z connection from 127.0.0.1:54808 accepted
2019-02-14T14:52:33Z PROCESSMESSAGE: INVALID MESSAGESTART version peer=2684
2019-02-14T14:52:33Z disconnecting peer=2684
2019-02-14T14:52:33Z Cleared nodestate for peer=2684

A generated block on forkA is propagated to only forkB.
# generate 1 block on forkA
./bitcoinA/src/bitcoin-cli -rpcuser=bitcoinrpc -rpcpassword=bitcoinrpcpass -rpcport=16591 -regtest generate 1

# forkA. current block = 1
$ ./bitcoinA/src/bitcoin-cli -rpcuser=bitcoinrpc -rpcpassword=bitcoinrpcpass -rpcport=16591 -regtest getblockchaininfo
{
  "chain": "regtest",
  "blocks": 1,

# original. current block = 0
$ ./bitcoinA/src/bitcoin-cli -rpcuser=bitcoinrpc -rpcpassword=bitcoinrpcpass -rpcport=16592 -regtest getblockchaininfo
{
  "chain": "regtest",
  "blocks": 0,

# forkB. current block = 1
$ ./bitcoinA/src/bitcoin-cli -rpcuser=bitcoinrpc -rpcpassword=bitcoinrpcpass -rpcport=16593 -regtest getblockchaininfo
{
  "chain": "regtest",
  "blocks": 1,

Here is a tutorial I have used to create my own altcoin: https://www.hackster.io/pjdecarlo/how-to-make-a-cryptocurrency-using-litecoin-v0-15-source-fb5e82

Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.

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


text:
Mining 0 fee transactions
If a miner is payed per block found, why not scrape the bottom of the barrel and full up blocks with 0 fee transactions? You would still be getting coins for blocks found just not the fees. The bonus would be no competition on finding blocks. Win/win for everyone...

Because fees + 12.5 BTC > 0 + 12.5 BTC. It is a lose for the miner because they could have picked transactions that would have paid them more.

I think you are assuming that miners who are picking low fees transactions are not competing with anyone which is incorrect. Mining is not progressive(i.e your chances do not increase the more you try), it is independent chance of success for every try. You still have the same chance to find a new block, regardless of the transactions you pick. So, there is no bonus advantage.
Therefore, it is always useful to pick high fee transactions than the low fee ones.


text:
Can Buy Bitcoin From Different country exchange and transfer to wallet
Completely new to this I want to know that,
If I purchase bitcoin from exchange website https://bitcoin.org/en/exchanges any country Then I can transfer it to Zebpay wallet.
Because it looks good deal price is not same everywhere just transaction fee if you purchase in volume then this seems nothing.
I'm new here many peoples already tried this or may be I'm getting it wrong.

What you are referring to is called Arbitrage. You can find most of your questions answered here... https://bitcoin.stackexchange.com/questions/49819/cryptocurrency-arbitrage-what-do-i-need-to-know

First, answering your question. Yes, you can send BTC from any exchanges/wallet to any other wallet including ZebPay's wallet.
Second, now here is where you are getting it wrong. Indian exchanges have premium values for Bitcoin because in our country India, it is very difficult to send money internationally without any strong reasons.
And even if you are able to send some money, you won't be able to do this for a large sum which can make a considerable profit for you in the long run.
Sending money internationally by wrong reasons can even get you a hefty fee to be paid and even jail.
But Indian exchanges like Zebpay, Coinsecure, Unocoin, etc make it easy and legally binding to buy BTC in our country.
So, unless someone find an easy way to send funds internationally and buy there and sell and continue this cycle, the BTC price in India atleast will be premium for that time.


text:
validation of a block with false transactions
When a miner can find a number to create a hash with enough zeros, the other miners can verify his work by testing that number and seeing if everything is correct. But how do they verify that the transactions in the block are not false? How do they see that the amounts are properly authorized? An attacker could create a transaction in which Alice sends him 5 BTC, without Alice knowing about it. Is it possible?

The block validation process involves checking that all the individual transactions in it are all valid according to the consensus rules which are set in the Bitcoin Core C++ implementation.
Block validation is done by Bitcoin full nodes and one would assume by all miners. If a block is not valid then it will be rejected and any miner who attempted to insert an invalid transaction would have wasted all the time and effort to generate the block hash.

"checking that all the individual transactions in it are all valid"
How is performed this action?

In the case of a Bitcoin Core full node, for block verification see https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp and for transactions see https://github.com/bitcoin/bitcoin/blob/master/src/consensus/tx_verify.cpp. Other wallet software or miners may or may not employ equivalent logic.

But how do they verify that the transactions in the block are not false? How do they see that the amounts are properly authorized? An attacker could create a transaction in which Alice sends him 5 BTC, without Alice knowing about it. Is it possible?

Most coins spent to addresses require a signature to spend them. That signature can only be generated if you know the private key(s) corresponding to the address which they were sent to. Without the private key, the transaction spending those coins is invalid, and anyone can see that it is invalid. Thus if a transaction with an invalid signature was included in a block, that entire block would be invalid too, and rejected by the network.


text:
Cryptocompare Api - understanding API return values
I have come across the API from cryptocompare.com which fetches data from various exchanges.
I do not understand the some values returned from the API call
https://min-api.cryptocompare.com/data/pricemultifull?fsyms=BTC&tsyms=INR&e=Unocoin
Questions

Difference between LASTVOLUME and LASTVOLUMETO
Difference between VOLUME24HOUR and VOLUME24HOURTO
Difference between TOTALVOLUME24H and TOTALVOLUME24HTO
{
    "RAW": {
"BTC": {
    "INR": {
        "TYPE": "2",
        "MARKET": "Unocoin",
        "FROMSYMBOL": "BTC",
        "TOSYMBOL": "INR",
        "FLAGS": "2",
        "PRICE": 847591,
        "LASTUPDATE": 1512451304,
        "LASTVOLUME": 0.00139926,
        "LASTVOLUMETO": 1186.00018266,
        "LASTTRADEID": "478501",
        "VOLUME24HOUR": 75.19298754,
        "VOLUME24HOURTO": 61956574.46784429,
        "OPEN24HOUR": 837298,
        "HIGH24HOUR": 860506,
        "LOW24HOUR": 491500,
        "CHANGE24HOUR": 10293,
        "CHANGEPCT24HOUR": 1.2293114279503832,
        "CHANGEDAY": 0,
        "CHANGEPCTDAY": 0,
        "SUPPLY": 16720800,
        "MKTCAP": 14172399592800,
        "TOTALVOLUME24H": 319738.400426581,
        "TOTALVOLUME24HTO": 271005614230.93204
    }
}
    },
    "DISPLAY": {
"BTC": {
    "INR": {
        "FROMSYMBOL": "Ƀ",
        "TOSYMBOL": "₹",
        "MARKET": "Unocoin",
        "PRICE": "₹ 847,591.0",
        "LASTUPDATE": "Just now",
        "LASTVOLUME": "Ƀ 0.001399",
        "LASTVOLUMETO": "₹ 1,186.00",
        "LASTTRADEID": "478501",
        "VOLUME24HOUR": "Ƀ 75.19",
        "VOLUME24HOURTO": "₹ 61,956,574.5",
        "OPEN24HOUR": "₹ 837,298.0",
        "HIGH24HOUR": "₹ 860,506.0",
        "LOW24HOUR": "₹ 491,500.0",
        "CHANGE24HOUR": "₹ 10,293",
        "CHANGEPCT24HOUR": "1.23",
        "CHANGEDAY": "₹ 0",
        "CHANGEPCTDAY": "0",
        "SUPPLY": "Ƀ 16,720,800.0",
        "MKTCAP": "₹ 14,172.40 B",
        "TOTALVOLUME24H": "Ƀ 319.74 K",
        "TOTALVOLUME24HTO": "₹ 271.01 B"
    }
}
    }
}

VOLUME...TO shows the volume made in INR, and without TO shows volume made in bitcoins.
As one bitcoin is around 750 000 INR, a volume made of 75 bitcoins in last 24 hours is equivalent to volume made  of 61956574 in INR currency.

what is CHANGEPCT24HOUR and CHANGEPCTDAY?

also wondering what CHANGEPCT24HOUR. seems inconsistent across currencies for example for 1337 crypto I have CHANGEPCT24HOUR = 15.00 EUR and CHANGEPCT24HOUR = -50.00 GBP? those currencies arent that different in value?

im thinking this isn't the amount the value of the coin fluctuated in 24 hours? otherwise the api is returning incorrect data


text:
Error message still returned after transaction was indeed broadcast
I use bitcoinj to create the following method to broadcast a raw transacion in testnet, and I did see on bitcoin explorer that it has been broadcast. But even the transaction has been already broadcast, it always return false message, please help me to solve this issue, I don't know if there is a problem when sync with the peer or if my broadcast method is wrong.
//sync with the peer
static WalletAppKit kit = new WalletAppKit(params, new File("."), "sendrequest-example");
kit.startAsync();
kit.awaitRunning();

//transaction broadcast method
public static boolean broadcastTransaction (Transaction tx) {
        System.out.println("Broadcast transaction: ");
        System.out.println(tx);
        try {
            TransactionBroadcast broadcast = kit.peerGroup().broadcastTransaction(tx);
            broadcast.future().get(20,TimeUnit.SECONDS);
            System.out.println(tx.getHash() + "broadcasted successfully!");
            return true;
        } catch (Exception e) {
            System.out.println("e.getMessage() = " + e.getMessage());
        }
        return false;
    }

The false message is always as following, although the transaction has been indeed broadcast.
e.getMessage() = Waited 20 seconds (plus 1985971 nanoseconds delay) for com.google.common.util.concurrent.SettableFuture@20d525[status=PENDING]

e.getMessage() = Waited 20 seconds (plus 4214583 nanoseconds delay) for com.google.common.util.concurrent.SettableFuture@38afe297[status=PENDING]

This looks like an implementation choice of the PeerGroup.broadcastTransaction method of bitcoinj.
If you send a transaction out to one or more peers, there is no guarantee that any of those peers will forward them on to others, and no way to verify it without having another node somewhere else on the bitcoin network listening for it (or listening to it from the same node but from different peers). You can only attempt to have some level of confidence that the transaction has been broadcast by sending it to multiple peers.
The broadcastTransaction method appears to have some confidence calculation in it, and probably does not complete the promise unless the confidence is met. I've not explored the details of it, but I'd suspect you're perhaps not connected to enough peers for it to have the confidence. Are you only connected to one peer perhaps? Maybe you need a longer timeout? Check the details of how the broadcast is implemented and you might figure it out.

If you're only connected to one peer, there's not much it can do. That peer won't send the transaction back to you. So until it's mined (which obviously will typically take much more than 20 seconds) it can't get any confidence at all.

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


text:
Fail to sign the Segwit Transaction's input in bitcoinj
I want to spend from a segwit address and it has a P2WPH script, I created this transaction just like creating a normal P2PKH transaction, but just changed the address of the input to the segwit address, I don't know if this is correct, and signing this transaction in the following method, but it says script was NOT verified successfully...
Transaction signedtx = signInput(rawtx.getHashAsString(),privkey,rawtx);

    public static Transaction signInput(String hash, String prvKey,Transaction spendTx) {
        ECKey ecKey = ECKey.fromPrivate(Utils.HEX.decode(prvKey));
        ECKey.ECDSASignature signature = ecKey.sign(Sha256Hash.wrap(hash));
        TransactionSignature transactionSignature = new TransactionSignature(signature,Transaction.SigHash.ALL,true);
        TransactionWitness witness = TransactionWitness.redeemP2WPKH(transactionSignature,ecKey);
        TransactionInput input = spendTx.getInput(0);
        input.setWitness(witness);
        return spendTx;
    }

I am not very familiar with bitcoinj, and currently there is very little technical guidance related to segwit, I hope someone can help me！

In general is should be like:
// input index to sign
int index = 0;
// amount to sign (must equal to actual input value)
Coin value = Coin.valueOf(123456);

TransactionSignature signature = tx.calculateWitnessSignature(
   index,
   prvKey,
   ScriptBuilder()
      .data(ScriptBuilder.createP2PKHOutputScript(prvKey).program)
      .build(),
   coin,
   Transaction.SigHash.ALL,
   false
);

tx.getInput(index).setScriptSig(ScriptBuilder.createEmpty());
tx.getInput(index).setWitness(
  TransactionWitness.redeemP2WPKH(signature, prvKey)
);

Most importantly, double-check that your outpoint txids are reversed (to little-endian) the sighash before signing. Maybe BitcoinJ does this for you, but since I never used it I'm not sure if it does.


text:
Lightning Node High Availability/High Throughput
Are there any resources/best practises on running a highly available/high throughput lightning node? If my lightning service where to take off, should I be running multiple lightning nodes or a single lightning node? Would it be possible to scale horizontally? Maybe each channel could be managed on a different machine?

So there are a couple things to consider here:

The database, it needs to be remotely available if you are going to failover your Lightning node. We talk about adding support to eclair for a remote database (postgres) in our blog post here
Safely accessing the database. If you have two nodes writing to the database at the same time, it is possible that they write conflicting versions which could result in a penalty transaction on the blockchain. This means you need some sort of locking mechanism to access the database. We have implemented this on eclair as well, you can find the blog post about it here and the actual PR on eclair here.
The final thing that needs to be considered is how to make the key material available in a highly available, yet secure way. This is still something we are exploring at Suredbits. The "dumb" thing to do is just replicate the keys across every node you have.

Now you should be able to spin up an arbitrary amount of nodes. There should be 1 master node that is actively updating the database, and n shadow nodes that are waiting for the master node to fail. For implementing this, you can use something like Amazon's ELB and health check's to determine when the current master node fails, and you should promote one of the "shadow" nodes.
You can see a demo of this here on youtube

Are there any resources/best practises on running a highly available/high throughput lightning node?

In Lightning Network, any disturbances (electricity outage, server crash) while running the application can result in permanent loss of funds. It is thus recommended that you run your server in a managed facility like cloud or colo if you are not able to provide high reliability of the servers yourself. This should especially be true in your case since you will be running multiple nodes that will route payments. Any server malfunction can have direct monetary losses.
For attaining high throughput (higher lightning routing) you can use autopilot feature to determine which nodes to connect to and what amount of liquidity you must have in each channel. The things that you might want to consider include increasing the centrality of your node, increase probability to have well funded routes, and improve your presence within your own geography.

If my lightning service where to take off, should I be running multiple lightning nodes or a single lightning node?

Depends on the service that you want to provide. If you want to provide a custodial solution, then running one lightning node may be considered. However, increasing the number of nodes will increase the probability of your routing capabilities, prevent bottlenecks and hence provide a better customer service.
If you want the users to be in charge of their funds, you have no option but to use multiple lightning nodes, one for each user.

Maybe each channel could be managed on a different machine?

No need to run different nodes on a different machine. You can create separate directories within the same machine and run the lightning node.

re: "It is thus recommended that you run your server in a managed facility like cloud or colo if you are not able to provide high reliability of the servers yourself." - I'm not sure I like the idea of hosting a high-capacity hot wallet on someone else's servers, as there are other security methods worth mentioning, eg watchtowers. Also, a lightning node does not require perfect uptime, it just needs to be online enough to ensure no channel partners have attempted to claim an outdated channel state (how much uptime this is will vary according to channel settings).

@chytrik I agree with your reasoning, but one of the issue that needs to be tackled is preventing force closes of channels. If OP is running a custodial solution, then their node will have high routing. If the server crashes at a time when multiple HTLCs are being routed, then it can lead to the peers force closing the channels if those peers are not able to fulfill those HTLCs. Watchtowers can play a role in ensuring that the peer does not cheat me, but honest force closing of channels is a legitimate concern that can cost high fees if this situation happens often.

that is a fair point; there is cost to manage channels. Thanks for elaborating


text:
How do I ask for witness data from a Bitcoin full node?
So, I'm trying to build a Bitcoin block explorer using my own Python library. I'm doing it just as an exercise to better understand how Bitcoin works under the hood.
Right now, when I send a block message to request information about a given block, I don't receive any witness data for the transactions.
I've read that to receive witness data, I should enable that service when I send my version message. I think I'm doing it but am still not receiving any witness data.
My services field in my version message looks like this:
Services bitfield: [1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
Receiver services bitfield: [1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
Sender services bitfield: [1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
However, the version message I receive has the following services fields:
Services bitfield: [1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
Receiver services: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
Sender services: [0, 0, 1, 0, 1, 1, 1, 0, 0, 1, 0, 1, 1, 1, 1, 1, 1, 0, 1, 0, 0, 1, 1, 0, 1, 1, 1, 0, 0, 0, 0, 1, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
What can I do to actually receive witness data?

When you send getdata, do you ask for MSG_BLOCK (0x00000002), or MSG_WITNESS_BLOCK (0x40000002)?

Was using MSG_BLOCK... Guess that's the issue? Thanks!


text:
CoinMe Issue Clarification of Transaction?
I made a withdrawal from a CoinMe wallet online to the BTC address 379h4LPA9fGBw6p2zEKnNhCSfayzETdtka for 500.00 however the remainder from that wallet was transferred to this wallet address 1ZX2pmcSNfnpchnBFktZmSy9inDkjnpAW 1824.51. Coinme is now saying , after locking my account, immediately after 500.00 transaction that I have no balance as it was transferred out. How could that happen ? How could my 500.00 withdrawal to one address then split make two payments. Their screens do not offer that as an option. the 500.00 landed safe and sound. why did it take the rest and send to 1ZX2pmcSNfnpchnBFktZmSy9inDkjnpAW . I have attempted to research on my own but cannot understand. I don't understand what to do.  Coinme is insisting that I transferred the entire amount to two serperate wallets.  My hunch is that remainder of my funds were simply moved to another coinme account and my "delightful customer service rep understands even less than I do.  5 Days before XMAS with a 10 year old. Originally they put a "check" in the mail. LOL I need to know what happeened and why. Is there anyone that can explain this to me..  Please

Does this answer your question? How does change work in a bitcoin transaction?

"My hunch is that remainder of my funds were simply moved to another coinme account and my "delightful customer service rep understands even less than I do." -- Yes, it sounds like this is normal and expected behaviour, involving a change address (see the link above).


text:
how to move my Bitcoin core wallet to electrum while syncing
How do I move my btc qt wallet to electrum while syncing?
Not address by address.
Removed some addresses already but I'm still missing some coins.
Don't understand the discrepancy.
Any help would be appreciated.

Does this answer your question? Send coins with Electrum from encrypted wallet created with Bitcoin Core

@chytrik no it doesn't.

I don't know of a way to import the wallet file; afaik the core wallet file is not compatible with electrum. You'll need to figure out which addresses still have coins on them, and then export priv keys from core, and import to electrum.

@chytrik I have removed all receiving addresses already but it does not equal the original balance. Don't really understand the discrepancy. That is why I wanted to move the whole wallet. Do you have any suggestions or ideas for the discrepancy in the balance?

If you ever sent coins out of the wallet, or moved them internally, then you likely have coins left in 'change addresses' as well. You could try the command listunspent or listtransactions, but if core is still syncing it may not be aware of coins sent to addresses at a point in time later than it is currently synced to.

@chytrik my btc qt looks like it will never fully sync. Keeps crashing after going through about 20% of the blockchain. Is there any other way?


text:
btc qt walletdump
I'd like to dump my entire btc qt wallet, while syncing, into an electrum wallet.
I don't want to do it receiving address by receiving address.
I already emptied out all my receiving addresses but there are still some left on the wallet.
I know that sounds wrong but it is true.
Maybe someone could explain otherwise.
I've tried dumping wallet in the debug console but am having problems with that too.
I have posted on this forum about this problem for awhile to no avail.
Is there another platform that could assist me or help?

Have you tried the dumpwallet command in Bitcoin QT's command line? This command should dump both External and Internal private keys.

I try but red letters pop up " .....(code-1)." Do you know anything about that? Is there a website that explains the debug console commands and responses?

How do you know there are still funds left on the bitcoin-core wallet? Did you know the exact amount sent to that wallet (and now the amount recovered to electrum is obviously less than that), or is it just that bitcoin-core is still showing some funds are left (while syncing)?

I know the exact amount in my btc qt. Emptied receiving addresses to electrum wallet. Does not equal original btc qt wallet amount. Do you have any suggestions? Dumpwallet is the only thing I can come up with. And I'm having problems with that. Do you know of a more advanced platform online I can bring this problem to or a physical location that trouble shoots this stuff?

@requim This is about the most advanced platform to ask your questions to. To use the command "dumpwallet" you need to specify the location+name you want to dump the file to. "dumpwallet Path/To/OutputFile.txt" Keep in mind you first need to unlock your wallet. Please see this answer

Does this answer your question? how do you transfer your Bitcoin core wallet while syncing?

Not really. I've seen that link/answer before. I know how to unlock my wallet using the debug console. I am having problems dumping my wallet. I don't know if it's because the path is wrong or the wallet is synching or maybe another error. When I try to dumpwallet I get red text in the debug console, (code-1). There is a lot more text but it won't all fit in this section. Do you know of a link or site that can explain the responses of the debug console?

@requim have you tried using the listunspent command? If your node isn’t fully synced it may not be useful, but there is a chance if may help you figure out which UTXOs haven’t been transferred yet.

What are the parameters of using the listunspent command in the debug console. Chytrik. Nothing is happening. Not even red letter errors. Does anyone know where I can just bring my laptop to solve this problem? This has been going on for months now. The Bitcoin community really needs to open up to this. Troubleshooting like this is a real debacle.

I've gone to some btc Meetups for assistance but these people are mostly just looking for yield. I think there is a real opportunity for someone to start a business like Geek Squad or something like that.

Ok I put listunspent in debug console and brackets, [ ], show up with nothing in between.


text:
wallet.dat on usb to electrum
I put my btc qt wallet.dat file on a USB and would like to open it on a software wallet. Preferably electrum. Is that possible?
If so how?
Too many problems with btc qt and takes forever to sync.

Electrum does not support bitcoin core wallet files. What you can do is dump all the private keys using bitcoin core and then import them into electrum. So first make sure that the wallet.dat file is in bitcoin core's data directory and then launch bitcoin qt, go to window menu > console and unlock your wallet:
walletpassphrase your-wallet-passphrase 300

Then dump the wallet to a file on your filesystem:
dumpwallet C:\path\to\new\file

Open that file using a plain text editor like notepad and you'll see your private keys in the row to the left. for example:
# Wallet dump created by Bitcoin v0.18.0
# * Created on 2020-01-16T09:48:08Z
# * Best block at time of backup was 115144 (0000000000000c76185d6ab9b04672082d8d9a876fbe9f908c63bd9ec5d02433),
#   mined on 2011-03-26T14:26:44Z

# extended private masterkey: xprv9s21ZrQH143K4UvtqjsWXxXBSDkxVbwePkX2ofaCRhrB2xBcMaFxnWBvZBKnTmgdc32cKc6PbmGCd1LB6X8K9JUGqqVGvxoWbEh231FB6x6

KyDFvw3oUNsJ1rFgAX4VQ5ffP5kpkeStU9kjyA3vAm5EpjF21TMh 2019-01-16T15:33:42Z change=1 # addr=3QKaCD7kQrwstfMvEYbv3iDuXPFLUUoj4p hdkeypath=m/0'/0'/874'
L3tWcLep3Vmhoq3eQFQioycDdyFvpdLBfmvBYHdSBH3bBepE5KR9 2019-01-16T15:33:42Z change=1 # addr=32ubG76VZ23TUWYf8ZGaU7MwFs1bJVbd3r hdkeypath=m/0'/0'/395'
KwQH7xszobX5ByvsTdFrhVrCshyZG3aLa1cagcv5rJghGHuQStuK 2019-01-16T15:33:42Z change=1 # addr=3GfzM8BRgQj6FtGvZZUfLKaE9KTfL39A1B hdkeypath=m/0'/0'/499'
L5Q4SnnKvvSoCDaz2GvQkWWLgjJx5aMXogRvjJHfQG9faXLmaNLM 2019-01-16T15:33:42Z change=1 # addr=3GWHaeXKBoAxa23MHRknaygDosJiWTiMP1 hdkeypath=m/0'/1'/159'
L3Bnvj1xTJFMzXsym7jBDMLbz5qhxotq8La4UxDdhKZnmZ4s1nw1 2019-01-16T15:33:42Z change=1 # addr=39WoYcrRnY9vRBuxSCmU4vtdEvnWRcn5QJ hdkeypath=m/0'/1'/918'

Your private keys are the strings that begin with K, L or 5 and are in the left most column.
Now to import them in electrum you download and install electrum and run it. The first time you run it it'll let you create a new wallet file. If this is not the first time you are running it use file > new/restore to create a new wallet file or simply enter a unique file name in the first window that pops up when you run electrum. During the wallet creation process choose "import bitcoin addresses or private keys" in the first step and in the next step enter the private keys one per line with either "p2wpkh:" for bc1 addresses or "p2wpkh-p2sh:" for addresses that begin with 3 prepended to each private key. If your address begins with 1 you don't have to enter a prefix. For example:
KyDFvw3oUNsJ1rFgAX4VQ5ffP5kpkeStU9kjyA3vAm5EpjF21TMh

becomes
p2wpkh-p2sh:KyDFvw3oUNsJ1rFgAX4VQ5ffP5kpkeStU9kjyA3vAm5EpjF21TMh

Follow on-screen instructions for the rest. Note that if you know exactly which addresses have coins sent to them you can import just those addresses' private keys.

Old wallet.dat might contain uncompressed privkeys.

@ChrisChen thanks. made that change.


text:
Possibly sent Bitcoin to wrong address
Almost a week ago I sent .05 BTC from my coinbase account to what I thought was my jaxx address, but I haven't received it.
The transaction (here) says that some of the output of the transaction was spent. Does that mean that I sent my BTC to the wrong address and the receiver spent it?

What receiving address does your Jaxx wallet show? Is it 1JERLfTG41p59o4FRHGfD3c3Jd2jg4z7FY ? It looks like the 1LWRFR6c7Huz6D44yKwMXPfxqQdeuH5orm address that had 0.41.. btc sent to it (now spent) was Coinbase's change address for your transaction. The 0.05 btc sent is confirmed and still unspent.

It shows an address starting with 1Hnep... I'm not sure where I got the 1JERL... from. Did I just send it to the wrong address and lose it?

It sounds like you may have sent your bitcoin to the wrong address, if that is the case it is likely gone. The 0.05 btc is sitting in address 1JERLf..., and has not moved since the coinbase withdrawl. If you control that address then there is no issue
You can try 'reset Jaxx cache', the wallet software might be experiencing some sort of bug and not displaying your balance correctly.
It may be worth checking any other wallet software you have, to see if you sent the btc to that wallet instead of Jaxx, and got mixed up about which wallet you got the receiving address from.


text:
How does the difficulty target affect the time to complete the block?
So, I'm currently doing a personal project where I'm creating my own crypto blockchain (just for fun). I'm currently coding the Difficulty Target part of the Blockchain, but I'm not entirely sure how the difficulty part affects the process for completing the block? I know that with Bitcoin, the difficulty adjusts every 2016 blocks based on how long it took to complete the 2016 blocks, but what is the difficulty applied to and how does it make subsequent blocks harder/easier to complete?
Thanks.

Have you read this? It is sort of technical, and goes into How is difficulty calculated? and How is difficulty stored in blocks?
https://en.bitcoin.it/wiki/Difficulty
re your comment about nonces: The nonce is not the difficulty. In the example below, I'm trying to find a sha256 that starts with 0. On my imaginary blockchain, a proof-of-work that starts with a single 0 is good enough. Notice that I don't change anything but the number after foo. The number after foo can be thought of as the nonce. It's just some thing I change to get a new proof-of-work.
[I] ➜  ~ echo -n "foo" | shasum -a 256
2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae  -
[I] ➜  ~ echo -n "foo1" | shasum -a 256
bb4eca334f61af3b67b5d528907d30285151610200539302f4c8cabe66225b53  -
[I] ➜  ~ echo -n "foo2" | shasum -a 256
4963bd713a7eb1bce458868b0c8472bdc8bc5929a7892a92dd24344aea92093d  -
[I] ➜  ~ echo -n "foo19" | shasum -a 256
06651ba147df6422edcd47690fd3d68795bc59636f37f10b67a94fa70fe1fdbb  - yay

Compare that with miners on the bitcoin blockchain. Currently they have to find a sha256 hash that starts with 19 0's. e.g: 00000000000000000006d31a10b4190a8f86c93189debe87a4d1fff54fbd5b23

Yeah, I did read that but unfortuantely, it was a bit too technical for my current understanding. I don't quite understand what the difficulty target changes. From my understanding, the nonce is what people need to find in order to complete the block. But currently the bitcoin blockchain has a difficulty of 20,823,531,150,111.52. That's 20 trillion, yet the nonce from what I can see currently varies between the hundreds of millions and 5 billion ish.
Basically I don't understand how (or whether it even does) it affects the nonce and the persons ability to complete the block.

The nonce isn't the only thing that varies between attempts. In fact, difficulty 1 means that only one in ~4 billion attempts will succeed. The current difficulty means you need trillions of times that many attempts (yes, really). In order to do so, miners change other things in the block to get more chances - the timestamp, an additional nonce inside the block data itself, the composition of transactions, ...


text:
Finally found an old transaction from 2009
The file contains the addrStr
Balance
Amount sent (0)
And such and then 2 transactions
The address does show the 50 bitcoin.
One of the 2 transactions also show the same.
However I’m not sure how to get the priv key from this.
The second transaction it shows is not recognized by block explorer.
Is that a hash of the priv.key? I ran it threw sha256 but still nothing.

Bitcoin transactions and addresses are public knowledge; there is no way to calculate a private key by looking at a transaction/address.
You'll need to find the private keys themselves, otherwise your coins will remain un-spendable.


text:
What are some interesting applications of Taproot "smart contracts"?
From a strictly technical perspective, MAST makes a lot of sense. However, understanding it in the context of Taproot/Tapscript does require prior knowledge in Merkle Trees and hash functions.
What are some toy use cases that could be used to highlight Taproot's value proposition? From what I've seen, 2FA-like applications are often used as example, but what are other fun applications this technology could serve?

I think it's important to note first that BIP341-BIP342 are improvements to the Bitcoin script "framework" more than they are improvements to the smart contracting "functionality".
All Bitcoin scripts can do in practice is enforce combinations of conditions on signatures by certain (sub)sets of signers, timelocks, and revealing hashes. At a conceptual level, this does not change with Taproot - everything that can be implemented using it can be implemented without Taproot too.
What it does do is:

Make certain things smaller/cheaper (but sometimes at the cost of higher signer complexity).
Make certain things more private.
Make certain things easier to do.
Add mechanisms through which actual new conditions/features can be added later.

In some cases, these advantages can be very substantial though - making the difference between feasible and infeasible in practice, or between actually incentivizing more private constructions or not.
It's hard to give a comprehensive answer what that entails, as it's akin to a new programming language, and there are presumably many things it enables that haven't been discovered yet. I can give a few examples though:

The "Taproot" function itself means that any output, regardless of how complex its script is, can be spent using a single signature on-chain if all signers agree with spending (which also reduces their costs, but it may complicate the signing procedure). This applies to escrows, cooperative Lightning closes and various other things.
Various kinds of multisig become cheaper even when the "optimistic" taproot single-key spend can't be used, either through key aggregation (one key representing multiple people), or MAST (just revealing a script that embodies the exact condtions that were satisfied, rather than revealing all possible conditions). The advantages of key aggregation are in theory already possible using multiparty ECDSA, but that is significantly more complex than what is possible with the Schnorr signatures introduced by BIP340, and not used by anything in practice (as far as I know).
Atomic swaps, which can be used as a new privacy tool, are also in theory possible using multiparty ECDSA, but become a lot simpler using Schnorr based adaptor signatures.

Taproot would improve the privacy and fungibility of Bitcoin transactions. It seems Smart contract payments, Lightning payments, and sophisticated multi-signature smart contract payments all look the same after Taproot. When Taproot does eventually roll out, it is likely to be followed by more incremental protocol upgrades. Graftroot, which delegates signatures to allow for additional multi-sig functionality.
Please let me describe the building blocks of Taproot for better context.
The aim of Taproot is to ensure that Pay to Script Hash (P2SH) transactions appears indistinguishable from other transaction types therefore improving privacy and scalability. There is a proposal within Taproot to replace EDCSA with Schnorr signatures and therefore allow signers to jointly produce a signature, rather than needing to compute independently and add to the transaction.
Taproot also introduces Merklized Abstract Syntax Trees (MAST). MAST looks to provide additional privacy for complex redeem conditions by hashing the various potential routes. Taproot aims to use MAST in order to hide all conditions for spending and reduce the size of this information. Taproot uses MAST to include the merklized hash as the public key, thereby then includes making a complex script transaction indistinguishable from a standard P2PKH transaction.
The introduction of MAST within Taproot improves both the scalability for complex redemption conditions as well as transaction privacy by obscuring the existence of alternative routes. Please find an interesting write up on Taproot, MAST and Schnorr Signature here.

Taproot Is Coming - Bitcoin Magazine
What is Taproot - Tara Annison

Tapscript proposes to make disabled opcodes OP_SUCCESSx meaning that new opcodes could potentially be introduced in a future soft fork (hopefully in SegWit v2.0).
Here's a list of potential opcodes I'm most excited;

OP_CHECKSIGFROMSTACK for arbitrary signature verification from stack.
OP_SUBSTR for data manipulation from stack.
OP_AND OP_OR for bitwise logic.
Arithmetic operations with bigger than 32-bit integers.
Some opcodes for writing to stack.


text:
How can I perform key derivation from a 130 characters hex public key?
I'm working with a hardware wallet (Keycard) and I'm able to export a 130 characters hex public key of the path m/44'/0'/0'. Now, I need to perform account discovery, and in order to do it I first need to get addresses from public keys obtained as explained here:
generate HD addresses using publicKey Bip44
The problem is that I have not an xpub. After derived the key for m/44'/0'/0', how can I use it to derive public keys for m/0/0-19? I've started working with this stuff just some days ago and I'm a bit confused.

With only a public key, you cannot do BIP 32 derivation. BIP 32 derivation requires an additional piece of information called the chain code. This chain code is derived with each key, so each private-public keypair has its own unique chain code. Without the chain code, you cannot do any further BIP 32 derivation.

So how do I proceed if I have both public key and chain code?

Follow the derivation process described in BIP 32. You can also produce an xpub (also described in BIP 32 from your pubkey and chain code and give that xpub to any BIP 32 compliant software to do the derivation.


text:
Unconfirmed Transaction - 8days - Exchange to Hardwallet
Hi All I transferred BTC from exchange (BTC Markets) to Ledger Nano. Transaction after 8 days still showing up as unconfirmed however the amount shows up in the wallet. Any suggestions or clarity on this?

Have you contacted Ledger support; they are pretty good. Tweet them and they normally respond

@talesfromtheCRYPT: The Ledger wallet is merely the recipient here, they are not at fault, and I don't see how they would be in a special position to help.

I suggest contacting BTC Markets and asking them to increase the transaction fee. Ledger isn't the issue - most wallets display unconfirmed transactions.


text:
Question about BIP70 and bitpays recent card top up changes
Okay so bitpay just sent out an email that outlines some changes to their card top-up process. Apparently, they are implementing BIP70 and I am honestly not very familiar with what exactly that is. I did some research but am still very confused. Also my main question really is will this be compatible with my trezor hardware wallet? I've attached a screenshot of bitpays email. I am hoping one of you knowledgeable crypo devs could help me clarify this and if it's not compatible perhaps you could recommend the best option from here going forward. I really do not want to sacrifice my security of my trezor.


text:
Owner of Blockchain Technology
Is Blockchain an open source technology or is it owned by a company?
I didn't see it spelled out but Blockchain.com website appears to belong to a company.
There also seems to be different implementations of blockchain databases/ledgers.

Blockchain is some concept. There are different implementations of blockchain. Most of them open source. The most notable one is the cryptocurrency Bitcoin with their reference implementation -Bitcoin Core.
Blockchain.com is just the company with the website which provides some services related to the bitcoin cryptocurrency and owns very attractive web address.

Its called blockCHAIN for a reason, There are many makers of this masterpiece this son. I hope it works for you, Best of luck mate.

it's CHAIN because it includes blocks which are connected with each other (with hashing).


text:
Why Bitcoin fees are changing?
Why the network fee is changing suddenly from one day to the next? One day transaction fee costs ~20USD, the next day it's already ~30USD. Why is that happening? I always thought that the fee is constant.

A Bitcoin block can contain only 1 mb of data. A transactiom averages around 255 bytes. A block is built about every 10 minutes and the blockchain forces the difficulty to do so. So per hour, only around 6mb worth of transactions can pass, however there's a much higher demand due to Bitcoin's popularity. If only X transaction can fit in a block but five times X would like to do a transaction, only the highest bidding  X number of transaction will proceed. At this point it's basic supply and demand understanding.

@Cedrik I still don't get it, especially last two sentences. Why is the fee changing all the time?

Checkout this site http://txhighway.com/# . Bitcoin Cash allows 8 megabytes so there's a ton of space for cars to go, Bitcoin only allows 1mb and the highway is jammed packed. Much more cars want to get on the road then there's cars that are displayed. Only the highest paying cars will manage to get on the highway.


text:
Which crypto exchanges charge zero maker fees other than GDAX?
GDAX charge zero maker fees and I thought it is a common practice until I realise many other exchanges charge a fee around 0.20%. What are other exchanges that has zero maker fees?

According to this list, these exchanges have zero maker's fee:
GDAX
Coinfloor
itBit
Luno
Cex.io
There are probably more exchanges, but those aren't listed there.


text:
Bitcoin transaction failed to broadcast (code 66)
I am using bitcoind. I got this error while trying to send a transaction:
CommitTransaction(): Transaction cannot be broadcast immediately, mempool min fee not met, 6835 < 7865 (code 66)
The balance was removed from my wallet and yet the node does not seem to retry sending this txid again. How do i fix it?

It will be rebroadcast by your wallet automatically. However, you may want to bump the fee (bumpfee RPC command) if it's urgent as you are paying so low fees that you got evicted from your mempool.

Thanks, it was eventually rebroadcasted like you said


text:
Problem caused by unconfirmed transaction chains
I want to build a service that requires sending many small bitcoin transactions to multiple wallets (like a faucet).
Since the transactions are small, the fees have to be kept small as well so it takes a while for them to be confirmed.
The system would need to send many transactions, which naturally creates long chains of unconfirmed transactions. If I understand it correctly, after 25 unconfirmed transactions the network starts rejecting new ones, and the system is basically stuck until the previous ones gets confirmed.
This limits the throughput of such a system to 25 transactions per confirmation time (which is at least a few hours given the low fees), making it completely unscalable.
Given the above, is there a way to build a (somewhat) scalable service that can send many small transactions? (without having to manage many wallets)

Have you considered batching the payments?

A few simple ideas get around the unconfirmed-tx-chain-limit you're running into:
Start with more UTXOs. Each UTXO can be used to create <25 unconfirmed child transactions. So if you need to make n payments, you'll need at least n/25 UTXOs to do so using this method.
However, you can definitely do this in a more cost-effective manner. As Murch mentioned, batch payments describe the method of creating a single transaction with many outputs. So instead of paying one customer per transaction, you can pay many customers per transaction.
Another option is to use the lightning network to send your payments. Lightning transactions are extremely cheap, and fast. If you are regularly sending small payments, I'd encourage you to consider this option.

Thanks for the answer! I was not aware of the possibility of batching transactions. This sounds like what I’m looking for. Is there a disadvantage to batching many transactions (say 100) together?
About the lightning network - wouldn’t that require the recipients of the payments to also be on the lightning network?


text:
Electrum & BitAddress Wallets Creation
Can anyone please tell me if my procedure is correct and enough.
I've always heard and read that I must disconnect from the internet when creating Electrum Wallets, to keep away from hacks, viruses, malware or having my bitcoins stolen.
I have created electrum wallets and bitaddress paper wallets yesterday. Though I dont know much about its technicalities, I just followed simple procedures I've read online.

downloaded electrum exe installer and bitaddress (from github)
save them in my usb
disconnected my laptop from the internet
uninstall and reinstall Windows 10 (I have windows installation files too, in my usb)
created Electrum wallet, write the seed in a paper. save the wallet file in my usb.
created bitaddress paper wallet, write the Public Key and Private Key in a paper (not print). have checked the spellings, capitalizations multiple times.
uninstall and reinstall windows 10 again, scanned my usb, then connect again to the internet.

Thanks for any advice / clarifications,
Elena

Why generate the bitaddress paper wallet? Besides the other issues that have made paper wallets somewhat obsolete, writing down the private keys manually is generally a terrible idea-- using an HD wallet mnemonic phrase as physical backup is a much less error-prone method of achieving the same goal.

Also, if you're downloading a binary electrum file, you should have a step to check the pgp sigs on that file, to ensure you're getting the authentic software signed by the project developers. There have been instances of malicious versions of electrum being distributed, leading to users losing funds.

If errors in paper wallets Public Address and Private Key is a concern,  I am 100% sure that I got it correctly written (checked multiple times, written multiple times to make sure all the outputs are 100% matched.). By the other concern (somewhat obsolete), please enlighten me about the matter. Thanks.

@coiners98bit https://en.bitcoin.it/wiki/Paper_wallet


text:
Worries about ability
I have never been the best at math. However I am pretty good with computers. If I buy the gear to mine the coin how hard is it to work the machinery and do the work to make the coin?

Based on this question, it seems like you did not research bitcoin mining enough.
At this point, mining bitcoin is not profitable for the average user unless you have close to zero electricity fees and a pretty powerful computer to start with.
The bitcoin difficulty is always going up, making any investment into hardware obsolete. Most mining farms are in China due to these reasons.
You yourself do not solve math problems when mining, instead you computer will solve mathematical puzzles that the bitcoin network gives it. The faster you find the key to the puzzle (you need a fast computer) the more coins you may mine. At this point, the profitability for bitcoin mining is close to zero for the average user.

Well my computer is far from average. There is only one i7 out there that is better than the one I have. And I think 32 gig's of ram should do it. But I can get up to 64 in no time.

Is mining other cryptocurrency profitable?

Joshua, most mining these days is done by ASICs, not general-purpose CPUs. "Puzzle" solving is a misnomer for the proof-of-work that mining requires. It's just tedious (for a human) repetitive binary arithmetic: find the value, which, when input to a procedure operating on a given set of data, produces a desired output. There's no way to make any educated guesses about the input value, so the program has to just start with the lowest (or highest) possible and keep incrementing (or decrementing) it until success.

All personal computer systems in the world combined would only be able to produce a tiny amount of BTC. Having a fast computer is irrelevant. All mining now happens on specialized hardware that is many orders of magnitude faster at hashing.

Joshua, mining cryptocurrency these days involves much more than a single CPU home computer.
Have a look at https://vimeo.com/165840295 from genesis mining. No endorsement from my side though. It should just give you the impression about the scale of hardware.
Unless you are able to heavily invest, conventional mining (at least bitcoin) is not profitable these days.
However, you may consider alternative ideas like distributed mining networks using green energy etc...


text:
How does solving a block work in relation to the first letter/number after the 0's?
I did a terrible job of explaining it in the title so I'll explain here. Say the target hash to solve for a block is 00004aef... etc. does that mean that you can't solve the block if you get 00005fad (since 5 is more than 4 so technically you didn't get lower or equal to the hash)? Or is the only thing that matters in relation to the less or equal when it comes to solving the hash the amount of 0's you get?
Also, what if you get a letter after the 0's, for example 0000ba2... does that mean you need to get 0000a... or does it not matter?
Thanks.

The comparison used is numeric
These are numbers not strings of characters. You can see this by looking at the code in the 2009 main.cpp of the Bitcoin reference implementation:
        uint256 hashTarget = CBigNum().SetCompact(pblock->nBits).getuint256();
        uint256 hash;

[...]

           if (hash <= hashTarget)
            {
                pblock->nNonce = tmp.block.nNonce;
                assert(hash == pblock->GetHash());

                    //// debug print
                    printf("BitcoinMiner:\n");
                    printf("proof-of-work found  \n  hash: %s  \ntarget: %s\n", hash.GetHex().c_str(), hashTarget.GetHex().c_str());

Note that if (hash <= hashTarget) is a numeric comparison. Both hash and hashTarget are type uint256 - an unsigned integer.
Numbers expressed in hexadecimal are still numbers
There is a choice of visual representations but the choice made does not change the underlying nature of the number or the way in which numbers are compared arithmetically or at a machine level in a computer.
Your example, 00005fad, is a number expressed in hexadecimal (base 16), the same number can be written in normal decimal (base 10) as 24493. Anyone unfamiliar with non-decimal representations such as hexadecimal, octal and binary can check this using something like the Windows 10 calculator, in the menu choose "Programmer Mode" then click on "hex" and enter 5fad - it shows the same value in several different representations.
Maybe this will make it clearer?

Item
Binary
Comments / Verdict

Target
000000001100

Block A hash
000000001101
Larger ∴ Failure

Block B hash
000000001011
Smaller ∴ Success

Even though the block hashes have the same number of leading zeroes, one is a failure and the other a success.
Leading zeroes
The notion that Bitcoin cares about the number of leading zeroes in, say, a hexadecimal representation, is a commonly repeated mistake (don't ask me how I know this).
If you insist on writing numbers with leading zeroes it is still obviously true that 000015 (fifteen) with four leading zeroes is smaller than 000150 (a hundred and fifty) with only three leading zeroes. It would however be a mistake to think that smaller numbers always have more leading zeroes. Both you and Bitcoin know that 000017 (seventeen) is smaller than 000019 (nineteen) even though both have the same number of leading zeroes.
It is true that a is less than b in exactly the same way that 7 is less than 8 or that 2 is less than 3. But it is probably a mistake to start comparing individual digits in a particular visual representation. The hash and hash targets are ordinary numbers (though large) that are compared in an ordinary way.
So where does this talk of leading zeroes come from? According to a prominent contributor:

hashcash, the original PoW system, had a "difficulty" that was actually the number of zero bits up front in the hash. Bitcoin's proof of work is based on it, but generalized to a big integer comparison.

See

Difficulty - Bitcoin Wiki
Target - Bitcoin Wiki
Difficulty Representation - O'Reilly, Mastering Bitcoin

Examples
Lets look at some recent blocks (most recent at top, reverse chronological order)

Block
Mined on
Difficulty
Hash
bits

669315
2021-02-06 02:48
21434395961349
0000000000000000000bbefe7b336aab05ef49c9c6ccd70a895b3cc4669ac924

669314
2021-02-06 02:36
21434395961349
0000000000000000000ae88c36b136ef612f0a0622bdf614854a7810e3f781cf

669313
2021-02-06 02:34
21434395961349
0000000000000000000acd9e8fd6512d3832e98a8c87d049afbd805abd44d8c2

669312
2021-02-06 02:25
21434395961349
0000000000000000000beb9d24f999168c79fa58394868f9fcc5367c28f137dc

669311
2021-02-06 02:22
20823531150112
00000000000000000004f29390852281bae27d3662f648020bb47cced0d883b8

669310
2021-02-06 02:18
20823531150112
00000000000000000000cd7ef96b5f6687c8b49df40c2dec2128adc39827707e

669309
2021-02-06 01:54
20823531150112
00000000000000000009d6c5902b0b8598f2ebd0fe076581b039fe789b4daca6

669308
2021-02-06 01:37
20823531150112
0000000000000000000be631fd1026989a86cf9dae421e7eca0f80d77b6bba5e

Notice that the difficulty increased after block 669311 but the number of leading zeroes in the hashes has not increased (not in hexadecimal and not in binary).
Implementations
If you want to see exact details you could look at early versions of the Bitcoin reference implementation in C++. However I would suggest instead looking at the current BTCD implementation in go-lang because that is well commented and, in my opinion, an easier language to read.
e.g. https://github.com/btcsuite/btcd/blob/master/chaincfg/params.go
    // TargetTimespan is the desired amount of time that should elapse
    // before the block difficulty requirement is examined to determine how
    // it should be changed in order to maintain the desired block
    // generation rate.
    TargetTimespan time.Duration

    // TargetTimePerBlock is the desired amount of time to generate each
    // block.
    TargetTimePerBlock time.Duration

and https://github.com/btcsuite/btcd/blob/master/blockchain/difficulty.go
    // Calculate new target difficulty as:
    //  currentDifficulty * (adjustedTimespan / targetTimespan)
    // The result uses integer division which means it will be slightly
    // rounded down.  Bitcoind also uses integer division to calculate this
    // result.
    oldTarget := CompactToBig(lastNode.bits)
    newTarget := new(big.Int).Mul(oldTarget, big.NewInt(adjustedTimespan))
    targetTimeSpan := int64(b.chainParams.TargetTimespan / time.Second)
    newTarget.Div(newTarget, big.NewInt(targetTimeSpan))

Calculating the hash target
See

How is a block header hash compared to the target (bits)?
Mining Difficulty and Leading Zeros
What keeps the average block time at 10 minutes?
How to calculate new "bits" value?
Chain with most proof of work - hash target or block header hash?

So if more 0's aren't added every time the difficulty increases, what actually changes in regards to its difficult? It started at difficulty 1 with the genesis block and is now at over 21 trillion difficulty, yet has only went from 8 leading 0's to 19 leading 0's. What would have changed when the difficulty went from 1, to 1.18 for example?

@LM: See answers to questions in additional links appended to answer.


text:
How are the nBits of a block calculated?
So I've been trying to figure out how the nBits of a block is calculated, but I can't seem to come up with an answer. I know (think) that it's based off the difficulty of the block, but I'm still not sure exactly how it works. The Genesis Block for example has a difficulty of 1.0, yet the nBits for that block was 486,604,799 (0x1d00ffff). Then if we look at the most recent block, it has a difficulty level of 21,434,395,961,348.92, yet an nBits of 386,736,569 (0x170d21b9).
So my question is, how exactly is the nBits of a block calculated and what is its relation to the difficulty of a block?
Thanks

Does this answer your question? What does the nBits value represent?

@MCCCS I did look at that before, but I don't see where it says the formula for calculating the nBits of a Block? I was under the impression Difficulty and nBits were different.

@LM No, they're arguably the same. The difficulty is just a human-friendly way of representing the same information. Target, nBits, and difficulty are all conceptually the same.

nBits is a compressed representation of the target value that the block's hash must be less than. Bitcoin does not actually care about difficulty. Difficulty is just for humans to think about how much work is actually being done. Bitcoin only cares about nBits and the target value it represents. A block's hash must be less than that target value. nBits is recalculated every time the difficulty changes. The calculation takes the previous target (previous nBits) and scales it by the ratio of the actual timespan it took for that difficulty period to the timespan that is targeted for a difficulty period.
What it code does is (in pseudocode):
new_target = last_block.nBits.uncompress();
new_target *= actual_timespan;
new_target /= target_timespan;
this_block.nBits = new_target.compress();

So nBits starts at the value of the genesis block, and then scales up and down depending on how quickly blocks are being mined.

The relationship between nBits and difficulty is inverted. As nBits represents a smaller and smaller target, the difficulty value goes up. The computation is essentially just the ratio between the current target value and the maximum target value, which also happens to be the target value found in the genesis block. The difficulty is the current target divided by the the maximum target.

So how did the Genesis Block gets its nBit value if it relies on the previous block? Is it similar to the previous hash in the Genesis Block where it was just given a random value?

The genesis block is valid by definition; its contents does not matter.

"A block's hash must be less than that target value." *less than or equal to according to this... https://developer.bitcoin.org/reference/block_chain.html


text:
How is the Target Hash determined?
So, I understand how the amount of leading 0's are calculated, but how is the hexadecimal that come after the leading 0's calculated? For example, the previous mined blocks hash was
000000000000000000084bc771b929b0780276b1c31cec10a96921b1e53b970a but how was the 84bc771b929b0780276b1c31cec10a96921b1e53b970a after the 0's determined?
I saw this answer: https://bitcoin.stackexchange.com/a/36228/110284 but I'm not gonna lie, I didn't understand it.

@PieterWuille Unfortunately not because I was under the impression that 3 of the variables (Time, Nonce, and Merkle Root) change or are not present before the block is completed. I thought the Time continues ticking until the block is successfully mined, the Nonce constantly iterates until the correct nonce is found, and the Merkle Root is the hash of all the transactions that occur in that block. So how can the Target Hash for a block be created from those values if the values constantly change prior to the blocks completion?

@L M I think I see your confusion. I retracted my close vote, and wrote an answer.

There are two values in play here, and the way your question is phrased makes me think you're confusing them.
Every block has:

A hash (computed by double-SHA256 the block header, including timestamp, nonce, version, Merkle root, nBits which encodes the difficulty, and previous block hash)
A target (computed from the difficulty only)

000000000000000000084bc771b929b0780276b1c31cec10a96921b1e53b970a is the hash of block number 669945. Just feeding the block's header exactly to double-SHA256 gives you this output (including the zeroes up front). It gets interpreted as a number:

0x000000000000000000084bc771b929b0780276b1c31cec10a96921b1e53b970a (in hex, with zeroes explicit)
0x84bc771b929b0780276b1c31cec10a96921b1e53b970a (in hex)
794600089940753232651370066465976921098309156434843402 (converted to decimal)

The target is the maximum allowed value that hash must have to satisfy the proof-of-work requirement. It is determined entirely by the difficulty(*) (which on its turn is determined by the timestamps of the previous blocks in the chain it is built on). That difficulty is also stored in the block header itself as the "nBits" value. The nBits value for block 669945 is 0x170d21b9; it encodes 0x0d21b9 · 2560x17 - 3, which equals:

0x0d21b900000000000000000000000000000000 (in hex)
1257769770588612382309009370720465882998915202417688576 (converted to decimal)

Since 794600089940753232651370066465976921098309156434843402 (the actual hash's value) is less than 1257769770588612382309009370720465882998915202417688576 (the target value), proof-of-work is valid for this block. And of course it is; if it wasn't, you would never have heard about this (attempted) block candidate.
(*) Technically speaking, the term "difficulty" is only used for representing how hard a block is for human consumption. Internally only nBits and the full target value are ever used. Difficulty is defined as 0xffff·25626 / target. The lower the target, the harder it is to find a block whose hash is below it, and thus the higher the difficulty is.

1 question, what do you mean by encodes 0x0d21b9 · 256^0x17 - 3? I understood everything else and it was very helpful, but just confused about that part. Not sure where you go the 0x0d21b9 and 256^0x17 - 3 from.

That's just how nBits works. If nBits = 0xABCDEFGH, that encodes the target value 0xCDEFGH * 256^(0xAB - 3). I don't know where or how Satoshi came up with it, but that's the definition.

I think you're confusing a few things.
A SHA-256 hash is a single value that is 64 hexadecimal characters long. This hash can be seen as simply a very long number.
A target hash in cryptocurrencies is the maximum value that a successful block hash should be. Miners are aiming to generate a block where the hash, when seen as a large number, is a smaller number than the target hash.
The entire thing 000000000000000000084bc771b929b0780276b1c31cec10a96921b1e53b970a is a block hash. It is a SHA256 hash, and just happens to be a number that contains a lot of zeroes.
If you want to see how the block hash is calculated, take a look at this article: https://en.bitcoin.it/wiki/Block_hashing_algorithm


text:
Does the Merkle Root get constantly updated inside the block or does it only get added once the block is completed?
So, pretty much just the title. I'm just wondering how the Merkle Root works exactly. I know it's the result of pairing transactions and then hashing them until the last transaction in the block, but when is this done? Is it constantly updated while the block is getting mined, or is the Merkle Root only calculated when the block is completed?
Thanks.

Once the mining pool has the list of all of the transactions they are including in that block, they calculate the merkle root for this list of transactions, then they distribute the block header, that includes the merkle root, to miners to work on.
So, no, it's not constantly being updated, unless for some reason a new transaction was being added or removed from the list of transactions being included in the block.


text:
Non-standard multisig
I have a question regarding this transaction where the outputs are showing as non-standard but appear to be multi-sigs. This is the first output:
Transaction ID: 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713
OP_1
e4cf0200067daf13255044462d312e340a25c3a4c3bcc3b6c39f0a322030206f626a0a3c3c2f4c656e6774682033203020522f46696c7465722f466c6174654465
636f64653e3e0a73747265616d0a789cad5c4b8b24b911becfafa8b3a1da292925654253d0d55373f06d61c007e39bbd061f0cde8bffbe25c55b5266f61ab3905d
9ba54728e28bb76a963777fbcfb77fdf96db7d291f93f3e599f7fafcedefb73fffe1f6aff665fdefb77f7c7bfefce6c2fa166e695bdfd6dbcfbfddfef8c3dd5cf9
OP_3
OP_CHECKMULTISIG

Is there an issue with the public key hashes or the script? I am new to this so sure I am missing something simple.
Thank you

https://bitcoin.stackexchange.com/questions/35959/

OP_CHECKMULTISIG is typically preceded by:

The number of keys (n)
n public keys (not public key hashes!)
The number of signatures required (k)

That is not the case here, because the 3 byte arrays that are pushed in between the OP_3 and the OP_1 are not public keys. Public keys are either:

33 bytes, starting with 0x02 or 0x03 (so-called compressed public keys)
65 bytes, starting with 0x04

The byte arrays pushed here are 65 bytes, but do not start with 0x04.

This is data store tx https://bitcoin.stackexchange.com/questions/35959/

Thank you Pieter and amaclin. I should have googled the transaction ID. I assume that it is not possible to spend these outputs as there is not corresponding private keys to enable the OP_CHECKMULTISIG to succeed.
And thank you for correcting my mistake in the original question.

@visualAd Indeed, it is unspendable.


text:
Trying to understand a nonstandard transaction in bitcoin tests
I am trying to implement a bitcoin script interpreter and today I stumbled upon a nonstandard transaction in tx_valid.json which gave me a lot of headaches. The transaction in question has the following prevout script public key:
DUP HASH160 0x14 0x5b6462475454710f3c22f5fdf0b40704c92f25c3 EQUALVERIFY CHECKSIGVERIFY 1 0x47 0x3044022067288ea50aa799543a536ff9306f8e1cba05b9c6b10951175b924f96732555ed022026d7b5265f38d21541519e4a1e55044d5b9e17e15cdbaf29ae3792e99e883e7a01
and has the CLEANSTACK flag set.
If we disregard the signature present in the script, which is nonstandard, the script is successful (it is the previous test in tx_valid.json)
Now if we add the signature to the script, at the end of execution there will be two values on the stack, 1 and 0x3044022067288ea50aa799543a536ff9306f8e1cba05b9c6b10951175b924f96732555ed022026d7b5265f38d21541519e4a1e55044d5b9e17e15cdbaf29ae3792e99e883e7a01. Because of the CLEANSTACK flag, which requires only one value on the stack, I think that the script should fail.
One idea I had is that FindAndDelete deletes all the other signatures in the script public key, so now we have only 1 on the stack. However I am not sure about this because from what I have read FindAndDelete only deletes values in the subScript when verifying OP_CHECKSIG and OP_CHECKMULTISIG, and does not modify the actual script.
So where am I wrong?

The flags listed in the file are inverted: it gives under which flags validation isn't expected to succeed (or in other words: under all flags except the ones listed there, it is expected to succeed).


text:
How does bitcoin find the block locator hashes in the leveldb database?
I am trying to understand how bitcoin core builds the list of block locator hashes needed for sendheaders and getheaders messages. I have looked on the wiki and I have seen that after the 10 most recent block hashes, it goes back exponentially until the genesis block.
So it seems that I have to get a block hash knowing its index in the blockchain. But how can bitcoin core find a block hash by its index? From my understanding leveldb lets you query data only by a key, and in this case the key is what I want.

The answer is that it doesn't use LevelDB for this.
It has an in-memory data structure with all known block headers, each pointing back to its parent. It also has a vector with pointers to all block headers in the currently active chain.
To build locator objects, it simply looks in this vector at specific indexes.

So every time bitcoin core receives a new block it has to update both this data and the database, am I right?

Indeed, but the in-memory structure is very cheap to update.


text:
Shutdown bitcoin-qt during reindexing?
I started bitcoin-qt with --reindex and pruning on.
Can I safely shutdown and restart?
If yes how? Do I have to pass --reindex again or will bitcoin-qt remember and continue from where it stopped?

Can I safely shutdown and restart?

Yes.

If yes how? Do I have to pass --reindex again or will bitcoin-qt remember and continue from where it stopped?

No, Bitcoin Core will remember that it was reindexing and continue the reindex.

Thanks! I'll give it a try.

First I made a backup of datadir. Next I started again with --reindex and it started from scratch.
Makes sense but I don't want that.
So I replayed backup and start without --reindex. It started where it had stopped before.
Andrew, thanks for the quick and helpful response!


text:
Ripple secret key
I am adding Ripple to my HD Wallet.
To be compatible with other HD wallet, I need to use bip32/bip44 paths.
So I will use such approaches:
https://github.com/iancoleman/bip39
https://github.com/you21979/node-ripple-bip32
But these libraries generate private key that is different from Ripple's secret key. Public/private key pairs are just like the bitcoins addresses.
How can I generate secret key from this private key?

When deriving a key using this method, the ripple secret key does not exist.
There is no compatibility because the derivation algorithm is different.


text:
mnemonics for ripple wallet
I am trying to write a ripple wallet. I want it to be HD wallet.
So I am generating 12 word mnemonics but I am not sure how to give this as a seed to ripple javascript api. See:
https://ripple.com/build/rippleapi/#generateaddress

I'm not 100% sure how this API works, but it looks like it lets you supply the entropy. Test to see if you always get the same address and secret if you supply the same entropy. If you do, then just use the mnemonic and any HD scheme you want to derive a secret of any kind (you can use the same algorithm you'd use for bitcoin) and pass that secret as the entropy to that API call.
Two cautions with this approach:
1) You must test to make sure that API really is deterministic. Try it on a few different machines and a few different JS implementations and make sure the same entropy always leads to the same address and secret.
2) Your ability to recover keys from the mnemonic would be tied to your access to this library. If the library ever changed its key generation algorithm, you might be unable to recover the keys. So pick a version that works and don't ever change it.

Test to see if you always get the same address and secret if you
  supply the same entropy.

I have tested this and can confirm that you always generate the same secret and public address when you supply the same entropy.
Here's my example code for submitting the entropy to the generateAddress method.
// This functions works on modern browswers, not sure about Node.js. Try https://www.npmjs.com/package/js-sha512 or https://nodejs.org/api/crypto.html
async function fun_SHA512_array(entropy) {
    'use strict';

    // Turns a string into an array of integers.
    // Made possible by https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/digest

    const msgUint8 = new TextEncoder().encode(entropy);                           // encode as (utf-8) Uint8Array
    const hashBuffer = await crypto.subtle.digest('SHA-512', msgUint8);           // hash the message
    const hashArray = Array.from(new Uint8Array(hashBuffer));                     // convert buffer to byte array
    // const hashHex = hashArray.map(b => b.toString(16).padStart(2, '0')).join(''); // convert bytes to hex string

    return hashArray;
}

const str_entropy = "Use a cryptographically strong, randomly created string of characters here.";
// Or, your passphrase string would go here.
// Or, you could use a BIP39 Mnemonic but you'd have to remember how you constructed the string. e.g. Did you separate the words with a comma or with a space?
// Or, on the linux terminal you can use: openssl rand -base64 n
// Where n = the number of characters you wish to randomly generate. Which are then converted to base64, therefore the amount of characters ends up being more than n.

var array_sha512 = [];

fun_SHA512_array(str_entropy).then(array_sha512 => {
    var obj_new_account = api.generateAddress({"entropy": array_sha512});
    var str_secret = obj_new_account.secret;
    var str_public_address = obj_new_account.address;

    console.log(str_secret);
    console.log(str_public_address);
});


text:
bip44 account discovery
In Bip44 "Account Discovery" section, there is following sentence:

We scan just the external chains, because internal chains receive only coins that come from the associated external chains.
  (https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#address-gap-limit)

I do not understand it. If I do not scan internal chain, how will I find the change addresses?
Yes, change address will exist in transaction output of public (external) addresses, but I can not find out which output address is change address as it can be real receiver address.
Thanks for help.

In terms of "Accounts discovery" algorithm, it is not needed to get internal addresses. We just sequentially take receiver addresses of an account and check whether one of them was used in any transaction. Literally: we get a transaction and check whether receiver address is in the set of target addresses of looking transaction.
This is so because if there is a change address in the transaction then there is a receiver address mandatory. It allows us to skip checking of change addresses for this task.


text:
I need to buy a gift card for PlayStation using bitcoins or altcoins
I need to buy a gift card for PlayStation using bitcoins or altcoins. Unfortunately, there is currently no other payment method. Can someone help?

https://www.bitrefill.com/ is an option, looks like they offer gift cards for the PlayStation store.