text:
Partially Signing multisig rawtransaction returns redeemScript/witnessScript does not match scriptPubKey
I want to partially sign a rawtransactions using bitcoind through RPC but I am really stuck almost at the end of the process when I try to sign my manually created raw transaction and I spent many hours trying to find the error but I do not understand it. I am going to replicate here all the steps I did.

First I create a 2-3 multisig address

$user1_pubkey = "03e33af80b92e4efd64852166d6126e10aafdcc741579c67c6aa9eb89080cebeb2";
$user2_pubkey = "02df4bf6a54f79b333b7796d2941de13b1755c00c09f4dbf696c7729aea2946210";
$user3_pubkey = $this->bitcoin->getaddressinfo("2Msqe8jLEReQpD4CYnRj29cAqQS8c81zidv")['pubkey'];
$keys[] = $user1_pubkey;
$keys[] = $user2_pubkey;
$keys[] = $user3_pubkey;
$multisig_address = $this->bitcoin->addmultisigaddress(2, $keys);

Returned values:

["address"]=>
    string(35) "2NBet88aY57CSYCkH7nXKb2Bxae4K3xdRBT"
    ["redeemScript"]=>
    string(210) "522103e33af80b92e4efd64852166d6126e10aafdcc741579c67c6aa9eb89080cebeb22102df4bf6a54f79b333b7796d2941de13b1755c00c09f4dbf696c7729aea29462102102c099a12b6cba679ad56d8e793847f422634bc84b42cb3fae0b00a6943f56921253ae"

I have sent two small transactions to the multisig address (one of 0.005 and another of 0.004)

ef669e71fb08a2dd7b9d2500a86d53ba75e41c3ab67b4ec58435904d87b749c4
8a9e837e94a639cd104631a29b57a86d55b5dc32b8372b7ec3bacdf777ba57e5

Now I retrieve all the information related to those txids:

$transaction1 = $this->bitcoin->getrawtransaction("ef669e71fb08a2dd7b9d2500a86d53ba75e41c3ab67b4ec58435904d87b749c4", true);
$transaction2 = $this->bitcoin->getrawtransaction("8a9e837e94a639cd104631a29b57a86d55b5dc32b8372b7ec3bacdf777ba57e5", true);

3.1. Result of previous variables:
$transaction1 =>

array(14) {
  ["txid"]=>
  string(64) "ef669e71fb08a2dd7b9d2500a86d53ba75e41c3ab67b4ec58435904d87b749c4"
  ["hash"]=>
  string(64) "e586e88456cef32c01820d94541296aab85d776d890d8879184b8e70344a6353"
  ["version"]=>
  int(2)
  ["size"]=>
  int(247)
  ["vsize"]=>
  int(166)
  ["weight"]=>
  int(661)
  ["locktime"]=>
  int(1891405)
  ["vin"]=>
  array(1) {
    [0]=>
    array(5) {
      ["txid"]=>
      string(64) "9d0c2b8203b1b8f63ac8a8dc17a0e48b36efceee43d38fde50a6b3c92f811830"
      ["vout"]=>
      int(0)
      ["scriptSig"]=>
      array(2) {
        ["asm"]=>
        string(44) "0014839c3b61637073d6aec4c74a5b2e8fe52fcc4d83"
        ["hex"]=>
        string(46) "160014839c3b61637073d6aec4c74a5b2e8fe52fcc4d83"
      }
      ["txinwitness"]=>
      array(2) {
        [0]=>
        string(142) "3044022055bbad9ea94df56180ded2760dd77b0fc959e633b459bc906e6bd4456f72c71302201d9430ac2ed9debc9508442484accac54021c990e8906ebbf7a6b205ec9e827101"
        [1]=>
        string(66) "0326ae8d30a90a6926b81718dfa07b0b5058636f9c86465a1c3f37b0322af023c8"
      }
      ["sequence"]=>
      int(4294967294)
    }
  }
  ["vout"]=>
  array(2) {
    [0]=>
    array(3) {
      ["value"]=>
      float(0.005)
      ["n"]=>
      int(0)
      ["scriptPubKey"]=>
      array(5) {
        ["asm"]=>
        string(60) "OP_HASH160 c9ebaa3be1c12351c9e07ea5758a68eb20ee5098 OP_EQUAL"
        ["hex"]=>
        string(46) "a914c9ebaa3be1c12351c9e07ea5758a68eb20ee509887"
        ["reqSigs"]=>
        int(1)
        ["type"]=>
        string(10) "scripthash"
        ["addresses"]=>
        array(1) {
          [0]=>
          string(35) "2NBet88aY57CSYCkH7nXKb2Bxae4K3xdRBT"
        }
      }
    }
    [1]=>
    array(3) {
      ["value"]=>
      float(0.01040373)
      ["n"]=>
      int(1)
      ["scriptPubKey"]=>
      array(5) {
        ["asm"]=>
        string(60) "OP_HASH160 301c49c04ede304bdef0ab48e2b365a9eef737e4 OP_EQUAL"
        ["hex"]=>
        string(46) "a914301c49c04ede304bdef0ab48e2b365a9eef737e487"
        ["reqSigs"]=>
        int(1)
        ["type"]=>
        string(10) "scripthash"
        ["addresses"]=>
        array(1) {
          [0]=>
          string(35) "2MwdcJyxRAxqQ4tf6TQSubcLMZd21MrTskx"
        }
      }
    }
  }
  ["hex"]=>
  string(494) "020000000001013018812fc9b3a650de8fd343eeceef368be4a017dca8c83af6b8b103822b0c9d0000000017160014839c3b61637073d6aec4c74a5b2e8fe52fcc4d83feffffff0220a107000000000017a914c9ebaa3be1c12351c9e07ea5758a68eb20ee509887f5df0f000000000017a914301c49c04ede304bdef0ab48e2b365a9eef737e48702473044022055bbad9ea94df56180ded2760dd77b0fc959e633b459bc906e6bd4456f72c71302201d9430ac2ed9debc9508442484accac54021c990e8906ebbf7a6b205ec9e827101210326ae8d30a90a6926b81718dfa07b0b5058636f9c86465a1c3f37b0322af023c84ddc1c00"
  ["blockhash"]=>
  string(64) "00000000b1c75e4431f9c23a75779c964fa51cd714f9703781670f1a2c50a8c7"
  ["confirmations"]=>
  int(388)
  ["time"]=>
  int(1605141275)
  ["blocktime"]=>
  int(1605141275)
}

$transaction2 =>

array(14) {
  ["txid"]=>
  string(64) "8a9e837e94a639cd104631a29b57a86d55b5dc32b8372b7ec3bacdf777ba57e5"
  ["hash"]=>
  string(64) "0e8dfd742d3ea5f12ee7c033112f5e6f585b41e317b3f9d3fef61db4200c4bbd"
  ["version"]=>
  int(2)
  ["size"]=>
  int(247)
  ["vsize"]=>
  int(166)
  ["weight"]=>
  int(661)
  ["locktime"]=>
  int(1891405)
  ["vin"]=>
  array(1) {
    [0]=>
    array(5) {
      ["txid"]=>
      string(64) "ef669e71fb08a2dd7b9d2500a86d53ba75e41c3ab67b4ec58435904d87b749c4"
      ["vout"]=>
      int(1)
      ["scriptSig"]=>
      array(2) {
        ["asm"]=>
        string(44) "0014c7f49ae39660b15632f46a3c69a67ccb4de7dc20"
        ["hex"]=>
        string(46) "160014c7f49ae39660b15632f46a3c69a67ccb4de7dc20"
      }
      ["txinwitness"]=>
      array(2) {
        [0]=>
        string(142) "304402207cc7558274cd9458c44bf7554d0b049bba1388cd82057b3f8d0786bc28690aad022057eea44e01ff11c608e254a844b620f428fb515db6ef33cd199c57d3008ce89c01"
        [1]=>
        string(66) "0303c01176f2db9efaa18e169e0ea7da87784208e05fcb1e0258ccb834805ed02d"
      }
      ["sequence"]=>
      int(4294967294)
    }
  }
  ["vout"]=>
  array(2) {
    [0]=>
    array(3) {
      ["value"]=>
      float(0.004)
      ["n"]=>
      int(0)
      ["scriptPubKey"]=>
      array(5) {
        ["asm"]=>
        string(60) "OP_HASH160 c9ebaa3be1c12351c9e07ea5758a68eb20ee5098 OP_EQUAL"
        ["hex"]=>
        string(46) "a914c9ebaa3be1c12351c9e07ea5758a68eb20ee509887"
        ["reqSigs"]=>
        int(1)
        ["type"]=>
        string(10) "scripthash"
        ["addresses"]=>
        array(1) {
          [0]=>
          string(35) "2NBet88aY57CSYCkH7nXKb2Bxae4K3xdRBT"
        }
      }
    }
    [1]=>
    array(3) {
      ["value"]=>
      float(0.00640207)
      ["n"]=>
      int(1)
      ["scriptPubKey"]=>
      array(5) {
        ["asm"]=>
        string(60) "OP_HASH160 0f670955696f3835ef9204dad881b1c9f3002cc7 OP_EQUAL"
        ["hex"]=>
        string(46) "a9140f670955696f3835ef9204dad881b1c9f3002cc787"
        ["reqSigs"]=>
        int(1)
        ["type"]=>
        string(10) "scripthash"
        ["addresses"]=>
        array(1) {
          [0]=>
          string(35) "2MtefZG3K2Zs38dYntJwJKg1WqSEqNoW9sF"
        }
      }
    }
  }
  ["hex"]=>
  string(494) "02000000000101c449b7874d903584c54e7bb63a1ce475ba536da800259d7bdda208fb719e66ef0100000017160014c7f49ae39660b15632f46a3c69a67ccb4de7dc20feffffff02801a06000000000017a914c9ebaa3be1c12351c9e07ea5758a68eb20ee509887cfc409000000000017a9140f670955696f3835ef9204dad881b1c9f3002cc7870247304402207cc7558274cd9458c44bf7554d0b049bba1388cd82057b3f8d0786bc28690aad022057eea44e01ff11c608e254a844b620f428fb515db6ef33cd199c57d3008ce89c01210303c01176f2db9efaa18e169e0ea7da87784208e05fcb1e0258ccb834805ed02d4ddc1c00"
  ["blockhash"]=>
  string(64) "00000000b1c75e4431f9c23a75779c964fa51cd714f9703781670f1a2c50a8c7"
  ["confirmations"]=>
  int(388)
  ["time"]=>
  int(1605141275)
  ["blocktime"]=>
  int(1605141275)
}

