text:
Validation Error: Error #-26: 258: txn-mempool-conflict
I am getting this error message. What does it mean?
Validation Error: Error #-26: 258: txn-mempool-conflict

This error means that you're trying to spend the same transaction output more than once.
More specifically, when you submit a transaction, a check is done (on the node) against the previous outputs of your new transaction to see if they are already trying to be spent by a transaction in the memory pool.
The check is in validation.cpp in the bitcoin source:
// Check for conflicts with in-memory transactions
std::set<uint256> setConflicts;
for (const CTxIn &txin : tx.vin)
{
    auto itConflicting = pool.mapNextTx.find(txin.prevout);
    if (itConflicting != pool.mapNextTx.end())
    {
        const CTransaction *ptxConflicting = itConflicting->second;
        if (!setConflicts.count(ptxConflicting->GetHash()))
        {
            // Allow opt-out of transaction replacement by setting
            // nSequence > MAX_BIP125_RBF_SEQUENCE (SEQUENCE_FINAL-2) on all inputs.
            //
            // SEQUENCE_FINAL-1 is picked to still allow use of nLockTime by
            // non-replaceable transactions. All inputs rather than just one
            // is for the sake of multi-party protocols, where we don't
            // want a single party to be able to disable replacement.
            //
            // The opt-out ignores descendants as anyone relying on
            // first-seen mempool behavior should be checking all
            // unconfirmed ancestors anyway; doing otherwise is hopelessly
            // insecure.
            bool fReplacementOptOut = true;
            if (fEnableReplacement)
            {
                for (const CTxIn &_txin : ptxConflicting->vin)
                {
                    if (_txin.nSequence <= MAX_BIP125_RBF_SEQUENCE)
                    {
                        fReplacementOptOut = false;
                        break;
                    }
                }
            }
            if (fReplacementOptOut) {
                return state.Invalid(false, REJECT_DUPLICATE, "txn-mempool-conflict");
            }

            setConflicts.insert(ptxConflicting->GetHash());
        }
    }
}


text:
Recovering an old Multibit wallet file (76 characters long)
I have a wallet file from 2011 back when I used to play around with Bitcoin.
I used an old version of Multibit which has since long been unavailable.
My wallet looks like this:
# KEEP YOUR PRIVATE KEYS SAFE !
# Anyone who can read this file can spend your bitcoin.
#
# Format:
#   <Base58 encoded private key>[<whitespace>[<key createdAt>]]
#
#   The Base58 encoded private keys are the same format as
#   produced by the Satoshi client/ sipa dumpprivkey utility.
#
#   Key createdAt is in UTC format as specified by ISO 8601
#   e.g: 2011-12-31T16:42:00Z . The century, 'T' and 'Z' are mandatory
#
U2FsdGVXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXsnQhpZ6
 2013-10-30T20:52:01Z
# End of private keys

I managed to get a version of Multibit HD from the web archive but this doesn't support this wallet.
I also tried using OpenSSL with the following command:
openssl enc -d -p -aes-256-cbc -md md5 -a -in C:\key\wallet.key.txt -out c:\key\wallet-decrypted.key.txt

