text:
How may bitcoins hash algorithm be secured in the future from quantum computing brute forcing?
Other threads already answer very clearly that quantum comps could easily "break" /attack bitcoins chain.
Now: Are there any ideas among the bitcoin devs circulating out there, how to save bitcoin from future quantum attacks? its only a couple years away right?
What could be viable options to change and make btc quantum proof, changing hashing algorithm to which new algorithm?
Thanks!
__

Possible duplicate of What effects would a scalable Quantum Computer have on Bitcoin?

it is not a real duplicate. your referenced link talks about the effect. So it only partly answers my question (yes, bitcoin would break easily by quantum comps).
But 2nd question is still valid:  Are there currently any code changes discussed for the future by btc core devs?  And how could solutions to this quantum problems look like, changing hashing algorithm to which new algorithm?
or is this really too far away in the future? I think not

The hashing algorithm is probably the most quantum-resistant piece of cryptography right now in Bitcoin. Barring any specific breaks, SHA256 and RIPEMD160 are as quantum-resistant as hash functions can be (there is an inevitable square-root speedup that applies to any hash function). Much more can be said about the quantum resistance of digital signatures.

@PieterWuille  hi thx. i did not know that sha256 is secure. makes sense, its symmetric
-Then pls tell me, which precise parameters of bitcoins chain would be susceptible to quantum attacks (u said signatures, what else)?

And what could be ways to prevent future attacks on those parameters? Any ideas circulating among btc dev community on how to "adjust" those parameters?   -

Or is the current consensus rather to wait for the crypto community till they provide new crypto schemes which are quantum proof (waiting for the NIST Post-Quantum Crypto  Competition ) ... thank u very much!

It is currently understood that quantum computers could theoretically offer a quadratic speed-up in cracking hash function preimages using Grover's algorithm, and cubic speed-up in finding hash collisions using Brassard-Høyer-Tapp algorithm.
It is also understood that elliptic-curve cryptography would be the the first to go as it could be completely broken using Shor's algorithm.
We summarize this in the table below:

Primitive
Conventional Computing Security Level
Quantum Computing Security Level

ECC-256
128 bits
0 bits

SHA-256
256 bits (preimage) / 128 bits (collision)
128 bits (preimage) / 85 bits (collision)

HASH-256
256 bits (preimage) / 128 bits (collision)
128 bits (preimage) / 85 bits (collision)

RIPEMD-160
160 bits (preimage) / 80 bits (collision)
80 bits (preimage) / 53 bits (collision)

HASH-160
160 bits (preimage) / 80 bits (collision)
80 bits (preimage) / 53 bits (collision)

From that we can say it is not so much about the algorithm - it is more about the hash function output size. Quantum computing doesn't break the algorithm but offers a speed-up for ANY algorithm, so all we'd need to do is pick one and increase the hash output size to 384 bits so we can maintain the 128 bits of security against collision attacks. BLAKE2 or SHA-3 would be good candidates. Even the SHA-2 familiy SHA-384 would be OK.
Actually implementing this in Bitcoin protocol would not be trivial, because a change of hash function would break a lot of software out there.


text:
Bitcoin privacy - current state of privacy BIPs - is mimblewimble broken?
Community,
what is the current state of privacy related BIPs? Anything on the roadmap by core devs to be deployed on main chain within the next year?  IF yes, could you link me to this BIP(s)?
And regarding mimblewimble: you are aware i assume on the latest researcher claims about broken privacy model of mimble wimble? This guy's analysis looks convincing.

"As Bogatty put it, all transactions on Mimblewimble are put into a
  single CoinJoin, which leaves anonymity set with all the transactions
  being located on one block. Unlike other privacy cryptocurrency
  networks and cons which shield their anonymity sets and transactions,
  Mimblewimble has this inherent flaw, and he was able to exploit it and
  access those transaction details."

quote from: https://insidebitcoins.com/news/litecoin-ceo-defends-mimblewimble-against-privacy-critics/242702

Now, I think the current BIPs have all somehow a mimblewimble-like or CoinJoin-Like approach to solving privacy, right??
Would above quote from BOgatty also apply to the current privacy BIPs (or to the majority of them)? Without claiming whether it is a flaw or not, just the basic fact: do the currently leading privacy BIPs have this approach of "putting transactions  into a single CoinJoin"?

Would be nice if someone can clarify the state of privacy with Bitcoin, or the future state.
Thanks

Community, what is the current state of privacy related BIPs?

CoinJoin related ones:

Adam Gibson's SNICKER draft, which permits a simple unidirectional CoinJoin construction.
BIP 79, Bustapay, a standard for CoinJoined payments.

P2P improvements:

BIP 156, Dandelion: routing newly broadcast transactions a few hops before broadcasting.
Draft for BIP 324: encryption of the P2P layer, making transaction origin harder to find for passive attackers
Draft for Erlay BIP: (less directly privacy focused) introduces a lower-bandwidth, less directed, transaction broadcast mechanism

Consensus rules:

My own draft for BIP-taproot

The first set of these are not consensus or protocol changes to Bitcoin's network. They're merely standards that wallet can choose to implement to improve privacy of their own transactions. There are many more techniques that may or may not be implemented by wallets which aren't written up as formal BIPs, see this great article on the Bitcoin.it wiki by Chris Belcher with an overview: https://en.bitcoin.it/wiki/Privacy

Anything on the roadmap by core devs to be deployed on main chain within the next year?

Privacy is a complex topic, and while there are some things possible at the protocol level where core developers may be more involved, there is far more to be done at the wallet level. The taproot proposal is an example of a protocol level change: it aims to improve a different type: on-chain policy privacy. This is the problem that the type of scripts your wallet chooses to use on the network reveals what kind of things it is doing (e.g. Multisig, Lightning, 2FA, ...). The goal of Taproot is to make sure that in cooperative cases, all transaction outputs and inputs look indistinguishable. This is completely distinct from the type of privacy leak that CoinJoin-style approaches (which expose linkage between transactions).
As for when it might activate on the network, I doubt anyone can tell you. That is up to the community.

And regarding mimblewimble: you are aware i assume on the latest researcher claims about broken privacy model of mimble wimble?

I think that's a highly confused statement. Mimblewimble itself does not provide any privacy improvement. It is an improved designed over Confidential Transactions (which is a privacy technique, hiding transaction amounts), making it more scalable and enabling non-interactive CoinJoin.
If you look at the original Mimblewimble paper by Tom Elvis Jedusor, or the more formal paper by Andrew Poelstra, you'll see that privacy is only mentioned in the context of what is provided by CT, or enabled by CoinJoin.
CoinJoin itself is not broken, but how it is used matters a lot. In correct usage, participants interact privately to jointly construct a single transaction, which, when revealed to the public, cannot be disassembled into the individual participants' contributions. What happened in a particular Mimblewimble implementation was they use CoinJoin on the public network. It should be obvious that this does not grant any privacy to anyone observing the network, as they can easily see all individual contributions to transactions. This is not a bad idea either, but it's only a scalability gain. For privacy, CoinJoin needs to happen elsewhere too.
So again: CoinJoin is not broken; it helps when used right. Mimblewimble or its privacy is also not broken - Confidential Transactions and the ability for non-interactive CoinJoin are great. Mimblewimble also enables non-interactive CoinJoin, which happens to be usable as a scalability improvement as well, but when done publicly, does not improve privacy.

Now, I think the current BIPs have all somehow a mimblewimble-like or CoinJoin-Like approach to solving privacy, right??

You don't "solve" privacy. Privacy is a goal to achieve, but it's multifaceted, and isn't solved by a single piece of technology. Significant parts of privacy are about education and incentives, not a magic bullet technology that suddenly hides everything.
Also, to the best of my knowledge nobody has seriously proposed Mimblewimble in Bitcoin.

Would above quote from BOgatty also apply to the current privacy BIPs (or to the majority of them)? Without claiming whether it is a flaw or not, just the basic fact: do the currently leading privacy BIPs have this approach of "putting transactions into a single CoinJoin"?

No, because it doesn't apply to CoinJoin. It applies to the use of a scalability improvement inherent to Mimblewimble implementations, which has been misrepresented by some as a privacy gain.

Would be nice if someone can clarify the state of privacy with Bitcoin, or the future state.

It's hard, but we'll get there.

source: Stack Exchange

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

sort: votes


text:
A security need for Bitcoin to fork to quantum resistant algorithm in a few years?
in just a few years I believe that quantums will exist that break asymmetric ciphers, and bitcoin is based on asymmetric ones like public-key-cryptography, correct? Symmetric algorithms are supposed to be safe.
Question is to experts here:
1) Which components of the bitcoin blockchain would be exposed to quantum attacks?
2) Are these components relevant the the blockchain's full functionality if they get "broken" or just minor nuisance but no major negative impact?
3) What do bitcoin (core)devs brainstorm currently, what could be feasible methods to make these above components more resistant against quantums?
Thanks for insights

asymmetric ciphers

Ones based on specific primitives, like RSA and ECDSA specifically.

Symmetric algorithms are supposed to be safe.

With approximately half the number of bits of security due to Grover's algorithm.

Which components of the bitcoin blockchain would be exposed to quantum attacks?

The security of SHA256 would be halved, ECDSA would be weaked beyond usability. In Bitcoin raw ECDSA keys are typically only exposed during the portion of time when the transaction is signed and when it is confirmed, assuming that there are not large chain reorganisations ("double spending") during this time, the window of opportunity is relatively limited.
Due to the way many pieces of software re-use keys, this is not the case for a large portion of the total Bitcoin in existence however. More than 10B USD worth of UTXOs are stored in addresses with known ECDSA public keys, which would be the obvious target for anybody to steal.

Are these components relevant the the blockchain's full functionality if they get "broken" or just minor nuisance but no major negative impact?

Generally speaking, all money would be vulnerable to being stolen without consequence or interaction from its owner.

what could be feasible methods to make these above components more resistant against quantums?

Bitcoin has upgrade paths available to it to use quantum safe cryptography like hash based signatures if such a thing were necessary in the future, but there's not a lot of strong evidence to suggest that true quantum computers that are capable of running the sort of algorithms will ever exist. We would expect to see gradual progress towards it rather than a definitive success story about it anyway, which gives a lot of room for making these sorts of changes.
Why don't we use hash based cryptography today? It's fairly awful and to be avoided unless necessary.                           Signatures are extremely large, public keys are even larger, and they don't allow for interesting constructions like is the case with ECDSA / Schnorr.

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


text:
Missing btc in personal wallet
I am missing BTC in my personal copay wallet.
https://live.blockcypher.com/btc/address/1HJKHvzxRjKFDcHopyLqLgL3RhWAGipgYY/
https://live.blockcypher.com/btc/tx/7b99ec55d467578ec3fece195e21a2922f974768210d9ec349dbcd9c57a768e4/

If you did not send the Bitcoin's then someone has access to your account or private key. This could happen many ways, if you have ever shared your login details with anyone or, your backup seed, logged in through internet cafe's or strange computers or if your phone or computer are hacked to name a few possibilities.


text:
Importing a private key (paper wallet) to Bitcoin Core client, while offline, is not actually importing
Trying to import a paper wallet to bitcoin core, while not having a fully synced node.
I've used: importprivkey 1Lblablablablabla "MyLabel" false
It returns "null", which I understand means successful import.
But then when I use dumpprivkey with the associated public address, it says there is no private key associated with the address.
I also look in the GUI and can't find any clue as to where that private key has been imported.
So basically the wallet is not giving me errors of failed import, but also not actually importing the private key.
What should I do?

What command did you use to import the key? It sounds like you just imported a bitcoin address, not a private key.

I wrote the exact command, importprivkey "private_key" (without the quotes). I'm not going to write the actual private key here, obviously.

does the private key you imported start with a '1'? If so, that sounds like it is a bitcoin address, not a privkey. You are right to not post what the privkey is exactly, but it may be helpful to describe it (ie, what character does it start with? how long of a string is it?), to ensure you're attempting to import a key with the correct format.

Compare the length, mix of character types and initial character of your private key value with examples in private key and address - this will help you discover if the value you have is one or the other. Also any small mistake in typing will be important.

