text:
Where does the mining reward in regtest go?
After using the bitcoind -regtest generate 1 command, where does the mining reward go? I tried list accounts and check balance for account "", but the balance always showed 0.000000.

To you, but with a delay.
What you're observing is the maturity period: the coins generated by a block can only be moved after there are another 100 blocks on top.
If you generate another 100, your balance will start increasing.

Is there a way to specify the mining reward address with bitcoind?

Yes, use the generatetoaddress RPC (which mines to an address of your choice) rather than the generate RPC (which mines to a fresh wallet address).


text:
Bitcoin regtest mining
I wonder if I can do mining with Bitcoin-0.16.1 in regtest mode, just for simulating mainnet situation where there are new blocks coming in constantly.
I am aware that I can use generate to generate blocks almost instantly after every transaction and thus confirm the transaction. But can I use a miner program to automate that process and simulate better the real-world situation, i.e. new block coming in constantly in small number?
I have tried cgminer connecting to my regtest solo mining but it does not seem to mine anything, it just sits there and hash rate is always 0. Any advice on how I can mine on regtest or should I set up some automated scripts to call generate from time to time?

You can build your miner with a bash command:
$ while true; do bitcoin-cli -regtest generate 1; sleep 300; done

You'l get a block every 5'. If you want a better simulation of mainnet you could use a rndom sleep

oh yes I discovered later this is probably a more efficient way to simulate actual mining on regtest than using a mining program

I am answering my own question for those who run into the same situation and for the sake of knowledge sharing.
YES you can mine on a regtest network. The difficulty of mining on regtest is extremely low that you miner program will just mine block after block almost instantly.
The reason why cgminer was not mining is because it is for GPU mining and there was no GPU on my machine and I could not find a way to mine with CPU using cgminer.
So I switched to another miner: cpuminer, which mines with cpu and it worked:)

source: Stack Exchange

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

sort: votes


text:
why is BnB coin selection algorithm not enabled by default?
BnB is one of the best coin selection algorithms existing and its implementation is in the Bitcoin source code. But as seen from this line: https://github.com/bitcoin/bitcoin/blob/f72d80b07af8ecbb2f9df1e87344eb465186f19d/src/wallet/wallet.cpp#L2403 it is not enabled by default. Why is that or have I been mistaken?

You're misunderstanding the code. That variable tracks whether BnB was used. Not whether we attempt to use it.
BnB does not always yield an acceptable result, as it requires a solution with no change to exist. It is attempted, but if no such solution can be found, Bitcoin Core's coin selection falls back to other algorithms. The bnb_used variable remembers whether that was the case.

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


text:
Detecting stale blocks with ZeroMQ
I'am writing an application which receives information about new tx and blocks via ZeroMQ. There is a chance that I will receive notifs about blocks which will later on become stale blocks. Is there a way to verify whether the block has become stale?

I don't believe there is a direct way to do this via ZeroMQ. Your best bet would be to validate the ancestry for each block as you receive it.
When you receive a block, check its parent hash against blocks you have already seen. If the parent chain validates and you do not have another, longer child chain from the parent block already, you can accept this block.


text:
I seem to have too many unspent outputs for my given balance. What am I missing?
I have an address on the testnet. I started out with 1.3 btc. I then sent 0.5 btc to another address. My balance is now 0.8. OK, that makes sense.
I expect now to have one UTXO which was the 0.8 in change from the previous transaction. But when I run listunspent, I see I have two UTXOs. The balance is correct, but it seems I have two outputs.
[
  {
    "txid":
   "321dab633022a33c3a49b4aab4b13d3c431771ae9402746dbb6dcc21be5fd603",
    "vout": 1,
    "address": "2N4wJG7gs1mVXeMkX2MCuyekZUCSzrW7CjT",
    "redeemScript": "0014221f8d76c5b85e979055e54ac97a0cada38bc4e9",
    "scriptPubKey": "a914803d96c7e19e4a568764f9912fa54499f814cd8e87",
    "amount": 0.79999834,
    "confirmations": 119,
    "spendable": true,
    "solvable": true,
    "safe": true
  }
]

When I run gettxout with the txid and vout 0, the first transaction UTXO is 0.5.
{
  "bestblock":
  "0000000000000043a1abc3cf9c778d3adeb417488019a507da871db9df74ffad",
  "confirmations": 119,
  "value": 0.50000000,
  "scriptPubKey": {
     "asm": "OP_HASH160 a43f8a90f292b6be0b487556ac357709a5e86480 OP_EQUAL",
     "hex": "a914a43f8a90f292b6be0b487556ac357709a5e8648087",
     "reqSigs": 1,
     "type": "scripthash",
     "addresses": [
       "2N8Dgvfmgs4fNCi7QatLZJR8ArvhPpMPW8P"
     ]
  },
  "coinbase": false
}

And when I run gettxout with vout 1, the second transaction UTXO is 0.799 (0.8) which is the balance.
{
  "bestblock":
  "0000000000000043a1abc3cf9c778d3adeb417488019a507da871db9df74ffad",
  "confirmations": 119,
  "value": 0.79999834,
  "scriptPubKey": {
    "asm": "OP_HASH160 803d96c7e19e4a568764f9912fa54499f814cd8e OP_EQUAL",
    "hex": "a914803d96c7e19e4a568764f9912fa54499f814cd8e87",
    "reqSigs": 1,
    "type": "scripthash",
    "addresses": [
      "2N4wJG7gs1mVXeMkX2MCuyekZUCSzrW7CjT"
  ]
},
"coinbase": false

}
And according to this: How to check if an output has been spent?
If gettxout returns something, then the output is unspent.
Why do I have two unspent outputs with the first one in the same amount that I sent to another address?

Does your wallet control both addresses? 2N4wJG... and 2N8Dgv...? If so, it makes sense that both UTXOs would be listed with listunspent

Ok, that's probably it.
What I did as an exercise is I made two copies of wallet.dat: sending.dat and receiving.dat. I then had a test faucet send some btc to sending.dat. I then sent btc from sending.dat to receiving.dat. What you see in my original question were the two UTXOs for sending.dat.
So I'm guessing that because I made copies of wallet.dat, all the resulting addresses I created actually belong to the same wallet?

Yes, the addresses belong to the same wallet. It was the same file copied, and with Bitcoin Core's HD wallets, the same addresses and private keys will always be generated with those wallet files.

As per the comments on OP’s question
Since you made a copy of the wallet.dat file (which is an HD format), both addresses will be under the control of (both copies of) your wallet. Hence, both UTXOs will be listed when calling the listunspent command, as each wallet is able to spend both UTXOs.
If you used a new wallet to generate a new address, and send some funds to it, then the listunspent command should function as you originally expected, as your bitcoin core wallet would not control the address you spent coins too (it would only control the change address).


text:
How do miners determine if a wallet has sufficient funds
I have ready about 10 posts that are similar and none of them seem to answer my question so any help is appreciated.
My question is how to miners technically determine if a "wallets" has the "balance" to complete the transaction. Before you say this is a duplicate let me elaborate:
User A has private key A and Public key A.1 and A.2
User B has private key B and Public key B.1 and B.2
Transaction 1 A-> B.1 by User B sending B.1 to A and A signs the transaction (0.5 BTC for illustration) with that private Key.
Transaction 2 A-> B.2  by user B sending B.2 to A and A signs the transaction (0.5 BTC) with that same private key.
Now private Key B has 1 BTC. But sense No one knows that B.1 a and B.2 belong to B because those are derived dynamically from B how can you know how much A has? Further suppose you loose track of you public keys, so B.1 and B.2 have been forgotten. How are you able to figure out the bitcoins that B has access to?

Related: https://bitcoin.stackexchange.com/a/91152/5406

The blockchain does not see wallets at all.  It only sees spent and unspent transaction outputs (txouts).  A txout is either completely spent or completely unspent - it cannot be "partially" spent and so there is no notion of balance.  (If you want to spend less than the full value of a transaction, you create a change output.)
In your example, there are now two txouts that B can spend.  The "private key" B would actually be a master private key - each "derived" key is really a keypair consisting of a private key B.1.priv and a public key B.1.pub.  So in order to spend the txout that was paid to B.1, user B must sign a transaction using the private key B.1.priv.  If B wants to spend the entire 1 BTC, she can create a transaction with two inputs and signed by both B.1.priv and B.2.priv.
It is true that nobody except B (and maybe A) knows that both txouts are spendable by the same person.  That is fine - they don't need to know.  This is considered a desirable privacy feature.
If B should lose B.1.pub, no problem - it can be regenerated from B.1.priv. This is part of how ECDSA works.   If she should lose B.1.priv, it can be regenerated from the master private key B.  If she loses the master private key, she is out of luck and cannot spend her coins.

wait but suppose I have my 12 word backup and I loose everything and re import my master private key from the words, how would I determine which private keys B.1.priv and B.2.priv?

@noone392 the wallet will derive keypairs from the master key, and then check to see if there are any valid UTXOs that are spendable by a key the wallet controls.

@chytrik so you saying there is some policy to derive keys sequentially in a repeatable way, then you generate the first say 100 keys and perform a verification on all 18 million BTC?! So validating the spendable amount requires probably 1.8 billion asymmetric operations?

No, that would be a very inefficient way to do it. For details of the key derivation see BIP32/39/44/84, eg: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki. For the balance check, it will depend on what type of wallet you are using, there are several different ways it might be done (full node vs SPV, etc). But in general, the network does not keep track of individual coins, it keeps track of 'UTXOs', so the wallet just needs to filter the current UTXO set for any entries that are spendable by one of it's keys. See BIP 37/157/158 for more info.