This output a file which wasn't correct and gave a bad decrypt error. I know the password for this file.
Does anyone know the correct method of decrypting this?
UPDATE: While I'm at it, I found a whole bunch more .key files. This one has a different format:
org.bitcoin.productionm!œ;€ò=°´zXXXXXXXXXXXXXXXXXÌñ9,o( 2D
ä¢¦]5+¡XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXE}Û@nŸé(2

ÐáXXXXR#
org.multibit.walletProtect.2 ZYour wallet description`

Does anyone know the correct method of decrypting this?

It doesn't seem to be encrypted. The comments at the start of the file don't mention any form of encryption. It only mentions a common form of encoding - Base58. Encoding is not encryption so no decryption is needed.

#   The Base58 encoded private keys are the same format as
#   produced by the Satoshi client/ sipa dumpprivkey utility.

That Base58 key ought to be able to be imported into several different modern wallet programs.
See

Private keys importing in format got by dumpprivkey
How to get the private key in hex from the output of dumpprivkey
https://btcinformation.org/en/developer-reference#dumpprivkey

Addendum 2024

it's not accepted when I copy and paste [...] Guessing wrong format

If we assume the binary private-key was encrypted and then converted to Base58, it should be possible to reverse that process.
According to some Multibit related source code
 * If you encrypt a string with this class you can decrypt it with the OpenSSL
 * command: openssl enc -d -aes-256-cbc -a -in cipher.txt -out plain.txt -pass
 * pass:aTestPassword
 *
 * where: cipher.txt = file containing the cipher text plain.txt - where you
 * want the plaintext to be saved
 *
 * substitute your password for "aTestPassword" or remove the "-pass" parameter
 * to be prompted.
 *

So I would try that aes command on two versions of the private key data from the wallet file:

As is. Omitting comments, trailing blanks and date etc
Same but converted to binary from Base58 by using base58decode.

I'd convert the result to Base58 encoding before attempting import, depending on what the documentation of the import tools tell you about the format they expect. It might be necessary to convert to WIF for example.
However, I've no idea if that source code corresponds to the Multibit classic used and I havent read the rest of the code to find out how that code is used (if at all) when reading the wallet data file.

Unfortunately it's not accepted when I copy and paste the key directly into a private key import such as electrum. Guessing wrong format or too few characters for a private key.

@HippoDuck: see addendum.

If the priv key starts with U2 and ends with = its most probably an md5 encryption.
Your password seems wrong, so you would need something like btcrecover that would jog through irerations.
You can find it on github here
https://github.com/gurnec/btcrecover
Good luck
/KX

I'm positive of the password though, long story but I remember the moment I set it up and the only password I used at the time etc. I will take a look at the GitHub repo. Thanks.

Did you solve your problem? If you got the string from the first image and the string starts with 5 or L then you can download electeum light wallet and import the private key.

No, I was unable to get btcrecover to work. ModuleNotFoundError: No module named 'cPickle' Even on Python 2.7. Seems broken.

Will have to shelve the idea for another year frustratingly. I know it was about £100/£150 back in 2011/2012. No idea what it would be now.

I think the issue comes from password change inside the wallet on user's side. Multibit wallet has password change issues and many users posted this issue.
When you choose your password through Multibit’s user interface, the software passes it as an argument to the PKCS5PasswordToBytes method, which is part of the Spongy Castle library. This method accepts the password as a char array and outputs it as a byte array. It is later used to either encrypt or decrypt a .key file. Below, here’s how the method is implemented in the PBEParametersGenerator.java file. Can you spot the bug?
public static byte[] PKCS5PasswordToBytes(
char[]  password)
{
byte[]  bytes = new byte[password.length];
    for (int i = 0; i != bytes.length; i++)
    {
        bytes[i] = (byte)password[i];
     }

   return bytes;
}

In Java, the char type is made up of 2 bytes; however, the code above assumes that a char is made up of only one byte! Thus, for each char processed in the loop, the low-order byte is kept while the high-order byte is discarded. Under the right circumstances, this can become an issue.
Since Java relies on the UTF-16 BE charset, Multibit encodes the password as 20 AC when it is entered in the user interface. When it is converted through the PKCS5PasswordToBytes method, the high-order byte (20) is dropped whereas the low-order byte (AC) is kept. Unlike with our previous example, AC is not the proper encoding for our password in any of the charsets above. As such, a password cracker may fail to decrypt the .key file even with the correct password. What are your options? If you haven’t done so already, you should try to unlock your wallet through Multibit Classic directly. Unfortunately, this approach quickly becomes impractical if you are unsure of your password and must type in every guess. In such a case, you will need a password cracker. You can avoid the bug described in this article by using the password cracker on a .wallet file instead of a .key file. While this approach beats typing in every guess, it scales terribly as the .wallet file has much better protection against password crackers than the .key file. Moreover, some of these tools have their own set of character encoding issues you should be aware of. If you use the password cracker on a .key file, they are multiple workarounds for character encoding issues, but they should be evaluated on a case-by-case basis and it is outside the scope of this article. I encourage you to keep doing your research or to contact me.

@HippoDuck, you can see my github and repos as reference.

In your case you have a few options:

Using MultiBit Classic: Since MultiBitHD doesn't support Classic wallets, you might want to find a MultiBit Classic executable. Install it in a secure, offline environment to avoid any potential security risks. Open your wallet with the correct password and use the "Export" feature to extract your keys.
Handling a .key File with plaintext:
Your first .key file contains plaintext and the encrypted private key. You should remove everything except the encrypted private key (U2FsdG...snQhpZ6) and attempt to decrypt it again. If there are multiple keys, repeat this process for each one.
Dealing with the Multibit Protobuf .key File:
The second .key file you have uses the Multibit protobuf format. You can decrypt this using btcrecover with the following command:

python btcrecover.py --wallet ./btcrecover/test/test-wallets/multibit-wallet.key --correct-wallet-password [YOUR WALLET PASSWORD] --dump-privkeys multibit-wallet.key.privkeys.txt

After extracting the keys, you can import them into a different wallet like Electrum.

source: Stack Exchange

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

sort: votes


text:
Bitoin payment sent and confirmed, but not received
I have sent and received a number of payments via the request function without problem. However, when I sent two payments directly from one bitcoin wallet address to another (from a business account to a personal account, public addresses), they are yet to arrive at the target! Is there an extra step I need to complete? I can't see that there is.
Thank you
 D
Transaction IDs
 e9104412aac5327e5eaad31485335d822d5e7a22f00c370d8f055286ed02e187 /
0e5fcac8b0618eabff747a0dea4cf4ff7dddf4b323e52f3473cd7581a88c425c

both tx are confirmed. Have a look at blockchain.info with your tx IDs, and see, if the target address matches the ones in your wallets. This is crucial. You didn't say which wallet you have/use, maybe the wallet first needs to synchronize with the network?

UPDATE: Payment/transaction didn't disappear. After looking into this it turns out the PASTED VALUE of e9104412aac5327e5eaad31485335d822d5e7a22f00c370d8f055286ed02e187 has invisible ASCII characters in here. Looks like a color code or some conversion of the Byte array. The transaction IS valid, but copy/pasting from the question in this topic will result in invisible ASCII.
Example:

Bad: e9104412aac5327e5eaad31485335d822d5e7a22f00c370d8f055286ed02e187
Clean: e9104412aac5327e5eaad31485335d822d5e7a22f00c370d8f055286ed02e187

They look the same, but they are not the same. You can test this by putting your cursor just after the final 'e' (4th to last character in string) then hitting the left arrow (be sure to use the "bad" or original example above). You have to hit the left arrow twice between the '2' and 'e'. The cursor is navigating the invisible character.
Here is a C# example of how to find this:
static void Main(string[] args)
        {
            var x = Encoding.Default.GetBytes("e9104412aac5327e5eaad31485335d822d5e7a22f00c370d8f055286ed02e187");

            foreach (byte item in x)
            {
                Console.Write(item);
            }

            var a = Encoding.UTF8.GetString(x);
            var b = Encoding.ASCII.GetString(x);

            Console.WriteLine(a);
            Console.WriteLine(b);
        }

The result is:
1015749485252495097979953515055101531019797100514952565351515310056505010053101559750501024848995155481005610248535350565410110048506363101495655e9104412aac5327e5eaad31485335d822d5e7a22f00c370d8f055286ed02??e187

e9104412aac5327e5eaad31485335d822d5e7a22f00c370d8f055286ed02??e187

-------------------------END OF UPDATE-----------------------
It LOOKS like somehow the transaction ID is messed up. It's a transaction on the blockchain but at the same time it looks abnormal. All of these show and contain the transaction:

Longhorn.Bullpay.com - https://longhorn.bullpay.com/?gateway=2&data=e9104412aac5327e5eaad31485335d822d5e7a22f00c370d8f055286ed02e187
BlockCypher.com - https://live.blockcypher.com/btc/tx/e9104412aac5327e5eaad31485335d822d5e7a22f00c370d8f055286ed02e187/
Blockchain.info - https://www.blockchain.com/btc/tx/e9104412aac5327e5eaad31485335d822d5e7a22f00c370d8f055286ed02e187

However, they "search" function in 2 of them fails to see it as a valid transaction (reported it to both). Was able to get to them by going to the wallet itself and finding the transaction. So while it is being consumed by looking at a raw block, the transaction ID itself is jacked up in some way.
This MAY mean, that your wallet program is also having a hard time seeing that transaction (even though it submitted the transaction to whatever node generated that transaction ID). It does exist and an expert should be able to form and submit a valid transaction to the blockchain using the UTXO's from it.
Without knowing more like what wallet is being used, the functionality of that wallet, in a general sense i would import that address into a more flexible more advanced wallet to see if it picks up the transaction. If it does, spend the UTXO's and stop using whatever wallet resulted in the malformed transaction ID. The node would have provided the transaction ID when it was submitted. So this is dependent on the wallet setup and what node setup the wallet used to cut out the "messed up" aspect.
Beyond that an expert in recovering this type of thing (assuming you still have ownership of it) should have no problem if you have access to the wallet and are willing to provide the information.
Note: This is not an endorsement of any particular recovery service (i listed none) or action you should or should not take. I've listed here some possible options to recover the coins from a wallet program that fails to see a particular transaction.

Your 2nd tx id works & can reflect a valid transaction. Your first transaction however doesn't seem to be a valid transaction id. More to the point as of this writing your 2nd tx has over 5000 confirmations. Assuming you've made these transactions in the order you listed them then the older transaction should have even more confirmations & listed in the blockchain. If you've made a transaction & it's failed to appear? I'd verify your complete address. (Not just the first / last few characters of the address as one wrong character being off can literally send your money into never never land to a wallet that may not even be being used at this point in time. You may wish to contact your sending wallet developer for assistance? Get some screen shots to show them what's up? Unfortunately you can't retransmit a transaction that's never happened. If it's not in the blockchain it's not real. If your wallet didn't sent it properly to the blockchain for processing that would explain why it never arrived. More to the point what kind of "security" is on your device that holds your wallet? Have you done a malware check ETC?

I tried to rebroadcast it for you with https://blockchain.info/pushtx, yet doesn't work and you not using your wallet for over one year doesn't affect the transaction in anyway.
My confusion is, the tx id seems not to be genuine and yet you got a confirmation on one of the tx and the money still doesn't reflect.
I honestly can't figure what the problem is, I will sure ask around and see if there is a solution, am really interested cus it might happen to anyone.

I also chose the budget transfer rate. Since these two failed transactions, I have selected the premium rate, which has always worked within minutes. Of course, even the budget option shouldn't take weeks!

When I try to add the txs into https://blockchain.info/pushtx or https://blockchain.info/decode-tx I always get the following error "Parse: exception decoding Hex string: invalid characters encountered in Hex string" or "Parse: Error Parsing Transaction"!

Are you sure you sent to the right address? I checked both your tx id and I can see the 2nd tx has been confirmed like you rightly said while the first tx couldn't be found on the blockchain.
Here is what am thinking, if you sent correctly to the right address and the tx that couldn't be found on the blockchain is unconfirmed yet, it has dropped off from the node. So rebroadcasting it might help  if it still doesn't show probably it's a double spend. but the confirmed tx id baffles me because I do not see any reason why it won't arrive at the destination  address if you sent it right...

Thank you for your response. I have checked and checked the addresses. They are correct. I hadn't used my accounts for more than one year, if that makes any difference? The transactions took place pre-Xmas! How can I rebroadcast them, as you suggest? I assume the wallets are synchronized now as recent transactions have been successful.

How can payments just disappear? This is maddening, and it seems that little to nothing can be done? D

I had the same problem. I couldn't understand where the payment went. I found out later that I made a mistake when entering the address. Check the payment details.

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

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


text:
Is mnemonic words -> mnemonic sentence standardized?
I was reading the BIP 39, and noticed that it does not refer to how the mnemonic sentence, used for seed calculation, is composed from mnemonic words.  This is actually troublesome because in case of Japanese, the bip39 npm package joins the mnemonics with IDEOGRAPHIC SPACE(U+3000), the space character typically used as space for Japanese.  It seems that copay is using this library and thus follow this rule.  Some other implementation may decide to use (more machine-friendly) space(U+20), or something else, which makes remembering just the mnemonic words in sufficient for wallet recovery (in other wallet).
Question:

Is there any standard of how mnemonic sentence is composed from mnemonic words?

From bip39:

To create a binary seed from the mnemonic, we use the PBKDF2 function
  with a mnemonic sentence (in UTF-8 NFKD) used as the password and the
  string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt.
  The iteration count is set to 2048 and HMAC-SHA512 is used as the
  pseudo-random function. The length of the derived key is 512 bits (=
  64 bytes).

When normalizing unicode in NFKD form, characters that look the same become the same, so U+3000 becomes U+20. This may also cause length to change as composite characters are broken down into their constituent parts.

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


text:
How to create the same (2 of 3) multisig adresses as electrum's multisig wallets with createmultisig?
Looking to create 2 of 3 multisig addresses with the electrum console with public keys (not the master public keys):
electrum createmultisig 2 '["1st public key wallet 1", "1st public key wallet 2", "1st public key wallet 3"]'

This will out put an p2sh address and a redeemScript. The address however only match the first address in an electrum 2 of 3 multisig wallet if public keys are entered in the right order (that has a one in six chance).
Electrum's 2 of 3 multisig wallets have consistent p2sh addresses no matter what order the master public keys are entered. How can createmultisig be used to be consistent with electrum's multisig wallets?
Edit: The suggested answer is the addmultisigaddress command from bitcoin-core (as I understand it correctly), thank you for the suggestion. However the question was how to do so with Electrum console (if possible).
The question is how to (re)create the correct first p2sh address of Electrum's multisig (2 of 3) wallet with master public keys as input, with only the first public keys of each of the master public keys and be consistent with Electrum's multisig (2 of 3) wallet all the time.
Edit2: An example with actual master public keys and there public keys:
Master public key a: xpub661MyMwAqRbcFRS9DDMPDGhicAnYcsELaWwWSviE3nETgBBW6P6FqXCxDobD9h1BqXbjbMEsXkeXyrLUmxANvBw9hi4jxZKjLDyZk3hK7nT
a's first public key a1: 03722ef79a70b43843c642f3495d2b9b8a6403189d52a04ecac652c133f7940fed

Master public key b: xpub661MyMwAqRbcEqNp5KidkrqspVy5HmMTwuQguSa8LSu6WWDdYMMD13appqVrMgAZyc5FKxSnxuTqNoT2j9PYtFtF67MUNBEzifV6vnd5qW2
b's first public key b1: 03f9652bfbbfb426eb2011db774c97866e00effdf954cc225807f89b23150dda3a

Master public key c: xpub661MyMwAqRbcEpBbahsh3vPcooVMbEfKAWCx7VNAyGokuShDN2FocJEa7mkcSAkWbkhbewN9TBW9AkoSJPGJoktCXZL98BGTCdZaspiebrA
c's first public key c1: 03f5ce19296793c6695bfefd7ead459a3f88ef776d8fc08b470dbc749d266d519f

The electrum's (GUI) option to create a multisig (2 of 3) wallet will take master public key a,b and c in any order and give a wallet with the first p2sh address:
3HRmAEyoBwdHhdntJHFMeR8DxZyCgiaKzV

Electrum's console command createmultisig will output different p2sh address depending on the order of public keys. Trail and error will get the same p2sh address as the GUI, however my goal is to get the correct address without verifying consistently.
With '["a1", "b1", "c1"]':
electrum createmultisig 2 -o '["03722ef79a70b43843c642f3495d2b9b8a6403189d52a04ecac652c133f7940fed", "03f9652bfbbfb426eb2011db774c97866e00effdf954cc225807f89b23150dda3a", "03f5ce19296793c6695bfefd7ead459a3f88ef776d8fc08b470dbc749d266d519f"]'

    {
    "address": "3EKHKsgn2smYcpeiD6zfR9sgrEp6PrqCTw",
    "redeemScript": "522102ae1359d50bdc7d5b61c3bab9f293fc01cdab3c2b1151a7309fb2e28540d94e842102b0b20cb5e55204f63c016c3df94c3aadaed931370e49bb94097c97dff485032d2103d5196cd7f661deedb3f27fce93095554e72032c7fd26b1ddfaeac8d6f5d56d0553ae"
}

With '["a1", "c1", "b1"]':
electrum createmultisig 2 -o '["03722ef79a70b43843c642f3495d2b9b8a6403189d52a04ecac652c133f7940fed", "03f5ce19296793c6695bfefd7ead459a3f88ef776d8fc08b470dbc749d266d519f", "03f9652bfbbfb426eb2011db774c97866e00effdf954cc225807f89b23150dda3a"]'

{
    "address": "3HRmAEyoBwdHhdntJHFMeR8DxZyCgiaKzV",
    "redeemScript": "522103722ef79a70b43843c642f3495d2b9b8a6403189d52a04ecac652c133f7940fed2103f5ce19296793c6695bfefd7ead459a3f88ef776d8fc08b470dbc749d266d519f2103f9652bfbbfb426eb2011db774c97866e00effdf954cc225807f89b23150dda3a53ae"
}

In this example I got "lucky" after the 2nd try and get the same p2sh address after 2 tries of the possible 6 permutations. My question however is how to get the correct order of public keys without verifying the GUI multi (2 of 3) wallet?

Are you seeking to use bitcoin-core's addmultisigaddress in a way consistent with electrum, or to use electrum's createmultisig in a way consistent with bitcoin-core?

Neither. Seeking to use electrum's createmultisig (console) to be consistent with electrum's multisig wallet (GUI). Want to get the first p2sh address of the electrum's multisig wallet (GUI) by using the first public key of each master public key used to create the electrum's multisig wallet (GUI) with electrum's createmultisig (console). The problem I encounter is that the multisig wallet accept master public key a,b and c in all possible orders and give the same first p2sh address. The createmultisig command with a1, b1 and c1 only one of the permutations give the same p2sh address

See BIP45.
Electrum is ordering the pubkeys lexicographically, ie

03722ef79a70b43843c642f3495d2b9b8a6403189d52a04ecac652c133f7940fed
03f5ce19296793c6695bfefd7ead459a3f88ef776d8fc08b470dbc749d266d5
03f9652bfbbfb426eb2011db774c97866e00effdf954cc225807f89b23150dda3a

Note they're all 03, so it's 72=>f5=>f9

Maybe you mean BIP45. "The indices can be determined independently by lexicographically sorting the purpose public keys of each cosigner." https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki


text:
What are the units of "difficulty"?
In various places, e.g. here and here, there are plots of the "difficulty" of bitcoin mining over time. What exactly is the interpretation of these numbers - in what units are they measured?
My first thought was that the "difficulty" is the number of bits that should be zero in SHA256(block+nonce). But, in this case the difficulty should have been a number between 0 and 255, and these sites show much higher numbers.
My second thought was that SHA256(block+nonce) should be at most 2^256-difficulty. But, in this case it should be an integer, while this link shows that the current difficulty level is not an integer.
So, what exactly the number called "difficulty" represent?

What you meant in "second thought" is probably Target

Difficulty is a multiple of the minimum amount of Proof of Work (PoW) any valid block can contain.  In Bitcoin, the minimum difficulty (called difficulty 1) is defined in the code by this byte mask:
consensus.powLimit = uint256S("00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff");

That is, a hash must start[*] with 8 hexadecimal zeros.  That's 4 zero bytes, or 32 zero bits.
If you double that difficulty, that's difficulty 2.  Double it again and it's difficulty 4, then 8, then 16.  At difficulty 16, the hash must have at least 8 + 1 = 9 zeros.  Double it again and it's 32, then 64, then 128, then 256.  At difficulty 256, the hash must have a minimum of 8 + 2 zeros.  Et cetra...
As I write this, the current difficulty is 4306949573981.513.  We can see how many minimum zeros that corresponds to by taking its binary log, dividing by the 4 bits that are in in half a byte (one hexadecimal character) and adding the eight zeros from the minimum difficulty:
log2(4306949573981.513) / 4 + 8
= 18.49245089279219

For comparison, here's the most recent block header hash (reformatted into byte pairs for readability).  It has 18 zeros, as expected.  (Note: if you do this experiment at home, note that the hashes are always allowed to have more zeros; they just can't have less.)
0000 0000 0000 0000 0023 bfeb 3a02 1b25 7577 9256 7762 275e b72a d88b 7d50 d7f7

[*] Bitcoin is weird.  We display hashes backwards from most other software, so the zeros that start a block header hash are actually at end if you use any non-Bitcoin software to do the hashing.

So, 32+log2(difficulty) is the number of initial bits that should be zero? If so, shouldn't the difficulty level always be a power of two, as in your examples?

Yes, that's the number of bits.  However, in Bitcoin (unlike hashcash), difficulty can be fractional because the amount of PoW required (the "target") is specified using a byte mask rather than just the number of bits.  For example, a byte mask of 00000000ffff...fffe would require on average just doing one more hash than the minimum difficulty.  In practice, Bitcoin targets have limited precision, but they're plenty precise enough to provide for very fractional difficulty.

So, is the formula    SHA256(block+nonce)   <   2^224 / difficulty ?

Difficulty is calculated from the target, which is itself derived from 32 bits in the header of every block.  For formulas you can use to calculate it, see https://en.bitcoin.it/wiki/Difficulty and https://bitcoin.org/en/developer-reference#target-nbits

Difficulty represents the expected number of hashes it takes to find a valid one. The probability of a hash being valid is inversely proportional to the difficulty. The constant of proportionality is (2^16-1)/(2^48); that is, the probability of a hash being valid is (2^16-1)/(difficulty*2^48)

This is the correct answer.  The other answers are not only incorrect but lard technical details that obscure the answer.
If I were to improve on your answer it would be to start with a conventional "units" expression:
hashes/block
And then nuance that with "average hashes/block" etc.

Difficulty has units, and these are "Trials / Nonce".  (Trials = Hashes)
It is the number of trials (or hashes computed) per nonce, on average, which will yield a success ( A "success" is defined as finding the variables to the hash function which will yield a result that meets or exceeds the difficulty threshold )
The Equation that governs this is:
HashRate (trials/second) = Difficulty (trials/nonce) * [Blocks_found/Blocks_expected] *  [ Size_of_nonce_space (nonces) / target_block_time (seconds) ]
(Note: This equation is normally used to set the mining difficulty to match the hashrate on the network.
In our case,  we assume that difficulty threshold is matched to the network's HashRate, so Blocks_found = Blocks_expected, and this term reduces to unity)
Currently (February 2020), in the case of bitcoin, to find a block:
Difficulty is 15.5 Tera (trials/nonce) * 1 * ( Nonce space is 2^32 nonces / 600 seconds) =
107.37 Exa (trials / second) is the Hashrate

It means how many times it is harder to mine than in the early days of Bitcoin. In early days it was used some kind of minimum difficulty.
AFAIK Bitcoin code do not operate on "difficulty". Instead of "difficulty" Bitcoin operates on Target which is more useful in source code.

Short Answer
To add to the already helpful answers here.
Simple put difficulty is a scaling parameter it does not have units.
Long Answer
To understand what is actually is doing requires a little background:
A bitcoin hash is comprised of 64 hex characters. Or in other words, 16^64 unique encodings (1.15 * 10^77).
The minimum proof of work (PoW) for a Bitcoin is to find a hash which has 8 zero hex characters at the start of the hash:
0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff

Therefore if you were guessing and checking (which the SHA256 algorithm is designed to be a close equivalent to), then you would need to guess 16^8 times before you could expect to find the correct hash (or there is a 1/(16^8) chance of finding the correct hash each time you compute a hash), so if you were hashing at a rate of 4.29 GH/s, you would achieve this in 1 second.
Bitcoin's design is to have a Block Reward every 10 minutes.  Therefore in order to ensure that the coin is mined at this rate, there will need to be an adjustment to the difficulty which is done by adding a zero to the target hash.
A difficulty of 1 is the minimum proof of work.  If another zero is added the difficulty doubles to 2.  It is, therefore, a judge of how many times longer it would take you to find a reward given the same hashing rate.
Example
The minimum PoW would be expected to require 16^8 or 4294967296 hashes to solve.
As of 1/10/2020, the difficulty of Bitcoin is 13798783827516.4.  It would be expected that we would need to go through 5.92653E+22 Hashes before we found a block reward.
If we had a global pool hash rate of 1.0728E+20 Hashes/second.  Then we would find a block every 552.4 seconds or 9.2 minutes.
This is faster than the target of 10 minutes and the average would be taken to determine if it was luck or if indeed the mining pool is hashing at a faster rate and the difficulty would therefore increase.


text:
Two days, no confirmation
I'm using blockchain.info to send btc. Blockchain has a default fee when you send btc, I did not change it and it was saying with the fee provided it will take up to an hour. 2 days later still waiting. With two transactions stuck.
Can anyone explain why transactions would get stuck like that?
https://blockchain.info/tx/06054ef9368e1de58c8c32d1f9b8fff00b17f1a7befdfa2f71e9f6f710c05401
https://blockchain.info/tx/ee4d9ba8edeb2704c68a7f9161fc040b066c218bc87f6ff2cb3ee33a2ad51c9e
A lot of similar questions there, but no real explanation of why?

Best answer online: https://bitcoinmagazine.com/articles/what-to-do-if-your-bitcoin-transaction-gets-stuck-1481042383/

authors: игорь киселёв


text:
Method to measure "distance" between 2 transaction id's
Is there a blockchain tool/code that takes two BTC transaction ID's and determines a distance between them.
It's 2017 and Bitcoin Privacy (aka trying to walk around in the public without a sign over you saying how much money you have in your pocket) is still left entirely to the user. I'm trying to explore different methods of adding privacy to bitcoin to protect myself but I have not found a good way to measure how well one method works vs a different method. Something like blockchain.info's taint tool (now hidden on their site) is nice but feels clumsey when trying to determine familiarity between two addresses or transactions. I clearly know that the two addresses are related but want to determine how trivial/untrivial it is to determine that on the blockchain
Update Distance is a vague term but maybe intentionally. Distance could, for example, be a combination of: the number of transactions required to get from TX A to TX B assuming there is a path, or a weight that includes the size of transaction.

This is a tough one. Basically you need to have the blockchain in a graph structure, and then you can calculate the distance between two transaction vertices. Post two tx hashes and i can see if i can try calculating that.


text:
Why does my c-lightning node pay more than the invoice plus routing fees?
A friend sent me an invoice for 500,000 Satoshis. To my surprise, I sent 502294 Satoshis.
Here's what I see from my c-lightning console:

"msatoshi": 500,000,000
"msatoshi_sent": 502,294,595

My friend received a different amount on lnd:

"value": "500000"
"amt_paid_sat": "501791"

Any reasons why I am not sending the amount requested on the invoice? Also is my understanding correct that I paid 503 satoshis in fees for this transaction? It's more than I expected on the lightning network.
Thanks,
Francois

In your c-lightning node you have configured your maximum fee rate which is used by the pay command to do the payment.
The BOLT04 describes how overpaying up to twice the amount to obfuscate payments in order to have better privacy is part of the protocol:

if the amount paid is more than twice the amount expected:
  SHOULD fail the HTLC.
SHOULD return an incorrect_or_unknown_payment_details error.
Note: this allows the origin node to reduce information leakage by altering the amount while not allowing for accidental gross overpayment.

In combination with this merged pull request c-lightning fixed this issue
implementing random overpayments up to the maximum fee rate.
So generally c-lightning will randomly overpay your transaction with an amount that is lower to the maximum feerate you are willing to pay.
Not that in earlier days lnd did not accept overpayments as they seemed to not have implemented this part of the protocol.

Thank you Rene! Is this a way to know the fees paid by each routing node? 503 Satoshis in routing fees seems like an amount that is higher than I expected. Happy to see a fee market develop for LN though!


text:
Delay time for the second block of Bitcoin blockchain
According to the data stored in the blockchain, the genesis block is mined at Jan 03, 2009. The second block is mined at Jan 09, 2009, 6:24:25 AM. Which is 6 days later. At first, it seems rational to me, because at that time, the only one who was running a node was Satoshi, and even if the difficulty was very low, mining by one machine was very time consuming. By this reasoning, I expected the mining of first 2016 blocks would take time at this magnitude (Because after the 2016 blocks the difficulty would be readjusted and set to a lower level, though I'm not sure it can be less than 1 or not). But next blocks are mined very faster.

Height 0: Jan 03, 2009, 9:45:05 PM
Height 1: Jan 09, 2009, 6:24:25 AM
Height 2: Jan 09, 2009, 6:25:44 AM
Height 3: Jan 09, 2009, 6:32:53 AM
Height 4: Jan 09, 2009, 6:46:28 AM

The difficulty of network was the same for all these blocks. What is the reason for this variation? Was there a jump in the number of miners at that time?

Related question: https://bitcoin.stackexchange.com/questions/115344/why-is-there-a-5-days-gap-between-genesis-and-block-1

The blocks with heights 1-4 may have been mined according to the Poisson process that governs block discovery today and throughout the vast majority of Bitcoin's history. Blocks are mined on average every 10 minutes (with difficulty adjustments every 2 weeks to re-tune) but with variability both above and below. It is certainly plausible that you'd get 4 blocks mined at random times within a 24 minute period. The 6 day gap between the block with height 0 and the block with height 1 is likely explained by Satoshi being the only miner and not having the miner turned on during this time.
Murch states in the comments that Satoshi's original Bitcoin client (main.cpp, lines 2191-2199) would only start mining if it had at least one peer so it is possible that Satoshi's node (and miner) was running when publishing the software but only started mining when a second peer joined the network. Of course today Bitcoin Core (the dominant implementation on the network) doesn't include a miner in its releases.

Thanks Michael, so you mean there is not any known justification for that 6 day gap?

@AmirrezaRiahi: Without speaking to Satoshi it can't be confirmed 100 percent but the probability of a 6 day gap in a Poisson process at the lowest difficulty level with any hash rate running is infinitesimally small. So almost certainly no hash rate running during that time.

I seem to remember that the original Bitcoin client would only start mining if it had at least one peer. So, possibly Satoshi’s node was running when publishing the software, but only when a second peer joined the network both nodes started mining.

@Murch: Ha interesting, thanks. Will add to the answer.

https://github.com/JeremyRubin/satoshis-version/commit/225135f220e2956d6684425abf0e008462d6ee2e#diff-34d21af3c614ea3cee120df276c9c4ae95053830d7f1d3deaf009a4625409ad2R2191-R2199 (you may need to expand main.cpp, because it’s pretty large, see lines 2191–2199)


text:
Is it okay to open a pull request while there there's little done?
I'm working on an issue in the Bitcoin Core. This is my first issue and so I have some questions. Is it good practice to open a pull request and ask reviewers of the pull request to help me or I should ask them elsewhere (such as IRC)? I think PR page on github is a good place to ask my questions. Note that I currently have not done anything worth mentioning.

You can open a pull request in draft if it isn't ready to be reviewed yet but it should at least be a work in progress rather than its current state ("not done anything worth mentioning"). Reviewers are unlikely to review it if it is in draft but adding to the open pull requests without it at least being a work in progress seems premature to me. IRC (#bitcoin-core-pr-reviews) is definitely the best place to ask questions as a new(er) contributor. That channel was set up specifically to help new(er) contributors get to grips with the codebase and the Core review process.


text:
How to compile bitcoin source code with wallet?
I've built the bitcoin core on my computer and once I tried to run tests related to wallet, I encountered this error:
[amirreza@localhost bitcoin]$ python test/functional/wallet_createwallet.py
2022-06-20T16:36:53.675000Z TestFramework (WARNING): Test Skipped: wallet has not been compiled.
2022-06-20T16:36:53.725000Z TestFramework (INFO): Stopping nodes
2022-06-20T16:36:53.725000Z TestFramework (INFO): Cleaning up /tmp/bitcoin_func_test_mnwvrnya on exit
2022-06-20T16:36:53.726000Z TestFramework (INFO): Test skipped

When I tried to reconfigure the compilation process by ./configure I noticed it doesn't compile wallet:
Options used to compile and link:
  external signer = yes
  multiprocess    = no
  with experimental syscall sandbox support = yes
  with libs       = yes
  with wallet     = no

But I don't know how to change this option to compile with wallet. I took look at ./configure options but see that it is enabled by default:
[amirreza@localhost bitcoin]$ ./configure --help
...
  --disable-wallet        disable wallet (enabled by default)
...

Did you install the wallet dependency (sqlite3)?

@MichaelFolkson not sure, but first I should find a way to compile the wallet then get errors for not satisfying the dependencies and try to fix them.

You need to have installed sqlite3 before you try to build Core with the wallet.

The ./configure autodetection script will automatically disable wallet support if it notices you're missing wallet dependencies. Installing sqlite3 (for newer-style descriptor wallets) and/or bdb (for older-style legacy wallets) is likely all that is missing.

@MichaelFolkson I didn't get any error for this. I'll install it and retry.

@PieterWuille thanks, I try it.


text:
System administration of mining rig/s
Newbie question; is there anything helpful you guys could point me to related to sys administration of several mining rigs.. my venture with an 8 card mining rig is slowly becoming a farm :)
What I mean is, I own a mining rig for a week or so (which is now being administered by the guy who sold it to me), and now several people are asking me to place their rigs at my place (I have large and secure storage place and I'm thinking of placing solar panels). My question was related to what to expect in future; Do I need to spend a lot of time daily checking up everything and re-configuring stuff. Thank you! :)

While most people still measure mining power using hash/s, this guy measures them in entire rig/s... ;)

Can you be more specific as to what you want?

what i meant is that i own a mining rig  for a week or so( which is now being administered by the guy who sold it to me), and now several people are asking me to place their rigs at my place ( I have large and secure storage place and I'm thinking of placing solar panels ). My question was related to what to expect in future; Do I need to spend a lot of time daily checking up everything and re-configuring stuff. Thank you! :)

Just try https://getminera.com , which will run as controller on your pi or other linux machine.


text:
How to find ripple faucet coin for development
I'm developing an app with ripple. I need some faucet coin for ripple. How can I find it?

I found the best solution. The link is: https://ripple.com/build/xrp-test-net/
We can generate new credential and it has 10000 xrp in testnet. The testnet websocket address is wss://s.altnet.rippletest.net:51233

I haven't tried it these website but i guess it should work: http://satoshibakery.com/ripple-faucet.php

Thanks for your reply. I'm using adblock and all faucet sites warning for disable it. I hate it.


text:
Problems with CGMiner 4.9.2
I have tried reaching out for assistance in other Bitcoin forums, to no avail as apparently I have bought miner hardware that is not supported by the people who are responsible for CGMiner software.  While I respect that, I am struggling with support on my kit and I would really appreciate some assistance if possible.
I have a WhatsMiner M3 that runs CGMiner 4.9.2.  When it arrived, I switched it on and it had 3 mining pools already configured from the factory.  It looked like CGMiner was running and it was mining.  The device became very hot, 83 degrees I think it was and then the screaming fans seemed to slow down to a crawl.  Within a few minutes the device had cooled down significantly and the fans sped back up to full speed.  I changed the pool settings from factory to the pool information using my chosen pool and worker name for the device.  I then restarted CGMiner but it would not restart.  I then rebooted the box too but that made no difference.  The device does not get hot at all currently.
At that point I only had 1 pool setup, so I added in 3 just to be sure and tried restarting CGMiner but it still didn't work.  The power supply is fine, and the device itself seems fine and I get get into the web interface as well as connect to the device via SSH.  The only visual feedback I have is from the device overview page which gives me the following error:
EventCode: E011
EventCause: Slot-0 Zero HS 4500 Seconds
EventAction: Zero HS Warning
EventCount: 6
LastTime: Thu Dec 7 12:59:42 2017
EventSource: system-monitor
Please see these images, they describe what I am seeing:
1) The device overview where it shows that CGMiner is waiting to start:  https://drive.google.com/open?id=1c6N1YvdUHrC6pYo0L3aaPgZhwes3AP4i
2) The pool settings:  https://drive.google.com/open?id=1m0uYPcc_o-T_I2ZQ8G3M6qDk_wUVgX-2
3) The device status I get when I try start CGMiner vis SSH:  https://drive.google.com/open?id=1OHxwqlqoFGfer6qyv8VuRkrimXWtI7O6
4) The event code error as described above:  https://drive.google.com/open?id=1aYE0-RhxfB-W-eGx2AW0XKh64cvIBReQ
My concern is that the initial run where it got up to 83 degrees has broken the miner, because it doesn't get hot at all currently.  Also, because CGMiner will not start, the device shows no system status information, I cannot see temperature info, I can't see if the hashboards are okay, I can't tell at all where the proble lies.  Please could I ask someone to assist me with figuring out what it wrong with this device?  I have looked at the logs but I cannot make sense of the logs as I do not know what I am looking for.
Thank you for any assistance.

Welcome to Bitcoin.SE! I have added a useful tag and had a look at the information in your question. My attempt to answer is below.

I cannot see from your screenshot, usually, the pool worker name is entered in the format userName.workerName.
Have you tried getting onto WhatsMiner support? Your question didn't say. The error message looks like it is coming from your miner actually and being reported by CGMiner. It looks like the support address for your WhatsMiner is shown in one of your screenshots.


text:
Can "Block" Message send multiple blocks?
Can multiple blocks be sent in a single block message in response to the GetBlocks message, or will a new Block message have to be sent for every block?
Thanks.

It sends exactly one block. If you want to send multiple blocks, you need multiple messages.


text:
How to get extended key from 512-bit seed?
I've followed the bip32 and bip39 specifications for generating the 512-bit seed, however I didn't understand how to generate the xpriv from this. I've used the left 256 bits for the private key and right 256 bits for the chain code, however my private key bytes and chaincode differs from the test vector:
Using 512-bit seed:
"d71de856f81a8acc65e6fc851a38d4d7ec216fd0796d0a6827a3ad6ed5511a30fa280f12eb2e47ed2ac03b5c462a0358d18d69fe4f985ec81778c1b370b652a8"
Desired Master Private Key bytes: "2fd0c70b975d9a38f84fba956ed795075fe43a85a45336143fe855551f1356db"
Desired Chaincode: "51fd417898af090d1a4dc040f4427a7e6a4ad5fd4024ace7f068a167861e8655"
Desired Xpriv: "xprv9s21ZrQH143K2shfP28KM3nr5Ap1SXjz8gc2rAqqMEynmjt6o1qboCDpxckqXavCwdnYds6yBHZGKHv7ef2eTXy461PXUjBFQg6PrwY4Gzq"

How do I obtain these values using the left 256 bits for the pk, and the right 256 bits for the chaincode?
Thanks.

Which test vectors exactly does this test case come from?

https://github.com/trezor/python-mnemonic/blob/master/vectors.json (test 3)
I obtained the seed and words from the entropy, then derived the chaincode and seed using Nbitcoin

My question was basically, how to use the seed to get the master key bytes and chaincode, sorry if it wasn't very clear

You're aware that according to BIP32, you need to use HMAC-SHA512 on the seed to compute the master key (see this section: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#master-key-generation)

I used HMAC-SHA512 to derive the seed from the entropy, you're saying I would need to do it again?

Yes, read the link I gave.

Let us continue this discussion in chat.

There are two separate processes:

BIP39 specifies how to go from a phrase/mnemonic to a seed, using 2048 iterations of HMAC-SHA512.
BIP32 specifies how to go from a seed to a master key (using another single HMAC-SHA512) and then how to derive child keys from that master key.

Perhaps you were missing that the master key is distinct from the seed, and that computing the xprv from the seed thus involves yet another HMAC-SHA512 step?


text:
How provide a sender address to a Know Your Transaction service
Due to the recent change in regulatory bodies, crypto businesses are now being asked to prevent their customers from facilitating transactions used for money laundering and other illicit activities such a purchasing illegal goods or services. A preventative measure called Know Your Transaction (KYT) has become a necessity to combat this.
KYT services use on-chain analysis to determine if a sender's address is high or low risk.
However I have recently come across the issue that some bitcoin transactions appear to have multiple input addresses (example). I have read some posts here outlining that it is difficult to determine the true sender address from one of these transactions.
I would like to know if providing one of the sender addresses is good enough for the KYT service to determine if the transaction is high risk, or should I attempt to pass each of the sender addresses (for multi-sender transactions) as separate transactions. One drawback of the latter is that we pay per usage for each sender address, so it would result in higher fees.
I would like to point out that:

I am using Coinbase Analytics
I'm not sure if this is relevant but the transaction occurs on-chain and if it is flagged as high risk we would return the BTC to the customer

The intersection of regulating bodies and technical reality is where things stop really making sense. 'To' and 'from' labels exist at the human-interaction-layer, and the human-interaction-layer may actually map very poorly onto the bitcoin-movement-layer. In fact, the bitcoin-movement layer may not look anything like the human-interaction-layer at all! So whatever way you end up interpreting and implementing this regulatory policy, it'll probably not match reality perfectly well

@chytrik I would like to point out that we generate a wallet address for the customer to send us BTC, so I know the receiver address but not the sender address. Apologies if this is not what you meant.

Yes, I did understand that. Your job here is just tough, as the regulators want their policy followed, even if it is nonsensical at a technical level. I'm sure there will be some method that is considered 'best practices' you will unfortunately have to follow, but as @redgrittybrick mentioned, thats a question best directed to your compliance team / lawyers / etc.

I would like to know if providing one of the sender addresses is good enough for the KYT service to determine if the transaction is high risk

I don't see how it could be good enough. If one of the other sender addresses is high risk, your service would give a false result. Wouldn't you knowingly have failed to adequately assess the risk and thereby aided in the processing of criminally obtained funds? At the least it seems negligent.
However I am not a KYT compliance officer, just some random person in the Internet. You should probably instead ask both your KYT service and a lawyer.

As you can see in the below transaction, there are 4 input addresses. So if the KYT service is intelligent enough, it would check all four input addresses. This is essentially my question. Apologies for not clarifying.
https://www.blockchain.com/btc/tx/6faef7b9cd63eaaa217006f6f52c2a42c898842987167bdd36331eac3413423b

To provide an accurate and complete assessment of a transaction, the KYT service must check every input to that transaction. If the KYT service does this for any referred transaction, you don't need to provide any addresses at all. I suggest you ask your KYT service about this.

The thing is we pay for a third party fraud prevention service who have a direct connection with Coinbase Analytics, so I thought I had a better chance asking here, but I will send them my query now and see what they say.


text:
Signing transactions with un/compressed key
Good day.
I've created 2 addresses from the same private key.
One address is of course compressed, while the other isn't.
compressed_public_key = "025d9a1a0a5dab7e3e4a84c30a42ddc0d71b2da0fa1f3b99fbda9fc03eb8c75cd5"
corresponding_address = "mfjRUvWr9QZadpiRnbRfHS4UDSxdR9FE75"

uncompressed_public_key =  "045d9a1a0a5dab7e3e4a84c30a42ddc0d71b2da0fa1f3b99fbda9fc03eb8c75cd535a0b893f20338d37d20eebe2941859dfe53b175f0bb24a27bc77741f0bb8cac"
uncompressed_address = "mi4kMd3HcLUGJSouNdJZ87eUBbi7cNE6C3"

I've also send some coins to each address.
utxo_to_compressed = "963baf6eb615a09afcb05ebcdbd3db05a163994dd2035002477c753ba3281eff"
utxo_to_uncompressed = "08a1286bb379f6eb5151828505b934c1b917201592bb76bd252a53b7a3009b17"

Using bitcore I've created the private_key to sign the transactions and the utxos as follow:
privateKey = new bitcore.PrivateKey(BN, "testnet")

scriptSig =  "76a914" + hashedPubKey + "88ac";

And the hashed public keys are:
1bf398bb044e55f1971e384cc1e6d861dca3adb9 for the uncompressed
025bafbac8a8a1fcbae04f9a6aa8b6f968c9d145 for the compressed

utxo_compressed = new bitcore.Transaction.UnspentOutput({
    "txId": "08a1286bb379f6eb5151828505b934c1b917201592bb76bd252a53b7a3009b17",
    "outputIndex": 0,
  "address": "mi4kMd3HcLUGJSouNdJZ87eUBbi7cNE6C3",
    "script": scriptSig,
    "satoshis": 5000000000
});

utxo_uncompressed = new bitcore.Transaction.UnspentOutput({
    "txId": "963baf6eb615a09afcb05ebcdbd3db05a163994dd2035002477c753ba3281eff",
    "outputIndex": 0,
  "address": "mfjRUvWr9QZadpiRnbRfHS4UDSxdR9FE75",
    "script": scriptSig,
    "satoshis": 5000000000
});

Signing the compressed utxo isn't a problem.  But once I'm trying to sign the uncompressed transaction I receive an error message.
compressedTx = new bitcore.Transaction();
uncompressedTx = new bitcore.Transaction();
compressedTx.from(utxo).to(some output).sign(privateKey); <-This one works fine
uncompressedTx.from(utxo).to(some output).sign(privateKey); <-This one fails
//Some inputs have not been fully signed Use//

In the past, I've sent and redeemed transactions from uncompressed public key (I did it manually, using a simple python code). I can't seem to find any reason why the inputs weren't signed.
I'll highly appreciate any help you might have to offer

compressed pubkey and uncompressed one have different hashes. so, your code should be something like:
scriptSig1 = "76a914" + hashedPubKey_1 + "88ac";
scriptSig2 = "76a914" + hashedPubKey_2 + "88ac";

Thank you for your comment. I'm indeed using 2 different hashed public keys. I'll update my original post ASAP to prevent further confusion.

Still, even though I'm using different hashed public key, I can't sign the uncompressed tx

following code from sign.cpp about line25 now.  Seems that the signing from uncompressed keys are purposed disabled in newer core code.
I didn't follow why that was disabled, maybe just to avoid potential hash collision in the future and keep data more standardized.
// Signing with uncompressed keys is disabled in witness scripts
if (sigversion == SigVersion::WITNESS_V0 && !key.IsCompressed())
    return false;

Uncompressed keys are only disabled for spending segwit outputs. The reason for disallowing them is to make transactions smaller and is unrelated to hash collisions.


text:
How to avoid "single point of trust" in online bitcoin exchange sites
How do an online service such as a Bitcoin exchange prevent some sysadmin from transferring assets from its users to him self (like in the bitcoin case, a secret wallet of his own) and take off to Bahamas?
I mean if I'm able to log in to their site, transfer or withdraw my assets at any time, it seems to me like someone on the inside could do the same for large amount of users with little effort? I'm thinking for instance of a DB admin or someone responsible for authentication.
If there's no satisfying answer to this (like a mechanism that requires cooperation of N people for such attack to succeed), I think I've reached my limit on how much of my money I can trust an online company with.

Posted this at security.stackexchange.com because I thought it was much more related to computer security than the specifics of bitcoin. The question is about protecting any digital asset really. If it could be migrated back to security I'd be happy.

It's not on topic on Security Stack Exchange in its current form.

Care to elaborate why?

Your question asks what controls prevent an admin of bitcoin transferring funds to himself. That is very specific to bitcoin.

Not really. It could be any digital asset. I see it plainly as a question about information security. May I try to reformulate the question on security.SE, and leave out all references to bitcoin?

Happy to chat in the DMZ - Security Stack Exchange chat, rather than here.

The Bitcoin Wiki (in the linked article for multisig) cites a post on BitcoinTalk describing nearly the same problem that you did:

Suppose I am working with a company that wants to accept Bitcoin for international trades.
The company, for security reasons, would not want a single one of its employees to have access to the company BTC wallet's password. Any transaction would have to meet the approval of more than one employee.
Is this possible already? If not, how could it be implemented with public-key cryptography?

One common solution to this problem is multisignature (commonly abbreviated as multisig).
Most Bitcoin transactions (the ones created by users like you and me) require only one signature — that of the owner of the private key that corresponds to the Bitcoin address. Multisig comes into play by requiring a certain number of signatures for a transaction to be verified. The Bitcoin Wiki gives a few examples of this. The following examples use M-of-N transactions, meaning that M users (out of N users who are able to sign the transaction) must sign the transaction for it to be verified:

1-of-2: Husband and wife petty cash account — the signature of either spouse is sufficient to spend the funds.
2-of-2: Husband and wife savings account — both signatures are required to spend the funds, preventing one spouse from spending the money without the approval of the other
2-of-3: Parents’ savings account for child — the kid can spend the money with the approval of either parent, and money cannot be taken away from the child unless both parents agree

Specifically in regards to your question, 10 executives or employees of a Bitcoin exchange may have the private keys associated with a multisignature address; a combination of any 5 of those private keys may be required to send bitcoins from this address (this is a 5-of-10 transaction in the M-of-N transaction format).
This doesn't guarantee the bitcoins won't be stolen. 5 "evil" employees could collude to steal the bitcoins without the other 5 "good" employees knowing. However, this is a much more trustworthy system than a single employee being able to steal all the bitcoins (as could happen with a "standard" bitcoin address if an "evil" employee had access to the private key).
However, you might notice some flaws with this in regards to a Bitcoin exchange. Wouldn't it get tiresome for the 5 employees to constantly sign a transaction to provide withdrawals to users? The answer is yes, which is why companies implement a "hot wallet" — a wallet that holds a fraction of the bitcoins the company actually owns (the rest of the bitcoins are in a "cold wallet", which would probably be the multisig address). I'm not sure of the exact process exchanges use to send bitcoin from the cold wallet to the hot wallet (and I'm sure it differs from company to company), but I would guess that every once in a while, if the hot wallet is running low on bitcoin, M employees would verify a transaction from the multisig wallet to the hot wallet.
The hot wallet is totally susceptible to being stolen by a single "evil" employee (since it's most likely not a multisig wallet for efficiency, and thus has only one private key), or to being stolen by a thief, but companies would much rather only lose a fraction of their bitcoins (a hot wallet) than all of their bitcoins (a cold wallet).

Very interesting. I totally buy that this is a feasible approach, both mathematically and practically. Thanks a lot for sharing.


text:
Why is Public Key aggregation in MuSig described as a product of the public keys?
In the the MuSig2 paper, it is described that:

Each signer randomly generates and communicates to others a nonce
Ri=g^ri; then, each of them computes R=∏ni=1Ri,c=H( ̃X,R,m)where
̃X=∏ni=1Xiis the product of individual public keys

I would expect that an operation of two or more points on an elliptic curve would be described as an addition operation, such as the sum of individual public keys {X1...Xn} (not the product of individual public keys). The paper describes the aggregation of public keys and public nonce values as a product. Am I misunderstanding the actual operation occurring here? Why is this the product of curve points?
In other words: my understanding is that adding points on the curve involves the geometric operation of drawing a line between two points and finding the third point that intersects the curve (with flip across x-axis). When it comes to doing things like combining public keys and public nonces, is the same geometric operation still occurring? Isn't this still described as 'adding' points on the curve?

This is purely a matter of notation.
The points on the elliptic curve form a cyclic group. A group is a set with an associated identity element and a group operation. People need a symbol for that group operation. In some contexts it is more common to use an addition symbol (and multiplication representing repeated application of the group operation), and in other contexts it is more common to use a multiplication symbol (and exponentiation representing repeated application of the group operation).
Both notations are commonly used, and it has no effect on the actual operations. It's just a question of how to write what. There are even somewhat heated debates on this topic. You may even notice one of the MuSig2 paper's authors commenting in that thread.
One thing to point out that may explain this, is that the MuSig2 paper not ever mentions elliptic curves. It needs prime-ordered groups in which certain assumptions hold, but beyond that it could be any group - and the paper states, in Section 3.1, "The group G is denoted multiplicatively". This is the case for most cryptography based on the discrete logarithm problem: it works for any group. And historically, the first type of groups used for this purpose were integers modulo a prime numbers (with certain other restrictions) - where multiplication is the obvious choice for the symbol. You may also notice it is called the "discrete logarithm" problem, and not the "discrete division" problem.
At the same time, in the context of elliptic curves, you're right of course that the operation is called point addition - and repeated application of it is called point multiplication. I personally prefer it as well, as means you get a more obvious correspondence between scalar and group operations (e.g. s = k + H(R,P,m)x for computing a Schnorr signature vs s·G = k·G + H(R,P,M)·x·G = R + H(R,P,m)·P for verifying it, as opposed to Gs = R·PH(R,P,m) in multiplicative notation), and avoids sometimes nested layers of superscripts in typesetting.
EDIT: Tim Ruffing pointed out to me that the real reason for using multiplicative notation in MuSig2 is because the paper started as a revision of the MuSig paper, which also used multiplicative notation. The MuSig-DN paper uses additive notation, however.

The point about the paper not mentioning elliptic curves is interesting. It would seem that once you have a prime-ordered group with certain assumptions, reasoning about cryptography concepts (like MuSig) can be done within the abstraction of an abelian group without thinking about the underlying curve operations.


text:
Recognizing Taproot outputs in raw transactions
What can be the contents of an P2TR output script? Is it always OP_1 0x20 <32-bit public key>? Can multisig script be there, and if yes - in what format, and more importantly - how do I convert that script to an address?

What can be the contents of an P2TR output script? Is it always OP_1 0x20 <32-bit public key>?

A Taproot output contains a 32 byte witness program (a tweaked internal key or an untweaked public key if eschewing the tweak) after OP_1. The OP_1 (01) makes it clear that it is a SegWit v1 output rather than say a SegWit v0 output (00). Any scripts are included in the leaves of the Taproot tree and hashed up to a Merkle root (which tweaks the internal public key) so the witness program can commit to various leaf scripts.

Can multisig script be there, and if yes - in what format?

A multisig script can be in a leaf or multiple leaves of the Taproot tree. Note that a Taproot multisig script uses the opcode OP_CHECKSIGADD rather than OP_CHECKMULTISIG (outlined in BIP 342).

How do I convert that script to an address?

The leaf scripts are hashed within the Taproot (Merkle) tree. The Merkle root then tweaks the internal public key. A breakdown of bech32m (SegWit v1) addresses is here. This tweaked internal public key (or witness program) is directly included within the address.

Thanks! Just to confirm - in any case, Taproot (Segwit v1) output is always 32-byte public key, which hides complexity of whatever script might be behind it. This public key is translated into address using bech32m, and that address represents the output.

Yes, a transaction output is a taproot output if and only if it consists of OP_1 followed by a 32-byte push.


text:
I am getting this error when I try to run example_test.py. Is there anything I am doing wrong?

I am getting this error when I try to run example_test.py. Is there anything I am doing wrong?


text:
How does OP_CHECKSIG work
Hi I am learning bitcoin and learning how scripting works and how to use P2PKH. I was wondering how does OP_CHECKSIG work. I want to understand what is the data that the private key signs to create the digital signature itself?
Is there a simple explanation which illustrates how the digital signature is constructed for verification in OP_CHECKSIG? I understand that the Opcode uses the ECDSA algorithm for verifying the signature but I want to understand how the signature is generated for verification?
Pardon me if this is a basic question. Thanks

What is signed is a simplified version of the transaction (replacing the scriptSig, since that is what we are creating). There is a lot here so hopefully I covered it all:
 * `version` (4 Bytes) - Transaction format version
 * `flag` (2 Byte Array) - Optional flag, if present, must be 0001, which indicates there is witness data in this transaction
 * `input counter` (Variable Length) - Number of inputs in the transaction represented by a Variable Length Integer.
 * `inputs` (based on Input Counter) - List of all transaction inputs which will be spent and which reference unspent transaction outputs from previous transactions.
 * `output counter` (Variable Length) - Number of outputs in the transaction represented by a Variable Length Integer.
 * `outputs` (based on Output Counter) - List of all transaction outputs where the coins will be sent and which will become unspent transaction outputs to be spent in future transactions.
 * `scriptsig` (variable) - First, a one-byte varint which denotes the length of the scriptSig, then it is temporarily filled with the scriptPubKey of the output we want to redeem.
 * sequence number (4 Bytes) - Used as a relative lock time if transaction version is >= 2. See BIP68.
 * one-byte varint containing the number of outputs in our new transaction
 * 8-byte field (64 bit integer) containing the amount we want to redeem from the specified output (in satoshis)
 * one-byte varint denoting the length of the output script
 * output script
 * `locktime` (4 Bytes) - If non-zero and sequence numbers are < `ffffffff`: it represents either the block height or timestamp when transaction is final.
 * four-byte "hash code type" (1 in our case): 01000000 see [Sighash types][1]

Then, double-SHA256 hash this entire structure and the hash is what is signed. For an example, see https://bitcoin.stackexchange.com/a/5241/60443

Thanks that was great! @JBaczuk Also is the way the signature is created differs for different sighash type? Is there a documentation where I can find where and how these transactions are signed?
Or if you know could you explain say something like a SIGHASH_ALL|SIGHASH_ANYONECANPAY. How the Unlocking Script signs the inputs?

Yes, see https://bitcoin.org/en/transactions-guide#signature-hash-types

So from what I have read. The input contains the previous transaction hash, the index and the ScriptPubkey of this input that we are consuming? But is this ScriptPubkey a temporary value which is replaced by some other script? @JBaczuk

No, the input does not contain the scriptpubkey, the scriptsig does while you are signing it, then it is replaced with the actual scriptsig which is a script that satisfies the scriptpubkey. The scriptsig will contain the transaction signature, this is why it is temporarily filled with the scriptpubkey

So that means, I have to replace the scriptPubKey of the input with the actual signature appended with the hash code type and then consequently remove the last 4 bytes? This will be the input that is hashed twice and signed over by the private key? @JBaczuk

Sorry I might have been confusing, I'd recommend following the link in my answer for how to sign a tx

So I did go through the link. My question is more towards verifying a transaction signature rather than how to sign a tx. @JBaczuk

Gotcha, see https://bitcoin.stackexchange.com/a/32308/60443

Okay So i found the bug, It was related to storing the data in little Endian format!

That will bite you while you're learning for sure


text:
What is a descriptor in "generatetodescriptor"?
I thought it would be like a label as in:
getnewaddress "myawesomelabel"
> bcrt11qay7aqw7azkqhpda22vuzxphkccgmcvc9grz8z

but then
generatetodescriptor 10 "myawesomelabel"
> myawesomelabel is not a valid descriptor function (code -5)

So all I believe I know is that a descriptor is not a label?
What is a descriptor?

If it were a label then the parameter would be named label.
Descriptor refers to output script descriptors which are described in this document as well as BIPs 380, 381, 382, 383, 384, 385, and 386,


text:
c-lightning node backup-restore
How do I restore a c-lightning node from  a backed up hsm_secret ?
I have tried running lightningd by replacing the generated hsm_secret with the backed-up one. It shows no output and no channel.
How can I retrieve the funds in the node from there ?

The hsm_secret is used to derive keys for both onchain and offchain (channels commitments) transactions.
On chain
To retrieve on chain funds you can rescan the block chain for your utxos by using the --rescan startup option of lightningd.
Off chain
You can not re create the whole state of your channels just from the hsm_secret, which are stored in the database. Moreover it's very discouraged to restore from a backed up database (penalty transactions...).
Fortunately, with the option_static_remotekey now enabled by default you can now claim your funds onchain after your peer force closed the channel (if the channel was opened when both peers signaled this option).
The process is detailed here as part of the C-lightning FAQ draft.
How do i backup, in practice ?
The different backup solutions currently available are detailed here.

Hsm secret is only used to derive your keys but you need more than that - which is the state of your channels (meaning the most recent commitment transaction and revocstion secrets). This information can be found in your sql file in the .lightning directory. The problem is that this backup has to be made everytime the state of a channel changes (even failed routing attempts) there is a hook for the plugin api that triggers an event everytime something is written to the database. So I guess it would be best to create a plugin that streams out a replica of your dB writes to a remote backup


text:
Where can I find a complete list of Bitcoin forks (soft, hard, intentional and unintentional)
I was looking to study the history of Bitcoin forks including the 2013 incident that may or may not have been a Hard fork depending on your definition.

There is a paper that provides extensive detail on the history of all kind of forks on Bitocin, Ethereum and Ethereum Classic, you can read it here, Atomically Trading with Roger: Gambling on the success of a hardfork.
Here is the list of Forks so far,

The following content is sourced from the above paper,

    So far, Bitcoin has implemented over six softforks. These softforks
range from introducing rules to prevent miners creating coinbase
transactions with duplicated identification hashes, requiring all
ECDSA signatures to strictly enforce DER coding, and introducing both
absolute and relative lock times for individual transaction outputs.
In terms of implementation, this involves storing new information in
the scriptsig of the coinbase transaction, constraining transaction
validation rules or re-defining the use of special OP_NOP function.
   On
the other hand, Bitcoin has experienced two accidental (and temporary)
splits (i.e. Fork-1, Fork-2 emerged) that required miner intervention
to remedy. The first split permitted a user to exploit an integer
overflow bug and create 184 billion coins. This required miners to
co-operatively extend a new blockchain without the coin creation
transaction [6] and to enforce a soft-fork to prevent this exploit.
The second split involved miners who upgraded to Bitcoin Core 0.8
accidentally creating blocks that were invalid for Bitcoin Core 0.7.
Unfortunately, BerkeleyDB’s configuration in Bitcoin Core 0.7 was
non-deterministic and as a result was not compatible with LevelDB’s
configuration in Bitcoin Core 0.8. Resolving this fork required miners
to immediately downgrade to Bitcoin Core 0.7 and abandon the forked
blockchain. Next, the developers released Bitcoin Core 8.1 that
enforced the activation of a hardfork12 after a two-month grace period
for miners and users to upgrade.

The best resource I've seen that answers this question is this BitMEX blog post. It includes some of the early Satoshi era forks that haven't been included in any existing answers.

On their github:
Please reffer to githubs help page for searching issues.
Examples:
This is just example of how you could use it in searching for "issue" from 2013-01-01 to 2013-12-31:
search?utf8=%E2%9C%93&q=issue+created%3A%222013-01-01+..+2013-12-31%22&type=Issues
Full link for bitcoin's issues from that period core would be: https://github.com/bitcoin/bitcoin/search?utf8=%E2%9C%93&q=issue+created%3A%222013-01-01+..+2013-12-31%22&type=Issues
This would look for "bug" for the same periods:
search?utf8=%E2%9C%93&q=bug+created%3A%222013-01-01+..+2013-12-31%22&type=Issues
I do not have enough reputation to post you more than 2 link: h++ps://github.com/bitcoin/bitcoin/search?utf8=%E2%9C%93&q=bug%20created%3A%222013-01-01%20..%202013-12-31%22&type=Issues
You could apply the same on cards and projects


text:
Taproot block version
In block 681543 Slush Pool had mined the proper taproot signalling (bit 2 in block version) block but the version wasn't the default 0x20000004 with a version base 0x20000000 but 0x3fff0004. Does it make any difference? Why would they use a different version base (0x3fff0000) just for this block?

I think this may be a duplicate of one of these two: https://bitcoin.stackexchange.com/a/96397/5406, https://bitcoin.stackexchange.com/q/105694/5406

Thanks, the ASIC boost may be the proper answer :)

If one of them answers your question, you can close it yourself as a duplicate by flagging


text:
How ./configure Bitcoin Core build to pick up depends build and installation path at the same time?
I'm trying to build Bitcoin Core and, if I understand it correctly, the configure script uses the --prefix= option twice, once for the inclusion of the depends build (from depends/README.md):
**Bitcoin Core's configure script by default will ignore the depends output.** In
order for it to pick up libraries, tools, and settings from the depends build,
you must point it at the appropriate `--prefix` directory generated by the
build. In the above example, a prefix dir named x86_64-w64-mingw32 will be
created. To use it for Bitcoin:

    ./configure --prefix=$PWD/depends/x86_64-w64-mingw32

And another usage of --prefix as it's usually used in configure, to specify a nonstandard install location (output from ./configure --help):
By default, `make install' will install all the files in
`/usr/local/bin', `/usr/local/lib' etc.  You can specify
an installation prefix other than `/usr/local' using `--prefix',
for instance `--prefix=$HOME'.

How can I specify an installation path and a depends path at the same time?

You cannot set the installation path with ./configure, but only when running make install. You need to specify --prefix=once for ./configure and once for make install.

make: unrecognized option '--prefix=/home/...

Another option might be to use DESTDIR: https://www.gnu.org/prep/standards/html_node/DESTDIR.html. If that works, maybe you can have --prefix= and DESTDIR= in the same ./configure command.


text:
How to use python reference for encoding a bech32 address?
Could someone provide an example of how to use the python reference implementation for generating a bech32 address?
For example, generating a mainnet bech32 address for this scriptPubKey: "0014751e76e8199196d454941c45d1b3a323f1433bd6"

The reference implementation provides a handy all-in-one encode function. To encode the scriptPubKey 0014751e76e8199196d454941c45d1b3a323f1433bd6 as a mainnet bech32 address, you would do:
import bech32
import binascii

spk = binascii.unhexlify('0014751e76e8199196d454941c45d1b3a323f1433bd6')
version = spk[0] - 0x50 if spk[0] else 0
program = spk[2:]
print(bech32.encode('bc', version, program))

To add to Andrew's answer I recently used the above code snippet to generate bech32m addresses from P2TR scriptPubKeys.
I cloned the bech32 repo and then created a file for the code snippet in the bech/ref/python directory.
I took a P2TR scriptPubKey from the BIP 341 test vectors e.g. 5120712447206d7a5238acc7ff53fbe94a3b64539ad291c7cdbc490b7577e4b17df5
Then this slightly adjusted code generated the associated bech32m address (bc1pwyjywgrd0ffr3tx8laflh6228dj98xkjj8rum0zfpd6h0e930h6saqxrrm).
import segwit_addr
import binascii

spk = binascii.unhexlify('5120712447206d7a5238acc7ff53fbe94a3b64539ad291c7cdbc490b7577e4b17df5')
version = spk[0] - 0x50 if spk[0] else 0
program = spk[2:]
print(segwit_addr.encode('bc', version, program))


text:
"Error: no RPC connection" when trying to run Bitcoin Core functional tests
I'm using WSL on Windows 10. I'm able to build from source and run the unit tests. Integration tests are failing for me when I run test/functional/test_runner.py --extended with error AssertionError: [node 0] Error: no RPC connection
I'm guessing bitcoind has to be running. If that's the case, do I have to sync it just to run the tests?
Full error:
Temporary test directory at /tmp/test_runner_₿__20220504_123152
Running Unit Tests for Test Framework Modules
..........
----------------------------------------------------------------------
Ran 10 tests in 0.614s

OK
Traceback (most recent call last):
  File "/usr/src/bitcoin/test/functional/create_cache.py", line 27, in <module>
    CreateCache().main()
  File "/usr/src/bitcoin/test/functional/test_framework/test_framework.py", line 156, in main
    exit_code = self.shutdown()
  File "/usr/src/bitcoin/test/functional/test_framework/test_framework.py", line 311, in shutdown
    self.stop_nodes()
  File "/usr/src/bitcoin/test/functional/test_framework/test_framework.py", line 567, in stop_nodes
    node.stop_node(wait=wait, wait_until_stopped=False)
  File "/usr/src/bitcoin/test/functional/test_framework/test_node.py", line 336, in stop_node
    self.stop(wait=wait)
  File "/usr/src/bitcoin/test/functional/test_framework/test_node.py", line 184, in __getattr__
    assert self.rpc_connected and self.rpc is not None, self._node_msg("Error: no RPC connection")
AssertionError: [node 0] Error: no RPC connection
2022-05-04T19:31:53.315000Z TestFramework (INFO): Initializing test directory /tmp/test_runner_₿__20220504_123152/cache
2022-05-04T19:31:56.079000Z TestFramework (ERROR): Unexpected exception caught during testing
Traceback (most recent call last):
  File "/usr/src/bitcoin/test/functional/test_framework/test_framework.py", line 132, in main
    self.setup()
  File "/usr/src/bitcoin/test/functional/test_framework/test_framework.py", line 294, in setup
    self.setup_chain()
  File "/usr/src/bitcoin/test/functional/test_framework/test_framework.py", line 385, in setup_chain
    self._initialize_chain()
  File "/usr/src/bitcoin/test/functional/test_framework/test_framework.py", line 777, in _initialize_chain
    self.start_node(CACHE_NODE_ID)
  File "/usr/src/bitcoin/test/functional/test_framework/test_framework.py", line 534, in start_node
    node.wait_for_rpc_connection()
  File "/usr/src/bitcoin/test/functional/test_framework/test_node.py", line 225, in wait_for_rpc_connection
    raise FailedToStartError(self._node_msg(
test_framework.test_node.FailedToStartError: [node 0] bitcoind exited with status 3 during initialization
2022-05-04T19:31:56.133000Z TestFramework (INFO): Stopping nodes
[node 0] Cleaning up leftover process
Traceback (most recent call last):
  File "test/functional/test_runner.py", line 832, in <module>
    main()
  File "test/functional/test_runner.py", line 471, in main
    run_tests(
  File "test/functional/test_runner.py", line 525, in run_tests
    subprocess.check_output([sys.executable, tests_dir + 'create_cache.py'] + flags + ["--tmpdir=%s/cache" % tmpdir])
  File "/usr/lib/python3.8/subprocess.py", line 415, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "/usr/lib/python3.8/subprocess.py", line 516, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['/usr/bin/python3', '/usr/src/bitcoin/test/functional/create_cache.py', '--cachedir=/usr/src/bitcoin/test/cache', '--configfile=/usr/src/bitcoin/test/functional/../config.ini', '--tmpdir=/tmp/test_runner_₿__20220504_123152/cache']' returned non-zero exit status 1.
`\

The test framework starts its own bitcoind instances, you don't need to have bitcoind separately.
This error is an indication that a bitcoind is failing to start when test framework tries to start it. If you look at the full output, you'll see that it is actually a combination of multiple errors. The line that actually matters is
test_framework.test_node.FailedToStartError: [node 0] bitcoind exited with status 3 during initialization

It is not clear why it isn't starting, but a good place to start looking is in the test datadir located at /tmp/test_runner_₿__20220504_123152/cache.


text:
as a individual miner's side, how UASF, UAHF agree or disagree is occurred?
UASF is timestamp-based method. after that time, new rules will start. but i have a few question about this. how this rules is accepted by USER?

does miner program contains 'yes' or 'no' about this decision?
'1' is true, and user not express any decision. by this case, is user's fork can be violate fork?
Who is the representative in the working blockchain that inform 'this feature will be added!'?    How is the notification received by all nodes?

Can you clarify your second question? It does not make any sense.

it mean.. new rule's apply require upgrade or update of Bitcoin-Core, but user do not any update. in this case, user's fork will remain old version and have possibility that be violate fork .

does miner program contains 'yes' or 'no' about this decision?

No. Forks are not votes, especially user activated forks. A user activated fork occurs with no requirements on miners. There is no signaling of readiness from miners nor do miners have any say on when it activates. All miners can do is decide whether they want to mine the fork and enforce its rules after the fork occurs.

Who is the representative in the working blockchain that inform 'this feature will be added!'? How is the notification received by all nodes?

There is no representative (that would imply there is some central authority in charge of the blockchain and there is not) nor is there any sort of notification system.
A user activated fork happens when a group of users decide they want some consensus change to occur. They write software that implements this change along with the activation time. Those users will then try to get other users to join them. When their fork activates, they will start enforcing their new rules.

thanks for your answer and please comment my other question. :) i have no permission of using mention function