I want to create a raw transaction to spend both utxos and I want to spent it in two different address. So having in mind the fee for the transaction I proceed to create manually the transaction.

        $fee = number_format(floatval($this->bitcoin->estimateSmartFee(6)['feerate'])/5, 8);
        $raw_amount = 0.00000000;
        $txids = [];
        $vouts = [];
        $amounts = [];
        $scriptPubs = [];
        for($i=0; $i<count($transactions); $i++){
            $total_amount+=$transactions[$i]["vout"][0]["value"];
            $txids[] = $transactions[$i]["txid"];
            $vouts[] = $transactions[$i]["vout"][0]["n"];
            $amounts[] = $transactions[$i]["vout"][0]["value"];
            $scriptPubs[] = $transactions[$i]["vout"][0]["scriptPubKey"]["hex"];
        }

        $inputs = '[';
        for($i=0; $i<count($vouts); $i++){
            $inputs.='{
                        "txid": "'.$txids[$i].'",
                        "vout": '.$vouts[$i].'
                      }';
            if($i+1!=count($vouts)){
                $inputs.=',';
            }
        }
        $inputs.=']';

        $minus_fee = $raw_amount-floatval($fee);
        $amount1 = $minus_fee*0.6;
        $amount2 = $minus_fee*0.4;

        $address1 = "tb1qhjcqny2rvaqd7q0700m968e3vuqctmuhhyk9fk";
        $address2 = "tb1q2nrysxf8nwxv8euwtu470wgjruw25guxkal3wd";
        $outputs = '{
                      "'.$address1.'": '.$amount1.',
                      "'.$address2.'": '.$amount2.'
                    }';

        $raw_transaction = $this->bitcoin->createrawtransaction(json_decode($inputs), json_decode($outputs));

4.1. Result of $raw_transaction is the following:
0200000002c449b7874d903584c54e7bb63a1ce475ba536da800259d7bdda208fb719e66ef0000000000ffffffffe557ba77f7cdbac37e2b37b832dcb5556da8579ba2314610cd39a6947e839e8a0000000000ffffffff02e83c080000000000160014bcb00991436740df01fe7bf65d1f31670185ef97f07d050000000000160014b92b9f7f7bf6e4e1cdd73d3d23a1dbc98aa57d4e00000000

I decode $raw_transaction

$decoded = $this->bitcoin->decoderawtransaction($raw_transaction);

Content of $decoded:
array(9) {
  ["txid"]=>
  string(64) "ba11b2caf11d79c1f4bc349f40895c380218e9ab91ec4c1d52aaee8284749549"
  ["hash"]=>
  string(64) "ba11b2caf11d79c1f4bc349f40895c380218e9ab91ec4c1d52aaee8284749549"
  ["version"]=>
  int(2)
  ["size"]=>
  int(154)
  ["vsize"]=>
  int(154)
  ["weight"]=>
  int(616)
  ["locktime"]=>
  int(0)
  ["vin"]=>
  array(2) {
    [0]=>
    array(4) {
      ["txid"]=>
      string(64) "ef669e71fb08a2dd7b9d2500a86d53ba75e41c3ab67b4ec58435904d87b749c4"
      ["vout"]=>
      int(0)
      ["scriptSig"]=>
      array(2) {
        ["asm"]=>
        string(0) ""
        ["hex"]=>
        string(0) ""
      }
      ["sequence"]=>
      int(4294967295)
    }
    [1]=>
    array(4) {
      ["txid"]=>
      string(64) "8a9e837e94a639cd104631a29b57a86d55b5dc32b8372b7ec3bacdf777ba57e5"
      ["vout"]=>
      int(0)
      ["scriptSig"]=>
      array(2) {
        ["asm"]=>
        string(0) ""
        ["hex"]=>
        string(0) ""
      }
      ["sequence"]=>
      int(4294967295)
    }
  }
  ["vout"]=>
  array(2) {
    [0]=>
    array(3) {
      ["value"]=>
      float(0.0053988)
      ["n"]=>
      int(0)
      ["scriptPubKey"]=>
      array(5) {
        ["asm"]=>
        string(42) "0 bcb00991436740df01fe7bf65d1f31670185ef97"
        ["hex"]=>
        string(44) "0014bcb00991436740df01fe7bf65d1f31670185ef97"
        ["reqSigs"]=>
        int(1)
        ["type"]=>
        string(18) "witness_v0_keyhash"
        ["addresses"]=>
        array(1) {
          [0]=>
          string(42) "tb1qhjcqny2rvaqd7q0700m968e3vuqctmuhhyk9fk"
        }
      }
    }
    [1]=>
    array(3) {
      ["value"]=>
      float(0.0035992)
      ["n"]=>
      int(1)
      ["scriptPubKey"]=>
      array(5) {
        ["asm"]=>
        string(42) "0 b92b9f7f7bf6e4e1cdd73d3d23a1dbc98aa57d4e"
        ["hex"]=>
        string(44) "0014b92b9f7f7bf6e4e1cdd73d3d23a1dbc98aa57d4e"
        ["reqSigs"]=>
        int(1)
        ["type"]=>
        string(18) "witness_v0_keyhash"
        ["addresses"]=>
        array(1) {
          [0]=>
          string(42) "tb1qhy4e7lmm7mjwrnwh857j8gwmex922l2wwc830y"
        }
      }
    }
  }
}

Now I proceed to partially sign the previous created transaction.

        $private_key = $this->bitcoin->dumpprivkey("2Msqe8jLEReQpD4CYnRj29cAqQS8c81zidv"); // cS6e5CojfNy2ELWcsB4tLFVQV9wSSQUw1PU4YrSwRSjYLaC8ikrU
        $redeemScript = "522103e33af80b92e4efd64852166d6126e10aafdcc741579c67c6aa9eb89080cebeb22102df4bf6a54f79b333b7796d2941de13b1755c00c09f4dbf696c7729aea29462102102c099a12b6cba679ad56d8e793847f422634bc84b42cb3fae0b00a6943f56921253ae";
        $vin = $raw_transaction["vin"];
        $vout = $raw_transaction["vout"];

        $prevtxs = '[';
        for($i=0; $i<count($txids); $i++){
            $prevtxs .= '{
                    "txid": "'.$txids[$i].'",
                    "vout": '.$vouts[$i].',
                    "scriptPubKey": "'.$scriptPubs[$i].'",
                    "redeemScript": "'.$redeemScript.'",
                    "amount": '.$amounts[$i].'
                  }';
            if($i+1!=count($txids)){
                $json2.=',';
            }
        }
        $prevtxs.=']';

        $partially_signed = $this->bitcoin->signrawtransactionwithkey($raw_transaction, json_decode($private_key), json_decode($prevtxs));

And in the previous step is where the process fails. The transaction is not signed and the bitcoind returns this error:

redeemScript/witnessScript does not match scriptPubKey

I am using bitcoin testnet to test it and I think that I added all the information. If someone knows where it is the mistake, please let me know. I searched information to fix it but I could not find a solution for my issue.
Edited:
I followed the next tutorial where I could notice that I was using the wrong scriptpub and I retrieved funding inputs using getrawtransaction passing the second argument (true) to get the decoded transaction. And well, now the previous error is gone but now it throws a new error: redeemScript/witnessScript does not match scriptPubKey
Thanks

Your redeem script hash should be:

RIPEMD160(SHA256(0x522103e33af80b92e4efd64852166d6126e10aafdcc741579c67c6aa9eb89080cebeb22102df4bf6a54f79b333b7796d2941de13b1755c00c09f4dbf696c7729aea29462102102c099a12b6cba679ad56d8e793847f422634bc84b42cb3fae0b00a6943f56921253ae))
= 0bf37781383277cbb4e544c402f5265a51f4d828

Which results this address:
2MtLR5mKgWRZBYtCYiSuaKpTUSuney9Cg2V

However you somehow end up with this hash:

c9ebaa3be1c12351c9e07ea5758a68eb20ee5098

Which results this address:
2NBet88aY57CSYCkH7nXKb2Bxae4K3xdRBT

Thanks a lot for your answer! I did not know that I should hash the redeem script, so I am trying to replicate the steps you followed: hash('ripemd160', hash('sha256', '0x522103e33af80b92e4efd64852166d6126e10aafdcc741579c67c6aa9eb89080cebeb22102df4bf6a54f79b333b7796d2941de13b1755c00c09f4dbf696c7729aea29462102102c099a12b6cba679ad56d8e793847f422634bc84b42cb3fae0b00a6943f56921253ae')) but it returned ) 3ad9a694cd5881032106e839f834600141b533e3) instead of your hash. I am using PHP but I do not think that it is my problem. Any idea?

About this hash c9ebaa3be1c12351c9e07ea5758a68eb20ee5098 and the address 2NBet88aY57CSYCkH7nXKb2Bxae4K3xdRBT it seems that it comes from the information from trannsactions in the multisig address

"3ad9a694cd5881032106e839f834600141b533e3" is the result of string message digest. Set "raw_output" true in order to calculate hex message digest. https://www.php.net/manual/en/function.hash.php

Sorry for disturbing you again but I still do not see it. First I followed your advice and I enabled raw_out which gave me the binary output, then I converted it to hex: bin2hex(hash('ripemd160', hash('sha256', '0x522103e33af80b92e4efd64852166d6126e10aafdcc741579c67c6aa9eb89080cebeb22102df4bf6a54f79b333b7796d2941de13b1755c00c09f4dbf696c7729aea29462102102c099a12b6cba679ad56d8e793847f422634bc84b42cb3fae0b00a6943f56921253ae', true), true)); but it did not return the desired value, I also tried adding and removing "0x" from the redeen script but it did not work.

And I tried all combinations with sha256 using raw_out and the other not etc On the other hand, I replaced my current redeemscript value for the one that you gave me 0bf37781383277cbb4e544c402f5265a51f4d828 but I still get the same error