It starts with L3y... I can see how my first example key written here was misleading starting with a 1. But I am using a proper private key for sure..

Does dumpwallet show anything relevant?

Actually yes I manage to see the imported private key in that dump file!

Ok from the dump file it's clear that I was using the wrong PUBLIC address and that's why it didn't give me a private key back... thank you!

You can use dumpwallet to examine the wallet's contents after importing the private key.
(for completeness, since comments are disposable)


text:
Error -26: mandatory-script-verify-flag-failed (Signature must be zero for failed CHECK(MULTI)SIG operation)
I've created a raw transaction, and I get this error when I try to send it with sendrawtransaction to my local bitcoin regtest:
{
    "error": {
        "code": -26,
        "message": "mandatory-script-verify-flag-failed (Signature must be zero for failed CHECK(MULTI)SIG operation)"
    },
    "id": "1",
    "result": null
}

This is the transaction from which I want to spend:
{
    "error": null,
    "id": "1",
    "result": {
        "hash": "95d4f6bbdda2ec79350c0559d5d9e9c279f73e5d37f8267834034a40c6d520c2",
        "hex": "0200000001c1c8886fe4e25ee471423e000532412b387fb0fea11a17a68cea09c122229e2c010000006a473044022029296a6ac3fdaf0a0c4616c783bee1b3b5f7ea24a63f3df3544e74aa4c1a65b102207baa71419ef0ceff6218e78b6fb93bfe6ac7445584e23d20be1fbf6454bab50f012102a4379f994ccce7041d30026092b13a7987c12cd6e33222dabdf890a00fc50b2effffffff01e0d96aee000000001976a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac00000000",
        "locktime": 0,
        "size": 191,
        "txid": "95d4f6bbdda2ec79350c0559d5d9e9c279f73e5d37f8267834034a40c6d520c2",
        "version": 2,
        "vin": [
            {
                "scriptSig": {
                    "asm": "3044022029296a6ac3fdaf0a0c4616c783bee1b3b5f7ea24a63f3df3544e74aa4c1a65b102207baa71419ef0ceff6218e78b6fb93bfe6ac7445584e23d20be1fbf6454bab50f[ALL] 02a4379f994ccce7041d30026092b13a7987c12cd6e33222dabdf890a00fc50b2e",
                    "hex": "473044022029296a6ac3fdaf0a0c4616c783bee1b3b5f7ea24a63f3df3544e74aa4c1a65b102207baa71419ef0ceff6218e78b6fb93bfe6ac7445584e23d20be1fbf6454bab50f012102a4379f994ccce7041d30026092b13a7987c12cd6e33222dabdf890a00fc50b2e"
                },
                "sequence": 4294967295,
                "txid": "2c9e2222c109ea8ca6171aa1feb07f382b413205003e4271e45ee2e46f88c8c1",
                "vout": 1
            }
        ],
        "vout": [
            {
                "n": 0,
                "scriptPubKey": {
                    "addresses": [
                        "moinqaiuWShfsemB9nGcAGFZNMa3ZwPMq6"
                    ],
                    "asm": "OP_DUP OP_HASH160 59fe1a9f9f0a5af33396c59990f064be1ca51274 OP_EQUALVERIFY OP_CHECKSIG",
                    "hex": "76a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac",
                    "reqSigs": 1,
                    "type": "pubkeyhash"
                },
                "value": 39.9998
            }
        ],
        "vsize": 191,
        "weight": 764
    }
}

I performed the following steps:

Create the raw transaction. This is the raw transaction:

0100000001c220d5c6404a03347826f8375d3ef779c2e9d9d559050c3579eca2ddbbf6d495000000001976a91459fe1a9f9f0a5af33396c59990f064be1ca5127488acffffffff020065cd1d000000001976a9141af72e49ec135151f1421c185b6cb1ce836576c388acc0269dd0000000001976a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac00000000

{
    "error": null,
    "id": "1",
    "result": {
        "hash": "16fa981ab0af1b0516467f80c71ced3e6b0d58e3fdd80137320029633dce1881",
        "locktime": 0,
        "size": 144,
        "txid": "16fa981ab0af1b0516467f80c71ced3e6b0d58e3fdd80137320029633dce1881",
        "version": 1,
        "vin": [
            {
                "scriptSig": {
                    "asm": "OP_DUP OP_HASH160 59fe1a9f9f0a5af33396c59990f064be1ca51274 OP_EQUALVERIFY OP_CHECKSIG",
                    "hex": "76a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac"
                },
                "sequence": 4294967295,
                "txid": "95d4f6bbdda2ec79350c0559d5d9e9c279f73e5d37f8267834034a40c6d520c2",
                "vout": 0
            }
        ],
        "vout": [
            {
                "n": 0,
                "scriptPubKey": {
                    "addresses": [
                        "mhyXyTy4fnu2jcmAGeChkgd9RmNgTg7xV5"
                    ],
                    "asm": "OP_DUP OP_HASH160 1af72e49ec135151f1421c185b6cb1ce836576c3 OP_EQUALVERIFY OP_CHECKSIG",
                    "hex": "76a9141af72e49ec135151f1421c185b6cb1ce836576c388ac",
                    "reqSigs": 1,
                    "type": "pubkeyhash"
                },
                "value": 5
            },
            {
                "n": 1,
                "scriptPubKey": {
                    "addresses": [
                        "moinqaiuWShfsemB9nGcAGFZNMa3ZwPMq6"
                    ],
                    "asm": "OP_DUP OP_HASH160 59fe1a9f9f0a5af33396c59990f064be1ca51274 OP_EQUALVERIFY OP_CHECKSIG",
                    "hex": "76a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac",
                    "reqSigs": 1,
                    "type": "pubkeyhash"
                },
                "value": 34.9996
            }
        ],
        "vsize": 144,
        "weight": 576
    }
}

Add 01000000 at the of the transaction. This is the hex of the transaction before signing:

0100000001c220d5c6404a03347826f8375d3ef779c2e9d9d559050c3579eca2ddbbf6d495000000001976a91459fe1a9f9f0a5af33396c59990f064be1ca5127488acffffffff020065cd1d000000001976a9141af72e49ec135151f1421c185b6cb1ce836576c388acc0269dd0000000001976a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac0000000001000000

Double SHA256 the raw transaction from step 2. This is the hash:

0b5a635ff615175cb114f051ea89e3f90e373dc059fc5ec8059ceeea4b42099f

Sign the transaction. To sign the transaction I have to use an endpoint of an HSM. I have to send the public key and the hex of the transaction and it returns the signature. The returned signature looks like this:

3044022052fe83beb097408e84d138bc4f723507f626b0f07019385df2103ebfc559a67a02206b5281554dfd80f1a29a0257d9cdfe07a7f7684d52c6ef875678ea3e3d289451

This is the public key:
3056301006072a8648ce3d020106052b8104000a034200049665be7c887cc801b1f6c5bb189434aa0a0635cd23d3b62832ffe3be70e9a3af64b03bb1217ee29ff2a0d5a88ff433c531cef6ba29f080e047f24f7e612bd93b

This is the signed transaction:
0100000001c220d5c6404a03347826f8375d3ef779c2e9d9d559050c3579eca2ddbbf6d495000000008a473044022052fe83beb097408e84d138bc4f723507f626b0f07019385df2103ebfc559a67a02206b5281554dfd80f1a29a0257d9cdfe07a7f7684d52c6ef875678ea3e3d2894510141049665be7c887cc801b1f6c5bb189434aa0a0635cd23d3b62832ffe3be70e9a3af64b03bb1217ee29ff2a0d5a88ff433c531cef6ba29f080e047f24f7e612bd93bffffffff020065cd1d000000001976a9141af72e49ec135151f1421c185b6cb1ce836576c388acc0269dd0000000001976a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac00000000

{
    "error": null,
    "id": "1",
    "result": {
        "hash": "5fcf741fba06e52692d731e69bf937e1e92d0439b3976f54dc733a90dd93a288",
        "locktime": 0,
        "size": 257,
        "txid": "5fcf741fba06e52692d731e69bf937e1e92d0439b3976f54dc733a90dd93a288",
        "version": 1,
        "vin": [
            {
                "scriptSig": {
                    "asm": "3044022052fe83beb097408e84d138bc4f723507f626b0f07019385df2103ebfc559a67a02206b5281554dfd80f1a29a0257d9cdfe07a7f7684d52c6ef875678ea3e3d289451[ALL] 049665be7c887cc801b1f6c5bb189434aa0a0635cd23d3b62832ffe3be70e9a3af64b03bb1217ee29ff2a0d5a88ff433c531cef6ba29f080e047f24f7e612bd93b",
                    "hex": "473044022052fe83beb097408e84d138bc4f723507f626b0f07019385df2103ebfc559a67a02206b5281554dfd80f1a29a0257d9cdfe07a7f7684d52c6ef875678ea3e3d2894510141049665be7c887cc801b1f6c5bb189434aa0a0635cd23d3b62832ffe3be70e9a3af64b03bb1217ee29ff2a0d5a88ff433c531cef6ba29f080e047f24f7e612bd93b"
                },
                "sequence": 4294967295,
                "txid": "95d4f6bbdda2ec79350c0559d5d9e9c279f73e5d37f8267834034a40c6d520c2",
                "vout": 0
            }
        ],
        "vout": [
            {
                "n": 0,
                "scriptPubKey": {
                    "addresses": [
                        "mhyXyTy4fnu2jcmAGeChkgd9RmNgTg7xV5"
                    ],
                    "asm": "OP_DUP OP_HASH160 1af72e49ec135151f1421c185b6cb1ce836576c3 OP_EQUALVERIFY OP_CHECKSIG",
                    "hex": "76a9141af72e49ec135151f1421c185b6cb1ce836576c388ac",
                    "reqSigs": 1,
                    "type": "pubkeyhash"
                },
                "value": 5
            },
            {
                "n": 1,
                "scriptPubKey": {
                    "addresses": [
                        "moinqaiuWShfsemB9nGcAGFZNMa3ZwPMq6"
                    ],
                    "asm": "OP_DUP OP_HASH160 59fe1a9f9f0a5af33396c59990f064be1ca51274 OP_EQUALVERIFY OP_CHECKSIG",
                    "hex": "76a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac",
                    "reqSigs": 1,
                    "type": "pubkeyhash"
                },
                "value": 34.9996
            }
        ],
        "vsize": 257,
        "weight": 1028
    }
}

Send the signed transaction with rpc sendrawtransaction:

{"id":"1","jsonrpc":"1.0","method":"sendrawtransaction","params":["0100000001c220d5c6404a03347826f8375d3ef779c2e9d9d559050c3579eca2ddbbf6d495000000008a473044022052fe83beb097408e84d138bc4f723507f626b0f07019385df2103ebfc559a67a02206b5281554dfd80f1a29a0257d9cdfe07a7f7684d52c6ef875678ea3e3d2894510141049665be7c887cc801b1f6c5bb189434aa0a0635cd23d3b62832ffe3be70e9a3af64b03bb1217ee29ff2a0d5a88ff433c531cef6ba29f080e047f24f7e612bd93bffffffff020065cd1d000000001976a9141af72e49ec135151f1421c185b6cb1ce836576c388acc0269dd0000000001976a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac00000000"]}

sendrawtransaction returns the following error:
{
    "error": {
        "code": -26,
        "message": "mandatory-script-verify-flag-failed (Signature must be zero for failed CHECK(MULTI)SIG operation)"
    },
    "id": "1",
    "result": null
}

What does this error mean? What am I doing wrong?

How does the HSM sign the transaction? Does it understand that it is a Bitcoin transaction and needs to be serialized in a certain way before signing? Does it know that it needs to be hashed twice with SHA256? Or is it just a generic HSM that hashes things once and makes the signature?

I serialize and hash the transaction (see step 2 above) before sending it to the HSM. It just signs the byte array with the private key, which belongs to the public key, and returns the signature.

... and the signature seems to be valid. The HSM also has an endpoint to verify the signature. It returns true if I verify it.

After some source code reading, I found out that my transactions most probably fails here: https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L368 Now the question is, which conditions triggers the failure.