Thank you @chytrik. I will spend some time reading this. So then in a transaction the sender must provide all derived public keys in the transaction to account for the funds? So suppose there is 3 derived keys each with 0.5 BTC. If you want to send 0.75 you would need to both sign the transaction, but also provide at least 2 of your public keys so the chain can validate the funds?

A signature actually includes the public key corresponding to the private key that is used to sign.  So yes, if you want to send 0.75 BTC, you will need at least two inputs, each signed by the corresponding (derived) private key and including the corresponding (derived) public key.

@NateEldredge I see thank you! So then the sender would have to pay gas tax twice in the above example? Sense it requires 2 of the three derived key pairs to cover the funds and both have to provide their signatures?


text:
bip143 witness formatting
in bip143 thet define a witness signature. In the first example there is a witness broken down
witness    00
               02 47304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee01 21025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357

this formatting doesn't appear to be defined anywhere in this document? my question is specifically

what is the entire second piece "21025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357"
the first part is the signature but what are the extra bytes on the front and end specifically 0x47 and 0x01
Most importantly the signature is too long?! it is 70 bytes instead of 64. "304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee"  I was able to take the example private key, public key, and sighash and sign and verify so I know they are good, unless they aren't using SECP256k1 but that doesn't appear to be specified anywhere?

Thank you a lot in advance!!

this formatting doesn't appear to be defined anywhere in this document?

The formatting follows the standard Bitcoin script. The main difference between the witness stack and traditional Bitcoin script is that instead of pushing things to the stack via a script, the stack is just provided. So all of the encodings are just as if it were a Bitcoin script.

what is the entire second piece "21025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357"

That is the public key, prepended with it's length.

the first part is the signature but what are the extra bytes on the front and end specifically 0x47 and 0x01

0x47 is the length of the signature, including the extra byte on the end
0x01 is a Bitcoin specific byte called the sighash type. This as an enum that indicates what data needs to be included in the message that is hashed for the signature, aka the sighash.

Most importantly the signature is too long?! it is 70 bytes instead of 64.

No, this signature is DER encoded, so there ends up being extra bytes to indicate type and length.

You a scholar and saint sir! Thank you again!


text:
How can I see what is bitcoin tx for pending Lighting channel (lnd)
When I open a new Lightning channel from lncli I get the blockchain tx hash back.
But afterwards how can I find this hash later on, if the channel is still pending state?
lncli pendingchannels does not show any tx data and lncli listchaintxns does not show unconfirmed bitcoin tx.
thanks

The output of lncli pendingchannels gives you as much as you need:
"pending_open_channels": [
{
        "channel": {
            "remote_node_pub": <pubkey>,
            "channel_point": <txid:output_index>,
            "capacity": ,
            "local_balance": ,
            "remote_balance":
        },
        "confirmation_height": ,
        "commit_fee": ,
        "commit_weight": ,
        "fee_per_kw":
}]

The channel_point will give you the txid, that you can later lookup at a bitcoin testnet explorer, or directly with btcctl --testnet gettransaction txid


text:
Why is my blockchain.com not receiving bitcoin?
I created a wallet on blockchain.com, copied the address from the '' bictoin request '', sent it to the person, and that person sent me a bitcoin after a few hours.
After a few hours my laptop restarted. When I logged in again, the Bitcoin address was different.
Bitcoin was sent to that address, but my wallet no longer recognizes the address it generated.
Can I recover the amount of bitcoin? What can I do?

Your bitcoins are not lost.
What you observed is completely normal behavior which one would experience across most wallets. The wallet generates a new address once it detects that you have received coins on the previous address. This is done to minimize address-reuse which improves the privacy of the sender and the receiver.
This has nothing to do with your laptop restarting.

Yes, but I did not get the amount of bitcoin, and I do not find the address I was supposed to get the bitcoin at the addresses I used.
And the address generated by the wallet that I received bitcoin, I can not find it in my wallet.

I'm not sure if I understand you correctly. Are you sure the other person send coins to you? Did they arrive at the "request-bitcoin"-address you send the person?

I used the "bitcoin address request" to get a bitcoin, I used a proxy, and after a few hours the proxy expired and my laptop has restarted, I used athoer  IP, and IP changed and I logged back into my wallet, it generated another address bitcoin request, and the funds received on the previously generated address are no longer recognized by my wallet.

https://www.blockchain.com/btc/address/13D6FEsc8oJ4ynJD7hL52CM1GPzKp8YZh4 , this is adress generated first time, and the btc is there..

block explorer shows that the funds arrived at the address specified as expected, but the transaction does not appear in my Blockchain wallet’s transaction history.


text:
Bitcoin explorers don't show my addresses transactions
I'm creating bitcoin addresses for a wallet we're building. To make sure the addresses are valid I went to a couple of bitcoin explorers and they reported, correctly, that the address does not have any transactions yet.
Great. But now I put in a couple of addresses from my existing wallets (Bread and Jaxx) which both have several transactions over the past year or so. Once again the explorers reported -- this time incorrectly -- that the addresses have no transactions.
The explorers I tried, with an example address that has transactions associated with it:
www.blockchain.com/btc/address/1LQs3i94JTJGimr2BiM929Zdhm1ShCatJR

insight.bitpay.com/address/1LQs3i94JTJGimr2BiM929Zdhm1ShCatJR

Why can't I see the transactions for this address?

Check that this is the actual address that you used to receive the Bitcoin in the past.
The default behavior for wallets is to generate a new address each time you want to receive funds. This means that if you simply opened your wallet, hit generate, and tried to scan that address, it will show 0 transactions. And, this is correct, because even though the wallet has received Bitcoin, that specific address hasn't.

If anyone is seeing this question, the answer is correct. Read about bip39 and bip44 to learn about this issue.


text:
Alternative to the move command?
As you know, account commands are deprecated in the future. In the same wallet, how do we carry other address bitcoins in one address ?

You can't, even with accounts. Bitcoin is not transferred between addresses when using the move command. It does not magically transfer Bitcoin from one address to another when you use move. The only way to do that is to make a Bitcoin transaction. All that move did was it changed which account an address was associated with. Nothing was actually moved, just a wallet internal database entry was changed.

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


text:
0.17 Specify Wallet with RPC/curl
In core 0.17 they allow a user to dynamically specify wallets for things like getbalance. So with bitcoin-cli --wallaet='foo' getbalance
But I can't actually figure out how to do this with JSON RPC/ curl? It doesn't seem to work as a parameter or in the --data portion for curl. Can someone help point to how this gets included with an RPC or curl call? Thank you in advance.

with bitcoin-cli --wallaet='foo' getbalance

I think you're referring to the -rpcwallet flag.
Usage
The flag changes the endpoint. Try changing the url of the curl call to:
<rpc-url>/wallet/<url-encoded-wallet-name>
Example:
curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getbalance", "params": ["*", 6] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/wallet/foo


text:
convert from public address format to raw transaction format
So I am trying to full understand how to decode transactions. In the dev docs it discusses a raw transaction: https://developer.bitcoin.org/reference/transactions.html
in the paragraph "TxOut: A Transaction Output" there is an example. Near the bottom of that example it decodes the bitcoin script. It shows you pushing 20 bytes labeled as the public key has onto the stack.

cbc20a7664f2f69e5355aa427045bc15e7c6c772

That value is autogenerated from "createrawtransaction" cli function which comes from the public key. It specifically references the example here
https://developer.bitcoin.org/examples/transactions.html#simple-raw-transaction
where it says

NEW_ADDRESS=mz6KvC4aoUeo6wSxtiVQTo7FDwPnkp6URG

how are they going from

mz6KvC4aoUeo6wSxtiVQTo7FDwPnkp6URG

to

cbc20a7664f2f69e5355aa427045bc15e7c6c772

? It doesn't say anywhere in the documentation. Is this just a read the source code situation? I should say I have tried plugging the address into many different hashing calculators. I never get the same result.

There are currently 3 address types defined in Bitcoin:

The satoshi-era P2PKH format, which is Base58 encoding of (1 byte version prefix) + (20 bytes pubkeyhash) + (4 bytes checksum). The checksum is the first 4 bytes of the double-SHA256 hash of the 21 bytes that precede it. The version number is 0 for mainnet; it's easy to find lists of prefixes for other networks.

It encodes the script OP_DUP OP_HASH160 <that pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG

The P2SH format specified in BIP 13 and BIP 16. It follows the same structure as P2PKH addresses, but with a different version number and instead of a pubkey hash, it is a script hash.

It encodes the script OP_HASH160 <that scripthash> OP_EQUAL.

The native witness address format introduced in BIP 173 It uses a completely different base-32 encoding (called Bech32) of data (5-bit witness version number) + (variable length witness program).

It encodes the script OP_(witnessversion) <witness program> (see BIP 141 for the semantics of such scripts).
The encoding was amended in BIP 350 to use a slightly different checksum algorithm for witness version 1 and up.

In general, if you're looking for specifications, the BIPs are where to look, except of course for protocol/standard aspects that predate the BIP process.

oh man thank you again. I just base58 decoded mz6KvC4aoUeo6wSxtiVQTo7FDwPnkp6URG and I ended up with 6f cbc20a7664f2f69e5355aa427045bc15e7c6c772 f982e923. and then double hashed the first 21 bytes and got f982e923!  Just one correction, it doesn't appear that the whole script it base 58 encoded. everything by generaterawtransaction was in clear hex

No, just the version prefix byte and the pubkeyhash/scripthash are Base58 encoded. The rest of the script is implied by the version number.


