How to calculate p2wsh signature?

I read the bip143, but didn’t understand how to calculate the scriptCode of p2wsh.

bip143 told us:
A new transaction digest algorithm is defined, but only applicable to sigops in version 0 witness program
Double SHA256 of the serialization of:
1. nVersion of the transaction (4-byte little endian)
2. hashPrevouts (32-byte hash)
3. hashSequence (32-byte hash)
4. outpoint (32-byte hash + 4-byte little endian)
5. scriptCode of the input (serialized as scripts inside CTxOuts)
6. value of the output spent by this input (8-byte little endian)
7. nSequence of the input (4-byte little endian)
8. hashOutputs (32-byte hash)
9. nLocktime of the transaction (4-byte little endian)
10. sighash type of the signature (4-byte little endian)

The item 5:

For P2WPKH witness program, the scriptCode is 0x1976a914{20-byte-pubkey-hash}88ac.
For P2WSH witness program,
if the witnessScript does not contain any OP_CODESEPARATOR, the scriptCode is the witnessScript serialized as scripts inside CTxOut.
if the witnessScript contains any OP_CODESEPARATOR, the scriptCode is the witnessScript but removing everything up to and including the last executed OP_CODESEPARATOR before the signature checking opcode being executed, serialized as scripts inside CTxOut. (The exact semantics is demonstrated in the examples below)

I don’t kown how to find out if “the signature checking opcode being executed”.
Then I read the example “Native P2WSH” in bip143 and I am even more confused.

Here is the first example of “Native P2WSH”:

The following is an unsigned transaction: 0100000002fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e0000000000ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac00000000

nVersion:  01000000
txin:      02 fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e 00000000 00 ffffffff
              0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8 00000000 00 ffffffff
txout:     01 00f2052a01000000 1976a914a30741f8145e5acadf23f751864167f32e0963f788ac
nLockTime: 00000000

The first input comes from an ordinary P2PK:
scriptPubKey: 21036d5c20fa14fb2f635474c1dc4ef5909d4568e5569b79fc94d3448486e14685f8ac value: 1.5625
private key: b8f28a772fccbf9b4f58a4f027e07dc2e35e7cd80529975e292ea34f84c4580c
signature: 304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201 (SIGHASH_ALL)

The second input comes from a native P2WSH witness program:
scriptPubKey : 00205d1b56b63d714eebe542309525f484b7e9d6f686b3781b6f61ef925d66d6f6a0, value: 49
witnessScript: 21026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
<026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae> CHECKSIGVERIFY CODESEPARATOR <0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465> CHECKSIG

To sign it with a nHashType of 3 (SIGHASH_SINGLE):

hashPrevouts:
dSHA256(fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f800000000)
= ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d41

nVersion:     01000000
hashPrevouts: ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d41
hashSequence: 0000000000000000000000000000000000000000000000000000000000000000
outpoint:     0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f800000000
scriptCode:   (see below)
amount:       0011102401000000
nSequence:    ffffffff
hashOutputs:  0000000000000000000000000000000000000000000000000000000000000000 (this is the second input but there is only one output)
nLockTime:    00000000
nHashType:    03000000

scriptCode: 4721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
^^
(please note that the not-yet-executed OP_CODESEPARATOR is not removed from the scriptCode)
preimage: 01000000ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d4100000000000000000000000000000000000000000000000000000000000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8000000004721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0011102401000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000003000000
sigHash: 82dde6e4f1e94d02c2b7ad03d2115d691f48d064e9d52f58194a6637e4194391
public key: 026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae
private key: 8e02b539b1500aa7c81cf3fed177448a546f19d2be416c0c61ff28e577d8d0cd
signature: 3044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e2703

scriptCode: 23210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
(everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed)
preimage: 01000000ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d4100000000000000000000000000000000000000000000000000000000000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000023210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0011102401000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000003000000
sigHash: fef7bd749cce710c5c052bd796df1af0d935e59cea63736268bcbe2d2134fc47
public key: 0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465
private key: 86bf2ed75935a0cbef03b89d72034bb4c189d381037a5ac121a70016db8896ec
signature: 304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503

The serialized signed transaction is: 01000000000102fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000004847304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac000347304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503473044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e27034721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac00000000

01000000
0001
02
fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e 00000000
48
47304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201
ffffffff
0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8 0000000000
ffffffff

01
00f2052a01000000
1976a914a30741f8145e5acadf23f751864167f32e0963f788ac

0003

47304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503
473044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e2703
4721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac

  1. Here “witnessScript” is RedeemScript, right?
  2. what is meaning of ‘CODESEPARATOR’ here?
  3. why need calculate both scriptCode(OP_CODESEPARATOR is not removed && OP_CODESEPARATOR is removed) and both put them into witness data?

My head is filled with question…
Anyone can help? thanks a lot.

What hierarchical deterministic derivation path is used for FIDO authentication on a Ledger Nano S?

What hierarchical deterministic derivation path is used for FIDO authentication on a Ledger Nano S? Does it ask for a different key each time or is it always the same key?

If I connect to Google for 2FA can it ask for proof of whatever key path they desire or does it have to be a particular key?

I’m wondering how much privacy I lose if I use a Ledger Nano S that is not exclusively for a particular accounts 2FA. E.g. What happens if I use it for multiple Google accounts, other companies, or have crypto currency. Could Google discover a Bitcoin balance if the same Ledger is used for 2FA?

Running bitcoin node with already verified blockchain

I’m following this guide https://stadicus.github.io/RaspiBolt/ to setup a bitcoin full node on my new raspberry pi.

I already downloaded and verified the blockchain on my host machine. I also pruned it (6GB) so it can fit on my microSD card. I moved the blocks and chainstate folders to ~/.bitcoin on my raspberry. But when I run the bitcoind service with the same bitcoin.conf file proposed on the guide, the verificationprogress shows that it starts from 0.