text:
Where is bitcoin.conf and why doesn't bitcoind find existing datadir v0.17.1
Just built no gui, no wallet bitcoin on WSL Ubuntu Bionic, Bitcoin v0.17.1.
I want to experiment with bitcoin-cli.
I followed recommendation to run bitcoind -princonsole and it says:
Using config file

/home/<myusername>/.bitcoin/bitcoin.conf

This file doesn't exist.
I followed some dense discussion on how should this behave to make dumb users happier on github, supposedly there were some merges, but frankly, I have no clue what was the final conclusion and what is or isn't in 0.17.1
Eventually, I understood that datadir must be specified first.
But that doesn't work for me.
~/bitcoin$ bitcoind -datadir /mnt/d/blockchain -txindex
Error: Specified data directory "" does not exist.

/mnt/d/blockchain definitely exists.
Thanks for any help.
 Many thanks to Nate Eldredge for pointing out a dumb error of mine and hope someone can help parsing and shedding some light on this:
https://github.com/bitcoin/bitcoin/issues/10746
Blockchain download has started and now I am waiting for the end result.

Please mark Nate's answer as correct by clicking the checkmark instead of editing your answer

The syntax should be
bitcoind -datadir=/mnt/d/blockchain -txindex

Note the = sign.
This will look for the bitcoin.conf file at /mnt/d/blockchain/bitcoin.conf and will store the blockchain, databases, wallet files, etc, all in /mnt/d/blockchain.  With this option, Bitcoin Core shouldn't read or write anything in ~/.bitcoin at all.