Try:
hash('ripemd160', hex2bin(hash('sha256', hex2bin('522103e33af80b92e4efd64852166d6126e10aafdcc741579c67c6aa9eb89080cebeb22102df4bf6a54f79b333b7796d2941de13b1755c00c09f4dbf696c7729aea29462102102c099a12b6cba679ad56d8e793847f422634bc84b42cb3fae0b00a6943f56921253ae'))));

Perfect! It returns the same hash you posted! :) But unfortunately when I pass the new hash as redeemscript to signtransaction function it returns the same error. I just followed the same process that I described here, but just changing the content of $redeemScript from 522103e33af80b92e4efd64852166d6126e10aafdcc741579c67c6aa9eb89080cebeb22102df4bf6a54f79b333b7796d2941de13b1755c00c09f4dbf696c7729aea29462102102c099a12b6cba679ad56d8e793847f422634bc84b42cb3fae0b00a6943f56921253ae to 0bf37781383277cbb4e544c402f5265a51f4d828

2MtLR5mKgWRZBYtCYiSuaKpTUSuney9Cg2V is your new address which is derived from scriptHash 0x0bf37781383277cbb4e544c402f5265a51f4d8289. Go all the way back to step 2 and send 0.005 & 0.004 to 2MtLR5mKgWRZBYtCYiSuaKpTUSuney9Cg2V. scriptPubKey of those transactions will be both OP_HASH160 0bf37781383277cbb4e544c402f5265a51f4d828 OP_EQUAL.
Retrieve those txids like you did in step 3 to construct new spending transaction. Spending transaction will have two inputs. One unlocking 0.005 BTC, another unlocking 0.004 BTC. You need to include corresponding scriptSigs of each input that fulfils the unlocking conditions. Your unlocking condition was 2-3 multisig, so your scriptSig should look like:
OP_0 <First Signature> <Second Signature> < OP_2 <First PublicKey> <Second PublicKey> <Third PublicKey> OP_3 OP_CHECKMULTISIG >

OP_0 is encoded as 0x00 in hex.

Say your first DER-encoded signature is 72-bytes, plus one-byte hash code type at the end, plus one-byte length prefix at the beginning is the following:

49 30460221AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0221BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB 01

Say your second DER-encoded signature is also 72-bytes, plus one-byte hash code type at the end, plus one-byte length prefix at the beginning is the following:

49
30460221CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC0221DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
01

< OP_2 <First PublicKey> <Second PublicKey> <Third PublicKey> OP_3 OP_CHECKMULTISIG > plus one-byte length  prefix is encoded in hex:

69
522103e33af80b92e4efd64852166d6126e10aafdcc741579c67c6aa9eb89080cebeb22102df4bf6a54f79b333b7796d2941de13b1755c00c09f4dbf696c7729aea29462102102c099a12b6cba679ad56d8e793847f422634bc84b42cb3fae0b00a6943f56921253ae

Your scriptSig in hex will look like:

0x004930460221AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0221BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB014930460221CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC0221DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD0169522103e33af80b92e4efd64852166d6126e10aafdcc741579c67c6aa9eb89080cebeb22102df4bf6a54f79b333b7796d2941de13b1755c00c09f4dbf696c7729aea29462102102c099a12b6cba679ad56d8e793847f422634bc84b42cb3fae0b00a6943f56921253ae

Construct scriptSig for the other input as well. You will need to customise your php code in order to achieve all this.

Well, again thanks for taking the time to put a detailed reply. I edited my question because I followed a tutorial (I added the link at the end) where it explains how to achieve my desired result without calculating manually scripts, I found a couple of errors, the redeemscript is properly calculated now but when I try to sign the transaction it says that redeemscript/witnessscript does not match scriptPubKey... Also being honest it is being hard to follow the process using bitcoin script and DER encoding as I am new to this, but I have been reading all day about it from official website

By the way, do you have any email or other external way to contact you? If you accept donations I would like to send you a donation once I have it working

You can reach me at burak@credentialsapp.org


text:
Function combinerawtransaction is not working
I have multiple partially signed transactions that I want to combine into one transaction. All those transactions were signed using the same key so it should be possible to combine all those partial signed into one combined transaction that can be signed and broadcasted at once using one key. According with bitcoin's rpc function combinerawtransaction is the proper to be used in my case but that function is not working because instead of combining all partial signed transaction into one is returning only the first partial signed transaction (it does not matter the order of the array, it will return always the first element)
Here you have the way I am trying to combine two partial signed address:
bitcoin-cli combinerawtransaction '["020000000001014a05cf2073d4ee6aa61256159e421d9f12291c44fc9607d99a4045ab192a580a01000000232200209acb3925f27bec7d8ac16b49705f6d47d5b87d48dc8571d3f49b10dcc7d89051ffffffff037cb002000000000016001488427232a9085b4ab6c334c6115725765864a6ad521d000000000000160014c2fe1292769b585b91fb8b045c651d79398589cc540700000000000016001454c64819279b8cc3e78e5f2be7b9121f1caa2386040047304402207abf6df0650b8723677d493b182e742a8dddd89ad1ee8eaa1c65a9b559841ecb022052fe5bcad01702e0e73c3b34cbfef957ba8e4744d614104f5d8fbc3d57cad4ce010069522103f6de61c401c947aad006ba9dbfdaad795e77be06972a3fb7308e70049d4026db2103e33af80b92e4efd64852166d6126e10aafdcc741579c67c6aa9eb89080cebeb221029791c6e3f0dc5bfa63db3f5aa0066badd6c5608d2a75394124d14df78795178153ae00000000", "02000000000101419e71a8980f8b86890a249e69bc9461f677dbefe4c856eb38baa361f0121d070000000023220020a8c4e11c15bcc878d57238016fe896c586508c913e0b300d80fa9409b031efb7ffffffff037cb002000000000016001488427232a9085b4ab6c334c6115725765864a6ad521d000000000000160014c2fe1292769b585b91fb8b045c651d79398589cc540700000000000016001454c64819279b8cc3e78e5f2be7b9121f1caa23860400473044022061b31eb92fb0555d368c2349ef9584df89bfc573a37acfd0bbf2de18d6cb51420220785706c33d3b7b735e434decddf1520ce687b168d17b40527da2712a3634f42f010069522103f6de61c401c947aad006ba9dbfdaad795e77be06972a3fb7308e70049d4026db2103e33af80b92e4efd64852166d6126e10aafdcc741579c67c6aa9eb89080cebeb221027152e86c82d162b47684a52cd9e74ed57b9fc2295531d8da6a560a7a602357fc53ae00000000"]'

The above command is executed without any errors and returns the following transaction:
02000000000101419e71a8980f8b86890a249e69bc9461f677dbefe4c856eb38baa361f0121d070000000023220020a8c4e11c15bcc878d57238016fe896c586508c913e0b300d80fa9409b031efb7ffffffff037cb002000000000016001488427232a9085b4ab6c334c6115725765864a6ad521d000000000000160014c2fe1292769b585b91fb8b045c651d79398589cc540700000000000016001454c64819279b8cc3e78e5f2be7b9121f1caa23860400473044022061b31eb92fb0555d368c2349ef9584df89bfc573a37acfd0bbf2de18d6cb51420220785706c33d3b7b735e434decddf1520ce687b168d17b40527da2712a3634f42f010069522103f6de61c401c947aad006ba9dbfdaad795e77be06972a3fb7308e70049d4026db2103e33af80b92e4efd64852166d6126e10aafdcc741579c67c6aa9eb89080cebeb221027152e86c82d162b47684a52cd9e74ed57b9fc2295531d8da6a560a7a602357fc53ae00000000

And that raw transaction is exactly the first raw transaction passed in the array to combinerawtransaction's function and returned unmodified
I am a bit lost because I do not know what is happening to not having both transactions combined. Also, I am using bitcoin testnet, I can sign and broadcast those transactions individually but I cannot combine them into one, any help will be appreciated
Steps to reproduce how I created those raw transactions:

First of all I create a 2-3 multisig address:

$participants = [];
$participants[] = "03e33af80b92e4efd64852166d6126e10aafdcc741579c67c6aa9eb89080cebeb2";//pubkey1
$participants[] = "03f6de61c401c947aad006ba9dbfdaad795e77be06972a3fb7308e70049d4026db";//pubkey2
$participants[] = "029791c6e3f0dc5bfa63db3f5aa0066badd6c5608d2a75394124d14df787951781";//pubkey3

$res = $this->bitcoin->addmultisigaddress($participants, $pubkey_str);
$multisig_address = $res["address"];
$redeemScript = $res["redeemScript"];
$this->bitcoin->importaddress($multisig_address, "", false); // I import the multisig address so I can check incoming transactions

The above code is to create the multisig address associated to the first raw transaction, to create the multisig address associated to the second transaction repeat same steps but changing the third pubkey for this 027152e86c82d162b47684a52cd9e74ed57b9fc2295531d8da6a560a7a602357fc

Once I created both multisig address I proceed to send some funds to both multisig address. You can check both txids: 0a582a19ab45409ad90796fc441c29129f1d429e155612a66aeed47320cf054aand 071d12f061a3ba38eb56c8e4efdb77f66194bc699e240a89868b0f98a8719e41(respectively). To fund both addresses I just opened a testnet account using electrum and spend some btc testnet.

Now the next step is to create partial signed transactions (using third pubkeys). For that I need to check unspent outputs and create a raw transaction based on that data.

$res = $this->bitcoin->listunspent(2, 9999999, json_decode('["'.$multisig_address.'"]'));
$fee = 0.00002;
$total_amount = 0.00;
$total_amount = 0.00;
$txids = [];
$vouts = [];
$amounts = [];
$scriptPubs = [];
for($i=0; $i<count($transactions); $i++){
    $txids[] = $transactions[$i]["txid"];
    $total_amount+=$transactions[$i]["amount"];
    $vouts[] = $transactions[$i]["vout"];
    $amounts[] = $transactions[$i]["amount"];
    $scriptPubs[] = $transactions[$i]["scriptPubKey"];
}

$amount1 = 0.00176252;
$amount2 = 0.00007506;
$amount3 = 0.00001876;

$address1 = "tb1q3pp8yv4fppd54dkrxnrpz4e9wevxff4d2v3r6e";
$address2 = "tb1qctlp9ynkndv9hy0m3vz9cega0yuctzwv6z273w";
$address3 = "tb1q2nrysxf8nwxv8euwtu470wgjruw25guxkal3wd";