text:
When generating witness for bip143, how do you choose WHAT outpoint to use?
in bip 143 for creating a witness signature it describes what needs to be serialized/signed. One thing that the doc seems to be missing is how to determine WHICH outpoint to use. So in these transactions there are multiple txins in each example, and they always seem to just pick one of them?
For example from the Native P2WPKH in bip 143
The following is an unsigned transaction:
    0100000002fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f0000000000eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac11000000

    nVersion:  01000000
    txin:      02 fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f 00000000 00 eeffffff
                  ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a 01000000 00 ffffffff
    txout:     02 202cb20600000000 1976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac
                  9093510d00000000 1976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac
    nLockTime: 11000000

  The first input comes from an ordinary P2PK:
    scriptPubKey : 2103c9f4836b9a4f77fc0d81f7bcb01b7f1b35916864b9476c241ce9fc198bd25432ac value: 6.25
    private key  : bbc27228ddcb9209d7fd6f36b02f7dfa6252af40bb2f1cbc7a557da8027ff866

  The second input comes from a P2WPKH witness program:
    scriptPubKey : 00141d0f172a0ecb48aee1be1f2687d2963ae33f71a1, value: 6
    private key  : 619c335025c7f4012e556c2a58b2506e30b8511b53ade95ea316fd8c3286feb9
    public key   : 025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357

  To sign it with a nHashType of 1 (SIGHASH_ALL):

  hashPrevouts:
    dSHA256(fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000)
  = 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37

  hashSequence:
    dSHA256(eeffffffffffffff)
  = 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b

  hashOutputs:
    dSHA256(202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac)
  = 863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5

  hash preimage: 0100000096b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd3752b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3bef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a010000001976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac0046c32300000000ffffffff863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e51100000001000000

    nVersion:     01000000
    hashPrevouts: 96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37
    hashSequence: 52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b
    outpoint:     ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000
    scriptCode:   1976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac
    amount:       0046c32300000000
    nSequence:    ffffffff
    hashOutputs:  863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5
    nLockTime:    11000000
    nHashType:    01000000

you can see that there are 2 txins and only one outpoint used in the signature, and this is pretty much true for all the examples. It does not say anywhere in bip143 HOW you choose. Any advice is greatly appreciated.

When you are creating signatures, you are signing for a specific input in the transaction. That specific input has a corresponding outpoint, so you use its outpoint in the sighash.
In the examples given, the sighashes for all of the inputs are given. So for each input, it makes a sighash using the outpoint for that input.
In this example, if you are signing for input 1, then you use the outpoint fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000. If you are signing for input 2, you use the outpoint ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000.

so then you would have to have 2 witness signatures, each with with the hashPrevouts including ALL the inputs? Also that example doesn't appear to have 2 sighashes, that example clearly only has one?is this example incorrect?

I think Andrew missed that the first input isn't a segwit output, so it doesn't use BIP143. In this case, for the second input, the output you substitute is the output being spent in the second input.

@noone392 Yes, if your transaction has two inputs requiring witness signatures, then there will be 2 witness signatures. hashPrevouts will include all of the outpoints, but in order for a sighash to apply to a specific input, the outpoint for that particular input is included explicitly. This example only has 1 witness sighash because there is only 1 witness input which I did not notice earlier.

Thank you guys a ton for the help. I am not sure it would be possible to come up to speed without just reverse engineering the core if it wasn't for the experts spending their time.


text:
How can I use Bread on iOS to manage bitcoin and litecoin?
I have a Bread wallet for iOS (https://bitcoin.org/en/wallets/mobile/ios/breadwallet/).
Is it possible to manage both bitcoin and litecoin with the same Bread app?
If so, how can I use the Bread app to:

create separate wallets for bitcoin and litecoin?
distinguish the wallets when I want to use one or the other currency?

As far as I can tell, Bread doesn't support Litecoin in any way.  It only supports Bitcoin.  So you can use it to manage your Bitcoin if you wish, but you'll need to find a different app for Litecoin.

Thanks, but do you have some sources for this? I searched for litecoin wallets, which led to "loaf wallet". Looking at the github for loafwallet, it said "deprecated, please look at litecoin-foundation/loafwallet-ios". And clicking there led directly to the github fork of Bread (https://github.com/litecoin-foundation/loafwallet-ios) (note the big Bread logo). So... from that I concluded that Bread supports litecoin. If that's not the case, it's Ok, but... geez I'm confused.

@martinjakubik: I don't know how to prove a negative, but I have never seen any reference to Litecoin within the official Bread app nor its documentation.  Loaf is not Bread; it's a fork.  Someone took the Bread source code (which did not support Litecoin) and modified it to create a different app which does (but as far as I can tell the fork no longer supports Bitcoin).  It looks like they were not very careful about changing all instances of the original app's name and logo.

alright, I'll take that as an answer. Thanks. what's frustrating is that they weren't careful about updating the ... uh... link to the App Store either.

There's a reference now. From the Bread blog on March 6th: "This new version of the app sports a modular framework, built from the ground up, that enables us to add multiple digital assets to the Bread platform, of which Bitcoin Cash is only the first." So as of March 6th, they have Bitcoin and Bitcoin Cash. No Litecoin yet. (https://breadapp.com/blog/bread-adds-bitcoin-cash-ios-users/)

The BRD wallet does not support Litecoin.  The latest IOS release (3.0.x, May 2018) has support for Bitcoin, Bitcoin Cash, Ethereum, and ERC20 tokens.

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


text:
How is SegWit a soft fork?
Reading this section of BIP144, I noticed the followng statement:

Parsers supporting this BIP will be able to distinguish between the old serialization format (without the witness) and this one. The marker byte is set to zero so that this structure will never parse as a valid transaction in a parser that does not support this BIP. If parsing were to succeed, such a transaction would contain no inputs and a single output.

And this is in fact confirmed by this line in Bitcoin Core which is executed for every transaction found in a block during the CheckBlock call.
As far as I understand, this should mean that old clients that see a block containing a SegWit transaction would consider that transaction invalid and hence discard the whole block. Is that correct? What am I missing?

Actually, the line of code you're citing checks whether a transaction has 0 inputs, which is not allowed ever. To see the code that decides whether a witness is present, look at primitives/transaction.h.

@PieterWuille Yes, I was citing that line to reinforce the fact that old clients seeing the marker as '0x00' would interpret it as as the varint that specifies the number of inputs and hence refuse the transaction because it has zero inputs

Yes, I know. But again, you're confusing the abstract object with the serialization. In a transaction, 0 inputs is invalid. But the conversion from bytes to transaction object is elsewhere. A segwit transaction does not have 0 inputs, it just uses an encoding that looks like 0 inputs to old clients. Look in primitives/transaction.h for the deserialization code.

That makes no sense, if it looks like 0 inputs to the old client and 0 inputs is never valid, then indeed it will look invalid to the old client, won't it?         In any case, that seems to be a minor point. If the transaction now doesn't contain the signatures, how could it possibly look valid to someone not seeing the signatures?

@relG SegWit scripts look like ANYONECANSPEND scripts to old clients (i.e. everyone can spend a script which consists only of OP_0 <32-byte push> without needing a signature) so old clients that will see an ANYONECANSPEND output being spent with no signature will consider it a perfectly valid transactions

So can't, indeed, anyone spend it, at least from the point of view of the old nodes? And then there will be a fork of the network, cause someone except the legit user will spend it, and the new nodes reading the segwit witness will not accept this send, but the old ones will?

A softfork is defined as a consensus change that converges as long as majority of the hashrate adopts it. Yes, a non-witness transaction spending a segwit output without signature would be valid to old nodes, but 1) they won't see that (such a transaction is nonstandard to everyone) 2) such a transaction won't be mined (same as 2) and thus 3) the majority chain will not accept such transactions.

You're confusing transactions (the abstract object) and their serialization (the bytes on the wire in the P2P protocol or on disk).
Sure, SegWit introduces an extension to the P2P protocol (BIP144), which relays witnesses along with transactions, and old clients wouldn't understand such messages.
But old clients don't see them. Witnesses are only included when the requester asks for them, which old clients don't do. For them, new clients remove the witnesses before relay. Exactly because the witness of a transaction does not contribute to its txid, it is in fact possible to remove them before relay, without invalidating them. That is what makes it a soft fork.

Ok, I see, so if I understand correctly, when an old client receives a block it will receive the block stripped of all witness-related data. Is that correct?

Indeed, it looks like (and is) a totally old style block to them.

how can? the old style block contains signature (witness) but the new and stripped one does not.

The new one contains empty signatures, which are valid according to the old rules, for spending SegWit outputs. SegWit just introduces an extra field to transaction (the witness), which does not contribute to the txid. The old scriptSig field is still there, but just unused for SegWit spends.

If a block contains empty signatures, how can the transactions be verified?

To an old client, all spends from SegWit outputs look like anyone-can-spend outputs, which are valid to spend without signature. Old spends still have signatures, which validate. New clients will also validate SegWit spends, by using the signatures from the witness.

@PieterWuille, And how is this different from SegWit2?

SegWit2X is an incompatible change to Bitcoin's rules sought by a number of companies, which will likely become a separate currency. It has nothing to do with Segwit.

Why is the empty signature there in the first place? Isn't it wasting space?

Yes, 1 byte of waste per input, which can be trivially removed by using a compressed transaction format. There are dozens of ways more inefficiencies exist - 4 bytes for timestamps, sequence numbers in all inputs, locktimes in all outputs, DER encoded signatures... each of those accounts for far more waste in terms of naively-counted block space. But for backward compatibility reasons it's not really worth the effort to fix them.