Lol. Feel embarassed. That worked.

On Ubuntu your bitcoin.conf file should be located at /home/username/.bitcoin/bitcoin.conf
If that file do not exist create it and fill with standard parameters like:
server=1
listen=1
daemon=1
rpcuser=youusername
rpcpassword=yourpassword
rpcallowip=your ip or the rpc commands sending machine

Maybe it should but it isn't:
~/.bitcoin$ ls
banlist.dat  blocks  chainstate  debug.log  fee_estimates.dat  mempool.dat  peers.dat  wallets

Just type 'touch bitcoin.conf' and fill the file with the aforementioned parameters.


text:
Bitcoind could not locate RPC credentials but rpcuser and password are set
I installed bitoind and synced it. But when i'm trying to connect from my php website i getting:
Unable to connect to http://user:password@my.bitoind.server.ip:18332/.
Also when i'm trying to see password through command
bitcoin-cli -stdinrpcpass getblockchaininfo
it returns
could not locate RPC credentials. No authentication cookie could be found, and RPC password is not set.  See -rpcpassword and -stdinrpcpass.  Configuration file: (/blockchain/.bitcoin/bitcoin.conf).
My bitcoin.conf file is setted and works nice
rpcuser=USER
rpcpassword=PASS
testnet=0
daemon=1
rpcport=18332
rpcallowip=*
server=1
datadir=/blockchain/.bitcoin
txindex=1