$inputs = '[';
for($j=0; $j<count($vouts); $j++){
    $inputs.='{
                        "txid": "'.$txids[$j].'",
                        "vout": '.$vouts[$j].'
                      }';
    if($j+1!=count($vouts)){
        $inputs.=',';
    }
}
$inputs.=']';

$outputs = '{"'.$address1.'": '.$amount1.', "'.$address2.'": '.$amount2.', "'.$address3.'": '.$amount3.'}';

$rawtransaction = $this->bitcoin->createrawtransaction(json_decode($inputs), json_decode($outputs));

$prevtxs = '[';
for($j=0; $j<count($txids); $j++){
    $prevtxs .= '{
                    "txid": "'.$txids[$j].'",
                    "vout": '.$vouts[$j].',
                    "scriptPubKey": "'.$scriptPubs[$j].'",
                    "redeemScript": "'.$redeemScript.'",
                    "amount": '.$amounts[$j].'
                  }';
    if($j+1!=count($txids)){
        $prevtxs.=',';
    }
}
$prevtxs.=']';

$private_key = $this->dumpKey($pubkey3_privkey); // replace this value with cTe9h3HqgqC7wzUsVVw7hgoPkBNLUuChZNB7aKFsSYeTi5MYcABX or cQon9MgHPoAj3wBU8ne2BVaThTuRkXvb9FUFyQdjePUrYWTjdCaE
        $partially_signed = $this->signrawtransactionwithkey($rawtransaction, json_decode('["'.$private_key.'"]'), json_decode($prevtxs))["hex"]; // and in this step I get the transaction hex string

In case you have a bitcoin node with testnet blockchain you can verify that pubkey1 (cPkPnf3qhf1AALzroHixPTYBq2cLQ9HLs9fvkTsS82ccBGZDHFaV) or pubkey2 (cQmzvzai8ft574ErkUH7nPVcP2SbR7xaPurKigWGPYVbhfMop9ia) can sign partial signed raw transactions

@Prayank Allow me some minutes and I will upload all detailed steps

@Prayank Done! I was testing it using a small php script but still I think that the code is enough clear, also I tried to keep it as simple as possible without removing any information. If you see that I am missing something to combine those transactions let me know :) Thanks!

The issue here is that the two transactions are different, and combinerawtransaction does not operate on different transactions (it apparently just silently does nothing). It sounds like you expect combinerawtransaction to take two separate transactions and create a new one which has the inputs and outputs of both transactions. (or perhaps take two transaction with the same outputs but different inputs and produce a transaction with the combined inputs and same outputs). However that is not what it does. Instead it actually takes the same transaction (i.e. same inputs and outputs) and merges the signatures for the same inputs together.
It is not possible to do what you want because the signatures commit to the particular inputs and outputs of that transaction. Once you try to join a transaction with another one, those signatures become invalid and the whole transaction would need to be re-signed.

Thanks for your reply! Sorry if I am asking stupid obvious questions but I am learning how to create and handle raw transactions. Now thanks your explanation I understand that function is merging signatures becoming them invalid. My intention is to make an easier multisig process between different parties, if you need to sign several multisig transactions I would like to make that you can sign several transactions at once (so you do not need to sign one transaction and broadcast it, repeating the process for all your transactions). Is that possible? Maybe using createpsbt and combinepsbt?

Or should I repeat the whole above process but including all inputs and outputs in the same transaction?

You have to include all inputs and outputs in the same transaction when you create it.

Ok thanks! It worked combining all inputs and outputs into one transaction!

source: Stack Exchange

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

sort: votes


text:
What's up with the block size of block# 295182?
I found an anomaly in the block size data: block 295182. This one seems to have a way higher payload. What happened there?

Or is this there something wrong with my parsing? This file block does appear to be at the end of a .dat file.
Here's the code I used:
import struct
import matplotlib.pyplot as plt

blockchain_path = 'mypath/blocks'

def get_block_path(index):
    file = 'blk' + str(index).zfill(5) + '.dat'
    return blockchain_path + '/' + file

def plot(x, y, title, xlabel, ylabel):
    plt.scatter(x, y)
    plt.suptitle(title, fontsize=20)
    plt.xlabel(xlabel)
    plt.ylabel(ylabel)
    plt.show()

def uint4(stream):
    return struct.unpack('I', stream.read(4))[0]

def blocks_remaining(f, i):
    cur = f.tell()
    try:
        uint4(f)
        f.seek(cur)
        return True
    except:
        print("End of file: blk" + str(i).zfill(5) + '.dat')
        return False

BlockHeight, BlockSize = ([] for i in range(2))
cur_block_height = -1

for i in range(0, 100):
    block_path = get_block_path(i)
    #stay with single file
    f = open(block_path, 'rb', buffering=16 * 1024 * 1024)

  #loop blocks in file
    while blocks_remaining(f, i):
        cur_block_height += 1
        magic_num = uint4(f)
        block_size = uint4(f)

        print(cur_block_height, f.tell(), magic_num, block_size)

        #append data
        BlockHeight.append(cur_block_height)
        BlockSize.append(block_size)

        #skip to next block
        f.read(block_size)

plot(BlockHeight, BlockSize, 'Block Size', 'block height', 'bytes')

Coud their be some suffix to the block files after the payload of the last block of a dat file?

block 295182 is 149,287 byte as you can see here https://blockchair.com/bitcoin/block/000000000000000043759025a93fbf64c13f581fdac9e678b5bbcf5b62d42790?_type=block&_search=header

@leevancleef I'm not trusting, just verifying. I have other values. If you claim theirs is right, then where is my mistake?

you can check it on your node with "bitcoin-cli getblock 000000000000000043759025a93fbf64c13f581fdac9e678b5bbcf5b62d42790". if I knew where your mistake is, I would have answered :)

If I'm reading your graph correctly, your code found a block that is around 2.4 Gigabytes in size. That's too large for a valid Bitcoin block. You might want to validate magic_num == 0xD9B4BEF9 and block_size <= 1M in your code

The magic numbers line up, so the parsing seems to work fine. I guess there might be an issue with the end of file situation. Though also for blocks within blk00000.dat I find different values for the block size against bitcoincli and blockchain.com. Very strange as I perfectly parse out the magic number each time and the block size is right after it...

Can you post a sample of the actual block sizes you are finding? Particularly for the outlier block that you have found too.

@AndrewChow You're right! The magic number is screwed up there! Still I get different values in blocksizes between mine and bitcoin-cli. Investigating it now.

Apparently from block 353 the data is off. I just checked the merkleroots and starting from that block the data is not correct.

From this point my blockheight + 30 is the right block. Could it be that the data in my blk files is not sorted on height? Because now I assign height as they come in linear order.

Ok. I assumed blocks were ordered by height in the data. This caused the problem.

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


text:
How to ask crypto exchange to seize scammed funds traced to one of their exchange wallets?
There are now blockchain explorers that allow popular wallet addresses like crypto exchange aggregate wallets to be labeled with "Binance 1" or "Binance 4" for instance.
If you trace scammed funds to a "Binance 1" aggregated wallet, what is the procedure for asking the crypto exchange, Binance, to investigate the account owner for fraud? The likelihood for their support team to comply with your request? Should one seek legal counsel and the feds first?

Even though its your own question, editing it to ask a completely different question, though related, undermines the purpose of this website: creating good answers to common questions with long term usefulness. The answers to the original question no longer apply since your change. I would have just asked a separate question and maybe added a link back to this, in its original state.

Possibly in it's activity, exchanges have quite unique transaction footprints and this can be used to make an inference. It's not an easy process however and there is nothing in the bitcoin address itself that indicates which exchange etc. was used to create it.

what are some examples of exchanges' unique transaction footprints


text:
How to automate bitcoin wallet to send return payments to website subscribers?
When a .onion website sells subscription log-in accounts, they ask for subscription payment and say that a return payment will be received immediately after, containing the payment code for creating a user account.
For example, the subscription might cost 0.001 BTC, so if the new subscriber pays that, and she receives 0.0002713 BTC afterwards as a return payment, then the new user can create their account by entering the following fields in the registration form:

Username
Password
Payment Code: 2713

How can a bitcoin wallet even be programmed to automatically respond to incoming payments with a return payment?
and further, disguise the payment code in the return payment amount such that the form will associate a unique code to each new user (unless maybe they are just fixing the payment code to be identical for all users)

Why would you want to pay money to send confirmation codes to people? Why not just associate each of your recipient addresses with a particular user account, or make the payment confirmation code the user's transaction ID, or something?

Ok how can that be done

Generate an address, then store it in your database as belonging to a user account. Check the address for payment, and when payment is received, mark the account paid. Or, if you want to go the payment code route: generate the address, then when the user submits a transaction ID, check that that transaction ID pays you the correct amount and hasn't been submitted before, then mark the account paid.

How can a bitcoin wallet even be programmed to automatically respond to incoming payments with a return payment?

What is a bitcoin wallet, exactly? It can be just about anything that is programmed to create keys, check UTXOs and build/sign transactions... A bitcoin wallet can be programmed to do just about anything.
Your question is broad... You need to program it yourself. Build a database to keep track of addresses and payment codes and whatever else then build your site to interact with your database and your wallet, or build your own wallet.

How can a bitcoin wallet be programmed to respond to incoming payments with its own return payments? never seen that before, given that manual confirmation of payments is the norm. can you link a tutorial? "building a database" myself completely avoids the question about "automation"

@user610620 You still have to build automation yourself, via maybe setting up a database etc. The process of setting your automation up is not itself automated :)

Ok how can it be done


text:
How to get a seed wallet in bitcoin-cli?
how does one get a seed wallet in bitcoin_cli ?
I use a bitcoin-cli sethdseed command but get the error :invalid private key

Bitcoin core wallets are deterministic by default i.e. all private keys are derived from a seed. However you can make sure that your wallet is deterministic by running the getwalletinfo command. In the response hdseedid  will only be set if it's an HD wallet.
Bitcoin core does not encode the seed as a mnemonic of english words. To create a backup of the wallet use the backupwallet command.

HI If I want to change it, how do I do it and what do you mean by HD?
And how should I use SEEDID?