This error message just means your signature is wrong (most likely because you're signing the wrong thing).

Does that mean that there is something wrong with the unsigned raw transaction? Can somebody have a look at it and maybe point out what is wrong with it?

The problem is that you are serializing the transaction for signing incorrectly. The data that is signed is not just the raw transaction with the sighash appended to it. You need to slightly modify it too. Specifically, for the input currently being signed, you need to put the scriptCode into that input's scriptSig. The scriptSigs of all other inputs must be empty.
The scriptCode is the scriptPubKey of the output being spent by that input except for P2SH. If the output is a P2SH output, then you need to use the redeemScript.
So you should be signing:
0100000001c220d5c6404a03347826f8375d3ef779c2e9d9d559050c3579eca2ddbbf6d495000000001976a91459fe1a9f9f0a5af33396c59990f064be1ca5127488acffffffff020065cd1d000000001976a9141af72e49ec135151f1421c185b6cb1ce836576c388ace0749dd0000000001976a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac00000000

Furthermore, Bitcoin uses double sha256. If your HSM hashes the message with SHA256, then you need to give it the first hash. So you have to hash the above once with SHA256 then give that hash to the HSM. If it just takes the hash, then you need to hash it with SHA256 twice.

Thank you very much. I changed it in the application and updated my original question accordingly. No I get the same output as yours. The HSM doesn't do any hashing. I double sha256 the serialized transaction which results in the following hash: bf2fa5a5f3fbc93f4b4db2f7a43f8b45ecfb2bdccfb80d55843cd9a0841c94fc Then I send this hash with the public key to the HSM and it returns the signature. But I still get the same error.

Just to make sure: I have to sign the transaction with the private key of the address, which is in vout of the transaction from which I want to spend. in my case: moinqaiuWShfsemB9nGcAGFZNMa3ZwPMq6 Correct?

There's a discrepancy between raw original raw transaction and the signed one. The signed one has an output with a value of 34.9996 but the non-signed one is 34.9998.

I read somewhere, that in the raw original transaction the sum of the values in vout, has to match the the value of the vout of the unspent transaction output. Is that wrong?
Now I calculate the values in the raw original transaction and the signed transaction like this: totalUspent - transactionValue - transactionFee (0.0002). Is that correct? I updated it again in my original question, but I still get the same error.

The unsigned transaction is exactly the same as the signed one except the scriptSigs are empty. The values are the same as in the final transaction. It is highly likely that you are misunderstanding whatever it is that you read. Your hash is now just completely wrong. I don't know how you calculated that hash as the data you are supposed to be hashing is correct.

Now I got it. I was able to broadcast the transaction without any errors. Thank you very much for your help. I will post the working example below.

Now I would like to create a raw transactions out of multiple UTXOs. I didn't fully understand your answer above. I've posted a new question for this: https://bitcoin.stackexchange.com/questions/95546/how-does-vin-have-to-look-like-with-multiple-inputs-in-a-raw-transaction

I'm sorry for the delving but it's not very widespread information: w.r.t. P2SH scriptCode what do you mean "then you need to use the redeemScript.", is it the default "OPHASH160 OP_PUSHBYTES_20 scriptHash OP_EQUAL" used by the output to be spent, or the custom script that will be used in the redeemScript?

@T.Rossi The redeemScript is the custom script.

@AndrewChow thanks, so if I'm about to spend a custom script P2SH output, the redeemscript is also used as placeholder for scriptSig in the dummy tx to create the message to sign. Well, I must have some other error around, thanks anyway for confirming that!

An error -26 almost always means your sighash is not constructed properly or that you did not hash it correctly. Unlike most other things in Bitcoin, sighashes are only hashed once.
In these cases, I recommend you cross-reference your sighashes and raw transactions by those generated by other programs. If you know Python then bit is a good library to start with as you can clone the repository and add some PDB breakpoints on the lines where the sighashes are made so that you can look at them for yourself.

Finally I was able to create a raw transaction, sign it on the HSM and broadcast it. Here is my working example:
The transaction from which I want to spend:
{
    "error": null,
    "id": "1",
    "result": {
        "hash": "1a8e4c9b19357a7ec187d7f9e062670e269973648a693c7f510dcd4c5812498d",
        "hex": "0100000001661b9987b96a6ff5731b045cd4c6bbaccbd4947996b789fcfc48d93e958b006a010000008b483045022100dc4da7f2b24090c9df8af280b3809bbfc7f8bc869bfaa16d7feb4f986562071602200ea902b3602435128663eaf6ae3d9652f4b8c9038225a7a2f4b820f741fa81190141049665be7c887cc801b1f6c5bb189434aa0a0635cd23d3b62832ffe3be70e9a3af64b03bb1217ee29ff2a0d5a88ff433c531cef6ba29f080e047f24f7e612bd93bffffffff0200e1f505000000001976a9141af72e49ec135151f1421c185b6cb1ce836576c388aca0f7a6ca000000001976a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac00000000",
        "locktime": 0,
        "size": 258,
        "txid": "1a8e4c9b19357a7ec187d7f9e062670e269973648a693c7f510dcd4c5812498d",
        "version": 1,
        "vin": [
            {
                "scriptSig": {
                    "asm": "3045022100dc4da7f2b24090c9df8af280b3809bbfc7f8bc869bfaa16d7feb4f986562071602200ea902b3602435128663eaf6ae3d9652f4b8c9038225a7a2f4b820f741fa8119[ALL] 049665be7c887cc801b1f6c5bb189434aa0a0635cd23d3b62832ffe3be70e9a3af64b03bb1217ee29ff2a0d5a88ff433c531cef6ba29f080e047f24f7e612bd93b",
                    "hex": "483045022100dc4da7f2b24090c9df8af280b3809bbfc7f8bc869bfaa16d7feb4f986562071602200ea902b3602435128663eaf6ae3d9652f4b8c9038225a7a2f4b820f741fa81190141049665be7c887cc801b1f6c5bb189434aa0a0635cd23d3b62832ffe3be70e9a3af64b03bb1217ee29ff2a0d5a88ff433c531cef6ba29f080e047f24f7e612bd93b"
                },
                "sequence": 4294967295,
                "txid": "6a008b953ed948fcfc89b7967994d4cbacbbc6d45c041b73f56f6ab987991b66",
                "vout": 1
            }
        ],
        "vout": [
            {
                "n": 0,
                "scriptPubKey": {
                    "addresses": [
                        "mhyXyTy4fnu2jcmAGeChkgd9RmNgTg7xV5"
                    ],
                    "asm": "OP_DUP OP_HASH160 1af72e49ec135151f1421c185b6cb1ce836576c3 OP_EQUALVERIFY OP_CHECKSIG",
                    "hex": "76a9141af72e49ec135151f1421c185b6cb1ce836576c388ac",
                    "reqSigs": 1,
                    "type": "pubkeyhash"
                },
                "value": 1
            },
            {
                "n": 1,
                "scriptPubKey": {
                    "addresses": [
                        "moinqaiuWShfsemB9nGcAGFZNMa3ZwPMq6"
                    ],
                    "asm": "OP_DUP OP_HASH160 59fe1a9f9f0a5af33396c59990f064be1ca51274 OP_EQUALVERIFY OP_CHECKSIG",
                    "hex": "76a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac",
                    "reqSigs": 1,
                    "type": "pubkeyhash"
                },
                "value": 33.9994
            }
        ],
        "vsize": 258,
        "weight": 1032
    }
}

The serialized unsigned raw transaction hash:
01000000018d4912584ccd0d517f3c698a647399260e6762e0f9d787c17e7a35199b4c8e1a010000001976a91459fe1a9f9f0a5af33396c59990f064be1ca5127488acffffffff0200e1f505000000001976a9141af72e49ec135151f1421c185b6cb1ce836576c388ac80c8b0c4000000001976a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac00000000

The decoded unsigned raw transaction:
{
    "error": null,
    "id": "1",
    "result": {
        "hash": "338615b2f4ece5132c3a275b8559863061e6eb1acdcf237a63c4d11980fb8aba",
        "locktime": 0,
        "size": 144,
        "txid": "338615b2f4ece5132c3a275b8559863061e6eb1acdcf237a63c4d11980fb8aba",
        "version": 1,
        "vin": [
            {
                "scriptSig": {
                    "asm": "OP_DUP OP_HASH160 59fe1a9f9f0a5af33396c59990f064be1ca51274 OP_EQUALVERIFY OP_CHECKSIG",
                    "hex": "76a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac"
                },
                "sequence": 4294967295,
                "txid": "1a8e4c9b19357a7ec187d7f9e062670e269973648a693c7f510dcd4c5812498d",
                "vout": 1
            }
        ],
        "vout": [
            {
                "n": 0,
                "scriptPubKey": {
                    "addresses": [
                        "mhyXyTy4fnu2jcmAGeChkgd9RmNgTg7xV5"
                    ],
                    "asm": "OP_DUP OP_HASH160 1af72e49ec135151f1421c185b6cb1ce836576c3 OP_EQUALVERIFY OP_CHECKSIG",
                    "hex": "76a9141af72e49ec135151f1421c185b6cb1ce836576c388ac",
                    "reqSigs": 1,
                    "type": "pubkeyhash"
                },
                "value": 1
            },
            {
                "n": 1,
                "scriptPubKey": {
                    "addresses": [
                        "moinqaiuWShfsemB9nGcAGFZNMa3ZwPMq6"
                    ],
                    "asm": "OP_DUP OP_HASH160 59fe1a9f9f0a5af33396c59990f064be1ca51274 OP_EQUALVERIFY OP_CHECKSIG",
                    "hex": "76a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac",
                    "reqSigs": 1,
                    "type": "pubkeyhash"
                },
                "value": 32.9992
            }
        ],
        "vsize": 144,
        "weight": 576
    }
}

The signature of the signed raw transaction:
3045022100eac45a27b4acd459b386f18461b851e94a9f94bec8a2896af64bc57934926ca8022023cc300a10df5fdead368d6fbd4a109b06baadc920f5a893f3721faef669e122

The public key:
3056301006072a8648ce3d020106052b8104000a034200049665be7c887cc801b1f6c5bb189434aa0a0635cd23d3b62832ffe3be70e9a3af64b03bb1217ee29ff2a0d5a88ff433c531cef6ba29f080e047f24f7e612bd93b

The serialized signed transaction:
01000000018d4912584ccd0d517f3c698a647399260e6762e0f9d787c17e7a35199b4c8e1a010000008b483045022100eac45a27b4acd459b386f18461b851e94a9f94bec8a2896af64bc57934926ca8022023cc300a10df5fdead368d6fbd4a109b06baadc920f5a893f3721faef669e1220141049665be7c887cc801b1f6c5bb189434aa0a0635cd23d3b62832ffe3be70e9a3af64b03bb1217ee29ff2a0d5a88ff433c531cef6ba29f080e047f24f7e612bd93bffffffff0280285b01000000001976a9141af72e49ec135151f1421c185b6cb1ce836576c388ac00000000000000001976a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac00000000

The decoded signed transaction:
{
    "error": null,
    "id": "1",
    "result": {
        "hash": "8855a7927cffd939fc9f42933c84cc6a584a1cf76225c2b30963e2103041c1ae",
        "locktime": 0,
        "size": 258,
        "txid": "8855a7927cffd939fc9f42933c84cc6a584a1cf76225c2b30963e2103041c1ae",
        "version": 1,
        "vin": [
            {
                "scriptSig": {
                    "asm": "3045022100eac45a27b4acd459b386f18461b851e94a9f94bec8a2896af64bc57934926ca8022023cc300a10df5fdead368d6fbd4a109b06baadc920f5a893f3721faef669e122[ALL] 049665be7c887cc801b1f6c5bb189434aa0a0635cd23d3b62832ffe3be70e9a3af64b03bb1217ee29ff2a0d5a88ff433c531cef6ba29f080e047f24f7e612bd93b",
                    "hex": "483045022100eac45a27b4acd459b386f18461b851e94a9f94bec8a2896af64bc57934926ca8022023cc300a10df5fdead368d6fbd4a109b06baadc920f5a893f3721faef669e1220141049665be7c887cc801b1f6c5bb189434aa0a0635cd23d3b62832ffe3be70e9a3af64b03bb1217ee29ff2a0d5a88ff433c531cef6ba29f080e047f24f7e612bd93b"
                },
                "sequence": 4294967295,
                "txid": "1a8e4c9b19357a7ec187d7f9e062670e269973648a693c7f510dcd4c5812498d",
                "vout": 1
            }
        ],
        "vout": [
            {
                "n": 0,
                "scriptPubKey": {
                    "addresses": [
                        "mhyXyTy4fnu2jcmAGeChkgd9RmNgTg7xV5"
                    ],
                    "asm": "OP_DUP OP_HASH160 1af72e49ec135151f1421c185b6cb1ce836576c3 OP_EQUALVERIFY OP_CHECKSIG",
                    "hex": "76a9141af72e49ec135151f1421c185b6cb1ce836576c388ac",
                    "reqSigs": 1,
                    "type": "pubkeyhash"
                },
                "value": 0.2275136
            },
            {
                "n": 1,
                "scriptPubKey": {
                    "addresses": [
                        "moinqaiuWShfsemB9nGcAGFZNMa3ZwPMq6"
                    ],
                    "asm": "OP_DUP OP_HASH160 59fe1a9f9f0a5af33396c59990f064be1ca51274 OP_EQUALVERIFY OP_CHECKSIG",
                    "hex": "76a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac",
                    "reqSigs": 1,
                    "type": "pubkeyhash"
                },
                "value": 0
            }
        ],
        "vsize": 258,
        "weight": 1032
    }
}


text:
Error 26: mandatory-script-verify-flag-failed (Data push larger than necessary)
I've created a raw transaction, and I get this error when I try to send it with sendrawtransaction to my local bitcoin regtest.
{
    "error": {
        "code": -26,
        "message": "mandatory-script-verify-flag-failed (Data push larger than necessary)"
    },
    "id": "1",
    "result": null
}

This is the transaction from which I want to spend:
{
    "error": null,
    "id": "1",
    "result": {
        "hash": "5fd0ca7c1fa3ef3b04dbf8aa096999604d30c47b88cd41d3ba1b6fba91f919a3",
        "hex": "0200000000010116402fe74ebc194f15f19ca11c5d49266608b024363c0b077a17c02bee4d1d820100000000feffffff0200ca9a3b000000001976a91485defe3226b7ec0a1dda4130a7808771a251fbfc88ace81a70eb0000000016001457026508dac7e8d071392868751eaebd6dc4f4d50247304402203752e4d8a536427c0865033b6bafd5972e9a58f6021d45f2c9e04cf5c253f3bc022075efc85af662dbd91aff1623e54295c68ce57e32963433e5215cab0041fac530012102de4a99f805dab29bb0035a496ceca72e7078d53f7bec92ebb44560ef019d505600000000",
        "locktime": 0,
        "size": 225,
        "txid": "97ab9a72367ad6b7a4c2ee122366e625b4049f795e4f15450bf857ea49d9e43c",
        "version": 2,
        "vin": [
            {
                "scriptSig": {
                    "asm": "",
                    "hex": ""
                },
                "sequence": 4294967294,
                "txid": "821d4dee2bc0177a070b3c3624b0086626495d1ca19cf1154f19bc4ee72f4016",
                "txinwitness": [
                    "304402203752e4d8a536427c0865033b6bafd5972e9a58f6021d45f2c9e04cf5c253f3bc022075efc85af662dbd91aff1623e54295c68ce57e32963433e5215cab0041fac53001",
                    "02de4a99f805dab29bb0035a496ceca72e7078d53f7bec92ebb44560ef019d5056"
                ],
                "vout": 1
            }
        ],
        "vout": [
            {
                "n": 0,
                "scriptPubKey": {
                    "addresses": [
                        "msioJPYMmXYkXieUQfVWyFwcXBvoCYhy2Q"
                    ],
                    "asm": "OP_DUP OP_HASH160 85defe3226b7ec0a1dda4130a7808771a251fbfc OP_EQUALVERIFY OP_CHECKSIG",
                    "hex": "76a91485defe3226b7ec0a1dda4130a7808771a251fbfc88ac",
                    "reqSigs": 1,
                    "type": "pubkeyhash"
                },
                "value": 10
            },
            {
                "n": 1,
                "scriptPubKey": {
                    "addresses": [
                        "bcrt1q2upx2zx6cl5dqufe9p58284wh4kufax477qlqr"
                    ],
                    "asm": "0 57026508dac7e8d071392868751eaebd6dc4f4d5",
                    "hex": "001457026508dac7e8d071392868751eaebd6dc4f4d5",
                    "reqSigs": 1,
                    "type": "witness_v0_keyhash"
                },
                "value": 39.4999268
            }
        ],
        "vsize": 144,
        "weight": 573
    }
}

I performed the following steps:

Create the raw transaction. This is the raw transaction:

01000000013ce4d949ea57f80b45154f5e799f04b425e6662312eec2a4b7d67a36729aab970000000000ffffffff0100ca9a3b000000001976a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac00000000

{
    "error": null,
    "id": "1",
    "result": {
        "hash": "1495eb8ada986cfaed1dc6dce56dc667fe7264c924ee75018190e3c39947b391",
        "locktime": 0,
        "size": 85,
        "txid": "1495eb8ada986cfaed1dc6dce56dc667fe7264c924ee75018190e3c39947b391",
        "version": 1,
        "vin": [
            {
                "scriptSig": {
                    "asm": "",
                    "hex": ""
                },
                "sequence": 4294967295,
                "txid": "97ab9a72367ad6b7a4c2ee122366e625b4049f795e4f15450bf857ea49d9e43c",
                "vout": 0
            }
        ],
        "vout": [
            {
                "n": 0,
                "scriptPubKey": {
                    "addresses": [
                        "moinqaiuWShfsemB9nGcAGFZNMa3ZwPMq6"
                    ],
                    "asm": "OP_DUP OP_HASH160 59fe1a9f9f0a5af33396c59990f064be1ca51274 OP_EQUALVERIFY OP_CHECKSIG",
                    "hex": "76a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac",
                    "reqSigs": 1,
                    "type": "pubkeyhash"
                },
                "value": 10
            }
        ],
        "vsize": 85,
        "weight": 340
    }
}

Sign the raw transaction. I don't have access to the private keys, because they are stored in a HSM. To sign the transaction, I have to send the serialized transaction and the public key to the HSM endpoint. It signs the transaction with the private key, which belongs to the public key and returns the signature.

This is the singed transaction:
01000000013ce4d949ea57f80b45154f5e799f04b425e6662312eec2a4b7d67a36729aab9700000000440101410454a3553d447e4589d165d6fbe76e7bc3e472f107d223e1d051db37875bac09ba9b2ce89676b2e3c571d797bed67a525ecc16e904186692cdee40968cffaf5576ffffffff01e07b9a3b000000001976a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac00000000

{
    "error": null,
    "id": "1",
    "result": {
        "hash": "24dbf04b3070c9b8eb4b2eac37a7a1ec355763d9c008b5dc1ebc636867b322b8",
        "locktime": 0,
        "size": 153,
        "txid": "24dbf04b3070c9b8eb4b2eac37a7a1ec355763d9c008b5dc1ebc636867b322b8",
        "version": 1,
        "vin": [
            {
                "scriptSig": {
                    "asm": "1 0454a3553d447e4589d165d6fbe76e7bc3e472f107d223e1d051db37875bac09ba9b2ce89676b2e3c571d797bed67a525ecc16e904186692cdee40968cffaf5576",
                    "hex": "0101410454a3553d447e4589d165d6fbe76e7bc3e472f107d223e1d051db37875bac09ba9b2ce89676b2e3c571d797bed67a525ecc16e904186692cdee40968cffaf5576"
                },
                "sequence": 4294967295,
                "txid": "97ab9a72367ad6b7a4c2ee122366e625b4049f795e4f15450bf857ea49d9e43c",
                "vout": 0
            }
        ],
        "vout": [
            {
                "n": 0,
                "scriptPubKey": {
                    "addresses": [
                        "moinqaiuWShfsemB9nGcAGFZNMa3ZwPMq6"
                    ],
                    "asm": "OP_DUP OP_HASH160 59fe1a9f9f0a5af33396c59990f064be1ca51274 OP_EQUALVERIFY OP_CHECKSIG",
                    "hex": "76a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac",
                    "reqSigs": 1,
                    "type": "pubkeyhash"
                },
                "value": 9.9998
            }
        ],
        "vsize": 153,
        "weight": 612
    }
}

What am I doing wrong?
Update 1: Based on the answer of MCCCS I changed 0101 to 0x51. Now my signed transaction looks like this:
{
    "error": null,
    "id": "1",
    "result": {
        "hash": "f1b87be3d529004e14a9e13cb59849a027191862872fc8c964e37c1a60d05e81",
        "locktime": 0,
        "size": 153,
        "txid": "f1b87be3d529004e14a9e13cb59849a027191862872fc8c964e37c1a60d05e81",
        "version": 1,
        "vin": [
            {
                "scriptSig": {
                    "asm": "81 0454a3553d447e4589d165d6fbe76e7bc3e472f107d223e1d051db37875bac09ba9b2ce89676b2e3c571d797bed67a525ecc16e904186692cdee40968cffaf5576",
                    "hex": "0151410454a3553d447e4589d165d6fbe76e7bc3e472f107d223e1d051db37875bac09ba9b2ce89676b2e3c571d797bed67a525ecc16e904186692cdee40968cffaf5576"
                },
                "sequence": 4294967295,
                "txid": "97ab9a72367ad6b7a4c2ee122366e625b4049f795e4f15450bf857ea49d9e43c",
                "vout": 0
            }
        ],
        "vout": [
            {
                "n": 0,
                "scriptPubKey": {
                    "addresses": [
                        "moinqaiuWShfsemB9nGcAGFZNMa3ZwPMq6"
                    ],
                    "asm": "OP_DUP OP_HASH160 59fe1a9f9f0a5af33396c59990f064be1ca51274 OP_EQUALVERIFY OP_CHECKSIG",
                    "hex": "76a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac",
                    "reqSigs": 1,
                    "type": "pubkeyhash"
                },
                "value": 9.9998
            }
        ],
        "vsize": 153,
        "weight": 612
    }
}

Now I get the following error when broadcasting the transaction:
{
    "error": {
        "code": -26,
        "message": "mandatory-script-verify-flag-failed (Non-canonical DER signature)"
    },
    "id": "1",
    "result": null
}

What does that mean?

In your signed transaction
                "scriptSig": {
                    "asm": "1 0454a3553d447e4589d165d6fbe76e7bc3e472f107d223e1d051db37875bac09ba9b2ce89676b2e3c571d797bed67a525ecc16e904186692cdee40968cffaf5576",
                    "hex": "0101410454a3553d447e4589d165d6fbe76e7bc3e472f107d223e1d051db37875bac09ba9b2ce89676b2e3c571d797bed67a525ecc16e904186692cdee40968cffaf5576"
                },

The 0101 in hex should've been OP_1, which is 0x51. Both are equivalent, and the shorter one has been required since a soft fork.
This is to prevent 3rd parties from changing parts of transaction not covered by a transaction to change the TXID. Yours disobeys BIP62 case 3.

I changed 0101 to 0x51 (see in my original question Update 1), but now I get the following error when broadcasting the transaction: "mandatory-script-verify-flag-failed (Non-canonical DER signature)"

@Bumblebee The transaction is not signed, it contains 0454a3553d447e4589d165d6fbe76e7bc3e472f107d223e1d051db37875bac09ba9b2ce89676b2e3c571d797bed67a525ecc16e904186692cdee40968cffaf5576 as signature, but it's a public key. Uncompressed public keys start with 0x04 and encode the 32-bytes of x coordinate and 32-bytes of the y coordinate, so this is a public key.

My private key looks like this: 3074020101042059b1b460e0b74f217be10f0f3ec4c5438053b0ea5fa7fced6da838b1044f47afa00706052b8104000aa1440342000454a3553d447e4589d165d6fbe76e7bc3e472f107d223e1d051db37875bac09ba9b2ce89676b2e3c571d797bed67a525ecc16e904186692cdee40968cffaf5576 How can I convert the ec private key into a private key that I can use to sign the transaction?

@Bumblebee A private key has 32 bytes or 64 hex characters, that can't be a private key.

Do you have your private key as PEM? I'm trying to understand the format of the private key you linked.

My private key is in DER.

Could you please show you exported it?

It is not en exported private key. I have to use a key pair which is created by OpenSSL and I get them in DER format..

I created a new keypair and I finally was able to broadcast the transaction.

MCCCS: that privkey format is the one defined in C.4 of SEC1 from https://secg.org/ . It is one of the formats supported by OpenSSL (in both DER and PEM encodings), and is used in many ECC applications other than cryptocoin, like SSL/TLS and SSH. In addition to the 'raw' private number (here 32 octets) it contains an 'object identifier' (OID) identifying the curve (because many applications aren't limited to a single curve), a (redundant) copy of the raw public point, and some ASN.1 metadata ('tag' and 'length' octets)

@dave_thompson_085 Thanks, I am not familiar different ways to encode ECC private keys and I'd expect it to start with BEGIN PRIVATE KEY and be in base64, and TIL that, thanks.

MCCCS: the text forms beginning with 5 hyphens (important), BEGIN, one or a few words, 5 more hyphens and linebreak, then base64 with linebreaks, then a similar END line, are 'PEM' format and OpenSSL supports, for ECC, 4 different PEM formats: 2 standard per RFC7468 sec 10 & 11 and 2 of its own that use BEGIN EC PRIVATE KEY.

Just in case somebody else runs into the same issue. Here is how I created the new key pair and derived the Wif private key from it. I used bx which is a part of https://github.com/libbitcoin/libbitcoin-explorer.
Here are the steps:

Create a new private key

# bx seed | bx ec-new
> d86a6cd08829b0e23dfb8e0eeb3abb8378147a950c638bedd368e9f51d1c45bc

Convert the private key to Wif

# bx ec-to-wif -v 239 d86a6cd08829b0e23dfb8e0eeb3abb8378147a950c638bedd368e9f51d1c45bc
> cUqPKAMJJ81psjeY2ZXM5S2HG6azieuqMypRb9viHoY1QvubReUp

Note: the -v 239 option is used for a testnet address. If you want to create an address/Wif private key for the mainnet, you can skip -v 239

Create the public

# bx ec-to-public d86a6cd08829b0e23dfb8e0eeb3abb8378147a950c638bedd368e9f51d1c45bc
> 02a4379f994ccce7041d30026092b13a7987c12cd6e33222dabdf890a00fc50b2e

Create the address

# bx ec-to-address -v 111 02a4379f994ccce7041d30026092b13a7987c12cd6e33222dabdf890a00fc50b2e
> mhyXyTy4fnu2jcmAGeChkgd9RmNgTg7xV5

Send some btc to this address

# bitcoin-cli sendtoaddress mhyXyTy4fnu2jcmAGeChkgd9RmNgTg7xV5 40.0
> 2c9e2222c109ea8ca6171aa1feb07f382b413205003e4271e45ee2e46f88c8c1

Get the raw transaction

#bitcoin-cli getrawtransaction 2c9e2222c109ea8ca6171aa1feb07f382b413205003e4271e45ee2e46f88c8c1
> 020000000001011ec966bff03a8b5af9ac98cf3ba606c558baf5112fff11b99c024743630bb3bd0000000000feffffff02e8e9d039000000001600148c579973d42679c854837ffebf5b6612d5673d1000286bee000000001976a9141af72e49ec135151f1421c185b6cb1ce836576c388ac0247304402206525f5763b0c427059ffcea4605492515bd9599250600a3771d4c7af8258ca0502201c54db8b24a146b74ca4a8e64fe1666016f6f9636c9cb39ad1bdb926149f7eef012103962b2c8bcff7291e647ae077b205a9b06660826e1e9754177f4366d074df7a9700000000

Decode the raw transaction

# bitcoin-cli decoderawtransaction 020000000001011ec966bff03a8b5af9ac98cf3ba606c558baf5112fff11b99c024743630bb3bd0000000000feffffff02e8e9d039000000001600148c579973d42679c854837ffebf5b6612d5673d1000286bee000000001976a9141af72e49ec135151f1421c185b6cb1ce836576c388ac0247304402206525f5763b0c427059ffcea4605492515bd9599250600a3771d4c7af8258ca0502201c54db8b24a146b74ca4a8e64fe1666016f6f9636c9cb39ad1bdb926149f7eef012103962b2c8bcff7291e647ae077b205a9b06660826e1e9754177f4366d074df7a9700000000
{
  "txid": "2c9e2222c109ea8ca6171aa1feb07f382b413205003e4271e45ee2e46f88c8c1",
  "hash": "945df62297918f141d235c42623bb6f39bb6c5418a9630462658d548e931455e",
  "version": 2,
  "size": 225,
  "vsize": 144,
  "weight": 573,
  "locktime": 0,
  "vin": [
    {
      "txid": "bdb30b634347029cb911ff2f11f5ba58c506a63bcf98acf95a8b3af0bf66c91e",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "304402206525f5763b0c427059ffcea4605492515bd9599250600a3771d4c7af8258ca0502201c54db8b24a146b74ca4a8e64fe1666016f6f9636c9cb39ad1bdb926149f7eef01",
        "03962b2c8bcff7291e647ae077b205a9b06660826e1e9754177f4366d074df7a97"
      ],
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 9.69992680,
      "n": 0,
      "scriptPubKey": {
        "asm": "0 8c579973d42679c854837ffebf5b6612d5673d10",
        "hex": "00148c579973d42679c854837ffebf5b6612d5673d10",
        "reqSigs": 1,
        "type": "witness_v0_keyhash",
        "addresses": [
          "bcrt1q33teju75yeuus4yr0llt7kmxzt2kw0gskkdjh7"
        ]
      }
    },
    {
      "value": 40.00000000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 1af72e49ec135151f1421c185b6cb1ce836576c3 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9141af72e49ec135151f1421c185b6cb1ce836576c388ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "mhyXyTy4fnu2jcmAGeChkgd9RmNgTg7xV5"
        ]
      }
    }
  ]
}