maybe it works when you change
rpcallowip=*
to
rpcallowip=127.0.0.1

I found I had to copy the contents of ~/.bitcoin/bitcoin.conf into /etc/bitcoin/bitcoin.conf because that's what's being used when bitcoind starts on boot up. I put my user and password in that file, rebooted, and bitcoin-cli worked again.
Also try adding
bitcoin-cli -stdinrpcpass getblockchaininfo -rpcuser user -rpcpassword password

Also strange thing, when i trying for exaple to change rcp port by bitcoin-cli -rpcport 8332, it's like setting to 0 and returns "Could not connect to the server 127.0.0.1:0"

Do you want to run testnet or mainnet? 18332 is the testnet port. 8332 is mainnet. You have testnet=0 which maybe should be testnet=1?

first of all i tried testnet, but it didn't work the same. You know, i solved the problem, but with not finally correct method. I used command: bitcoind --daemon -rpcuser=user -rpcpassword=password -txindex -rpcallowip=127.0.0.1 -rpcallowip=185.50.25.17 -rpcport=8332. It works, but i don't think this method is ok.


text:
bitcoin repo sighash.json data format
Bitcoin enthusiast here. Learning "the hard way" how bitcoin works (andreas books, looking in js/python implementations), I'm writing (as an hobby) some code here and there to understand things and to test it, I'm using the tests available on the bitcoin github repo. But now, I'm struggling with the ones on the sighash.json file.
What is the encoding format used for the raw transactions ? (first element on each array).
I understand the traditional format which looks like 0100000000010280e688...000ffffffffe9b54...39da98ac00000000. But here I'm honestly lost. On the tests file, it doesn't look like a regular transaction.
Example:
907c2bc503ade11cc3b04eb2918b6f547b0630ab569273824748c87ea14b0696526c66ba74020000004ab65ababfd1f9bdd4ef073c7afc4ae00da8a66f429c917a0081ad1e1dabce28d373eab81d8628de802000000096aab5253ab52000052ad042b5f25efb33beec9f3364e8a9139e8439d9d7e26529c3c30b6c3fd89f8684cfd68ea0200000009ab53526500636a52ab599ac2fe02a526ed040000000008535300516352515164370e010000000003006300ab2ec229