HD = hierarchical deterministic wallet i.e. a wallet where all address specific private keys are derived from a seed. i only mentioned seedid because it tells you whether your wallet is HD or not. If it's present you have an HD wallet. To change the seed you can use sethdseed: https://bitcoincore.org/en/doc/0.18.0/rpc/wallet/sethdseed/. However I don't recommend it.

Hi, I read that link was useful, but I got an error Private Key
and Can hdseed be used as a wallet recovery word?
For example I am now in a bitcoincor wallet
I have 1 bitcoin unit and I also have hdseed

@nickburcart see the second paragraph in my answer above about how to backup your wallet. i suggest you take your follow up questions to bitcointalk's technical support subforum. this place is not for back and forth discussions.

Hi, I read that link was useful, but I got an error Private Key
and Can hdseed be used as a wallet recovery word?
For example I am now in a bitcoincor wallet
I have 1 bitcoin unit and I also have hdseed
Can I get 1 bitcoin in another full node bitcoincor using this sethdseed one?


text:
How to fix the Bitcoind service shutdown seemingly by invalid block?
I logged into my node to check the blockheight and saw that it was no longer running.
When I checked the logs I got:
Apr 07 15:27:29 btc.home.local bitcoind[222318]: 2022-04-07T15:27:29Z New outbound peer connected: version: 70016, blocks=730857, peer=19090 (block-relay-only)
Apr 07 15:28:41 btc.home.local bitcoind[222318]: 2022-04-07T15:28:41Z New outbound peer connected: version: 70015, blocks=730857, peer=19093 (block-relay-only)
Apr 07 15:29:02 btc.home.local bitcoind[222318]: 2022-04-07T15:29:02Z UpdateTip: new best=00000000000000000006f59c754697e1cbcc330e9cd6dbd51c9631d33e617e83 height=730858 version=0x20000004 log2_work=93.446902 tx=723828017 date='2022-04-07T15:28:57Z' progress=1.000000 cache=109.8MiB(777828txo)
Apr 07 15:33:12 btc.home.local bitcoind[222318]: 2022-04-07T15:33:12Z ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 000000008b133defdf2bd580dc9c6b82ddad0ccf0e6ba0c30ab11e0491e089fe, bad-diffbits, incorrect proof of work
Apr 07 15:34:03 btc.home.local bitcoind[222318]: 2022-04-07T15:34:03Z New outbound peer connected: version: 70016, blocks=730858, peer=19185 (block-relay-only)
Apr 07 15:43:44 btc.home.local bitcoind[222318]: 2022-04-07T15:43:44Z ERROR: ReadRawBlockFromDisk: Block magic mismatch for FlatFilePos(nFile=16, nPos=811845): 4f238f1b versus expected f9beb4d9
Apr 07 15:43:44 btc.home.local bitcoind[222318]: bitcoind: net_processing.cpp:1777: void {anonymous}::PeerManagerImpl::ProcessGetBlockData(CNode&, {anonymous}::Peer&, const CInv&): Assertion `!"cannot load block from disk"' failed.

In Summary:

ERROR: AcceptBlockHeader - incorrect proof of work
ERROR: ReadRawBlockFromDisk - Block magic mismatch
A c++ error: Assertion `!"cannot load block from disk"' failed

Previous questions are similar but do not address this situation exactly:

block magic mismatch - advice to redownload entire blockchain
node knocked off - banned

What is the correct way to fix this issue? (I have re-downloaded/re-indexed the blockchain before and it takes too long to be feasible)
Update June 2022:
Jun 13 17:58:48 btc bitcoind[840]: 2022-06-13T17:58:48Z New outbound peer connected: version: 70016, blocks=740639, peer=94798 (block-relay-only)
Jun 13 18:23:39 btc bitcoind[840]: 2022-06-13T18:23:39Z ERROR: ReadRawBlockFromDisk: Read from block file failed: CAutoFile::read: end of file: iostream error for FlatFilePo>
Jun 13 18:23:39 btc bitcoind[840]: bitcoind: net_processing.cpp:1777: void {anonymous}::PeerManagerImpl::ProcessGetBlockData(CNode&, {anonymous}::Peer&, const CInv&): Assert>
Jun 13 18:23:53 btc systemd[1]: bitcoind.service: Main process exited, code=killed, status=6/ABRT
Jun 13 18:23:53 btc systemd[1]: bitcoind.service: Failed with result 'signal'.

My config:
[main]
datadir=/mnt/btc/bitcoin

maxconnections=32
maxuploadtarget=2048

After changing to 32 max connections from 16 - I encountered this issue.