Create raw transaction. To create the raw transaction I created this quick and dirty shell script:

#!/bin/bash

# Adjust the options of bitcoin-cli according to your setup
CLI='bitcoin-cli -regtest -rpcuser=user -rpcpassword=password -rpcport=8332'

# Private Key from Step 1 (This is not used, just for verification)
PRIVATE_KEY='d86a6cd08829b0e23dfb8e0eeb3abb8378147a950c638bedd368e9f51d1c45bc'
# Wif Private Key from step 2
PRIVATE_KEY_BASE58='cUqPKAMJJ81psjeY2ZXM5S2HG6azieuqMypRb9viHoY1QvubReUp'

# Transaction id from Step 5
TX_IN_ID='2c9e2222c109ea8ca6171aa1feb07f382b413205003e4271e45ee2e46f88c8c1'

# Transaction hash from Ste 6
TX_IN_HASH='020000000001011ec966bff03a8b5af9ac98cf3ba606c558baf5112fff11b99c024743630bb3bd0000000000feffffff02e8e9d039000000001600148c579973d42679c854837ffebf5b6612d5673d1000286bee000000001976a9141af72e49ec135151f1421c185b6cb1ce836576c388ac0247304402206525f5763b0c427059ffcea4605492515bd9599250600a3771d4c7af8258ca0502201c54db8b24a146b74ca4a8e64fe1666016f6f9636c9cb39ad1bdb926149f7eef012103962b2c8bcff7291e647ae077b205a9b06660826e1e9754177f4366d074df7a9700000000'