How am I supposed to decode such string ?
Thanks.

You decode them in exactly the same way that you decode a transaction. They are perfectly valid transactions and a decoder should be able to decode them properly and get meaningful data out of them. The reason they look weird is because every part of the transaction is randomly generated so the fields do not necessarily contain data that you expect (e.g. the version number is randomly generated instead of the standard 01000000 or 02000000).


text:
Issues with stopping bitcoind after 22.0 update
My setup was originally Bitcoin core 0.21.0, with IBD done long time back.
Now for some experimental purposes, I turned on txindex in bitcoin.conf and reindexing was happening for hours.
In mid of it, I stopped the process, upgraded to 22.0 and started 'bitcoind' again. I picked up re-indexing from where it was terminated before. But then when I did 'bitcoin-cli stop', it got stuck with the following logs:
2021-11-25T13:17:05Z UpdateTip: new best=0000000000000000000883a03094dde1221683e17fb3982ca36d84cb114b3eb8 height=605407 version=0x20400000 log2_work=91.374385 tx=478072907 date='2019-11-26T01:00:35Z' progress=0.699403 cache=303.2MiB(2246070txo)
2021-11-25T13:17:05Z UpdateTip: new best=00000000000000000014e207348c17b888af84a47b909006d92f4e764368a8e9 height=605408 version=0x20000000 log2_work=91.374410 tx=478076043 date='2019-11-26T01:10:59Z' progress=0.699408 cache=303.4MiB(2248147txo)
2021-11-25T13:18:45Z tor: Thread interrupt
2021-11-25T13:18:45Z torcontrol thread exit
2021-11-25T13:18:45Z addcon thread exit
2021-11-25T13:18:45Z Shutdown: In progress...
2021-11-25T13:18:45Z opencon thread exit
2021-11-25T13:18:46Z msghand thread exit
2021-11-25T13:18:46Z net thread exit
2021-11-25T13:18:47Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat started
2021-11-25T13:18:47Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat completed (0.29s)
2021-11-25T13:19:54Z scheduler thread exit