text:
Is it more dangerous when 51% attack happens than just having a pool with >50% hashrate?
Many people told me that, if a mining pool performs a 51% attack, the price of the coin will drop.
But I disagree.
There are pools with >50% hash power already for a long time. Flypool is an example. (On the ZCASH network)
If one day these pools start to mine only on their own blocks, but not double spending or refusing any transactions, they performed a 51% attack. However, I think the security risks didn't become higher.
Yes, they can revert a transaction at any time so it is a security risk, but they already have had this ability for months!
For these two situations:

there is a pool with >50% hashrate
this pool mines only on their own blocks

I think the second is not more dangerous than the first one.
So my question is, is it becoming more dangerous when a pool with >50% hashrate starts to mine only on their own blocks? Will the coin price drop and why? Why didn't pools like Flypool mine only on their own blocks?

One can't say what's more or less dangerous for a cryptocurrency value. You don't have a control group. You would need a parallel universe where Flypool had no more than 51% to compare prices there to prices in our universe.
Saying that, being decentralized it's the very point of a cryptocurrency, and very few people will invest in one of them that's actually centralized. I can only speculate what's in their minds, but maybe people invest in ZCash today hoping it will become less centralized in the future. Flypool, despite having more than 50% hashpower, like you said, probably don't mine only on their own blocks because they would make people sure the thing it's centralized. Or maybe because they sincerely want the security of ZCash against a double-spend, so the accept the smaller pools help. Both things must probably increase an overall reputation of the ZCash in people's mind and must probably keep the price a little high.

Mining pools besides ASIC manufactures are extremely dangerous for every PoW based cryptocurrency. A mining pool or a group of pools with >51% hashing power can destroy the network in minutes. The fact you wonder why Flypool doesn't double spend on ZCash is a bad thing per se. You shouldn't ever be in a position you have to be surprised a pool doesn't do any harm.
There ARE solutions to discourage or even completely block pools in PoW based blockchains but in my opinion there is no will to face the problem. Bitcoin and other developers are millionaires while crypto investors are computer illiterates and this is the combination that will lead to disaster.


text:
why should I backup zcash wallet regularly
On zcash official website, making regular backups of the wallet is recommended.
When I use bitcoin, I have a master private key, and all private keys can be generated using the master key. So I can only backup my wallet once.
So what's different in zcash? Why should I backup the wallet regularly?