# Receiver address
TO_ADDRESS='moinqaiuWShfsemB9nGcAGFZNMa3ZwPMq6'

# Amount to be sent
TO_AMOUNT=39.9998

echo ""
echo ""
echo "Raw In Transaction"
echo "=================="
$CLI decoderawtransaction $TX_IN_HASH

RAWTX=`$CLI \
    createrawtransaction \
    '[{"txid":"'$TX_IN_ID'","vout":'$TX_IN_VOUT'}]' \
    '{"'$TO_ADDRESS'":'$TO_AMOUNT'}'`

echo ""
echo ""
echo "Raw Transaction"
echo "==============="
echo $RAWTX

echo ""
echo ""
echo "Raw Transaction Decoded"
echo "======================="
$CLI decoderawtransaction $RAWTX

# scriptPubKey from Step 7 (Make sure to take the on from the vout from which you want to spend)
SCRIPT_PUB_KEY='76a9141af72e49ec135151f1421c185b6cb1ce836576c388ac'

echo ""
echo ""
echo "Sign Raw Transaction 1"
echo "======================"
# Make sure to set the vout from which you want to sped
RAWTX_SIGNED=`$CLI \
    signrawtransactionwithkey \
    $RAWTX \
    '["'$PRIVATE_KEY_BASE58'"]' \
    '[{"txid":"'$TX_IN_ID'","vout":1,"scriptPubKey":"'$SCRIPT_PUB_KEY'","redeemScript":""}]' `

echo ""
echo ""
echo "Raw Transaction Signed"
echo "======================"
echo $RAWTX_SIGNED

Send the signed raw transaction

# bitcoin-cli sendrawtransaction 0200000001c1c8886fe4e25ee471423e000532412b387fb0fea11a17a68cea09c122229e2c010000006a473044022029296a6ac3fdaf0a0c4616c783bee1b3b5f7ea24a63f3df3544e74aa4c1a65b102207baa71419ef0ceff6218e78b6fb93bfe6ac7445584e23d20be1fbf6454bab50f012102a4379f994ccce7041d30026092b13a7987c12cd6e33222dabdf890a00fc50b2effffffff01e0d96aee000000001976a91459fe1a9f9f0a5af33396c59990f064be1ca5127488ac00000000
> 95d4f6bbdda2ec79350c0559d5d9e9c279f73e5d37f8267834034a40c6d520c2


text:
Bitcoind is not syncing, why?
My log was stuck on this for 30 minutes:
2019-12-09T22:33:17Z txindex is enabled at height 0
2019-12-09T22:33:17Z txindex thread exit
2019-12-09T22:33:17Z Bound to [::]:8333
2019-12-09T22:33:17Z Bound to 0.0.0.0:8333
2019-12-09T22:33:17Z init message: Loading P2P addresses...
2019-12-09T22:33:17Z Loaded 587 addresses from peers.dat  3ms
2019-12-09T22:33:17Z init message: Starting network threads...
2019-12-09T22:33:17Z net thread start
2019-12-09T22:33:17Z dnsseed thread start
2019-12-09T22:33:17Z addcon thread start
2019-12-09T22:33:17Z init message: Done loading
2019-12-09T22:33:17Z opencon thread start
2019-12-09T22:33:17Z msghand thread start
2019-12-09T22:33:28Z Loading addresses from DNS seed seed.btc.petertodd.org
2019-12-09T22:33:28Z Loading addresses from DNS seed seed.bitcoinstats.com
2019-12-09T22:33:28Z Loading addresses from DNS seed dnsseed.emzy.de
2019-12-09T22:33:39Z Loading addresses from DNS seed seed.bitcoin.sprovoost.nl
2019-12-09T22:33:39Z Loading addresses from DNS seed     seed.bitcoin.jonasschnelli.ch
2019-12-09T22:33:39Z Loading addresses from DNS seed dnsseed.bitcoin.dashjr.org
2019-12-09T22:33:50Z Loading addresses from DNS seed dnsseed.bluematt.me
2019-12-09T22:33:50Z Loading addresses from DNS seed seed.bitcoin.sipa.be
2019-12-09T22:33:50Z 282 addresses found from DNS seeds
2019-12-09T22:33:50Z dnsseed thread exit