I waited for 1-2 hour for it to properly quit. It didn't. So I closed my terminal, wishing it shouldn't be screwing up / corrupt the files!
Gladly it didn't. I then increase dbcache to 4096 (with the hope of increasing the speed of reindexing) and started bitcoind again. Now I again tried terminating with 'bitcoin-cli stop' and again got stop with these logs:
2021-11-25T17:33:01Z UpdateTip: new best=0000000000000000000c7b7267385a7a8b0136a6723380872b6846dfa1b5a802 height=627203 version=0x20000000 log2_work=91.883753 tx=523176359 date='2020-04-22T21:25:52Z' progress=0.765346 cache=2827.6MiB(21174875txo)
2021-11-25T17:33:04Z UpdateTip: new best=0000000000000000000f0b3f604df25db94b1248e69097548baafa7125b1bc65 height=627204 version=0x3fffe000 log2_work=91.883775 tx=523178937 date='2020-04-22T21:32:05Z' progress=0.765350 cache=2827.6MiB(21175427txo)
2021-11-25T17:33:05Z UpdateTip: new best=000000000000000000103cbcbe3cbb20759da63f5c9574d33400ae81e873b4bb height=627205 version=0x20000000 log2_work=91.883796 tx=523182006 date='2020-04-22T21:34:48Z' progress=0.765354 cache=2827.8MiB(21176750txo)
2021-11-25T17:33:06Z tor: Thread interrupt
2021-11-25T17:33:06Z addcon thread exit
2021-11-25T17:33:06Z opencon thread exit
2021-11-25T17:33:06Z torcontrol thread exit
2021-11-25T17:33:06Z Shutdown: In progress...
2021-11-25T17:33:06Z net thread exit
2021-11-25T17:33:09Z UpdateTip: new best=0000000000000000000ff51c79d6d89c3c9368b2c44cc763e104e911137a833d height=627206 version=0x20000000 log2_work=91.883818 tx=523185004 date='2020-04-22T21:57:24Z' progress=0.765359 cache=2828.2MiB(21179795txo)
2021-11-25T17:33:09Z msghand thread exit
2021-11-25T17:33:19Z loadblk thread exit
2021-11-25T17:33:19Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat started
2021-11-25T17:33:19Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat completed (0.27s)
2021-11-25T17:33:19Z scheduler thread exit
2021-11-25T17:33:20Z FlushStateToDisk: write coins cache to disk (21179795 coins, 2965556kB) started