I’ve tried with these options too:

prune=6000
reindex=1
reindex-chainstate=1

But none of them make the progress to be completed. I also tried waiting some minutes in order to see if the progress completes faster but that’s not the case. What options do I need?

Issue with sendrawtransaction missing inputs error code -25

Working with Bitcoin-qt 0.16.3 testnet

Attempting to sendrawtransaction, however, receive following error:

Missing inputs (code -25)

From what I have read, this results from attempting to use outputs in the transaction that have already been spent.

I am confused, however, because I am explicitly using a transaction listed by listunspent. Doesn’t that mean the output is unspent???

If you could point me to where I am going wrong, it would be greatly appreciated.

Here’s exactly my work:

listunspent

output

[
  {
    "txid": "8d42a2db310b794ae0d75ed9a68262081fd83817a862f87a99cd176ce8743223",
    "vout": 1,
    "address": "2MtBLx3arsHFV1cBYSo5AXmX5Pf3tfcgda3",
    "account": "addy2",
    "redeemScript": "0014436faf386d5c77c575e3372a97e268a08e3f5378",
    "scriptPubKey": "a9140a3c45e4e27e98b6bf1171b4fe1bf689b9a3dbf287",
    "amount": 0.00010000,
    "confirmations": 229,
    "spendable": true,
    "solvable": true,
    "safe": true
  }
]

input

createrawtransaction '[{ "txid": "8d42a2db310b794ae0d75ed9a68262081fd83817a862f87a99cd176ce8743223", "vout":2 }]' '{ "2N8kPhdhwAYYK8rFt7Fhvm3oapsMF7vqbcB":0.00003, "2MtBLx3arsHFV1cBYSo5AXmX5Pf3tfcgda3":0.0000695}'

output

0200000001233274e86c17cd997af862a81738d81f086282a6d95ed7e04a790b31dba2428d0200000000ffffffff02b80b00000000000017a914aa0e0ebe49d03dc1b79f91775aada9293179bb2387261b00000000000017a9140a3c45e4e27e98b6bf1171b4fe1bf689b9a3dbf28700000000

input

signrawtransaction '0200000001233274e86c17cd997af862a81738d81f086282a6d95ed7e04a790b31dba2428d0200000000ffffffff02b80b00000000000017a914aa0e0ebe49d03dc1b79f91775aada9293179bb2387261b00000000000017a9140a3c45e4e27e98b6bf1171b4fe1bf689b9a3dbf28700000000' '[{"txid":"8d42a2db310b794ae0d75ed9a68262081fd83817a862f87a99cd176ce8743223","vout":2,"scriptPubKey":"a9140a3c45e4e27e98b6bf1171b4fe1bf689b9a3dbf287","redeemScript": "0014436faf386d5c77c575e3372a97e268a08e3f5378",
"amount":0.0001}]'

output

{
  "hex": "02000000000101233274e86c17cd997af862a81738d81f086282a6d95ed7e04a790b31dba2428d0200000017160014436faf386d5c77c575e3372a97e268a08e3f5378ffffffff02b80b00000000000017a914aa0e0ebe49d03dc1b79f91775aada9293179bb2387261b00000000000017a9140a3c45e4e27e98b6bf1171b4fe1bf689b9a3dbf287024830450221009274a153ee55925681d5382fecbff723e2ec12e92dafc7188565e2ee2bef092402201133ec3545333afeacda23b63917660ed62be667508dbb5a121a4ed9aa52125401210273340ff4511f6bbcf7d9f1c1fe69f66704398e54f4cde0e0ec60313476fc92ab00000000",
  "complete": true
}

input

sendrawtransaction 02000000000101233274e86c17cd997af862a81738d81f086282a6d95ed7e04a790b31dba2428d0200000017160014436faf386d5c77c575e3372a97e268a08e3f5378ffffffff02b80b00000000000017a914aa0e0ebe49d03dc1b79f91775aada9293179bb2387261b00000000000017a9140a3c45e4e27e98b6bf1171b4fe1bf689b9a3dbf287024830450221009274a153ee55925681d5382fecbff723e2ec12e92dafc7188565e2ee2bef092402201133ec3545333afeacda23b63917660ed62be667508dbb5a121a4ed9aa52125401210273340ff4511f6bbcf7d9f1c1fe69f66704398e54f4cde0e0ec60313476fc92ab00000000

output

Missing inputs (code -25)

Help get specific address private key

I want to know if someone can help me with this situation:
Two years ago I changed the password of my Bitcoin-Core wallet and forgot it.

I sent my wallet.dat to some person, who claimed that will crack it down and return my coins with some fee.

In the wallet there were only 2 addresses, and after some time the coins dissapeared, but only from one of them. I saw in the blockchain that they were “mixed” or split, in a way not to be traced.

Here is the address they went to: https://www.blockchain.com/btc/address/1PFygtEEhi4spjHJ3DHEBvgVpNp8oBY4A2

Coins from the other address are still in the wallet, and I found my password for the core wallet, but I don’t know how to use it for that specific address with the coins left.

There are 1.3 BTC inside / still 8.30 stolen / but it will be a little relief for me if I can get them.

I have my original wallet.dat file also – so if anyone can help me, I will be very grateful.

My Multibit wallet is empty

I had a few bitcoins in a Multibit wallet version 0.5.14 on my old computer. I decided to start up the old computer again and transfer the bitcoins to a hard wallet. I opened it up and there’s nothing in it. The wallet appears to have synchronized. I can remember before I used to input a password to see what was in my wallet but that option doesn’t come up anymore. Does anybody have any advice? Please don’t be too technical in your replies. Thanks.