And then after 30 minutes, showed this:
2019-12-09T23:05:32Z Potential stale tip detected, will try using extra outbound peer (last tip update: 1890 seconds ago)
2019-12-09T23:16:02Z Potential stale tip detected, will try using extra outbound peer (last tip update: 2520 seconds ago)
2019-12-09T23:26:32Z Potential stale tip detected, will try using extra outbound peer (last tip update: 3150 seconds ago)
2019-12-09T23:37:02Z Potential stale tip detected, will try using extra outbound peer (last tip update: 3780 seconds ago)
2019-12-09T23:47:32Z Potential stale tip detected, will try using extra outbound peer (last tip update: 4410 seconds ago)
2019-12-09T23:58:02Z Potential stale tip detected, will try using extra outbound peer (last tip update: 5040 seconds ago)
2019-12-10T00:08:32Z Potential stale tip detected, will try using extra outbound peer (last tip update: 5670 seconds ago)
2019-12-10T00:19:02Z Potential stale tip detected, will try using extra outbound peer (last tip update: 6300 seconds ago)
2019-12-10T00:29:32Z Potential stale tip detected, will try using extra outbound peer (last tip update: 6930 seconds ago)
2019-12-10T00:40:02Z Potential stale tip detected, will try using extra outbound peer (last tip update: 7560 seconds ago)
2019-12-10T00:50:32Z Potential stale tip detected, will try using extra outbound peer (last tip update: 8190 seconds ago)
2019-12-10T01:01:02Z Potential stale tip detected, will try using extra outbound peer (last tip update: 8820 seconds ago)
2019-12-10T01:11:32Z Potential stale tip detected, will try using extra outbound peer (last tip update: 9450 seconds ago)
2019-12-10T01:22:02Z Potential stale tip detected, will try using extra outbound peer (last tip update: 10080 seconds ago)
2019-12-10T01:32:32Z Potential stale tip detected, will try using extra outbound peer (last tip update: 10710 seconds ago)
2019-12-10T01:43:02Z Potential stale tip detected, will try using extra outbound peer (last tip update: 11340 seconds ago)
2019-12-10T01:53:32Z Potential stale tip detected, will try using extra outbound peer (last tip update: 11970 seconds ago)
2019-12-10T02:04:02Z Potential stale tip detected, will try using extra outbound peer (last tip update: 12600 seconds ago)
2019-12-10T02:14:32Z Potential stale tip detected, will try using extra outbound peer (last tip update: 13230 seconds ago)
2019-12-10T02:25:02Z Potential stale tip detected, will try using extra outbound peer (last tip update: 13860 seconds ago)
2019-12-10T02:35:32Z Potential stale tip detected, will try using extra outbound peer (last tip update: 14490 seconds ago)
2019-12-10T02:46:02Z Potential stale tip detected, will try using extra outbound peer (last tip update: 15120 seconds ago)
2019-12-10T02:56:32Z Potential stale tip detected, will try using extra outbound peer (last tip update: 15750 seconds ago)
2019-12-10T03:07:02Z Potential stale tip detected, will try using extra outbound peer (last tip update: 16380 seconds ago)
2019-12-10T03:17:32Z Potential stale tip detected, will try using extra outbound peer (last tip update: 17010 seconds ago)
2019-12-10T03:28:02Z Potential stale tip detected, will try using extra outbound peer (last tip update: 17640 seconds ago)
2019-12-10T03:38:32Z Potential stale tip detected, will try using extra outbound peer (last tip update: 18270 seconds ago)
2019-12-10T03:49:02Z Potential stale tip detected, will try using extra outbound peer (last tip update: 18900 seconds ago)
2019-12-10T03:59:32Z Potential stale tip detected, will try using extra outbound peer (last tip update: 19530 seconds ago)
2019-12-10T04:10:02Z Potential stale tip detected, will try using extra outbound peer (last tip update: 20160 seconds ago)
2019-12-10T04:20:32Z Potential stale tip detected, will try using extra outbound peer (last tip update: 20790 seconds ago)
2019-12-10T04:31:02Z Potential stale tip detected, will try using extra outbound peer (last tip update: 21420 seconds ago)

Any ideas what could be wrong?
UPDATE
I've tried deleting the blocks and chainstate folders. Same thing happens. It gets up to here:
2019-12-10T04:53:34Z Loading addresses from DNS seed dnsseed.bitcoin.dashjr.org
2019-12-10T04:53:34Z Loading addresses from DNS seed seed.bitcoin.jonasschnelli.ch
2019-12-10T04:53:34Z Loading addresses from DNS seed     seed.bitcoin.sprovoost.nl
2019-12-10T04:53:46Z Loading addresses from DNS seed seed.bitcoinstats.com
2019-12-10T04:53:47Z Loading addresses from DNS seed dnsseed.emzy.de
2019-12-10T04:53:47Z Loading addresses from DNS seed seed.bitcoin.sipa.be
2019-12-10T04:54:00Z Loading addresses from DNS seed dnsseed.bluematt.me
2019-12-10T04:54:00Z Loading addresses from DNS seed seed.btc.petertodd.org
2019-12-10T04:54:00Z 282 addresses found from DNS seeds
2019-12-10T04:54:00Z dnsseed thread exit

And then does nothing. I assume it's going to start with the "Potential stale tip detected" errors soon.

This answered my question.

put these lines to your conf file, shutdown and restart syncing again
addnode=104.237.131.138
addnode=151.80.205.132
addnode=192.155.82.123
addnode=74.220.255.190
addnode=80.100.203.151

And I had to unblock outgoing ports  8333.


text:
Script to import multiple priv keys in Electrum
DuckDuckGo turns up nothing of interest. How to import multiple priv keys in Electrum from a file using Electrum console or shell script, for all derivable valid BTC addresses? (1,3,bc1)
Eventually I would like to pipe the output of one script directly into an import script.
The file is in format:
BTC Pattern: <pattern>
BTC Address: <bitcoin address beginning with one>
BTC Privkey: <bitcoin address beginning with five>
...

Does this help?

@KappaDev Thank you, I can filter my input file and paste a bunch. Updated question for derivable addresses.

First of all get rid of all that junk. One priv key per line is all you need. So use grep privkey filename|cut -d":" -f2 > clean-file.txt. Then call this  python script with that file as an argument:
import sys
from electrum import bitcoin
f = open(sys.argv[1], "r")
for privkey in f:
    privkey=privkey.strip()
    orig_format,secret,compressed=bitcoin.deserialize_privkey( privkey)
    formats = [ bitcoin.serialize_privkey( secret, False, "p2pkh"), bitcoin.serialize_privkey( secret, True, "p2pkh"), bitcoin.serialize_privkey( secret, True, "p2wpkh"), bitcoin.serialize_privkey( secret, True, "p2wpkh-p2sh") ]
    for thing in formats:
        print(thing)

It'll output all the private keys in the various formats.


text:
18 word mnemonic seed that contains words outside of BIP39 wordlist, struggling to recover BTC
I recently recovered a document containing information relating to some BTC I purchased in 2015. I only have: a passphrase/password, an 18 word mnemonic phrase(the majority of which are not in the BIP39 wordlist, nor the electrum old/new wordlists, e.g. mccartney, hopkinton), and the address: 1CfadqyBDRPt62S9UvBHDPtqRu2kSvwPPu.
I idiotically forgot to add what wallet I used, so I'm a bit stuck.
Any ideas about what the mnemonic could be for?

Answering these kinds of questions are rarely ever free.

I understand, I  was just wondering if someone else had encountered a similar issue in the past.

That’s a blockchain.info “recovery phrase”, which isn’t a seed and isn’t enough to recover your wallet.

Remember the 1st four characters of the BIP39 seed words need to remain unchanged to identify what the real BIP 39 seed words are.  If this gets you nowhere, read the BIP 39 Standard as to how seed words are used to synthesize entropy.  You will note that the entropy associated with different spoken languages leads to wildly different results.  Understanding that the effective sha512 hashing a the seed words might provide insights what happens when seed words are misspelled or improperly recorded. However, taking this approach will be  very implementation specific.

it is your waled ID and password for blockchain.com in encrypted format. should be enough to recover your funds.


text:
I mined in early 2010 with a cpu miner and just found my keys after forgetting all thease years, no joke need info please
who is the best most reputable bitcoin recovery company?
I have added details and questions about our situation below
Thank you
And God Bless
what was the mining program from the devs back then? I remember a pop up kinda like a dos window and it dispalyed the key and said somthing like write this down we will not give it to you again...
I also remeber a pass sentance proram that could be used to recover somthing if you entered in you full sentace string..
I have been out of crypto since I mined a few blocks way back then and I have my keys so do i just download and sink the wallet first?
remeber I did this long ago and was hoping to located the mining program from way back then to read the readme and refresh my memory.
Also back then you could contact a dev to help you,,
thanks in advance for helping out a old man trying to pay a few bills.
Sorry guys I am old sick with cancer so I do not want anyone to think I am lazy to ask questions like this. I believe what I found are my entropy codes. I remember seeing a sit down report on CNBC back in the day about Silk Road and weather or not bitcoin was a legitimate coin ect and they spoke for a good bit at length and they told you where to download the program and I thought the blocks was 50 at a time? It was a long time ago. I had ignored the boom from a few years ago to embarrassed and to and sick to care what ever happened to my codes / keys until I found my old drives and then my old codes. I do not remember it being a pool but if it was my guy is saying it was from the dev teams or team. It was a pop up miner and it would not have much on he display in the small little box. Just your mined coin count and a splash code that said something like write this down you will not get it again and will need it for us to help you recover your coins ect.

BIP32/BIP39 (the specification for the system you are describing) did not exist in 2010, so this could not have happened.

First, please don't post any actual data. In what format did you find the keys? Did you find a wallet.dat file? Else, do you have the raw keys?

Could you please provide more information about the format of what you found? Is it a list of words or just a single string of letters and numbers?

I think in late 2010 the first mining pools emerged. Could it be that you have been contributing your CPU Power to a mining pool and this was your credentials. If that was the case and you never cashed out your Bitcoin I guess you will not be able to access your coins unless you figure out which pool it was and see if the pool still exists


text:
How can I send bitcoins with Bitcoin-QT using the API?
I'm making a bitcoin-based online marketplace. I've been reading/studying the Bitcoin API commands, and some of the commands need "unlocked wallet". Does this mean a wallet without a passphrase?
I think it's vital that the wallet be encrypted at all times. Still, if I've understood everything correctly, I need to decrypt the wallet (at least for a while) to be able to send bitcoins to another wallet.
So how should I proceed? If someone on the website wants to take his/her coins on to another wallet, do I need to make it so the API removes the PIN or encryption from the wallet, sends the bitcoins and encrypts it again?
Is it secure to do so?
Oh, and I'm using Bitcoin-QT to handle the coins.

"unlocked wallet" means an encrypted wallet for which the encryption key is known. Bitcoin-Qt/bitcoind doesn't actually support decrypting a wallet.

To send bitcoins using the API:
It is recommended to have some knowledge of AJAX if using this method
WORD OF WARNING: Using this method can cause large amounts of inputs being set as miners fees. I suggest you continue with caution and start by using small inputs.
That being said...
Using the commands listunspent, createrawtransaction, signrawtransaction and submitrawtransaction.
To access the Bitcoin-qt console:
launch your bitcoin client as usual and wait for it to load the blockchain and start up
click on 'help' in the menu bar (top right)
click on 'debug window'
select the 'console' tab