Update: Still not fixed
Jun 13 21:21:40 btc bitcoind[26301]: 2022-06-13T21:21:40Z New outbound peer connected: version: 70016, blocks=740662, peer=776 (block-relay-only)
Jun 13 21:29:33 btc bitcoind[26301]: 2022-06-13T21:29:33Z ERROR: ReadRawBlockFromDisk: Block magic mismatch for FlatFilePos(nFile=16, nPos=28970925): 53aeffff versus expected f9beb4d9
Jun 13 21:29:33 btc bitcoind[26301]: bitcoind: net_processing.cpp:1777: void {anonymous}::PeerManagerImpl::ProcessGetBlockData(CNode&, {anonymous}::Peer&, const CInv&): Assertion `!"cannot load >

Is your hard drive connected via USB or the blockchain data stored on a SD card?

Connected via USB

I'd guess that you had a write error. You may want to try connecting it via SATA.

What worked for me is restart bitcoind.
I don't have more details unfortunately.

Have you tried turning it off and on again


text:
What is the difference between True and False setting of newkeypool variable on the sethdseed command?
When I create a new blank wallet and set the seed with both newkeypool as True and False...I do not see a difference in the resulting dumped wallets.
The cli help states:
Arguments:
1. newkeypool    (boolean, optional, default=true) Whether to flush old unused addresses, including change addresses, from the keypool and regenerate it.
                 If true, the next address from getnewaddress and change address from getrawchangeaddress will be from this new seed.
                 If false, addresses (including change addresses if the wallet already had HD Chain Split enabled) from the existing
                 keypool will be used until it has been depleted.

I am using testnet

My process:
bitcoin-cli createwallet "mytestwallet" false true
bitcoin-cli -rpcwallet=mytestwallet sethdseed false c...
bitcoin-cli getnewaddress

Then I delete the wallet rm -R .bitcoin/testnet3/wallets/mytestwallet and recreate with:
bitcoin-cli createwallet "mytestwallet" false true
bitcoin-cli -rpcwallet=mytestwallet sethdseed true c...
bitcoin-cli getnewaddress

The resulting new address is the same regardless of the newkeypool boolean

The dumpwallet looks the same but the keys and addresses are in difference order...

Why with bitcoin-core is the address generated after a sethdseed command is the same m/0'/0'/0' whether newkeypool is set to True or False?

newkeypool only applies to wallets which already have a keypool. If it is true, the current keypool will be emptied and filled with keys generated with the new seed. If it is false, then it will not be emptied, but new keys that are added to the keypool will be generated with the new seed.
With a blank wallet, there are no keys in the wallet, so there are also no keys in the keypool. Thus the newkeypool option has no effect on a blank wallet. If you set it to true, the keypool is already empty and it gets filled by keys produced by the new seed. If you set it to false, new keys will be added to the keypool generated from the new seed, and because it is empty, the first key you request from it will be a new key.
You will be able to see the difference if you make a wallet that isn't blank, or if you use sethdseed again.

Ok, if you use sethdseed again - it has to be a different seed. Just to note for other readers.

sethdseed can be used without a seed argument and a randomly generated seed will be used.


text:
Why is the seed not at the top of the file and clearly identified when dumping a wallet in bitcoin core?
When I dump my wallet in bitcoin core:
bitcoin-cli dumpwallet mywallet.txt

The output looks like this, obfuscating keys with XXX
# Wallet dump created by Bitcoin v0.21.0
# * Created on 2021-08-12T17:19:57Z
# * Best block at time of backup was 695445 (00000000000000000004f27a30ca376652c836a0c498d1c93ced4727e94074d0),
#   mined on 2021-08-12T17:15:35Z

# extended private masterkey: xprv9XXXXX

XXX 2021-08-12T12:29:33Z reserve=1 # addr=bc1qq9XXX hdkeypath=m/0'/0'/50'
XXX 2021-08-12T12:29:33Z reserve=1 # addr=bc1qq9XXX hdkeypath=m/0'/0'/200'
XXX 2021-08-12T12:29:33Z reserve=1 # addr=bc1qqfXXX hdkeypath=m/0'/0'/238'
XXX 2021-08-12T12:29:33Z reserve=1 # addr=bc1qq0XXX hdkeypath=m/0'/0'/134'
XXX 2021-08-12T12:29:33Z reserve=1 # addr=bc1qq0XXX hdkeypath=m/0'/0'/174'
XXX 2021-08-12T12:29:33Z reserve=1 # addr=bc1qqjXXX hdkeypath=m/0'/0'/58'
XXX 2021-08-12T12:29:33Z reserve=1 # addr=bc1qq5XXX hdkeypath=m/0'/0'/159'
XXX 2021-08-12T12:29:33Z reserve=1 # addr=bc1qqkXXX hdkeypath=m/0'/0'/153'
XXX 2021-08-12T12:29:33Z reserve=1 # addr=bc1qqhXXX hdkeypath=m/0'/0'/62'
XXX 2021-08-12T12:29:33Z hdseed=1 # addr=bc1qqaXXX
XXX 2021-08-12T12:29:33Z reserve=1 # addr=bc1qq7XXX hdkeypath=m/0'/0'/127'
XXX 2021-08-12T12:29:33Z reserve=1 # addr=bc1qqlXXX hdkeypath=m/0'/0'/205'

As a new user, I would think that based on the structure of this file the important part to backup is # extended private masterkey: xprv9XXXXX
However, this is not the case according to this answer for storing the seed, the important part is the hdseed:
XXX 2021-08-12T12:29:33Z hdseed=1 # addr=bc1qqaXXX

The XXX portion from above.
Why is that not made clearer in the output of dumpwallet?

The dumpwallet RPC was introduced in this commit, in the v0.9 release of Bitcoin Core.
This was back in time when the wallet was just a random bag of independent keys. That is, before HD wallets came along. So there was no such thing as a seed, hence the dumpfile being simply a long list of keys.
Since HD wallets were introduced, no-one has modified this RPC to put the seed at the top. That's all there is to it :)

Not to mention that the seed by itself was not useful for a long time as there was no way to import a seed and set the wallet to use a particular seed.

Nobody† knows.
The motivation for features in Bitcoin core is rarely documented in easily accessible places - though you might examine the source code for hints. It might be, for example, that the original author of dumpwallet felt that backupwallet was adequate for people seeking to preserve the seed and that they intended dumpwallet as a debugging aid for developers and not as a way for end-users to make a note of their seed for recovery purposes. If so, for this debugging purpose, the lack of prominence of the seed is unimportant.

Footnotes:
† Approximately. Presumably the original author knew at the time they implemented the dumpwallet feature but they may have forgotten or died.

verify = dumpwallet, trust = backupwallet

Actually, sipa introduced the dumpwallet RPC: https://github.com/bitcoin/bitcoin/commit/4e534aa9d892dd6db64afda979ba1f8d44371389 (he definitely hasn't died I hope!)

Not the best of my knowledge.

Glad to hear it :-)

The most important bit is the master seed, which is at the top of the file. A user deciding what parts of a backup file are "important" to them isn't really a consideration regardless.

As OP points out, the seed is not at the top of the file.


text:
Redirected from a real exchange site to a fraudulent site?
I was attempting to reset my authenticator through the real binance site and somehow I got redirected to binancezh.cc which was immediately alarming to me when I noticed; however, upon further investigation, one of the links that led to binancezh.cc was in an automated email sent from binance.com.
How could I have been redirected to a fraudulent site from an interaction that I initiated on the real site?

Edit: It appears that the site is somehow legit but not intended for public use
https://www.reddit.com/r/binance/comments/krt1he/binancezhcc/gif9ca0?utm_source=share&utm_medium=web2x&context=3

How did you verify that the email was authentic and the sender address not just spoofed? Did you check DMARC, DKIM?

I didn't, I will check that

@Murch, I have validated the DKIM

If it's a fraud, how could they have sent a fraudulent link through a real binance email address?

It has long been trivial to forge the "from" address in Internet e-mail. You could learn how to do it in about thirty seconds.
See https://en.wikipedia.org/wiki/Email_spoofing

The core email protocols do not have any mechanism for authentication, making it common for spam and phishing emails to use such spoofing to mislead or even prank the recipient about the origin of the message.

The link above goes on to describe countermeasures - but note these are not universally applied.

Even still, I initiated the email flow from the real Binance site

It looks fraudulent to me, because of the domain. The .cc extension is for the Cocos Islands, and Binance would not use it. They usually tell you to carefully check you are using the right domain. An e-mail can easily be made to look from the right party when it's not.
I would speak to Binance support. Their correct domain is:
https://www.binance.com/

I've opened a ticket with Binance, thanks

I checked with Binance support, and they gave me a tool they have to check if a site is official. According to this, the site is official. I am guessing they have this site because they operate a decentralised business structure, hence the .cc domain for the Cocos Islands, an Australian territory.


text:
Is it possible to know if the result of 2 point subtraction is before or after G
I am trying to see if there is a way to see if subtraction of 2 points on the elliptical curve resulted in a point before or after G?. Let me explain what I mean by it.
Let's take a point GP. Using the Bitcoin curve equation, for a value of P=10 I get below X and Y
G10 =(72488970228380509287422715226575535698893157273063074627791787432852706183111,62070622898698443831883535403436258712770888294397026493185421712108624767191)
Let's take another point GQ for subtraction with GP. for Q=20 I get,
G*20 = 34773495056115281091786765947597603724784643419904767525769502836017890139287,8470533044743364938367028725608288731153024648869546164814808839694950063162)
Now subtract GP - GQ, In normal math, it is 10-20= -10, but with EC math I get a point  (72488970228380509287422715226575535698893157273063074627791787432852706183111,53721466338617751591687449605251649140499096371243537546272162295800209904472)
which has the same X value as 10 but Y is different.  If I add G to the result the point is 9G but with a different value.
I am not sure how it is called (Y inverse ?) but I see it's like a point before G and if I add G it comes closer to G. 9G,8G,7G.... 1G
Another way of seeing this is that Y can have 2 possible values (below is the python code which I used to calculate)
One valve is used for 10 and the other for a point which is a result of subtraction.
p = 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f
x = 72488970228380509287422715226575535698893157273063074627791787432852706183111
ysquared = ((xxx+7) % p)
y = pow(ysquared, (p+1)/4, p)
print "y1 = %s " % y
print "y2 = %s " % (y * -1 % p)
So that question can also be, How to know which Y value to use if a value of X is given,

As mentioned in other replies, the y^2 = x^3 + 7 equation has two roots (two valid y values for every x). EC point multiplication with scalar is defined here so in your example to get the result for -10 * G pick one of the algorithms in the link and substitute P = G and d = -10 mod (curve order)

If the point (X,Y) is on the elliptic curve y2 = x3 + ax + b, then the point (X,-Y) is also on that curve. Substitution yields (-y)2 = x3 + ax + b, which is the same equation.
In fact, it is the case that if kG = (X,Y), then (-k)G = (N-k)G = (X,P-Y), where the multiplications with G are point multiplications, N is the curve order, and P is the field size (P = 2256 - 232 - 977 for secp256k1).
So if your question is how you find the correct Y coordinate given just X, the answer is you don't. There will always be two solutions.
Typical point encoding standards avoid that by either encoding the Y coordinate explicitly, disambiguating, or only permitting one:

The SEC2 uncompressed public key encoding is 0x04 + (X coordinate) + (Y coordinate); 65 bytes for 256-bit curves.
The SEC2 compressed public key encoding is 0x02 + (X coordinate) if Y is even, and 0x03 + (X coordinate) if Y is odd.
The proposed BIP340 Schnorr signatures (which I'm a co-author of) just store the X coordinate (32 bytes), but with an implicit Y-is-even.

There is no such thing as negative numbers on the elliptic curve used by Bitcoin because it is an elliptic curve over a finite field. It is a cyclic group of points composed of positive-integers. You might want to learn about modulo arithmetic and cyclic groups

Thanks, I understand the curve the point is on a cyclic group of points. I would have been more clear with my question. I have updated the main question.

How subtraction works
P - Q = P + (-Q) where -Q is the negated Q. (- changes the sign, or in another words, subtracts from the modulus)
An example: On this website. For this example, set p = 523;
Let the generator (P) be (10, 22). I have 4P and I need 3P. I do the following to calculate 4P - P:
Set n = 4 to find 4P = (-236, 235)
For n = 1 to find P = (10, 22)
Now, we need to negate it, so set n = -1 to find -P = (10, -22)
Go to the addition tab to add -P to 4P, to find (22, -42)
Set n = 3 to see if we find the same value ... we do (22, -42)

But, the answer is not "negative", as pinhead explains.

I guess I should have been more clear with my question. The explanation of a point not being negative makes perfect sense.  I will explain what I am trying to understand. I will edit the main post.


text:
Upgrade to 0.21.0 - No incomming connections via Tor after upgrading
I upgraded to 0.21.0 a couple of days ago and noticed I'm no longer getting incoming connections while using Tor as a proxy. Was fine before the upgrade.
'getnetworkinfo' shows "reachable": true, "proxy": "127.0.0.1:9050" on ipv4, ipv6 and onion.
I've tried setting 'connect=myonionaddress' on my second node it's throwing the error "connect() to 127.0.0.1:9050 failed after select(): Connection refused (61)". Not sure if there's any configuration change that I need to do since the upgrade?
The debug.log file shows "Got service ID removedonionaddress, advertising service removedonionaddress.onion:8333"

maybe you are using the auto binding on the onion address and your second node is trying to connect on the same onion address. This is only an idea.

I think everybody using Tor with the newest Core has the same problem, including myself. There’s a Good explanation here why this is happening:
https://www.reddit.com/r/Bitcoin/comments/kzhhgk/bitcoin_core_0210_tor_v3/
My solution was to roll back (for now) to the previous version. It now works fine.
I still do not understand why this appears not to be backwards compatible with Tor v2. As the official bulletin release clearly states:
“This release adds support for Tor version 3 hidden services, and rumoring them over the network to other peers using BIP155. Version 2 hidden services are still fully supported by Bitcoin Core, but the Tor network will start deprecating them in the coming months. “

If you're using the automatic Tor hidden service functionality in Bitcoin Core (which you are, unless you've manually configured a hidden service), with 0.21, that will be a V3 hidden service. Older nodes cannot relay this address on the network, or connect to it, so until a significant portion of the network upgrades, there will be connectivity issues. This is an unfortunate chicken-and-egg problem.

Thank you very much @PieterWuille for the clarification. I really need to get my head around it, because if true (I believe you btw), it splits the bitcoin network in two. It is quite ugly, from a Tor perspective, to remove backward compatibility, and imo this is going to have profound implications to the bitcoin core community dedicated in using only Tor (we are a big chuck of the network)

It's unfortunate that TorV3 support landed in Bitcoin Core (and the Bitcoin network; it needed BIP155 first) so late. If it happened earlier, we'd have had time to first enable V3 support but not make it default yet. However, due to Tor's timeline of dropping V2 support we had no choice but making V3 default in 0.21. I suspect this is going to be a short temporary problem though as nodes upgrade. New nodes can still connect to old ones too, btw.

Thanks for the feedback Pieter and Singh. I stuck with 0.21 but had to install the Tor daemon (was just using the Tor Browser before) to get it to connect to my 2nd node as I was getting the connection refused issue. Maybe I had setup something wrong in my conf...one other thing I've noticed is that my score is stuck at "4" on both nodes even though they've been up for more than 24 hours. Is this because I have no other incoming connections to my nodes at the moment?


text:
If I buy an ASIC miner and run it at home, do I become a Bitcoin node?
I tried to find the Bitlist visualization as mentioned in the documentary The Rise and Rise of Bitcoin, but could not

but instead found https://bitnodes.io/

It says there are 9741 nodes.  Does that mean if I buy an ASIC miner and set it up, then I become a node and that would make it become 9742?  But the usual practice is said to be joining a mining pool, so if I join one, then I won't be one extra node but will merge into one?

TL;DR: No, you just need to run any p2p-participating bitcoin software.
What's bitnodes?
Bitnodes.io attempts to track all publicly reachable nodes in the Bitcoin network. They presumably achieve this by running "spy" nodes which aggressively connect to all nodes they know of and poll them for more peers. This process will generally only discover nodes that accept inbound connections, so called "listening nodes".
What is a node?
We call any instance of software participating in the Bitcoin peer-to-peer network a node. This includes e.g. full nodes (listening or not), some thin clients, and Lightning Network nodes. It does not include server-trusting clients that only connect to a central service which provides information about the Bitcoin network.
The vast majority of nodes are not publicly reachable, and thus not easy to track. As Prayank already pointed out, Luke-jr maintains some statistics sourced from his DNS seed, a service that serves as an initial connection point for the P2P network. As many node implementations contact DNS seeds on their first connection to the network, he is able to learn about some of the non-reachable nodes and increases the lower bound established by the 9,741 reachable nodes to about 78k full nodes.
What is the difference between nodes and miners?
"Miner" is an umbrella term for entities that contribute proof-of-work to the Bitcoin network. Working on a new block requires awareness of the current state of the network to determine the chain tip, current difficulty, and the eligible transactions for inclusion. Some miners, especially larger operations, work independently on extending the blockchain. These miners run one or multiple full nodes to track the network state and to generate block templates. Other miners depend on mining pool operators to assign them work. In that case, the mining pool operator must run a full node for the same reason, but mining pool contributors don't have to (since they get work assignments). Given that the full nodes of mining operations could be the target of attacks, I would expect that they usually run multiple nodes and at least some of their nodes are non-listening.
Miners run nodes as part of their mining operations, but you don't need to mine to be considered a node.


text:
Is it true that all the bitcoins in existence are on the blockchain (the ledge), but it just depends on who the owner (address) is?
It seems that for the 18.5 million bitcoins generated, plus even the 6.25 bitcoins that were rewards just 10 minutes ago, are all recorded in the blockchain (the ledger), but it just depends on who the owner (the address) is?
And if Peter sends Mary 0.001 bitcoins, then it is just the ownership change (which address has it), all the same number of bitcoins is all recorded on the blockchain.

I guess? I don't really understand what the question is.

The blockchain is more of a transaction journal, while the "UTXO set" is the ledger. Generally "statement + am I right" don't tend to work great as topic starters here. Could you please edit your question to ask more openly? E.g. "Where are bitcoins stored?", "How are Bitcoin balances tracked?", or "How does the Blockchain help keeping track of who owns how many bitcoins?"

@Murch I think I can rewrite it as, "a question + what I research and found so far"... if I post it as a question, there are people who come up and say, "what have you found out so far", "we don't provide answer without seeing that you already putting in effort"

Mh, I think I understand what you mean, sorry if that was your experience. Usually, conveying your current understanding as a background for your question is very helpful. What I'm at a loss here is to get a sense of what further information you are trying to get here. I don't know what "it just depends on who the owner is?" is aiming at. Depends for what? It would help if the question managed to better convey what an answer should cover! :)

I realized all of a sudden, that the blockchain actually states where all bitcoins in existence are at, no matter it is a collection of bitcoins, or each bitcoin, or a bitcoin fraction is at, and they are just in different mini-accounts called "address", so I just asked if this is the correct concept

Rabbit holes are deep

Bitcoin's blockchain doesn't really know who owns anything.
Bitcoins don't exist as things whose ownership can be reassigned.
Bitcoins have no individual continuity.

Yes the Blockchain effectively keeps track of changes of something that often corresponds to what we think of as ownership of money. However the blockchain cannot distinguish between Alice sending 1 BTC to Bob (money changing hands) and Alice sending 1 BTC to a different address in one of her wallets (rearranging her money, no change of ownership).
Wallets can process transaction data to keep track of a set of unspent transaction outputs (UTXOs) removing outputs that have been spent and adding newly created outputs.
The total monetary amount of the UTXO set should add up to 18.5 million (or whatever the quantity mined so far adds up to).
However the identity of bitcoins is not preserved. It is only the total amounts that always sum up to the correct current money supply.
If you think of UTXO's as coins, the mined transactions effectively melt all the input coins down and use the combined molten metal to cast a new set of coins. No coins change hands, all coins are destroyed in every transaction and new coins created.
For example in the following transaction there is no way to say that certain inputs correspond to certain outputs. This is true regardless of the amounts although you can sometimes make inferences. An exchange might consolidate several of its users transactions into one bitcoin transaction  with dozens of inputs and dozens of outputs and there's no certain way to determine which inputs correspond to which outputs.
In block 669188 there is a transaction 1218…d33e. If you look at that in a blockchain explorer such as blockchair the details will be shown as
Senders

Amount
Address

0.00149566 BTC
3PxGWkwnxQ88zQw8TgBiYrH4pQxhakmN16

0.05809775 BTC
3CDcCbis6dEBeksMY8uYhWyU3EaLN6vh82

Recipients

Address
Amount

1C7cDqqGK5vscgPfD9d6gwcMw2tSRb4Q1Q
0.01076317 BTC

3BwbGdAidTuFLYdAhgVX1DgnoPCJ9fECRY
0.04809524 BTC

See footnote.
Where did the 0.00149566 BTC end up? At 1C7c…4Q1q or at 3Bwb…ECRY? No one can say, it may not be a meaningful question.
So the notion "the blockchain actually states where all bitcoins in existence are at" isn't meaningful because there are no things called bitcoins, there are only amounts of money specified in a unit of measure named Bitcoin.
The reality is simply that the total amount of mined bitcoin is kept track of as a list of amounts, each of which is associated with a bitcoin-script.

Footnote
The data under "Senders" doesn't all come from the transaction data directly.
Inputs are specified by the transaction ID of a prior transaction they were created in (received in) and an index number into the list of outputs of that transaction.
You can look at the raw data, for example by clicking on "raw data" in the Blockchair web page. It will show a Hex and a JSON view of the actual data
0200000000010274d82567d8e55f9b25628093bd151289543e8630c3f18656cfcd090953cf2ab601000000171600140cabe7062ed5a42e1c6dc75efb708e980efc9aa9ffffffffbc06dcfee104538ef7c333cc16be005de31a4fecec6d766da23ecb2ae6bebda001000000171600148a1e82051ee5b269209d35aee915ca71c2d80a47ffffffff025d6c1000000000001976a91479e947df07c7941727d79ea4cac9b909c43d3c1c88ac346349000000000017a9147072ead5bae0971c1aed1b49b61a822b502c6b3d8702473044022038577fabbcee921e0b4613df3f1b146f32bcc8cde69f0a298b4e0d481231dff402204db6efa7e562a103e103679870188bc7953bea4a0dfed014d6f32dff55bc8d7b012102988d62c603eddc6bd7b4972b03a8173b497bf2647b1ea0a8d2bb64ad7aa22f1b02473044022029fd501198a4dc7692fefc4d48a63c5a6d5a2936215ce0b3a7b1fb449428f13a02201d4f354d61ebd81300e27361e064fb0628ad807f4308ded893238767b68351d4012102ee971f8d307d7b75de716c743b49b579b577b2247f75465820407347feced7d900000000

That's hard to make sense of so they provide a JSON view (or JSON interpretation):
{
  "txid": "1218039587a3fc96f0c6f3d0fb0d49404f54917a3d63cb52158a1ef84f27d33e",
  "hash": "cb44308832dfeceeba412633b937ebc3bbf5c4629a463f7fa04442b74c76d53d",
  "version": 2,
  "size": 420,
  "vsize": 258,
  "weight": 1032,
  "locktime": 0,
  "vin": [
    {
      "txid": "b62acf530909cdcf5686f1c330863e54891215bd938062259b5fe5d86725d874",
      "vout": 1,
      "scriptSig": {
        "asm": "00140cabe7062ed5a42e1c6dc75efb708e980efc9aa9",
        "hex": "1600140cabe7062ed5a42e1c6dc75efb708e980efc9aa9"
      },
      "txinwitness": [
        "3044022038577fabbcee921e0b4613df3f1b146f32bcc8cde69f0a298b4e0d481231dff402204db6efa7e562a103e103679870188bc7953bea4a0dfed014d6f32dff55bc8d7b01",
        "02988d62c603eddc6bd7b4972b03a8173b497bf2647b1ea0a8d2bb64ad7aa22f1b"
      ],
      "sequence": 4294967295
    },
    {
      "txid": "a0bdbee62acb3ea26d766decec4f1ae35d00be16cc33c3f78e5304e1fedc06bc",
      "vout": 1,
      "scriptSig": {
        "asm": "00148a1e82051ee5b269209d35aee915ca71c2d80a47",
        "hex": "1600148a1e82051ee5b269209d35aee915ca71c2d80a47"
      },
      "txinwitness": [
        "3044022029fd501198a4dc7692fefc4d48a63c5a6d5a2936215ce0b3a7b1fb449428f13a02201d4f354d61ebd81300e27361e064fb0628ad807f4308ded893238767b68351d401",
        "02ee971f8d307d7b75de716c743b49b579b577b2247f75465820407347feced7d9"
      ],
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.01076317,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 79e947df07c7941727d79ea4cac9b909c43d3c1c OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91479e947df07c7941727d79ea4cac9b909c43d3c1c88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1C7cDqqGK5vscgPfD9d6gwcMw2tSRb4Q1Q"
        ]
      }
    },
    {
      "value": 0.04809524,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_HASH160 7072ead5bae0971c1aed1b49b61a822b502c6b3d OP_EQUAL",
        "hex": "a9147072ead5bae0971c1aed1b49b61a822b502c6b3d87",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "3BwbGdAidTuFLYdAhgVX1DgnoPCJ9fECRY"
        ]
      }
    }
  ]
}

Note that the two inputs listed under vin are

txid
vout
scriptsig etc

b62a…d874
1
…

a0bd…06bc
1
…

So the two inputs are specified, not using an address and an amount but by specifying a source transaction and a position in the list of outputs (vout). There is also other data, essentially proof of right to spend. So the blockchain explorer can use txid & vout as an index to look up additional details of those inputs from its records of the specified earlier transactions (e.g. "date received" for each vin)

Good answer. One sort of nit: Outputs are locked to some spending conditions or locking script, which usually means requiring the signature of a specific key. This is well-represented by an address. But inputs identify which UTXO they are spending by the  "outpoint", i.e. the transaction that created the output and its position in the output list of that transaction (txid:vout). :)

@Murch, thanks for the clarification, I'll update my answer with a real-world transaction and expand on this a little

Great clarifictation, and yeah, I must admit that most blockchain explorers represent it exactly in the way that you first showed it, so maybe I'm a bit out of line pointing out what it does under the hood. Thanks for your great posts! :)

The blockchain only implicitly tracks the existence of each piece of Bitcoin. If you have experience with accounting, the terms "journal" and "ledger" may be familiar. The "transaction journal" is a list of all the transactions that were made in some period of time, for example one business day. At the end of the day, the accountant tallies up all the payments between accounts and updates the list of current balances in the "ledger".
Similarly, the blockchain journals the full history of all transactions and the Unspent Transaction Output set (UTXO set) represents the ledger of current balances. Unconfirmed transactions are payment promises until they get collected in a block. Once included in a block, they are committed into a fixed order, and the network continues burying them under more and more work. As more blocks get added, the likelihood of transactions getting replaced shrinks rapidly.
Each block represents an update to the global shared state of the ledger. The strict order of all transactions is what allows full nodes to perform the initial synchronization with the network. The full nodes process the complete blockchain transaction by transaction until they reach the current blockchain tip and have recalculated the shared ledger.
However, none of the balances are actually tied to any specific identities, rather each transaction output is encumbered by a locking script that defines the conditions under which its funds may be spent. The most common locking script types require a specific private key to provide a cryptographic signature when a UTXO is spent by an input. Generally, whoever can provide the signature is considered the owner of the funds—without ever needing to reveal their identity.


text:
Is there a way to tell that our bitcoin is safe after we put it in a hardware wallet for cold storage after 3 or 5 years?
If I consolidated 1 bitcoin into an address using a hardware wallet, and put it in cold storage. Can I know after 3 to 5 years that the bitcoin is safe?
So far the research I have is: can I go to https://www.blockchain.com/btc/blocks and search for that address, and see that it was still used once (for the time I put the bitcoin in), and therefore know that the bitcoin is safe?

Yes, you can use, for example, two or three different blockchain explorers to check the balance for your Bitcoin address(es).
Or you can set up a watch-only wallet on any PC or phone - import the Bitcoin-addresses but not the private keys and the wallet cannot spend the money, only monitor. The money will be shown by the wallet as "watch-only" or "non-spendable" (depending on the wallet). It will show you any transactions involving money at that bitcoin-address.


text:
Is it safest to double check my new bitcoin address never showed up in the Ledger (the blockchain) before?
I just noticed in my Coinbase Pro, I can click deposit, BTC, and get a brand new address every time. It probably is due to "address is very cheap". It can be just a new pair of private key and public key, and from that, a shorter "address" can be created.
So since an address is a shorter version, the chance of collision is higher than the private key.
Let's say if a person is to deposit US$300,000 or $3,000,000 into that address, would it be safest to double check that this new address never showed up in the blockchain (the ledger) before?
Otherwise, is it true that when there is a collision of address, both that person's private key and mine can move this bitcoin amount to else where?

would it be safest to double check

Yes but the difference in safety, although not exactly zero, is approximately zero.

is it true that when there is a collision of address, both that person's private key and mine can move this bitcoin amount to else where

Yes.
Statistically that will not happen in any timespan you or I can properly comprehend. See related topics in right hand margin of this web-page. Especially Is a bitcoin address collision possible if generating 90 million addresses every 4 hours?


text:
Is it still possible to recover Multibit Classic wallet from multibit.key file?
I have the file mulibit.key (long string starting with U2FsdGVkX19E+pw) and password.
Cannot find the Multibit Classic wallet to import the key and export to Electrum...
Tried to decrypt the key with
openssl enc -d -p -aes-256-cbc -a -in multibit.key -out key.txt -pass pass:Mypassword
but got only such response:
*** WARNING : deprecated key derivation used.
Using -iter or -pbkdf2 would be better.
salt=44FA9C205936F29D
key=8E260D08EE31BB97AB7544D70BC41535369
iv =B6B2A8A90712B2393DDF8
bad decrypt
140404139345280:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:crypto/evp/evp_enc.c:588

EDIT WITH FULL ANSWER:
The problem was different version of open ssl... After adding flag -md md5 my multibit.key get encrypted! So I could enter the private key into Electrum wallet
openssl enc -d -p -aes-256-cbc -md md5 -a -in multibit.key  -out key.txt  -pass 'pass:myPassword'

No. The links are not working any more...

Can you find the multibit classic ("Multibit") in your hard drive or should I send you my copy of Multibit 0.5.16? The former is better since it doesn't require that you trust me.

Or you can download it from https://linux.softpedia.com/get/Office/Finance/MultiBit-102886.shtml . The file is multibit-0.5.18-linux.jar but it works on all operating systems

It seems to me those links do work, they just redirect to a github repository for the source code to Multibit Classic.

Thank you @MCCCS . Managed to decrypt the key without Multibit wallet :)

did you try the -md5 flag, the openssl decryption changed a few years back and the md5 flag should solve it

YES!! That did the job!! it was -md flag: openssl enc -d -p -aes-256-cbc -md md5 -a -in multibit.key  -out key.txt  -pass 'pass:myPassword'


text:
How to find nodes forwarding transactions with less than minRelayTxFee?
Technically, it is up to each node operator to set the minRelayTxFee as he pleases.
Assume a transaction with less than 1Sat/vB in transaction fees and a fairly empty mempool.
Is it possible to identify nodes on the network that are likely to forward or have previously forwarded transactions with less than default minimum fees?
If a subnet of such nodes existed, miners should be incentivized to also connect to it -- at least in times of empty mempool.
EDIT:
Originally, I did not intend to discuss my assumptions about miners' incentives. However, I find that discussion rather interesting, and will happily clarify my views.
I understand that close to zero fee transactions may (currently) not incentivize miners enough. On the other hand, we can be certain that in principle miners are willing to include transactions at a fee of 999 Sat/vB. That being said, I think it is a fair assumption that a market price could be established somewhere in between, i.e. 0 < fee < 1000 Sat/vB. If that is true, transaction fees currently do NOT represent a market price, due to minRelayTxFee = 1000.
Furthermore the incentive to include non-standard transactions is likely to depend on the fiat price of Bitcoin, as the labour necessary for a transition is likely to be priced in fiat. I conclude that the incentive will grow in the future.
Finally, I do not agree with the notion that the demand for transaction is flat (static, fixed). I am absolutely certain of a demand for cheaper transactions.
EDIT:
Regardless of the transactions miners receive, nobody can force them to include those transactions in a block anyhow. If miners regard transactions as too cheap, they may very well omit them. It may not be wise to do so, because the fees, as little as they may be, will be picked up by another miner. Miners (i.e. some miners/a miner/somebody) will eventually change their parameters if the volume of non-standard transactions becomes large enough.
My entire argument is about extending the fee market to the lower side.

Since 0.13.0 nodes will tell their peers via the feefilter p2p message what their current minimum acceptable feerate is. Given that it's fairly uncommon for nodes to run with something other than the default, I don't think nodes use this information for preferential peering. I guess you could parse the log to identify nodes that announce something lower than the default and then add them as peers via addnode.
When I last checked in January 2022, it was obvious that no miners were mining transactions that pay less than the default minRelayTxFee. That seems rational to me: a full block of 1 s/vB transactions brings a total of ₿0.01 in fees, and transactions below the minRelayTxFee even less than that. Compared the current subsidy of ₿6.25, that's less than a sixth of a percent. My understanding is that mining pools are mostly large logistics endeavors, and they tend to have a limited contingent of programmers on staff. Given a limited pool of skilled labor, you'd probably want to prioritize other things such as energy efficiency of your operation, reducing latency, stable power supply, redundant internet connections, improving pool worker management, or any of a dozen other things that could cause your very expensive hardware to run at less than optimal performance.
Additionally, having a minimum price for blockspace is in the interest of node operators, because every transaction has the externality of needing to be transmitted, validated, and stored by every node operator. Maintaining a minimum fee rate on their mempool is also a safeguard against a malicious party wasting lots of bandwidth with unconfirmed transactions that they later replace or don't get confirmed otherwise.
There is some discussion of those findings on Twitter here: https://twitter.com/murchandamus/status/1480553169239355393

I don't quite see what's irrational about NOT including a transaction into an otherwise non-full block. Also, there is a precise configuration setting in the core client.

I updated my answer to more clearly express why I think miners wouldn't prioritize low feerate transaction processing.

Thx.
I don't understand what you mean by "cost of all future synchronizations".
(see my update)

The bigger the blockchain, the longer it takes to catch up with the current state of the network for new nodes. Therefore, it may be beneficial, if blockspace maintains a minimum price rather than every single block being full.

Sorry, no. You're essentially saying Bitcoin cannot handle full blocks.

No, that's not what I said. There is an externality to every confirmed transaction that is being paid by every full node operator. I'm pointing out that giving away the remaining blockspace does not align with the interests of full node operators, even while the miners could earn a minuscule amount of additional fees, and it obviously would be beneficial to the senders that get cheaper blockspace. The Bitcoin network could handle it fine, although it may cause there to be some amount of fewer full nodes.

Also, it is in the interest of full nodes to enforce minimum feerates on their own mempools, because it puts a minimum price on transaction senders using their bandwidth. Removing the minimum feerate would make it trivial to waste a lot of node operators' bandwidth with unconfirmed transactions that never make it into blocks.

What was the argument for the drop from 5000 down to 1000 then? Why 1000 and not 2500? How can you assume that 1000 is optimal?
Also, transactions can be filtered dynamically or by mempool size limit.

The last drop of the minRelayTxFee was from 10,000 to 1,000 in this PR: https://github.com/bitcoin/bitcoin/commit/6a4c196dd64da2fd33dc7ae77a8cdd3e4cf0eff1. If you're referring to https://github.com/bitcoin/bitcoin/commit/9e93640be6c49fa1505ba5c5df8c89210da5a6e4, you may want to consider that it was just reverting this change: https://github.com/bitcoin/bitcoin/commit/28e3249e53b8ef7516636df0f1406466a513095d and never got shipped.

You can read the arguments people had in the PR here: https://github.com/bitcoin/bitcoin/pull/3305