I am not afraid to kill the terminal, since the last line of the log says 'Writing something to disk'. I waited for almost an hour now.
My system monitor doesn't show bitcoind, it shows this process: b-shutoff, which is not doing any active Disk read / writes!
Is it safe to close the Terminal? I don't want to do IBD again! Any measures I can take to avoid this (bitcoind not stopping) in future?
Thanks.
Edit:
It ended properly exactly after an hour, once I made this post:
2021-11-25T18:33:41Z FlushStateToDisk: write coins cache to disk (21179795 coins, 2965556kB) completed (3620.90s)
2021-11-25T18:33:43Z FlushStateToDisk: write coins cache to disk (0 coins, 249287kB) started
2021-11-25T18:33:43Z FlushStateToDisk: write coins cache to disk (0 coins, 249287kB) completed (0.17s)
2021-11-25T18:33:48Z [default wallet] Releasing wallet
2021-11-25T18:34:02Z Shutdown: done

I am glad. But any hints to improve this situation?

Is this a slow spinning disk, or a USB drive, or a network drive or so? Flushing gigabytes to the database on disk may take a while on those, though an hour is very long.

It's a recently bought external HD. I just tried copying a 1GB file from my system to that external HD and it took roughly 5s.

The message "FlushStateToDisk: write coins cache to disk (21179795 coins, 2965556kB) started" got me here, I am still in the IBD process setting up a new node.
Reason: this flush to disk took a considerate amount of time.. the impatient nature of mind got me looking into a potential problem. Before even writing this post, the IBD already continued.
I was not able to capture the amount of data being written... I know it is huge, as it's the current validation cache flushing to disk triggered by running out of cache space.
More to read: What should I do about these messages in Bitcoin-core's debug-log?
To answer your question on preventing this, besides not stopping your bitcoin daemon..
You can either let this process finish itself or the validation will be forced to start from an earlier "checkpoint" (potentially means a re-run of the full chain)
Increasing the "dbcache" I don't consider a viable option. When you increase the cache value, the amount of data to be written when the flush triggers will increase to be a.. big dump :)