Use listunspent to get an array of you spendable inputs in your wallet
This is where you set you transaction fee: Use createrawtransaction to generate a transaction in the form createrawtransaction [{\"txid\":\"[txid of the input transaction]\",\"vout\":[vout that relates to the txid of the input transaction]},...] {\"[address to send your bitcoins to]\":[amount of bitcoins to send to this address],...} All inputs that are not spent in a transaction are used as miners fees.
Use signrawtransaction [the output of createrawtransaction] to sign your generated transaction Note: Your wallet must be unlocked to perform this command. If not type walletpassphrase [your passphrase] 21600
Use submitrawtransaction [the output of signrawtransaction] to send your signed transaction to the network to be included into a block

You can see your transaction by going to http://blockchain.info/tx/[txid output from submitrawtrasaction]

You are absolutely right.Look at the end of API calls list.There is walletpassphrase command. Use it to decrypt for some time, send money, then do walletlock.
Regarding security, it is not the best option, but still better than unencrypted wallet.
Consider using PHP or other script languages to decrypt wallet: usually, if the attacker can access your unencrypted wallet, he can also find a password in PHP files and decrypt encrypted wallet. Compiled languages are a bit more secure, but the password is still there. Someone with Hex Editor could afterall find the password.

So you're saying that anyone with Hex Editor and a bit of time could "hack" any wallet that is used by any PHP-based site? I think either you or I have misunderstood something. :)

Not anyone. If he accessed your filesystem, he would be able to read your unencrypted wallet, as well as to read PHP files in order to find password for your encrypted wallet. The password is stored somewhere in your code, which in case of PHP is clear text. You don't need Hex then. If you use for instance C++, then the password would be in a compiled binary, and then you can use Hex editor.

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


text:
Signing transaction offline - manual way vs. Electrum
Being inspired by the thread (Redeeming a raw transaction step by step example required) I wanted to understand transaction signatures on the byte level.
So I created my own Linux scripts that:

generate key pairs
accumulate all the necessary bytes that a raw transaction needs
leverage OpenSSL to sign the transactions

Everything that deals with private keys I do on an offline computer, while I look at the blockchain explorer on the screen of a different, online system.
For my test transaction, I wanted to redeem one utxo of an address that I control on mainnet, and send some satoshis (just above the 'dust' level) to some other addresses using P2PKH. Here is the transaction that I created and signed manually:
{
    "version": 1,
    "locktime": 0,
    "ins": [
            {
                    "n": 1,
                    "script": {
                            "asm": "304402200c441b33dc180ec93e1df07df575399f74112dbf4a0a200151c9c4f1afc7c71e02200fc2fcf42847d5c504f06edef7b8fa81b092e7b8b00169d7f8868a02da6ad12401 02dece727c6ddde3140abfcc554ffe50768ab29faa7439c411772fe3c7b93f7cb2",
                            "hex": "47304402200c441b33dc180ec93e1df07df575399f74112dbf4a0a200151c9c4f1afc7c71e02200fc2fcf42847d5c504f06edef7b8fa81b092e7b8b00169d7f8868a02da6ad124012102dece727c6ddde3140abfcc554ffe50768ab29faa7439c411772fe3c7b93f7cb2"
                    },
                    "sequence": 4294967295,
                    "txid": "127ea67612d6e217f99b2b28cc9f8347eb518f99c45102f925774ad8f4958d0f",
                    "witness": []
            }
    ],
    "outs": [
            {
                    "script": {
                            "addresses": [
                                    "1HangpEdoDsSe5i3n7DQNbYie65PGGmPcq"
                            ],
                            "asm": "OP_DUP OP_HASH160 b5e5e05c83c470ffd21c3330fb99a6a0101351ad OP_EQUALVERIFY OP_CHECKSIG",
                            "hex": "76a914b5e5e05c83c470ffd21c3330fb99a6a0101351ad88ac"
                    },
                    "value": 800
            },
            {
                    "script": {
                            "addresses": [
                                    "1HaXuSmR7PXhR4GCcyvGC7USYDuDjw6FHw"
                            ],
                            "asm": "OP_DUP OP_HASH160 b5d9896cc07a30e1d739097df0c1d47181cbbe75 OP_EQUALVERIFY OP_CHECKSIG",
                            "hex": "76a914b5d9896cc07a30e1d739097df0c1d47181cbbe7588ac"
                    },
                    "value": 900
            }
    ],
    "hash": "18d7100c870deb63dec258282f5ff150ebc64e4497d107073503fb4343f4810d",
    "txid": "18d7100c870deb63dec258282f5ff150ebc64e4497d107073503fb4343f4810d"
}

... which corresponds to hex representation
01000000010f8d95f4d84a7725f90251c4998f51eb47839fcc282b9bf917e2d61276a67e12010000006a47304402200c441b33dc180ec93e1df07df575399f74112dbf4a0a200151c9c4f1afc7c71e02200fc2fcf42847d5c504f06edef7b8fa81b092e7b8b00169d7f8868a02da6ad124012102dece727c6ddde3140abfcc554ffe50768ab29faa7439c411772fe3c7b93f7cb2ffffffff0220030000000000001976a914b5e5e05c83c470ffd21c3330fb99a6a0101351ad88ac84030000000000001976a914b5d9896cc07a30e1d739097df0c1d47181cbbe7588ac00000000
Electrum has a menu item to 'load transaction by text', what I did with my hex string. It displayed the result correctly as a "transaction unrelated to your wallet" because I had not imported the private key yet. Electrum offered me the option to broadcast the transaction, but I decided not to (*) because I wanted to compare the manually created transaction with the transaction that Electrum would generate when I use their UI features.
(*) I later broadcast my manual transaction via blockchain.com
So, in order to be able to compare, I imported the private key into Electrum and created a transaction with identical parameters (using the 'Pay to many' feature). Here is the transaction that Electrum created:
{
    "version": 2,
    "locktime": 636848,
    "ins": [
            {
                    "n": 1,
                    "script": {
                            "asm": "3045022100fa7033d292275ebcd4d8fdf38d6b76461ba4a9330df3b21cf5e72f25f08938c802207268e19442c1d3e0ff9850cd6f500985260c250e18d71976093475bd61180ebb01 02dece727c6ddde3140abfcc554ffe50768ab29faa7439c411772fe3c7b93f7cb2",
                            "hex": "483045022100fa7033d292275ebcd4d8fdf38d6b76461ba4a9330df3b21cf5e72f25f08938c802207268e19442c1d3e0ff9850cd6f500985260c250e18d71976093475bd61180ebb012102dece727c6ddde3140abfcc554ffe50768ab29faa7439c411772fe3c7b93f7cb2"
                    },
                    "sequence": 4294967294,
                    "txid": "127ea67612d6e217f99b2b28cc9f8347eb518f99c45102f925774ad8f4958d0f",
                    "witness": []
            }
    ],
    "outs": [
            {
                    "script": {
                            "addresses": [
                                    "1HangpEdoDsSe5i3n7DQNbYie65PGGmPcq"
                            ],
                            "asm": "OP_DUP OP_HASH160 b5e5e05c83c470ffd21c3330fb99a6a0101351ad OP_EQUALVERIFY OP_CHECKSIG",
                            "hex": "76a914b5e5e05c83c470ffd21c3330fb99a6a0101351ad88ac"
                    },
                    "value": 800
            },
            {
                    "script": {
                            "addresses": [
                                    "1HaXuSmR7PXhR4GCcyvGC7USYDuDjw6FHw"
                            ],
                            "asm": "OP_DUP OP_HASH160 b5d9896cc07a30e1d739097df0c1d47181cbbe75 OP_EQUALVERIFY OP_CHECKSIG",
                            "hex": "76a914b5d9896cc07a30e1d739097df0c1d47181cbbe7588ac"
                    },
                    "value": 900
            }
    ],
    "hash": "0f33ae7fc5ca788351a4b571083cf0fa8cbb37afe0206260b02c4c889c05c099",
    "txid": "0f33ae7fc5ca788351a4b571083cf0fa8cbb37afe0206260b02c4c889c05c099"
}

... which corresponds to hex representation 02000000010f8d95f4d84a7725f90251c4998f51eb47839fcc282b9bf917e2d61276a67e12010000006a47304402200dd93baf0a38e4a352a7029c2a37a9bb8ef06bc32ab33fabb8278c6733193e4a02203393c4f5b73345a2a76694de9dff429d65b4de77581601ccc748c642a0dac308012102dece727c6ddde3140abfcc554ffe50768ab29faa7439c411772fe3c7b93f7cb2feffffff0220030000000000001976a914b5e5e05c83c470ffd21c3330fb99a6a0101351ad88ac84030000000000001976a914b5d9896cc07a30e1d739097df0c1d47181cbbe7588ace5b70900
And here comes my question:
When I compare the 2 decoded transactions, I get the following differences:
~/$ diff tx-manual tx-electrum
2,3c2,3
<   "version": 1,
<   "locktime": 0,
---
>   "version": 2,
>   "locktime": 636848,
8,9c8,9
<               "asm": "304402200c441b33dc180ec93e1df07df575399f74112dbf4a0a200151c9c4f1afc7c71e02200fc2fcf42847d5c504f06edef7b8fa81b092e7b8b00169d7f8868a02da6ad12401 02dece727c6ddde3140abfcc554ffe50768ab29faa7439c411772fe3c7b93f7cb2",
<               "hex": "47304402200c441b33dc180ec93e1df07df575399f74112dbf4a0a200151c9c4f1afc7c71e02200fc2fcf42847d5c504f06edef7b8fa81b092e7b8b00169d7f8868a02da6ad124012102dece727c6ddde3140abfcc554ffe50768ab29faa7439c411772fe3c7b93f7cb2"
---
>               "asm": "3045022100fa7033d292275ebcd4d8fdf38d6b76461ba4a9330df3b21cf5e72f25f08938c802207268e19442c1d3e0ff9850cd6f500985260c250e18d71976093475bd61180ebb01 02dece727c6ddde3140abfcc554ffe50768ab29faa7439c411772fe3c7b93f7cb2",
>               "hex": "483045022100fa7033d292275ebcd4d8fdf38d6b76461ba4a9330df3b21cf5e72f25f08938c802207268e19442c1d3e0ff9850cd6f500985260c250e18d71976093475bd61180ebb012102dece727c6ddde3140abfcc554ffe50768ab29faa7439c411772fe3c7b93f7cb2"
11c11
<           "sequence": 4294967295,
---
>           "sequence": 4294967294,
38,39c38,39
<   "hash": "18d7100c870deb63dec258282f5ff150ebc64e4497d107073503fb4343f4810d",
<   "txid": "18d7100c870deb63dec258282f5ff150ebc64e4497d107073503fb4343f4810d"
---
>   "hash": "0f33ae7fc5ca788351a4b571083cf0fa8cbb37afe0206260b02c4c889c05c099",
>   "txid": "0f33ae7fc5ca788351a4b571083cf0fa8cbb37afe0206260b02c4c889c05c099"

Who can explain me the differences (or point me to the appropriate BIP) and why does Electrum use them? I'm aware of the fact that the signatures are not deterministic (EDIT: Following the comment of @Coding Enthusiast, Electrum's signatures are deterministic, but mine are not) and must consequently differ, and thus the hash/txid must differ as well. But what about version, locktime and the significance of the e5b70900 suffix after the last scriptpubkey (see hex representation of the Electrum tx)?

The signatures produced by Electrum are deterministic (uses RFC-6979).

The version number is sort of arbitrary and up to the client, so long as the number chosen is valid.

The nLockTime is usually set to the current block height in modern wallets, this is a simple protection against a specific issue in Bitcoin called "fee sniping", where it is more economical to orphan other people's blocks to steal the fee income than it is to mine your own new one at a later height.

e5b70900 is the nLockTime, meaning a block height of 636901. See the protocol documentation.

Perfect, that clarifies my questions, thanks.


text:
Chat online using Bitcoin addresses?
I was surfing on the web and trying to find a chat app that uses Bitcoin address instead of phone numbers or any other identifier. Do you know about any project in this field?

That sounds like a terrible idea. Addresses are not intended to be long-term persistent identities.

The idea was around for some time, and as Pieter mentioned, using addresses without any additional obfuscating seems like a bad implementation.
There are few other projects, the one that is most serious is Microsoft's ION decentralized identity project. It's not the chat-app itself, rather the way of signing into apps using bitcoin-generated identity.
When it comes to chat apps, there is a pretty rapid development in the field of lightning network. As messages on LN are onion-routed, it seem to be a good idea for privacy-preserving communication.
There are two projects I heard about, self-custodial Juggernaut and centralized (so what's the point) Sphinx.
I'd be very hesitant in using these solutions, they are working as untested, beta-version projects, so they may not be as stable and secure.


text:
Configure Bitcoin full node in my local LAN
It is said that deploying a Bitcoin full node would protect the privacy of my Bitcoin addresses. If I configure a Bitcoin full node to be outbound only, would that be enough to protect me? Do i still need to have a public IP address? (Since no other full node will connect in, do i still need to configure/supply a public IP address?)

It is said that deploying a Bitcoin full node would protect the privacy of my Bitcoin addresses.

Only to some extent. It is true that at least some employees of any business providing custodial wallets know a lot about the person associated with each address in their wallets. It is also true that nodes relied on by a simplified payment verification (SPV) wallet also know more than normal about the wallet holder.
However there's information in the public blockchain which is amenable to some forensic analysis that a sufficiently resourceful person or organisation can use to penetrate privacy to some extent.

If I configure a Bitcoin full node to be outbound only, would that be enough to protect me?

I doubt it has much effect on privacy regarding addresses used in transactions.

Do i still need to have a public IP address? (Since no other full node will connect in, do i still need to configure/supply a public IP address?)

No.
You might want to investigate whether your router supports UPnP and the implications of that.

Thx for the insight. Can I conclude that if someone running a full node solely for the purpose of "privacy protection", having one behind the firewall with outbound only connections would give me the full benefits (as far as the "privacy protection" is concerned, regardless of its effectiveness), without the need to fool around with my router.


text:
Does cryptocurrency ETF use block-chain technology?
As you know, one of these days trends is cryptocurrency ETFs that the CES doesn't approve it yet. But there are some questions about them and their functioning. Is it necessary to build them over block-chain technology? If yes, would someone explain it? and in case the answer is no, why?
Question: In other words, the main question is about how do they implemented and function.

Is it necessary to build [Exchange Traded Funds] over block-chain technology?

No.

in case the answer is no, why?

Imagine an ETF based on stocks in gold mining companies. Those companies own open-cast mines and rock-crushing machines.
An exchange can buy and sell shares, or funds based on those shares without directly themselves operating any open-cast mines or rock-crushers.
Rock-crushing machines are not suited to keeping track of sales and purchases of stocks and shares, or of funds based on them.


text:
Confused on using SHA256 code from Bitcoin Core
I was looking at Bitcoin Core code to use its SHA256 code but am confused on where I should be looking at.
In bitcoin/src/crypto/sha256.h there is CSHA256
and in bitcoin/src/crypto/sha256.cpp there are namespaces named sha256_sse4, sha256_shani.
And then there is bitcoin/src/hash.h
Explanations and guidance would be greatly appreciated.

sha256.h has the exported (visible from outside) methods and functions. To compute SHA256, you should #include that.

sha256_sse4.cpp
sha256_sse41.cpp
sha256_avx2.cpp
sha256_shani.cpp

contain SHA256 transform functions (used in SHA256.Write), each specialized for different processors with different instruction sets. Above is the list in order, most of the computers support SSE4, but only a few support SHA-NI instruction set, which is the fastest way a new processor can calculate SHA256.
sha256.cpp contains other methods that aren't a bottleneck, functions that check which instruction sets are supported, tests, as well as a pure-C++ transform function for older and non-x86 computers.
hash.h favors polymorphism via C++ templates.
Examples:

hash std::vector<something> vch to std::vector<something> vchHash
hash std::vector<something> in to std::vector<something> WitnessV0ScriptHash
hash uint8_t * nonce.begin(), uint8_t *  hash.begin(), unsigned char pubkey[], std::vector<unsigned char> vchSig to std::vector<unsigned char> entry
hash op_true to witness_program


text:
2nd 'air-gapped' computer / cold wallet setup for travel
I travel quite a bit and don't want to lug around a 2nd 'air-gapped' computer. I know that connecting a hardware wallet like a Ledger Nano S to the Ledger Live desktop app running on a computer that's connected to the internet not considered a 'fully cold' wallet setup.
I asked if a non-networked VM would do but it sounds like there's no extra security with that.
So, what would be a good solution for a 2nd 'air-gapped' computer for travelers? Perhaps Tails installed on a USB stick or 'OS on a stick' products that are out on the market, such as the Intel Compute Stick:
https://www.amazon.com/Intel-Compute-Computer-Processor-BOXSTK1AW32SC/dp/B01AZC4NHS

https://www.amazon.com/Intel-Corp-BOXSTCK1A8LFC-Compute-STCK1A8LFC/dp/B00W7KAABK
I'm looking for a solution where I can use my laptop's screen and keyboard.

Unless you have a very unusual laptop, this is probably impossible: the only thing that can talk to your laptop's screen and keyboard is its own CPU.  And so, for instance, if your regular OS gets some sort of malware that compromises your BIOS, then your "airgap" install gets compromised as soon as you boot it.

Some hardware wallets don't need to be connected via USB, for example the 'Cold Card' can sign txs via SD card transfer.

Chytrik, I looked at the Coldcard Wallet website but didn't see any mention of what desktop wallet app would accept a signed tx imported via the SD card. Also, could web wallets accept this signed tx?

I just saw a link to a Medium post showing the use of Electrum on the desktop (Mac). Looks like the exported file is json. Do other wallets support this format?

This seems a lot like an XY problem. For the vast majority of users, the threat model simply does not require more guarantees than those provided by a solution such as Ledger.
Naturally, if you are dealing with very large amounts, you would be wise to take better steps to secure it. But something like a Ledger, which will parse the tx being signed and display the outputs on the Ledger itself prior to signing, should cover most use cases.
Additionally, as Chytrik mentioned, you have wallets such as the Cold Card which can operate without being directly connected to a computer at all, transferring Partially Signed Bitcoin Transactions via an SD Card.
Beyond that, if you really do need the security benefits offered by a fully offline computer, you should consider buying a cheap netbook or laptop, epoxy the ports, strip out any networking hardware, and verifying it as far as you can to be in a secure state - If you are genuinely moving amounts while travelling that merit that kind of security, then your best bet is to carry the extra 800 gram to 1 kilogram of weight.

I will be storing large amounts and in multiple coins, so I'm looking for a fully offline solution that supports these coins. I have four laptops (2 Win, 2 Mac) and will be traveling with 2. Bringing a 3rd computer would be too much. I think a disconnected smartphone (networking disabled; no sim; no wifi/bluetooth) + micro SD card would be the solution. I'll even seriously consider 'stripping out any networking hardware' as you suggested. Can anyone suggest mobile app wallets that allow me to sign TXs and save the file to the SD card and on the flipside, load updates into it?

Your use case sounds like you're at a point where consumer solutions simply won't exist, especially once you get into multiple coins - you should seriously consider hiring someone to build something like this for you. Most existing solutions you would find would be limited to Bitcoin, as it is one of the few coins designed with pure offline usage in mind - many altcoins make it rather difficult to handle things offline without an intricate knowledge of what you're doing.


text:
Recovery after losing wallet.dat and formatting hard disk
I have received the bitcoin way back in 2013 in Bitcoin Core. At that time I don't know about the importance of wallet.dat - I have formatted my hard disk and install Bitcoin Core again in 2017 but there it didn't show my Bitcoin in my balance. I have my Bitcoin Key.
I meant "Bitcoin Key" is my Public Key on which I got my bitcoin. Is there any other way to get my Bitcoin back if I didn't get my original wallet.dat of Bitcoin Core?
How can I get my bitcoin back?
How can I get to know my Private Key?

Related: https://bitcoin.stackexchange.com/q/103688/5406

Your money is lost without at least one of

a backup of important data from the hard disk before it was formatted
a backup of the wallet.dat file
a note of the private key

There is no way to recover the private key from other information. If there was, Bitcoin would be completely unsafe and unusable.

there is still a minor hope for you this is the software which recover the data even from the formatted hard drive if you successfully recovered your wallet.dat file then replace the file with your new wallet.dat of bitcoin core which has Zero balance.

How can I get to know my Private Key?

That's what your wallet.dat contained. You cannot get that back if you've lost your wallet.dat. Otherwise, Bitcoin would be worth $0 as anyone could just "make up" private keys with any amount of Bitcoin.
Since the wallet.dat was long deleted, re-installing Bitcoin Core is insufficient—there is nothing left for Bitcoin Core to guess your old key.

I meant "Bitcoin Key" is my Public Key on which I got my bitcoin.
Is there any other way to get my Bitcoin back if I didn't get my original wallet.dat of Bitcoin Core?

If you lost your wallet.dat, have no backups or dumps of it, I'm afraid there is no way to recover your coins.

Oh..okay.Thansk for your comment.

Hi Coiner, I edited your answer to remove rude phrasing. We expect users on this site to respectfully communicate with each other.


text:
update bitcoin core upgrade!
I have an old version of bitcoin core wallet, i can't see my balance right now. is it safe to download the new version of bitcoin core wallet? there is no chance of losing my balance after downloading the newest version? hope to get an answer soon. Thank you
Regards
Faim


text:
I transferred crypto from Revolut but I'm unaware of who the wallet service provider is. I have the wallet address but that's all
I've stupidly transferred crypto from Revoult to ramp. Then it seems I have no idea where it's gone from there. I have the wallet address and the hash transaction reports but I'm unsure what the wallet service provider is.
Is there a way of solving this horrible issue I have got myself into?
Any help would really really be appreciated. I don't have a clue here as my skills are on other fields.
My email is operationportal@proton.me
Thank you again for all your help and advice.
Jamie

This question is similar to: Old bitcoin purchase. If you believe it’s different, please [edit] the question, make it clear how it’s different and/or how the answers on that question are not helpful for your problem.

You will be receiving lots of email from fake recovery agents (scammers) who seek out victims who seem vulnerable to confusion, impulsiveness and panic.  You will find it helpful to read answers to Is it normal to be asked for an advance fee on a withdrawal?


text:
Can fraudsters access my wallet if I didn't give them my PIN or passphrase?
I sent crypto from my cold wallet to a scam. I didn't give out PIN or passphrase. Can these guys access my wallet now?

To steal money secured by the private keys stored by a wallet, a thief needs

access to the wallet data files or a copy of them.
knowledge of any passphrase (or PIN etc) used to encrypt the keys in those files.

However, if someone has been tricked by a scammer, it is certainly possible that the victim was also tricked into giving the scammer access to their computer, perhaps by installing software suggested by the scammer, perhaps by giving screen-sharing access to someone who they thought was a helper. Their computer might have had back-door access and/or keyloggers installed.
It would perhaps be prudent to assume the worst. I would make a new wallet, with new keys, on a new, clean computer using nothing from the existing computer. I would create an on-chain transaction to move money to that clean environment.

i think for a piece of mind im going to take your advice. getting new phone today before i go into anything. these guys are good. not worth  the risk. thanks mate

To access your wallet, someone would need both your seed phrase and your passphrase. If all you did was send some coins to another address then the fraudsters would have neither of these, so the short answer would be "no".
If you think that someone else may have your seed phrase then I would recommend moving your remaining coins to another wallet as the passphrase could be guessed. The passphrase is still required to access the wallet however, assuming you have a passphrase set.


text:
Tracing Blockchain.com Wallet-ID from Receiver Address. Address Re-use
I am wanted to question related to blockchain.com ?

If i have some one BTC to BTC receiver address can i trace name or wallet id or something?
For example if i generate multiple btc to btc receiver address can we trace the wallet id?
If i use old btc to btc receiver id is this OK? When it will be expire? Is these receiver id goes to expire.?

Looking forward for reply.
Best Regards,

If i have some one BTC to BTC receiver address can i trace name or wallet id or something?

Generally no. Blockchain.com might be able to. That's why I would be wary of using their "wallet" and why I'd use one of the non-custodial wallet (self-custodial wallet) listed at https://bitcoin.org/en/choose-your-wallet

if i generate multiple btc to btc receiver address can we trace the wallet id?

No.

If i use old btc to btc receiver id is this OK?

If by "receiver id" you mean the receiving bitcoin address, yes, it is OK so long as you have a real (non-custodial) wallet.
If you gave your money to someone else to look after for you, then all bets are off. They can make up their own rules to separate you from your money.

When it will be expire? Is these receiver id goes to expire.?

Bitcoin addresses never expire. It is preferable to avoid reuse for privacy reasons because all transactions are public and people can infer information about you from patterns of usage.
If you gave your money to someone else to look after for you, then all bets are off. They can make up their own rules to separate you from your money.

Related questions:

What kinds of wallets are there?
How can there exist businesses that "specialize in blockchain analysis looking for patterns of usage that reveal how money is being used"?
When you make a Bitcoin transaction, can the receiving person (and the world?) really see how much coins you have in the entire wallet?
Bitcoins Anonymity - Do Exchanges Break It?