Zcash was built on a fork the Bitcoin Core 0.11.2 codebase, which generated (transparent) keys randomly. The Sprout shielded keys were similarly generated randomly. Thus, it is necessary to back up your wallet whenever you use transparent addresses (because Zcash inherited Bitcoin Core's behaviour of using a new transparent address for every change output), or whenever you generate a new shielded address or import a shielded key (which are the only times that new shielded keys are added to the wallet, because shielded address reuse for change outputs leaks no information).
Bitcoin Core added a minimal BIP 32 implementation to their 0.13 release, which is used for new wallets (legacy wallets still generate all keys randomly even after 0.13). Once that is backported to Zcash, transparent addresses will similarly be deterministically generated.
We are currently working on ZIP 32, which will define how to generate shielded keys (for both Sprout and Sapling) deterministically. Once this is finished, support for deterministic shielded addresses can be implemented in Zcash.

The BIP32 specification allows a user to derive many keys from a master extended private key, and this master key is derived from a seed (often, a mnemonic phrase). This allows the user to just back up one piece of data (the seed phrase), knowing that they'll be able to use it to derive all subsequent keys in their wallet.
Prior to the implementation of BIP 32, most wallets were a collection of keypairs that were independently generated at random, so one key would bear no relation to the next. In this style of wallet, every time you generate a new address, you need to save a new backup copy that includes the new address. Older backups would not contain the info that allows you to derive the same new address.
I am not extremely familiar with Zcash, but I would guess that not all implementations of their wallet software use a BIP32 style wallet architecture, thus the recommendation for regular backups (similarly, not all bitcoin wallets use BIP32).


text:
what is preventing me from changing difficulty every submit when pool mining?
If I do pool mining at difficulty=1000 and I find a share with difficulty=2000, I can tell the pool that I was mining at difficulty=2000 and then submit the share. I can earn more in this way.
Does the pool allow me to change difficulty whenever I want? If not, assume that it let me change difficulty every 30 minutes, then I can use a high difficulty which makes every share more than 30 minutes.
Even if this cannot be done, when I find a share with difficulty=2000, I can connect to the pool as a new worker with a static difficulty=2000 and submit the share.
What is preventing me from doing this?

I don't know what pools actually do, but an easy way to prevent this would be that when you change difficulty, or when you join as a new worker, you're given fresh work: say, with a different set of transactions, or some new magic cookie in the coinbase transaction.  Then if you later submit a share that has the old cookie, it gets rejected.

The work you were given is associated with a difficulty that the server decided upon before giving you that work.
Any work results you send in must be associated with work data known by the server.
When you submit work results, the work is looked up, and voila, there is the difficulty.
You may be given new work that has a different difficulty associated with it at a later time, but the old work still has the old difficulty.


text:
Bitcoin core incorrect balance?
So I have ubuntu 16x running bitcoin core. Its a full node and fully synched. Run with bitcoind --daemon as suggested. Using a particular address from my wallet, whenever I send money to the address getblanace works fine (bitcoin-cli getbalance XXXX 1). Whenever I send money from the address, (on a completely different system using a web based wallet), it shows that the bitcoins arrive when expected, but my getbalance of my correct address never goes down. I even tried sending all the money out in 10 different transactions and saw it was failing when the the account should have been zero'd out, all the while always reporting that I had my high original balance.
I feel like I am missing something basic but I can't seem to figure it out. Thank you in advance

Have the transactions confirmed?

Yea all the transaction have a dozen or so confirmations at this point, and they show up in the other wallet and I can spend them in the new wallet.

that also shows the incorrect balance.

Does bitcoin core have all the latest blocks? $ bitcoin-cli getblockcount

wait there is a mysterious entry at the top of list accounts that says "" -0.00145718 which is approximately what i have sent from that address!?

block count is 544380 which is the same number in getblockchaininfo

The accounts feature is very confusing and has been removed in the latest version v0.17.0. https://bitcoin.org/en/release/v0.17.0#label-and-account-apis-for-wallet

aww shoot. Thank you for that. I guess its back to the drawing board for my development.

The issue that you are experiencing is not really an issue. Rather it is a fundamental misunderstanding of how the accounts system works. Because it is so unintuitive and behaves in an unexpected way, the accounts system has been removed from Bitcoin Core.
The behavior that you see is completely expected. Accounts are not involved in the sending of Bitcoin except for the internal account values are decreased. The association of addresses to accounts is a receiving only thing. Account balances are only updated when addresses for the account receive money. Sending money "from" those addresses will not update the balance. The account balance will be decreased only if you use the send* RPC commands which allow you to specify an account to decrement the amounts from.
It is also important to note that "sending from" an account does not mean that coins associated with the addresses in that account will be the only ones chosen for the transaction. Any coins can be chosen, and then the account's balance will be decremented. Because of this, it is also possible to have accounts with a negative balance.
In general, you should stop using the accounts system. Not only is it being removed, but it also has strange and unexpected behavior.

Thank you so much this, I couldn't find this information anywhere! Looking at the new API it doesn't appear that its possible to get a balance of a particular label or a particular address? Is it now only possible to get the balance of an entire wallet? If so is it possible to have multiple wallets with a single 0.17 node?

Yes, you cannot get the balance of a label that doesn't really make sense because a label is not an account. Bitcoin Core has supported having multiple wallet loaded for a few versions now. With 0.17, you can dynamically create and load them. You will want to use createwallet and loadwallet.

(bitcoin-cli getbalance XXXX 1) ... getbalance of my correct address never goes down

XXXX there is an account name for getbalance.
As JBaczuk commented

The accounts feature is very confusing and has been removed in the latest version v0.17.0.

(strictly speaking it is deprecated in 0.17 and expected to be fully removed in 0.18.)


text:
signed raw transaction does not conform?
I have become fairly familiar with constructing raw transaction. One thing I can't understand is after a raw transaction comes back from a signing, it doesn't look like it conforms to the transaction formatting. I was wondering if there was a different specification for signed raw transactions vs unsigned as shown here
https://developer.bitcoin.org/reference/transactions.html
here is the original unsigned raw broken into its chunks

02000000 01
5aab7df5106f76ae87544058edf7768fcb4c8fcbe2906d7ef9721a261bf505d3
01000000 00 ffffffff 01 968601000000 00
00160014e874b2647cf1f47e7d360a0e9753045950910f8a 00000000

the following is a signed raw transaction. I can see the parts that were added but the 0001 specifically should have the first byte be none zero sense it is a compactSize type. The bold areas were the data that was added. Obviously the second long hex is the signature/unlocking script of sorts but I can't find where to decode that either in the docs.

02000000 0001 01
5aab7df5106f76ae87544058edf7768fcb4c8fcbe2906d7ef9721a261bf505d3
01000000 00 ffffffff 01 9686010000000000 16
0014e874b2647cf1f47e7d360a0e9753045950910f8a
02473044022049ea695e1e7454be2e365142faa8258b8f5ce58b2c9cd9474085ce23df1b7e220220349da1acb0327a5025a0ed85dd88e9628703ed4086f4f8f4ac9b3c020a855bce012103773c3298e0ab8b000b48691c9262e774376239e23069370509e643217062010f
00000000

Any help is greatly appreciated.

What you're seeing is the extended transaction serialization format introduced in BIP144 (segregated witness). It adds a marker 0x0001 to indicate the presence of a witness after the version number, and a list of witness stack items after the transaction inputs.

oh thank you mysterious internet saint haha. I found https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki and it looks like it accounts for everything. Its so hard to learn this stuff when the official docs are out of date

I'm afraid you'll need to learn that there is nothing "official" in Bitcoin.

yeah that is unfortunate. At this point I have decided just to run bitcoin core in debug mode and just watch what the code does and reverse engineer it. It appears to be easier then looking for information on the internet... unless there was someone I could pay to answer my questions LOL

There is a great site, called https://bitcoin.stackexchange.com, where people are willing to answer certain questions for free though!


text:
Recipient calculation in verifyTransactionBytes for Ardor
I'm trying to add verifyTransactionBytes to my app.  I am currently stuck because of transaction.recipient !== data.recipient.  I don't understand how transaction.recipient will ever equal data.recipient.
data.recipient equals ARDOR-64L4-C4H9-Z9PU-9YKDT
However,  transaction.recipient equals 12686039152117651770352583052021228896653772998482022211948610002430512793010043372255281183988421160450227631016638876582933743874739812608892576232835541561180017189881475915550182092483428449468438018195304514943626747005224233901130236596723251118266281272406204049816147466250586545776300564249483796886483621200942491492199171631589798205980673
This doesn't really surprise me, because I don't see how an ARDOR address gets generated from transaction.recipient = String(helpers.byteArrayToBigInteger(byteArray, pos));
Which looks like it should return a number, not a string.  What am I missing

You need to either convert data.recipient from RS format to numeric format or convert transaction.recipient from numeric format to RS format using NRS.convertNumericToRSAccountFormat(id)

So transaction.recipient should be the numeric format of the recipient addresses?

Right, you can convert the public key to numeric account then convert it to RS format using NRS.convertNumericToRSAccountFormat(id)

I found my error.  My byteArrayToBigInteger function was incorrect.  Your answer helped me though, as I new what outcome I should expect with the numeric address.  Thank you!


text:
How a web-service like bitnode.earn can know each node's blockchain height?
How a web-service like bitnode.earn can know each node's blockchain height?
We can get some information of each node in bitcoin network in this web-site:
https://bitnodes.earn.com/nodes/
And, it is updated regularly(in approximately every 5 minutes).
My question is from here.
How(the method) the web-service can get all the information from all the nodes in the network? They ask those information to all nodes in every 5 minutes? Doesn't it take quite long time to get the responses from all the nodes(about 10K nodes in the network)?
Also, doesn't it required to be in peer-relationship with all of them to request those information?
I'm waiting any answer from you guys.
Thank you in advance for your nice answer!

Possible duplicate of Is there a way to find how many nodes are there?

Yes! The web-site: https://bitnodes.earn.com/nodes/ offers some information such as how many nodes are in current bitcoin network, height of each blockchain and IP addrs, etc.

Sites like bitnodes run their own lite nodes which are crawlers. These nodes connect to other nodes and only receive data from those nodes. When a node receives a new block, it will send it to the nodes it is connected to. If one of these is a bitnodes crawler, it can record that it received a block at height X from the node. In this way it can track the current height of a node.
Furthermore, nodes send their current height when they connect to another node. The crawlers, if they happen to disconnect from a node, can quickly retrieve the latest information about the node once they reconnect by simply waiting for the version message which must be sent in order for the connection to continue (it is part of the handshake at the start of every connection). The version also contains other information such as protocol version number and user agent string.
Other metrics such as up and latency come from the fact that the crawlers have open and active connections to those nodes. The fact that they have a connection means it is up. They can use the ping message to measure latency.


text:
How do mining pools connect to the Bitcoin network and miners connect to pool?
I couldn't find the answer anywhere so I start a thread.

How do mining pools connect to the Bitcoin network to propagate transactions and blocks? Do they run their own full node? If yes, how many of full nodes?
I presume it's hard to run a mining pool with only one full node because it's IP will be exposed to some network attack like DDoS.
How do miners connect to a pool? Is there any server running by mining pools so miners can connect to?

How do mining pools connect to the Bitcoin network to propagate transactions and blocks?

They connect in the same way that everyone else connecting to the Bitcoin network does. Miners are still nodes, they do everything that a full node does.

Do they run their own full node?

Yes.

If yes, how many of full nodes?

At least one. It doesn't matter how many nodes a miner is running, so long as they are running a node. At least one node is needed in order for them to see transactions and blocks and for them to broadcast their own blocks. Large mining operations may have multiple full nodes. Small ones may only have one. It is difficult to know how many and what nodes belong to miners as they look like any other node on the network.

How do miners connect to a pool? Is there any server running by mining pools so miners can connect to?

Mining pools operate servers which give out work to miners with that pool. The miners have to connect to those servers in order to get work to do. They can connect using a variety of protocols. The two protocols in use today are stratum and getblocktemplate.

Mining pools connect to the P2P network by running their own nodes.
Theoretically, they could avoid running a node but then they would be exposed to mining invalid transactions and on invalid chains, so this would be pretty foolish.
I've recommended that miners in the past run one or more private nodes that accept no incoming connections to generate their work. These private nodes then connect out only to public nodes they run on unrelated networks and a small number of well selected third party nodes.  I've also seen that plenty of miners have ignored advice like this, and sometimes they get DOS attacked.
Public mining pools advertise locations for their users to connect to. Some have private alternative addresses for high hashrate users to reduce exposure to attack.


text:
Can full node with only IPv4 connect to another full node with only IPv6?
As far as I know, IPv4 and IPv6 are two different protocols and direct connection between an IPv4 and IPv6 cannot be established.
If I run a full node with only IPv4, can my node connect to another node with IPv6 only?
If no, why do I sometimes see my node's peers are IPv6?
Likewise, is it true that nodes with IPv6 can only connect to other nodes with IPv6?
Since there are only about 1000+ IPv6 full nodes in the network now, isn't that they have much fewer choices of peers?

No. IPv4 can not connect to IPv6. They’re almost completely disjoint networks except for the fact that some nodes can be dual stack with both, or many of each type routed.

Does that mean a full node may have 2 different IPs, one is IPv4 and one is IPv6?

That’s correct. It can have an arbitrarily number of IPv4 and IPv6 addresses as listening sockets.

Can we assume that all the nodes with IPv6 (https://bitnodes.io/nodes/) also have IPv4 enabled? Otherwise, these nodes can only connect to other IPv6 nodes.

Generally the opposite isn't true. An IPv6-only system can connect to the IPv4 world (as the IPv4 address space is embedded in the IPv6 one).


text:
When is CMPCTBLOCK message sent in High Bandwidth Relaying?
In the Compact Blocks FAQ, particularly, the High Bandwidth Relaying diagram attached below, the CMPCTBLOCK message is sent by node A when receiving block is not yet completed.
The description says: When a new block arrives, Node A performs some basic validation (such as validating the block header) and then automatically begins sending the header, shortened txids, and predicted missing transaction (as described above) to Node B.
Is this really true? As I am checking the latest Bitcoin Core code, I see that INV/HEADERS/CMPTCBLOCK messages of a new block are only relayed once the block tip is updated (i.e., new hash is pushed to vBlockHashesToAnnounce).
Isn't that this means the CMPCTBLOCK message is sent only after the new block is fully validated (non-contextual and contextual checks)?


text:
How exactly trading of Bitcoin does?
How exactly trading of Bitcoin does? Is it just like a trading of shares of any company listed on stock exchange? Can anyone explain its transaction in detail?? Is there any Transaction fees or trading margin like stock exchange?

When trading bitcoin on exchanges you trade directly at the exchange (not through a broker). Another big difference is that everything at an exchange is visible publicly, this includes the current orderbook and a recent set of historical trades.
What is features are supported and what the fees are depend on the exchange, a few big exchanges are:

bitstamp: They only support trading assets that you own, you can make limit orders or market orders. Margin trading is not supported.
bitfinex: They support the same as bitstamp as well as margin orders.
kraken: Similar as bitstamp, but also supports other cryptocurrencies.

Besides the top few, there are also exchanges that do not have markets with FIAT money, the biggest one here is poloniex (which supports margin trading).

authors: علیرضا نسیون پور


text:
Sent bitcoins to a suspicious address!
I just may have been scammed via a phishing link. The transaction is verified but not confirmed, I'm new to bitcoins, as you can probably tell. From the quick bit of research I've done there is nothing I can do. It was only $20.
Here's my question, Is there anyway to make sure the transaction doesn't confirm or send the bitcoins out of my wallet before it confirms?

Basically, no.  You can attempt to double-spend, but the Bitcoin protocol is designed to make this difficult to accomplish, and your odds of success are low.  The recipient can also do things like increasing the transaction fee via child-pays-for-parent to encourage miners to confirm the original transaction instead of your attempted double-spend.  The design goal of Bitcoin is that once a transaction is made, it cannot be undone, and you should generally not plan on being able to do that.

The transaction can be replaced under certain conditions. See my answer.

I think Opt-in Replace By Fee is what you are looking for. The wallets implementing RBF lets you mark your transactions as unfinished and that let's you replace it with more fees than the previous one. But merchants are advised to wait for at least one confirmation before accepting optin rbf transactions (to avoid a double spending risk).
The only wallet I know that have implemented RBF is Electrum.
Below you have some useful links:
https://bitcoincore.org/en/faq/optin_rbf/
https://petertodd.org/2016/are-wallets-ready-for-rbf
https://electrum.org/#home

I don't think RBF will help here.  The goal of RBF is to allow a transaction to be replaced by a new transaction which has a higher fee but whose outputs are otherwise the same.  It will not allow you to change or cancel a transaction.  For that you need a true double-spend, and the aim of RBF is to provide a standard for miners to make it possible to increase fees without encouraging double-spend.

@NateEldredge As I understand, it's equally possible to make a double spend transaction with any type of unconfirmed transaction, being RBF or not. That's why I linked the Peter Todd's article where he studied the awareness of wallets to that kind of issue. Here you have the RBF BIP specification: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki#implementation-details. I did not found any official documentation that says replacements must have equal outputs, can you provide any source?

Sorry, you are right.  I was thinking of the RBF-FSS variant.


text:
How to setup seed node?
I have compiled and build my own coin using cryptonote fork.
After that i have printed genesis block.
Then I pasted this genesis block hash and rebuild the binaries.
But, my question is:-
What to do next?
I have all this on my local pc.
How to start seed node?
I have purchased digitalocean VPS.
What files do i need to transfer to VPS.and what commands do i need to run on vps.
Please help me

I have been in the same boat since last 2 weeks. Made a BTC clone out of a very old source code found online.
I have been a bit successful as well.
All the below assumes that you are running Ubuntu.
After compiling I was able to run it using the ./xyzcoind
I did find out that you would need at least two nodes to test. I read this somewhere and also validated this. Can not start mining till there are two servers talking to each other.
I have done this by setting up two small servers on Azure. One connects to the other.
./xyzcoind -connect=a.b.c.d
To test if it is running well or not you may goto .xyzcoin in your home folder and check debug.log
To set up the dns seed node, the parameter can be directly specified in chainparam.cpp if you are using bitcoin source in line that reads as "

vSeeds.push_back(CDNSSeedData("someaddress.com or IP addy",
  "someaddress.com"));

And then you need to add all the seed node IP address to the A records where ever you have your domain name from. You might need to do it on your own if you have a privater server or can use cpanel depending on the scenario at your end. I did it via cpanel as I have domains hosted with siteground.
some more details on below link

What is a DNS seed node vs a Seed Node?

i ran some instance of node on various server and noted the ip of them
1)change file

net.cpp

static const char *strMainNetDNSSeed[][2] = {

{"aaa.aaa.aaa.aaa","aaa.aaa.aaa.aaa"}, {"bbb.bbb.bbb.bbb","bbb.bbb.bbb.bbb"}, {"ccc.ccc.ccc.ccc","ccc.ccc.ccc.ccc"},

};

Now convert you ip to hex and add on line no 1240(search on basis of function name and not by line number):
unsigned int pnSeed[] =
{
0xa5esadf3d, 0xa5ssddf, 0xa5sd1s3, 0x68ec1asc,
}

Thats all, now when ever you run ./altcoin -daemon it will directly connect with any running node among mentioned above

authors: Петр Мазaнько


text:
I was unable to fund another wallet since this morning

Hello everyone, I have been trying to transfer some amount from my wallet to another bitcoin address but didn't successful since morning, please I need help on this critical issue.

That's funny. The problem is caused by transactions that haven't confirmed, but the transactions have plenty of fee.

How do I solve it? @Nick O'Dell and how are my going to know if it's confirmed?


text:
Why are only specific transaction types accepted into the mempool?
In the Bitcoin Mainnet, only specific transaction types are accepted:

Bitcoin uses a scripting language to specify (and satisfy) the encumbrances, thereby allowing a whole host of transaction types. Although many transaction types can be represented in the scripting language, only a limited number of standard transaction types are actually accepted by the network and the miners. (source)

What is the point of equipping Bitcoin with a scripting language, while only accepting a pre-defined set of transaction types? What harm could be caused to the network by accepting valid transactions with an arbitrary locking script?

This information seems very outdated (or wrong).

Any script can be used in P2SH/P2WSH technique. Using arbitrary scripts in transaction outputs cause grows of UTXO database and other problems.


text:
How to initiate a transaction with address and privateKey using nodejs
I have a list of bitcoin addresses and private keys, I need to write an automation script which checks for the balance in each address and transfer the balance funds to another bitcoin address. My question is how I perform the fund transfer with address and privateKey using nodejs
Thanks in Advance

i.e. "How do I steal bitcoin from accounts I've hacked..."

No, it's not stealing bitcoins. I have the list of accounts and privateKeys that I have generated. I am using these accounts for receiving funds. For privacy reasons, I keep on switching the incoming address and monitor all the address and if any funds deposited on these address I move those funds to my hot wallet address.

Oh, ok :). Your use case is exactly why HD wallets (BIP32) were introduced. You can generate many addresses from a single private key and not have to store a list of private keys.

Given a list of bitcoin private keys, first you need to check the balance of the corresponding address, probably best done using a block explorer, e.g. blockchain.info:
Single Address
https://blockchain.info/rawaddr/$bitcoin_address
Address can be base58 or hash160

Optional limit parameter to show n transactions e.g. &limit=50 (Default: 50, Max: 50)
Optional offset parameter to skip the first n transactions e.g. &offset=100 (Page 2 for limit 50)

{
    "hash160":"660d4ef3a743e3e696ad990364e555c271ad504b",
    "address":"1AJbsFZ64EpEfS5UAjAfcUG8pH8Jn3rn1F",
    "n_tx":17,
    "n_unredeemed":2,
    "total_received":1031350000,
    "total_sent":931250000,
    "final_balance":100100000,
    "txs":[--Array of Transactions--]
}

Then, you can use bitcoinjs-lib, for example, to create a raw transaction for each private key:
const alice = bitcoin.ECPair.fromWIF('L1uyy5qTuGrVXrmrsvHWHgVzW9kKdrp27wBC7Vs6nZDTF2BRUVwy')
const txb = new bitcoin.TransactionBuilder()

txb.setVersion(1)
txb.addInput('61d520ccb74288c96bc1a2b20ea1c0d5a704776dd0164a396efec3ea7040349d', 0) // Alice's previous transaction output, has 15000 satoshis
txb.addOutput('1cMh228HTCiwS8ZsaakH8A8wze1JR5ZsP', 12000)
// (in)15000 - (out)12000 = (fee)3000, this is the miner fee

txb.sign(0, alice)

For which, you will need unspent outputs to each private key's address.
You will also need to broadcast the raw transaction:
// build and broadcast our RegTest network
regtestUtils.broadcast(txb.build().toHex(), done)

I had a similar issue for a store I had where I was accepting bitcoin. I ended up creating a nodejs app that would take the input of just a private key and an address. It would gather all the UTXOs that belong to the private key using a third party API, and then send ALL funds to the address specified. Back then I was using bitcore-lib, but that library is now outdated, I would use bitcoin-js if I re-did it today.
These are the basic functions I used:
app.post("/address", function(req,res){
    var pkey = req.body.pkey;
    var addr = req.body.addy;

    validateAddress(addr, function(isAddyValid){
        if(isAddyValid == 0){
          res.render("pages/index.ejs", {
            outMessage: "Destination address invalid"
          });
        } else {
            validatePrivateKey(pkey, function(isPkValid){
                if(isPkValid == 0){
                    res.render("pages/index.ejs", {
                    outMessage: "Private Key invalid"
                    });
                } else {
                    convertPK(pkey, function(convertedAddy){
                        getUTXO(convertedAddy, function(result, feeAmt, totalToSend){
                            if(result == 1){
                                res.render("pages/index.ejs", {
                                    outMessage: "No UTXO"
                                });
                            } else if(result == 2){
                                res.render("pages/index.ejs", {
                                    outMessage: "Source offline"
                                });
                            } else if(result == 3){
                                res.render("pages/index.ejs", {
                                    outMessage: "Insufficient funds to pay fee"
                                });
                            } else {
                                buildTX(result, feeAmt, totalToSend, pkey, addr, function(payloadTx){
                                    pushTX(payloadTx, function(txdone){
                                        if(txdone !== 1){
                                            res.render("pages/index.ejs", {
                                            outMessage: "TX ID: " + txdone
                                            });
                                        } else {
                                            res.render("pages/index.ejs", {
                                            outMessage: "broadcast failed try later"
                                            });
                                        }
                                    });
                                });
                            }
                        });
                    });
                }
            });//end validatePrivateKey
        }
    });//end validate address
}); //end app post

function validateAddress(output, result){
    addyValue = output.replace(/[^\w\s]/gi, '');
    if(bitcore.Address.isValid(addyValue)){
    result(1);
    } else {
    result(0);
    };
};

//convert pk to addr
function convertPK(pkeyValue, result){
    var address = new bitcore.PrivateKey(pkeyValue).toAddress();
    result(address);
};

function validatePrivateKey(wif, result){
pkeyValue = wif.replace(/[^\w\s]/gi, '');
        if(bitcore.PrivateKey.isValid(pkeyValue)){
        //private key is valid
        result(1);
        } else {
        result(0);
        };
};

//get outputs
function getUTXO(address, callback){
    request({
        url: "https://chain.so/api/v2/get_tx_unspent/btc/"+address,
        json: true
    }, function(error, response, body){
        if(!error && response.statusCode == 200){
            if(body.data.txs.length < 1){
                //no utxos
                console.log("no utxo");
                var err = 1;
                callback(err);
            }
            var status = body.status;
            var num = body.data.txs.length;
            var utxos = [];
            var totalSats = 0;
            var txSize = 44;
                //loop through all UTXOs
                for(i=0;i < num; i++){
            var convertSats = body.data.txs[i].value * 100000000;
            convertSats = parseInt(convertSats);

                    var utxo = {
                    "txId": body.data.txs[i].txid,
                    "outputIndex": body.data.txs[i].output_no,
                    "address": address,
                    "script": body.data.txs[i].script_hex,
                    "satoshis": convertSats
                    };
            utxos.push(utxo);
            totalSats = totalSats + convertSats;
            //calc tx size for fee
            txSize = txSize + 180;
                }; //end utxo loop
            getBestFee(function(bestHourFee){
                var fee = txSize * bestHourFee;
                totalSats = totalSats - fee;
                console.log(totalSats);
                console.log(fee);
                    if(totalSats < 1){
                        //not enough funds to send
                        var err = 3;
                        callback(err);
                    } else {
                        callback(utxos, fee, totalSats);
                    }
            });
       } else {
           //err or no response from api
           console.log("no response from api");
            var error = 2;
           callback(error);
       }
    });
};

//build transaction
function buildTX(utxo, fee, total, pkeyValue, output, callback){

        var transaction = new bitcore.Transaction()
        .from(utxo)
        .to(output, total)
        .sign(pkeyValue);

        //payload to push tx
        var txjson = transaction.toString();
        var pload = {
            "tx": txjson
        };
        callback(pload);
};

//push transaction
function pushTX(pload, callback){
    request({
    url: "https://api.blockcypher.com/v1/btc/main/txs/push",
    method: "POST",
    json: true,
    headers: {"content-type": "application/json"},
    body: pload
    }, function(err, response, body){
            if(err){
         //no response or error POST to chainso
             callback(1);
        } else {
                console.log(JSON.stringify(body));
                completeTxId = body.tx.hash;
                console.log("done");
                callback(completeTxId);
            };
    });
};

function getBestFee(bestFee){
  var findfee = "https://bitcoinfees.21.co/api/v1/fees/recommended";
    request({
        url: findfee,
        json: true
    }, function(error, response, body){
        if(!body.hourFee){
            //no response from api use 150 sats per byte
            var fee = 150;
            bestFee(fee);
        }
        if(body.hourFee){
            var fee = body.hourFee;
            fee = fee * 0.5;
            fee = Math.ceil(fee);
            bestFee(fee);
        }
    });
}

If you want to see the entire project here's the repo, it's a simple nodejs express app with a form submission POST option and a GET endpoint /sweep option. Be aware the way I wrote it, it will only work with legacy P2PKH addresses (addresses that start with a 1), no segwit.
https://github.com/coinables/sweepkey

Sending private key through API post request body is not a good approach.

you're using https://api.blockcypher.com/v1/btc/main/txs/push to post transactions.  what is the testnet version of this? I tried test and testnet but both fail


text:
Light clients transaction verification
How does a light node know which block its transaction got included in?
Say a light node sends out a transaction spending its UTXO. Does it get some sort of notification when its transaction is mined in some block or does it need to manually ask a full node if its transaction is present in every new block that is mined after it made the transaction?
Also, say a wallet program was loaded after a month of inactivity. Now the wallet needs to know the balance of its address? How does it go about reconstructing its balance after downloading the latest block headers?
Note here that I'm asking about the low level apis and not any service like a block explorer!

How does a light node know which block its transaction got included in?

Most SPV wallets use BIP 37. The protocol defined in BIP 37 is roughly as follows:

Wallet sends to a full node a bloom filter which, when applied to transactions, indicates whether a transaction applies to that wallet.
Full nodes, for every block and transaction, applies the filter to see if there is a match.
If there is, relay the transactions to the wallet.
If there is a match for a transaction in a block, generate a merkle proof and send the proof with the transaction to the wallet.
Update the filter on matches.
When blocks are received, send the block header to the wallet.

This is generally how all SPV wallets work too, even ones that don't use BIP 37. They may not use bloom filters, but they use some kind of filter and rely on a full node to check things against the filter and then send along the things that match.
For privacy reasons, the filters do not match exactly. They have a false positive rate (but not a false negative rate) so some things are sent to the wallet that do not apply to it. The wallet just ignores those things.

Also, say a wallet program was loaded after a month of inactivity. Now the wallet needs to know the balance of its address? How does it go about reconstructing its balance after downloading the latest block headers?

It connects to a full node, sends it the filter to use, and then asks the node to send all of the transactions that match that filter that are in all blocks since block X where X is the latest block header the wallet has.

How does a light node know which block its transaction got included in?

Lightweight clients use Simplified Payment Verification (SPV).
The Bitcoin wiki says:

[SPV] clients connect to an arbitrary full node and download only the block headers. They verify the chain headers connect together correctly and that the difficulty is high enough. They then request transactions matching particular patterns from the remote node (ie, payments to your addresses), which provides copies of those transactions along with a Merkle branch linking them to the block in which they appeared. This exploits the Merkle tree structure to allow proof of inclusion without needing the full contents of the block.

Section 8 of Satoshi Nakamoto's Bitcoin white paper says

It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he’s convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it’s timestamped in. He can’t check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.

See also:

How do SPV get their transactions after being offline?
What is an SPV client?
SPV Wallets vs API Wallets - Pragmatic
How does an SPV node verify an unconfirmed transaction?
How does SPV prevent double spending of UTXO?
Thin client security

how does the full node know which block to search for the transaction in?
Does it persist all the accepted transactions? Or does it do a linear search across all blocks?

@pd176 that's an implementation detail that probably varies depending on who wrote the code used by that node.


text:
How to store private key in MySQL database?
I want to receive payments from Bitcoin on my web app, but I do not want to use corporate gateways (coinpayments, bitpay, etc), I'm wanting to make my own gateway. I do not know how best to do this but initially thought of generating the bitcoin address and storing the public/private key in MySQL after the payment was confirmed the system would use the private key and send the balance to an offline wallet.
How can I securely store the private keys that are generated for each payment in MySQL?
Let's say I do not want to leave the funds in these wallets, once I receive the system already sends the official wallet.

Storing private keys in an online server is not best practices (even if you quickly transfer to an offline wallet). Generally, you should not store private keys on an online device
Instead, if you use a BIP32 HD wallet architecture, you can just store an extended public key on your online server. This will allow you to generate receiving addresses on the fly, while generating (and securely storing) the private keys on an offline machine.

I do not understand the whole concept of BPIP32, it seems to be quite complex. For example, each request will have a single wallet to receive the funds, using the BIP32 it stores all the private keys of each address in a single parent key and I would just use the parent key to withdraw the coins and send it to an offline wallet? Sorry, it's a little confusing for me yet.

@viniciussvl I don't mean to be rude, but you'll need to take some time to read about BIP32 and its implementation, it isn't really possible to give a full synopsis in a short comment. There is lots of good info on this site alone. Think of it simply as a method of generating keypairs that is much easier to backup, and allows for better opsec. In regards to spending funds at a child key using a parent privkey (not possible), see the third part of this Q: https://bitcoin.stackexchange.com/questions/73376/a-few-questions-about-how-hd-wallet-works/73381?noredirect=1#comment92253_73381

Okay, I'll give it a look at it because it's too complex to understand. Thank you very much for your patience.

@viniciussvl happy to help :)  Though BIP32 may be a little more complex, it is worth learning if you are trying to build a legitimate system!

I wanted to develop something similar to Coinpayments, I already used it. Do you think they use the technology of HD wallets?

@viniciussvl I am not familiar with their system, sorry.

@viniciusscl - Look at https://github.com/libbitcoin/libbitcoin/wiki/Altcoin-Version-Mappings#7-bitcoin-btc-bip-3944-technology-examples and surrounding info.  Much safer to store public extended keys on a server.  Here is how a public key can be synthesized from private BIP 39 words: % echo "radar blur cabbage chef fix engine embark joy scheme fiction master release" | bx mnemonic-to-seed | bx hd-new | bx hd-private -d -i 44 | bx hd-private -d -i 0 | bx hd-public -d -i 0
xpub6DHi64TFkDPx2AH4q2ku3vX9LJYNpTis5tLrET8Sb9irp174eCkgtAnvBpyzQXgrtmF31Lrq4gTMGFUGcjJicMu9LdueVdqt6FZ2Wzcg8F

I understand how I can store the extended public keys in the online server to generate receiving addresses but what if I want to send money from one of these addresses? how do I go from an online http request to the offline server to sign the transaction and avoid exposing the pvt keys?

You might want to checkout BTCPay, which is a self-hosted payment gateway

https://alternativeto.net/software/btcpay-server/about/


text:
Diffrent transactions in different block sync problem
Consider that miner A and B both try to solve its block, A's block has transactions (T1,T2), B's block has transactions (T1,T3). A solved its block then synced the block to B. Does B will discard its block which contains T1 and continuely create a next block contains T3? and how to check T1 is confirmed but T3 not?

Once A solves the block containing T1 and the new block reaches B, B will cease to mine for (T1,T3). When B receives A's block, it will be validated. As part of this validation process, B will check each transaction in the block, and notice that T1 has been mined in that block.
B will then construct a new mining template, including T3, and possibly other transactions that were recently broadcasted, or previously didn't make the cut due to space constraints. Mining will then commence on this new template for B.


text:
Convert WIF to Witness PubKey Hash Address in Go
How can WIF be easily converted to WitnessPubKeyHash in Go?
We need to get the public key from WIF and than calculate witness program as ripemd160(sha256(compressed_pub_key)).
But is there a function in btcutil to convert the public key to witnessProg required by NewAddressWitnessPubKeyHash function:
func NewAddressWitnessPubKeyHash(witnessProg []byte, net *chaincfg.Params) (*AddressWitnessPubKeyHash, error)

There are 2 cases where the version byte in the witness program is either 0 or 1.
If the version byte is 0, you need a 20-byte HASH160 of the public key. Reference wiki.
witnessProg := btcutil.Hash160(w.SerializePubKey())
p2wpkh, err := btcutil.NewAddressWitnessPubKeyHash(witnessProg, chainParams)

But I am not really sure about the case where version byte is 1.
Edit: previous implementation was probably wrong, fixed after some more research.


text:
Can SPV clients offer "proof of absence" of a transaction?
So light SPV clients give the user the ability to obtain merkle proofs (from a full node) that a given transaction is included in a block. Is there some cryptographic mechanism by which an SPV client could obtain proof that a transaction (or type of transaction) is not included in a block, while still being relatively "light" (O(log(n), say)?
Asking for a layer 2 solution ;)

You could check if it's in the mempool (this means it hasn't been confirmed yet). But, are you talking about any arbitrary transaction that may or may not have been submitted to the network?

I'm talking about transactions included in a block - I want my SPV to be able to ask a full node to prove that no blocks contain, say, a transaction that has a given address in its inputs or outputs.

There is no known way to do this with the current consensus rules nor does it seem likely except via computationally expensive general ZKP.
The normal way to make compact proofs of non-membership is to have a hash tree which is ordered by the key you're looking to prove non-membership on.  The proof is just the two neighbors that are greater and lesser than the key in question.
To show non-membership in a block this with a general ZKP (like bulletproofs) you would have to write an arithmetic circuit that computes the hash root of a block, and also scans over transactions looking for the thing-of-interest.  If done using a bulletproof the proofs would be log in the size of the circuit, and take time to prove and verify linear in size... so they'd be somewhat slow but bandwidth efficient.

Client side filters (neutrino) allow you to check whether a certain transaction is included in a block. This can act as a proof of non-inclusion.
https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki
https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki
Note that this is not part of consensus, so nodes could lie to you. There won't be an SPV merkle proof connected to PoW, so perhaps it's not good enough for what you have in mind.


text:
where are the 21.co bitcoin tutorials?
I had a bunch of links for the 21.co bitcoin tutorials. It was quite extensive, and I thought I would start working on them for some day. The day has come, but I can't find the material.
They have rebranded the website so it became earn.com and I can't find the tutos anywhere on the web. I guess another good reason to dislike coinbase.
If you have info, or a mirror link, or whatever, I would be grateful.
Edit: The url https://earn.com/learn/ gives a 404 which is a sad thing.

It looks like they have been archived over at archive.org.

Thanks. It's already something, even though some pages redirect to a 404 earn.com page like this one: https://web.archive.org/web/20171031225351/https:/earn.com/learn/diy-bitcoin-computer-odroid-xu4/
Found some links though, I will try to keep them in one place.

Example link1: https://github.com/ChristopherA/Learning-Bitcoin-from-the-Command-Line


text:
Double transaction on same hash (transaction ID) - Loosing 0.01 btc each time
Each time I send some btc to another bitcoin wallet there is a second transaction on the same transaction ID (hash) and each times i am loosing around 75 USD.
You can see by yourself here;
https://www.blockchain.com/btc/address/1NrZWuS4J8MAqX63NHFuLrdmBYf6FttX29
Another weird fact is that on my bitcoin wallet software balance, it's not showing to balance I lost.
Any help would be very appreciated,
Thanks.

what wallet software are you using? And you mean .001 BTC? The only one that I could see was this one: 5f48a419f861ca157e938492a5a8550a85c4d93749cd7d2bcdb9822be6ee9b3b

Bitcoin Core Wallet from https://bitcoin.org/en/download
No, I really mean 0.01 BTC
https://www.blockchain.com/btc/tx/5f48a419f861ca157e938492a5a8550a85c4d93749cd7d2bcdb9822be6ee9b3b
https://www.blockchain.com/btc/tx/9d9659dc3633588757798eaf17b8fd19051619561b376384e528271a66df6633
https://www.blockchain.com/btc/tx/50595313b33a2ea0b0a1c2fba5f71a73d72414060d161563d659163930c0145d

Yeah it looks like change, and it's not .01BTC every time.

Please have a look on those transactions, you can clearly see 2 different wallets with 2 different transaction on the same transaction ID (hash)
https://www.blockchain.com/btc/tx/5f48a419f861ca157e938492a5a8550a85c4d93749cd7d2bcdb9822be6ee9b3b
https://www.blockchain.com/btc/tx/9d9659dc3633588757798eaf17b8fd19051619561b376384e528271a66df6633
https://www.blockchain.com/btc/tx/50595313b33a2ea0b0a1c2fba5f71a73d72414060d161563d659163930c0145d

@JohnSmith to clarify: you are confusing terms slightly, a 'wallet' is software that holds a collection of keys, and those keys let you spend bitcoins at addresses related to them. I believe what you are calling a 'transaction ID (hash)' is actually just a bitcoin address. Looking at the 3 txs you linked, I see three UTXOs from the same bitcoin address (1NrZW...) being spent to various addresses, with what appears to be a change address generated for each transaction. See the other replies for info on what a change address is. That should answer your main question.

See above link about How change works. Looking at this transaction 5f48a419f861ca157e938492a5a8550a85c4d93749cd7d2bcdb9822be6ee9b3b:
(Assuming) you tried to send .001 BTC to 1PqarrL2NAobkNbExtjBA1KEzXk7rwPfGQ, but there did not exist any unspent transaction outputs (UTXO) to satisfy that exact amount (plus tx fee). So your wallet chose to use the UTXO worth 0.01105895 BTC. It then sent the change (minus tx fee) back to your wallet in a separate output to 147FWjxpW9nYo5Z32qaHSoUZbVCNgsPGuL. The address for the change is different because it is based on a different public key (it is a hash of a public key, thus a different address), but is presumably still spendable by your wallet.

allright ! good to know, that's why my wallet software doesn't show the "lost" funds since there is NO lost funds. Thanks a lot for this explanation and I feel way better knowing that I haven't lost some digital gold hehe.


text:
How to protect the latest block in block chain be tampered?
We know for each block in block chain, it has the previous block header hash which make the block be tampered become difficult. If the block is tampered, then all blocks after this tampered block need to be tampered too.
However, how can we prevent latest block (last block in the chain) be tampered ? There is no next block follow it which means there is no header hash in next block.
Thanks in advance.

Recall that in order to be a valid block, it has to have a valid proof of work: the hash of the header has to be below the current target value (i.e. start with a sufficient number of zeros).  If you just alter something in the block (e.g. the destination of the coinbase transaction), its hash will change and almost certainly will no longer meet the proof-of-work target.  So you'll have to also find a nonce value which does result in a hash that meets the target.  This is just as much work as mining a new block from scratch and carries no particular benefit compared to regular mining.
If you succeed in doing so, then there will simply be two candidate blocks for the head of the block chain: the original one, and your new "tampered" version (whose hash will necessarily be different from that of the original one).  Miners will be free to choose either one to build their blocks on top of.  Soon, a consensus will be reached as to which one is part of the block chain and which one is an orphan.

Nate, are you saying if a hacker successfully creates the new block with an appropriate hash for the modified transaction, it is 50/50 as to whether the tampered one is kept or the original (depends on random chance of what the other nodes decide is correct)?

@Vik: Probably not literally 50/50.  In practice, most nodes will decide according to some deterministic criteria; usually, the one that they saw first. (This does have some randomness due to unpredictable propagation time.) But the protocol doesn't require this, and would have no way to enforce it even if it did, so in principle something else could happen.


text:
my passphrase doesn't work I cant sent anything on bitcoin core - wallet
my passphrase doesn't work I cant sent anything  on bitcoin core - wallet and I have $400.00 USD in bitcoins .. this is driving me crazy.. it was perfectly fine last Friday, now for the past 3 days I am not able to send or even change my passphrase ... this is ridiculous

I assume you’re looking for help? It’s not really clear what your exact question is. Are you sure you are using the correct password? Do you have a backup of the wallet (or a seed phrase)? Etc. The more info you provide, the better chance someone will be able to provide meaningful help.

Sorry, I am not able to change my passphrase .. i tried sending some bitcoins but it wanted my passphrase i typed it in and said it was the wrong one .... it was fine a couple of days ago

The wallet is encrypted ...

I have a bitcoin wallet and was trying to send it over to it from bitcoin core .. that is how I found out my password wasn't working ... I tried the btcrecover and no luck ... I am at my wits end ...

Without the accurate password or the recovery phrase for the sending wallet, you're out of luck.

If your wallet-encryption passphrase doesn't work,
first you should check that you are not using a passphrase for a different wallet, not using a recovery-phrase as a wallet-passphrase, don't accidentally have caps-lock on or something silly but easy to overlook. Try variations of the passphrase.
ultimately you must use the safe copy you made of  your 12/18/24 recovery seed words or the safe copy you made of your private key and create a new wallet to regain control of your bitcoin as.


text:
How are miners prevented from doing too much work?
I understand that scripts can be written within transactions that make the miners do some work.
How does Bitcoin ensure that scripts that make miners do too much work are prevented?

Yes, it does take a miner some amount of computational work to "execute" a script and verify that it allows the transaction to be spent.  In fact, not only miners, but every full node on the Bitcoin network has to execute these scripts.  However, there are measures to limit the cost of this.
Bitcoin scripts have no loops and so the amount of computation needed to execute a script is roughly proportional to its length.  In turn, miners demand transaction fees that are roughly proportional to the transaction's length (or size in bytes), so a long and relatively costly transaction will be more expensive for the creator.  A transaction with a long script would typically be non-standard and thus would not be relayed over the peer-to-peer network (though it could still be included in a block by a miner who received it some other way).  This limits the number of nodes who would ever see the transaction and thus would have to verify the script.
There is a final upper limit: no single transaction can be larger than the maximum size of a block (currently 1 MB).
(To clarify a semantic disagreement with amaclin's answer: in the case of pool mining, the script verification can be done once by the pool operator on behalf of the individual miners who contribute to the pool; then the individual miners do not have to do it themselves.  My answer here treats a pool conceptually as a single miner, since they are functionally equivalent from the point of view of the Bitcoin protocol.)