text:
My bitcoin change
I am new to this.I have sent out bitcoin over the blockchain before and saw that the hash just took a fee. However the other day it took out over.95 of a bitcoin when wanting to only send 0.04 of a bitcoin to binance. I was told they send you an adress for change, which I didn,t know. I saw my ledger nano scrolling an address. Was this the change coming back? Since I saw such a large amount I wasn't sure that my coin would be going out to someone else or me. I clicked on the x instead of the checkmark. Did I lose my coin? Can I get that address back. can I go to that blockchain transaction and have it sent to my wallet since it says unspent.Please help. Once again did I lose my Bitcoin can I go back and have it sent to me from the original transaction?Can I get it back with the original address rather then the new?

I marked this as a duplicate, but here is some specific info to help calm your nerves. Don't worry, from the sounds of things you did not lose any coins :)
Your ledger nano would not require you to 'accept' the change being returned to you, this would happen automatically in the wallet when you send any transaction. No action required on your part (beyond sending the transaction itself), in fact almost every bitcoin transaction will include a change output that pays back to the owner of the input, this is inherent to the function of bitcoin.
If your transaction says 'unconfirmed' that is normal, and means that it has not yet been included in a block. Depending on the fee paid, it should confirm in due time, and then your reported wallet balance should simply be (balance before transaction) - (payment sent).

Would the ledger nano scroll the address coming to me? If so I might have pressed the x instead of the check.Would I still get the coin back.

This page has details on how to send a transaction using your ledger: https://support.ledgerwallet.com/hc/en-us/articles/360006353314 . If you clicked an 'x', chances are you simply declined to send the transaction in the first place (the screen was likely asking you to confirm the recipient's address, not your own change address). I have never seen any wallet software that forces you to 'confirm a change address' in order to receive your change, in fact that would be a positively horrible implementation. From the info you've provided, I am reasonably sure your coins are safe.

When my change was going to come back to me an address scrolled on my ledger nano, because I hit the X the transactions for the change return seems to have not worked.Can I retrieve my change again by going up to the same transaction on the blockchain and get the change?

Is your balance now lower than expected? Again, there is no action required to ‘have your change sent to you’. This happens automatically if a transaction is sent, it is a part of (nearly) every transaction.

I think the ledger nano won't allow incoming info with out verfiying the address which by mistake I hit the x which says its not verified.Can you check that out.

The ledger will display the address you are paying to, and ask you to confirm that. It will not ask you to confirm the change address. Once you confirm payment address, the hanger address will be automatically generated and managed by the software.

^typo above. That should read "the change address will be automatically generated and..."


text:
How to create valid P2SH-address with Bitwasp-Library that can be used with Electrum?
There is something I didn't understand regarding different Address formats. In short: I create a Master key, import it via xprv-Key into Electrum, generate P2SH and P2WSH-Adresses, send Coins to it but they don't appear.

I have created an extended key on the testnet with Bitwasp: tprv8ZgxMBicQKsPd1Euv7Q428UserpbDf6mxhRtjevgfPcL4XwU8aNAXqMp6QAQjPU5bCeskWBUtqZYS1UHRYQuYzrcZFppbsS2JgWjUzgK654.
I have imported this Key into Electrum running also on testnet.
Clicking on "Receive" tells me the following address: n28hWyXh8VPBCV6seKty19dW5ZNbqapB58
I've sent some testnet coins to this address, which became visible in Electrum very fast.
Using the BitWasp-Library I wrote the following Code (inspired by there own example-code:

        $network = Bitcoin::setNetwork(NetworkFactory::bitcoinTestnet());

        $random = new Random();
        $hdFactory = new HierarchicalKeyFactory();

        $master = $hdFactory->fromExtended("tprv8ZgxMBicQKsPd1Euv7Q428UserpbDf6mxhRtjevgfPcL4XwU8aNAXqMp6QAQjPU5bCeskWBUtqZYS1UHRYQuYzrcZFppbsS2JgWjUzgK654");

        $addrReader = new AddressCreator();
        $publicKey = $master->getPublicKey();
        $helper = new P2pkhScriptDataFactory();
        $scriptData = $helper->convertKey($publicKey);
        $script = $scriptData->getScriptPubKey();

        echo "key hash types\n";
        $p2pkh = $scriptData->getAddress($addrReader);
        echo " * p2pkh address: {$p2pkh->getAddress()}\n";

        echo "\nscript hash types:\n";

        $redeemScript = new P2shScript($p2pkh->getScriptPubKey());
        $p2shAddr = $redeemScript->getAddress();
        echo " * p2sh: {$p2shAddr->getAddress()}\n";
        $p2wshScript = new WitnessScript($p2pkh->getScriptPubKey());
        $p2wshAddr = $p2wshScript->getAddress();
        echo " * p2wsh: {$p2wshAddr->getAddress()}\n";
        $p2shP2wshScript = new P2shScript(new WitnessScript($p2pkh->getScriptPubKey()));
        $p2shP2wshAddr = $p2shP2wshScript->getAddress();
        echo " * p2sh|p2wsh: {$p2shP2wshAddr->getAddress()}\n";

It gives me the following output:
WIF: cUhtBXtsVhSikXiD46B5dKsCTjKqZGTWEADxSMNknP1V6VZfm1zR
key hash types
 * p2pkh address: mjCptm7yxr3c7DpA6i17ude5ZkiHQMz7Rr

script hash types:
 * p2sh: 2MsjH4FEdpcwmwaTtbW3HFnx8aw1DCfN74G
 * p2wsh: tb1qnwsk39m5yw4m3h36ddvw9euvl0vxl7vg8mrmyj777pwl74crkassxgg7l2
 * p2sh|p2wsh: 2NFS1fXMuAJuJWaGAwMi7puE86n5XnbLEPo

Questions:

Why is the Receive-Address in Electrum so different from those that I've got generated with the Bitwasp-Library. None of the generated addresses is similar to the address out of Electrum
Sending Coins to the Address from Electrum will show up the received coins
Sending Coins to P2shScript-Address for instance (2MsjH4FEdpcwmwaTtbW3HFnx8aw1DCfN74G) will never appear in the Electrum-Wallet, even they are based out of the same private key
I've tried also sending coins to the p2wsh-Address (tb1qnwsk39m5yw4m3h36ddvw9euvl0vxl7vg8mrmyj777pwl74crkassxgg7l2), which also never gets any coins that was sent to.

Where is my mistake?
Update:
after the answer from @Abdussamad I tried the following: derivePath and send coins to that address then. I also imported the xprv of the derived Key into Electrum and send out some satoshis to its address. Nothing came in.
Additional code:
$purposePriv = $master->derivePath("{$purpose}'/0'/0'/0/0");
  echo "m/{$purpose}'/0'/0/0/0': ".$purposePriv->toExtendedPrivateKey().PHP_EOL;
  echo "M/{$purpose}'/0'/0/0/0': ".$purposePriv->toExtendedPublicKey().PHP_EOL;

  $purposePriv = $master->derivePath("{$purpose}'/0'/0'");

  $masterAddr = new PayToPubKeyHashAddress($purposePriv->getPublicKey()->getPubKeyHash());
  echo "   Address: " . $masterAddr->getAddress() . "\n\n";

Sending coins to the address will send them to elsewhere, not to the specific wallet.
Update 2:
I tried the following code, suggested here:
$mnemonic = "blahblahblah";
$seed = (new Bip39SeedGenerator())->getSeed($mnemonic);
$purpose = 44;
$factory = new HierarchicalKeyFactory();
$root = $factory->fromEntropy($seed);
$accountPriv = $root->derivePath("{$purpose}'/0'/0'"); // m/44'/0'/0' (change and regular addresses come from here)
echo "master public key: ".$accountPriv->toExtendedPublicKey().PHP_EOL;
$addressPriv = $accountPriv->derivePath("0/0"); // // m/44'/0'/0'/0/0 <- 0'th non-change address
$masterAddr = new PayToPubKeyHashAddress($accountPriv->getPublicKey()->getPubKeyHash());
echo "   Address: " . $masterAddr->getAddress() . "\n\n";

I've got:
master public key: xpub6CXUv9gQCfQNNksArMAnKyu14vji7cK3V5wG7gYSoVntmtXTwzmhz4tFPzAiwagcdTYXXXjKCuFAQcUXM67k7cZL2sPbBEuZjp3GrwURdCo
   Address: 15e5vNCSE9iBUbRW6kdHx84XFEcQgY4zfC

But after importing the xpub-key into Electrum, it shows the receive-address: 144aHwG4JKtpCjpJLKcB7aZq8nEidrBaKN

You haven't provided a derivation path in that code. For p2pkh addresses electrum uses m/j/i where m is the xprv/xpub you use, j is 0 for receive and 1 for change addresses and i is the index of the address. So first receive address would be m/0/0.

Thx, but this doesn't work either. I derived a key and send coins to this derived key, while importing its xprv into electrum as well. The sent Satoshis are gone, never appeared. Is there any way to generate a valid address were coins can be sent to? (Pls consider my Update at the bottom of my question)

@delete the $masterAddr assignment line is incorrect. You are deriving the address for m/44'/0'/0'. You should be using $addressPriv instead of $accountPriv there. BTW there is a good tool to test these things here

source: Stack Exchange

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

sort: votes


text:
How to get the compressed WIF of my key?
I'm a trying to understand the different encoding on the private keys. What format is used by the iancoleman validator and why? How can I reproduce it?
All my Data is valid.
According to the bitcoin wiki The procedure to create a bitcoin address is as follow

It seams to me that I have achieve all that with the following code;
First I generate a mnemonic and seed with BIP39.
    exports.seed = async () => {
      return new Promise(resolve => {
        const mnemonic =  bip39.generateMnemonic();
        const seed =  bip39.mnemonicToSeed(mnemonic);
       resolve(seed)
      });
    }

The mnemonic produced

drive captain sustain winner neutral anchor congress skirt buzz usage
orient wood

The seed

c981bc6db5b0680aa96140f2c9f5f0b910ff69157b01b4de24f9e7590950f44c300386362a0e4ecf109b4c770e74efe81c0b1f673e3de8d1d82a687b1c0d206d

Now I use that seed to generate a key pair with hdkey
exports.key = async (seed) =>{
  return new Promise(resolve => {

    const hdkey = HDkey.fromMasterSeed(Buffer.from(seed))
    const masterPrivateKey = hdkey.privateExtendedKey
    const addrnode = hdkey.derive("m/32'/0'/0'/0")                    // derived path
    const nodePubKey = addrnode.publicExtendedKey

    const sha256 = createHash('sha256').update(nodePubKey).digest()
    const pipedMd = createHash('rmd160').update(sha256).digest()      // 20 bytes hash

    var fingerprint = Buffer.allocUnsafe(21)                          // fingerprint 20+1 bytes

    fingerprint.writeUInt8(0x00, 0)                                   // 0x00 network byte
    pipedMd.copy(fingerprint,1)

    var sha1 = createHash('sha256').update(fingerprint).digest()
    var sha2 = createHash('sha256').update(sha1).digest()
    var checksum = sha2.slice(0,4)                                  // checksum 4 bytes

    var rawAddr = Buffer.allocUnsafe(25)                            // raw address 25 bytes

    fingerprint.copy(rawAddr,0)                                     // fingerprint 21 bytes + checksum 4
    checksum.copy(rawAddr,21)

    var address = bs58check.encode(rawAddr)                         // base58 encode the raw address

    resolve(address)
  })
}

So what I can validate so far is that according to this BIP39 validator

The seed generated by the mnemonic is good
The masterPrivatekey is the BIP 32 root key (as per validator)
Both xpub and xprv key are valid with this derivedpath "m/32'/0'/0'/0"

The address resolve in
1XNR1ABuzSKp4tb3WpF9Yrj88ZBSxMYQ3BnHjtn
This is not a valid address it has 39 characters. The validator, Under the BIP32 tab returns
1B4CKfR96isLCXET5D8jykA2Yz3DBhxAZX
I'm not sure how this address is generated. I think i might be missing a layer in the keys?
Should I use the BIP32 extended xpub key and derive some more keys out of it. My reasoning behind this is
that I derived a keys pair from  m/32'/0'/0'/0
The validator return a different address with this path m/32'/0'/0'/0/0
So the problem has to be from the concatenation of the networkid + fingerprint + checksum or the base58 encoding. I'm also not sure if the network byte should be added to the fingerprint before the 2 SHA256 hash checksum or after.
This are the 2 other modules I use;
bs58check
create-hash
UPDATE
Changed the bs58check for base58-encode
I am getting the right address length
By pointing that first address to m/44'/0'/0'/0/0  i have finally obtained
A valid address and a public key

Address 1HaGGkWmUDTKExFxyXaiGHHPxYNaCefQrj

Public Key 02a84461e76ba44d674d5915b9b48b1bbc0b9b09ccd8e83a43f6d2a42cae78e806

But the private key is wrong, if I read this account private key like this
const nodeAcc = hdkey.derive("m/44'/0'/0'/0/0")
const nodeAccPubKey = nodeAcc._publicKey.toString('hex'))
const nodeAccPrvKey = nodeAcc._privateKey.toString('hex'))

The private key I get from my code

6301454cea9ddf9318e7ac82fdfb6edefbf2984384a05c37bdf79258d2331464

IT seams to me I'm not getting the right format. The private key the BIP39 validator is giving me for my address is this

KzYASafouu8yEFUByEt3g9XMAGtbAfqQqgmQxDct4h4kgQzKiXDY

If I encode that private key in the base58 format I get

7fUVBZBe47GfV2oMe9RWWaQvBpfh3r2EQuSnv1vCyuqd

I also found this article that uses WIF format
They basically say that to generate a WIF private key I have to repeat the Network byte and checksum process. I don't understand why in the case of the address generation we use the network byte 0x00 and for the WIF Private key we use 0x80 Both are for main network?
I could validate my WIF with this tool
My private key WIF

5JZtXicXZq4crDo32sGeJw3LyUchpWBy9mMV5op6gMQWP636o2m

So I am wondering which encoding is use by iancoleman's app
I validate my private Key in the Hex format
I Validated my WIF
I have Validate the import process from another wallet (Electrum)
I know that in the end the key will be used in the byte format but I would still like to understand why I'm not able to match it to the validator

I don't see why you think the private key is "wrong", it is actually the key for 1HaGGkWmUDTKExFxyXaiGHHPxYNaCefQrj.

Which one is good? The last one is from the validator an KzYA.....
The one I get is 63014...

That’s the private key in hex format.

ok So what format is the KzY one so I can reproduce it.

that’s just base58.

If I encode it to base 58 i still get a different value
7fUVBZBe47GfV2oMe9RWWaQvBpfh3r2EQuSnv1vCyuqd
How could you tell that this key was good?

Let us continue this discussion in chat.

So if it's just base58 why cant'i reproduce it by encoding my key to base58 instead of Hex ?? My WIF is valid and it is not that.

I think you should start with understanding addresses and WIFs before trying to roll your own from an xpub or xprv.  Your hex private key 6301454cea9ddf9318e7ac82fdfb6edefbf2984384a05c37bdf79258d2331464 has a compressed WIF: KzYASafouu8yEFUByEt3g9XMAGtbAfqQqgmQxDct4h4kgQzKiXDY, Addr: 1HaGGkWmUDTKExFxyXaiGHHPxYNaCefQrj , and the uncompressed WIF: 5JZtXicXZq4crDo32sGeJw3LyUchpWBy9mMV5op6gMQWP636o2m, Addr: 16HUmgrkTeMCK4aaCrmjracBhw2MVWm2Z9

So how do I generate the compressed version of it? And what is it used for. It doesn't look any smaller than the uncompressed version. I am further in the code now and I validated my wallets against Electreum and Metamask. I could import both and got all the right adresses along so my understanding is a bit further now. This is also what I'm asking. How to get the compressed version.

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


text:
How to avoid "Unconfirmed UTXOs are available, but spending them creates a chain of transactions that will be rejected by the mempool"?
I'm encountering an issue with Bitcoind where I frequently get the error:
"Unconfirmed UTXOs are available, but spending them creates a chain of transactions that will be rejected by the mempool."
This problem seems to be exacerbated by the high volume of transactions generated by bitcoinfaucet.uo1.net, leading to long chains of unconfirmed transactions. What can I do to prevent this error and ensure my transactions are accepted by the mempool?

Does this answer your question? 64: too-long-mempool-chain

It sounds like your wallet’s UTXO pool is too small for the number of transactions you are making. Here are some possible ways to mitigate your issue:

Dial-back consolidatory behavior
If you are operating a send-only wallet, the default Bitcoin Core behavior might be too consolidatory for your use-case. Bitcoin Core uses multiple different coin selection algorithm to produce input set candidates when building transactions. You may want to set consolidatefeerate=0.00000000 in your config to always prefer less consolidatory input sets.
Create more UTXOs
If you have a lot of funds, but few UTXOs, you could combine the above with deliberately splitting up some of your largest UTXOs into many smaller useful pieces. Especially if you know that you will need a specific amount for later transactions, you could fan out a large piece into dozens or hundreds of outputs of that size in a single transaction.
Use a higher feerate
Your transactions exceeding the default ancestor count limit indicates that you are either combining funds from too many unconfirmed transactions, or making long chains of unconfirmed transactions. If you generally use a higher feerate for your transactions to ensure a prompt confirmation, this will free up confirmed UTXOs for later use.
Batch payments
Instead of adding new transactions for every payment, you could gather payment requests for some timespan and then create a single payment-batching transaction with multiple outputs. A send-only wallet using payment-batching will generally require way fewer UTXOs to reliably operate.
Add more payments to previous unconfirmed transactions using RBF
As a fairly advanced strategy, you could have only a single unconfirmed transaction in flight, and every time you get another payment request, you replace your unconfirmed transaction with a new version that adds the payment. This approach is limited in practice because each replacement needs to increase the feerate, and you need to add a new input with each batch of payments you fold into the transaction to ensure that you pay the recipients only once.

Overall, it seems to me that you may be trying to create an unsustainable count of transactions and should look into achieving the same outcome with fewer transactions.

Creating more UTXOs and setting consolidatefeerate=0 fixed the problem. I was batching payments already when I posted the question.

Nothing, as you are not deciding the ancestor count for other nodes. See https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-limits.md
Similar question: https://bitcoin.stackexchange.com/a/77056/61384

I'm thinking about increasing the number of available unspent outputs by creating a transaction that splits existing outputs into a larger number of outputs. Should I try that?


text:
Decode public key from address
The process of encoding a public key is very clear and explained here https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
I am looking for the other way around: how to get the public key from an address?
When you send bitcoins to someone you usually use the "readable form" (encoded) of the address (e.g. 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa). However the blockchain stores the unencoded form (e.g. 04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f)
How is it possible to recover the unencoded form of the address?
Example: If you want to send bitcoins to 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa the node has to find out that you refer to the public key 04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f

Hashing is a one way mathematical function. There is no way you can reverse engineer it. Hashing is also quantum resistant. So it's impossible to get public key from a public address.

You are right I will edit and reformulate my question: When you send bitcoin to someone you use the "readable form" of the public key. However the blockchain stores it in the other form. How does it link the readable form of the address to the public key then?

No, the node does not have to find the public key. When you send some bitcoins to an address, the bitcoins are encumbered by you providing a valid public key and a signature from your private key to spend it. The unspent outputs are only stored in the hash form.


text:
why when making a command on bitcoin console does this appear staggered square brackets appear
Why when making a command of listunspent ,generate ,listlockunspent etc , Does this appear?  [
].

The output is in JSON format; [] is a list containing no items.

Thankyou,is this because i am not synced yet?

It just means your wallet contains no UTXOs, whatever the reason. Given comments you've made on other questions, my assumption is simply that you don't have any coins.


text:
Elliptic Curve Point Addition Question
I am doing a school project about Bitcoin and more specifically point addition on the Elliptic Curve. I am very new to all this so please forgive my mistakes.
I have been reading that when adding points together the result can go "outside of the bounds before intersecting a third point" as in this image.

This is fascinating but also a little confusing and I would like to know more.
So my questions are:
1.
Is it possible to know when the point addition process has gone outside of the field?
And 2.
Is there a way (like a Python script or something) that I could use to add 2 points and it would tell me if the result went outside of the field?
I know that the result of the addition is still a valid point on the curve, but I would love to know if it passed out of bounds first.
This would be fantastic for my project to show others how this works.
I hope that made sense and thanks in advance for your help.


text:
Just to be sure, the downloads at bitcoincore.org are the safer ones?
(more than bitcoin.org?)
And a few more questions regarding this:

Why did they change the naming of the versions from 0.xx to xx.0? (latest update changed from 0.21 to 22.0).

Why they did not add the docs for the RPC API of version 22.0?

Will they update the API to use JSON-RPC version 2.0?

**This is the same question divided to sub-questions that are related so please don't delete.

For the version change see https://github.com/bitcoin/bitcoin/pull/20223.

the downloads at bitcoincore.org are the safer ones?

https://bitcoincore.org is the website where developers of bitcoin-core place ready to use executables you can download.
I wouldn't characterise https://bitcoin.org as unsafe but nowadays I would prefer to download executables from https://bitcoincore.org
Some might argue that it is safer still to download and carefully inspect source code from https://github.com/bitcoin/bitcoin and then compile it yourself.
Whatever you do you should take care to test the checksums and/or digital signatures, making sure you don't get the expected values or keys from the same download source.


text:
Start mining without the need to downlod the 360gb blockchain
I am new to bitcoin mining but at least i understand the mathematics behind - the sha256 and finding nonce, i am a junior back-end developer. recently i have being interested in bitcoin mining, as way to earn revenue but spotted constraints that would hinder people from exploring the venture, all cost related. Which bring me to my question of how a solo-miner with the necessary requirements but with a less than 1.7mbps internet speed could evade the initial download of all the 360gb blockchain. it does seem like an eternity to wait for such a colossal download. and the reasons for such download is still unclear. it makes sense to only download the previous hashes, for the block you are trying to mine, but not the whole data.

Does this answer your question? Why does bitcoin core need to download the blockchain

@RedGrittyBrick No it actually doesn't i mean there are already verified blocks and are already in the chain and so i see no need to verify again, besides if one person verifies a block incorrectly it won't change the system, or will it?it is not practical to process every transaction that bitcoin has ever made to begin mining. There must/should be a way to skip all other blocks and maybe process the current block and the last few.

If you don't care about being deceived and having your money stolen then indeed you can dispense with security measures and simply trust random strangers. Its certainly a choice you can make.


text:
Extinct block in index
I am working on a blockchain parser. I first parse the header index to know where the data is located in the .blk files. And then I parse the blk files in the right order. (I use the data from my full node)
However I noticed that I am including an extinct block (see Single tx included in two different blocks) while parsing (and blockchain.info seems to do the same).
How is that possible? How to get the actual block?
While parsing the index I check the condition NStatus&(blockHaveData|blockHaveUndo) != 0 before including the block, is that enough?
A validated block has NStatus = 0x9d whereas the extinct block has NStatus = 0x8b.
There does not seem to be another valid version of the extinct block in my index (height 525890)
Edit: The error comes from my validation condition NStatus&(blockHaveData|blockHaveUndo) != 0. As a temporary fix when a given height is referenced twice in the index I keep the on with the largest NStatus.


text:
CDiskBlockIndex: NFile and NDataPos not defined
This is the source code snippet that is used for the serialization of block indexes (found in leveldb).
Block 478573 index is (as of my node's leveldb) 89af109c996d020000000020774f568005a00bf4ffed76b52e3a7e5e5140a5371834a00000000000000000009f5db27969fecc0ef71503279069b2df981ba545592a7b425f353b5060e77f3e7e13825935470118da70378e
Isn't NFile undefined (i.e. 0) in this case? (and NDataPos and NUndoPos too).
Whereas for block 478574 it is :
89af109c996e1d801886399fbf8017828daf5502000020dcc139c241e6315463dd82c89fc288de35f004c87816430000000000000000000f7f9503fc2daab46c4103516c386b1c5b2390e082af76ba8c49fb522d5e5b148b96805935470118ae6ba061
Which yields NFile = 953 and is correct.
Why block 478573 is not defined? And how to retrieve NFile and NDataPos in that case? I understand that the index is different for every node because it depends on the order the blocks were downloaded.

What do you mean by undefined? Zero?

Yes I meant zero

This is likely the case because you don't have the block.
Blocks are downloaded out of order, and the block index contains entries for blocks that are not in the main chain ("orphan blocks"). Many of those are clearly not in the best chain before they're even downloaded, in which case Bitcoin Core will not download them at all.

Very clear, thanks! I thought the block index contained only the main chain.


text:
Multisig Wallet Setup - Security Tradeoffs With Pruned Bitcoin Core Node?
What are the security tradeoffs of running a pruned Bitcoin Core node for a multisig wallet, such as Specter?
It seems that using a multisig wallet with a pruned Bitcoin Core node could be a good incremental improvement of securing assets vs. storing funds on an exchange or on a single seed hardware wallet.

How is the pruned node run for Specter? Is it running off of Bitcoin Core directly?
I've heard that similar services, Unchained Capital, run a node supported by Blockstream if I understand correctly.

Is the privacy risk mitigated by connecting Bitcoin Core's pruned node through Tor/VPN (That do not save/collect logs)?
Chain analysis companies are able to gather information from non-self-hosted nodes and tie it to personal information.

Are there additional tradeoffs to consider?

1. How is the pruned node run for Specter? Is it running off of Bitcoin Core directly?

In the Specter setup a pruned node is directly downloaded from Bitcoin Core with the 1-click install in ≥ v1.3.0, as shown in Coinkite's How To Use Specter Wallet video.
A user on bitcointalk.org provided clarity on using a pruned node in this post.

Security of running a full node versus a light client is obviously higher. Being pruned doesn't change the fact that the node is still a full node, it just doesn't store the historical blocks that are too old.

It seems I was confusing Specter's usage of Blockstream for their Bitcoin explorer with running the Bitcoin Core node which is unrelated.

2. Is the privacy risk mitigated by connecting Bitcoin Core's pruned node through Tor/VPN (That do not save/collect logs)?

The bitcointalk.org post also mentions there are potential privacy implications from exposing the Bitcoin Core node on a non-private IP address.

Chain analyzers are analyzing the "chain" not the network although that is a possibility but it is a much harder thing to do. However, you do gain additional privacy when running your clients through TOR since it prevents other kinds of attack such as packet sniffing.


text:
Multisig Setup - Pruned Bitcoin Core on Computer vs. Dedicated Hardware
Are there security implications of running a pruned Bitcoin Core node on a personal computer vs. a full Bitcoin Core node on a dedicated hardware device (i.e. Raspberry Pie with Umbrel, myNode, nodl, and etc.)?

The intended use case for the Bitcoin Core node is integration with a multisig wallet such as Specter, Electrum, and etc.

This scenario presumes the personal computer is configured to run Bitcoin Core through Tor/VPN (That do not save/collect logs) as in the Specter desktop 1-click setup.

One non-security implication is the performance impact on the personal computer when running the pruned Bitcoin Core node.

Both a full Bitcoin and pruned node can be run from Bitcoin Core with the same level of security.
Pruned nodes have the following differences:

Does not keep the full blockchain on disk
Size limit is defined by the user
Will discard unnecessary block data as it synchronizes

As a user on the Bitcoin Talk forum explains, most "dedicated hardware" Bitcoin Nodes are software wrappers around Bitcoin Core which may be less secure than running Bitcoin Core directly.
See Multisig Setup - Pruned Bitcoin Core on Computer vs. Dedicated Hardware - bitcointalk.org


text:
Single pool vs multipool mining?
I noted that many clients now-a-days have the option for multipool. Regarding such feature I've got two questions:
What are the advantages of being in a multipool setup against the single pool?
Is such setup option fair for those people who are in only one pool?

Multipool clients generally have two sets of functionality fail-over or load balancing.  Fail-over is simply having backup servers in place so that your miner can continue working if your primary server goes down or experiences a connectivity issue.  Load balancing will split up the work across multiple pools simultaneously.  This would make the most sense to me in an environment where multiple people purchase a rather expensive mining rig and want to distribute shares of the rigs capability to accounts that are controlled by different owners.  I can't see a scenario where this functionality could be unfair to someone mining in a single pool.

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


text:
Quick question about wallets
On my current OS I have daemons of bitcoin and other altcoins running in bitcoin there were 5 different addresses lets say

userA
userB
userC
userD
userE

userB has sent some coins to a address generated by him, and this transaction was covered in e.g block number 300 but my bitcoind was synced till block number 250 only. Now if I save wallet.dat and place it in the same folder after reinstalling the OS will this retainn the addresses generated by different users ? and after synchronizing to block 300 will those coins comes into the wallet ?

Your balance is kept in the cloud, specifically in the block chain.
Your wallet does not contain any balance info but just a private key that you can use to unlock the funds inside the block chain.
This means that it doesn't matter that you backup your wallet.dat file before your client is fully synched. Since it only contains your private keys, and not the balance itself.
So yes, after a full synch is completed, those coins will appear in your wallet. As long as you have your wallet.dat file, with the private keys associated to your address, you can access your funds.

So you suggest I should not perform the reinstall until I get the coins in the wallet and then backup the wallet and place it in the appropriate directory after reinstall?

As long as you have the private keys associated with the addresses where your money is, all you need is the private keys, which are inside your wallet.dat file. So you can back that up, and even if your computer exploded, you still have access to your funds. As long as you have your wallet.dat file.

authors: แบงค์เฉิน เพิ่ลเค้าเรียกกัน

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


text:
Weird Bitcoin RPC listreceivedbyaddress behaviour
Everything was done on regtest network.
So I've generated a new address using getrawchangeaddress on wallet 2 and made a 0.1 BTC transaction from wallet 1 to wallet 2 and tried check this address balance on wallet 2 using getreceivedbyaddress.
Well, it says that address received 0.1 BTC, but when I try to execute listreceivedbyaddress, it returns an empty list.
NOTE: This transaction have above 6 confirmations.
 > bitcoin-cli --rpcport=19011 --rpcuser=admin --rpcpassword=123 listreceivedbyaddress 1 true true bcrt1qn858fc33j9f6w83vu6vglk2d3e5th3zhrxj9lg
[
]

 > bitcoin-cli --rpcport=19011 --rpcuser=admin --rpcpassword=123 getreceivedbyaddress bcrt1qn858fc33j9f6w83vu6vglk2d3e5th3zhrxj9lg
0.10000000

Weird thing also is that I've marked include_empty to true, but the answer is an empty list.
EDIT: listtransactions shows the transactions, but there is a lot of other transactions.

listreceivedbyaddress (and the other transaction listing RPCs) list logical transactions, not physical transactions. So it really lists transaction outputs. Additionally, they share a lot of code. Because these are logical transactions, there are some things that are hidden so that the output is not confusing to the user. One of those things are change outputs, as those are not the same kind of transaction as a send or receive.
Since you used getrawchangeaddress, the address you have is marked as a change address. So the code that fetches the logical transactions for listing will filter the transaction outputs for the address you specify, but later code (that is intended for other RPCs), will filter out those outputs that belong are marked as change. Thus you see no results.
getreceivedbyaddress is a balance fetching RPC, and so it uses different code paths from listreceivedbyaddress. It does not filter out change addresses in the same way as balance calculation (for other RPCs) actually needs to include change outputs. So you see the balance of the change address in getreceivedbyaddress

This is intended behavior, but it is clearly confusing. However most users are not aware of change addresses and are unable to even see what their change addresses are, so fixing this is fairly low priority.

Thanks for your answer, pretty clear now. But is it even possible to list transactions of change address?


text:
What's your recommendation regarding a Bitcoin wallet?
I'm a novice so go easy on me!!! thanx
I'm writing a freeware open-source program with a donation scheme.
in the end, it will look like this Github page
first is PayPal and then multiple cryptocurrencies receive addresses. first on the list that we'll talk about is Bitcoin.
right now I'm downloading Bitcoin core and I hear there are lots of others that install instantly. what's their difference?
on BiglyBt's Readme.md page I see it uses one receive address for all four BCH, BTC, BSG, and BSV coins. can I do that using Bitcoin-core?
basically I want a good Bitcoin Platform and Wallet with high security...

Hi, welcome to the Bitcoin SE. The other wallets listed on that link are not Bitcoin addresses, thus how to create them is not relevant to this forum. You should refer to the SE forums for those coins for help creating addresses for those coins.

I was told I can ask any question I have about any cryptocurrency I can post it here. don't you guys read your own SE documentations?

https://bitcoin.stackexchange.com/help/on-topic "[your question] is not about … any cryptocurrency or technology that is not applicable to the Bitcoin network and users of the Bitcoin currency" This is not a general cryptocurrency forum -- although I understand why it might look that way!

I edited the post so that It only concerns bitcoin

I went through a similar problem for generating new bitcoin wallets.
I used the following python libraries:

pycoin
bitcoinlib


text:
Tool to generate graphical DAG from a seed
I'd like to have a tool that generates a graphical DAG display from addresses generated from a seed.
In particular to distinguish which transactions are for "receive" addresses, and which are for "change" addresses.
The motivation is to make it easy to distinguish the origin of coins before spending.
A command line tool to generate eg. dot files would do. Any suggestions?


text:
What is the difference between your address and your public keys
I'm beginning to learn about cryptocurrencies, and I'm having a lot of trouble because some terms are used in different contexts. I know that public keys are generated through a private key. So, are those public keys the addresses? And is it possible to generate more than one address per each private key in wallet? Why?

Possible duplicate of https://bitcoin.stackexchange.com/q/13059/5406

cited:

A Bitcoin address is a 160-bit hash of the public portion of a public/private ECDSA keypair.

a picture may make it easier to understand how an address is generated from a public key;

Image provided under Creative Commons CC0 1.0 Universal Public Domain Dedication

Public key are not the addresses, A  address is like an email address that funds can be sent to.
The public key is used by the wallet to make different  addresses.
we can also say that The public address is a hashed version of the public key. Because the public key is made up of an extremely long string of numbers, it is compressed and shortened to form the public address

That explains it clearly and concisely. The main point is that your public key is tightly coupled to an address, as it must be.


text:
In simple terms, what are the major differences between P2WPKH and P2WSH bech32 addresses?
I've read over the bip173, bip141, and bip143 specifications and they're a bit too technical to get at the simple answers I'm looking for.

Are you asking about the differences between P2WPKH/P2WSH in general, or about the differences between their corresponding address formats?

In short, both.  As you can see, I've added some of the research I've done over the past month or so.  I'm programming a bech32 encoder/decoder in perl, but also trying to understand bech32, segwit, P2WPKH, and P2WSH beyond simply porting the code from the node/c++ code in bip173.

Also, there were few simple and concise answers that I could find with a google search that correspond to bech32 validation and how bech32 relates to SegWit, so I wanted to share the conclusions I came to.

P2WPKH - This stands for "Pay To Witness Public Key Hash" and the scriptPubkey is OP_0 0x14 {20-byte-hash}, where OP_0 is the version, byte 0x14 is the size of the data, and the {20-byte-hash} is a HASH160(PubKey).
P2WSH - This stands for "Pay To Witness Script Hash"  and the scriptPubkey is OP_0 0x20 {32-byte-hash}, where OP_0 is the version, byte 0x20 is the size of the data, and the {32-byte-hash} is a SHA256(script).

This data is taken from: http://bcoin.io/guides/segwit.html

Examples:
For the P2WPKH address: "bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4"
OP_0 , 0x14 , HASH160(PubKey) -- looks like (in hex):
00 14 751e76e8199196d454941c45d1b3a323f1433bd6
For the P2WSH address: "bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3"
OP_0 , 0x20 , SHA256(script) -- looks like (in hex):
00 20 1863143c14c5166804bd19203356da136c985678cd4d27a1b8c6329604903262
Examples taken from http://bitcoin.sipa.be/bech32/demo/demo.html and https://github.com/sipa/bech32/blob/master/ref/c%2B%2B/tests.cpp

Not MD5 (lol), it's SHA256.

Ah, thanks!  I thought md5 sounded wrong myself!


text:
Relation between bitadress and blockchain
When i create a wallet at bitaddress.org i could see my balance at  https://www.blockchain.com/explorer . If bitadress.org is a client sided page and shouldn't send any information to outside world and I haven’t shared the wallet address with anybody, how does the blockchain.com/explorer page know if an address is included in a wallet?

how does the blockchain.com/explorer page know if an address is included in a wallet?

Short answer: it doesn't.
Blockchain.com just looks to see if it has a record of a transaction involving the address you give it.
A transaction is something such as a bitcoin-exchange sending you Bitcoin (after you sent them dollars) or you sending Bitcoin to someone else (e.g. when buying something with Bitcoin)
Details of Bitcoin transactions are public information and are copied to every Bitcoin user (or are available to every Bitcoin user).
But you don't need to use bitaddress.org or any similar service and I wouldn't!

A little more detail.
The web-page at Bitaddress.org uses a pseudo-random number generator based on mouse movements and keyboard input to generate a random private-key.
From a private-key you can derive a public-key. The Bitcoin-address is a hash of the public-key.
The private-key enables you to spend Bitcoin and should never be shared with anyone else.
The public-key enables other people to send you Bitcoin, you give them the address derived from the public key.
There need be no link between bitaddress.org and any blockchain explorer. The latter just searches the blockchain for transactions involving the address you type in.
The blockchain is a ledger (or more accurately a journal) containing a record of all bitcoin transactions from the creation of Bitcoin 10 years ago. All "full-node" wallets have their own copy of the whole blockchain.

Don't trust websites
Despite the above, I would not use a public service like bitaddress.org to create my private-key. After all, we don't know if the owner of that website dishonestly keeps the private-keys (or has been hacked). Bitcoin was originally designed to be used without trusting third-party services like this. You can download a desktop-wallet and generate your private-key in the privacy of your own home on a computer that is disconnected from the Internet. That is the one of the safest ways to inexpensively create a Bitcoin wallet.

Never let anyone else generate, use, borrow or see your private-key
Never share the password to your wallet, even if you change it afterwards it is useless to do so because they can already have copied your private-key - which they can later use outside your wallet to spend any  Bitcoin you later added to that wallet.
If you do not understand Bitcoin adequately you may lose all your money.
If you trust websites, you may lose all your money.
If you are not careful about these things you will lose all your money.

Thanks but i still got question marks in my mind.How exactly blockchain.com reaches my public key?I only generate my private key i didn't share any public key to outside world.

@Winslet - That probably should be a separate question, but briefly: blockchain.com doesn't reach your public key. When someone sends you bitcoin they broadcast the transaction details to Bitcoin nodes - your Bitcoin-address is included in those details. Bitcoin miners then include those transaction details into a mined block and broadcast that new block to the Bitcoin world, your wallet receives that new block and updates your wallet balance. See https://bitcoin.stackexchange.com/q/148/13866 and https://arstechnica.com/tech-policy/2017/12/how-bitcoin-works/

right now i have nothing in my balance.I haven't send my public key to anywhere and when i search my wallet at explorer site can see it through . How explorer access to my public key ? Even if were created my wallet without this site eventually the explorer will reach again. I can't make it up together in my mind right now sorry for being slow learner but could you explain this please

I'm not sure why you think blockchain.info knows anything at all. You gave it your address, it looks for any transactions involving that address, and as there aren't any, it shows 0. To receive coins from someone, you give them your address and they create a transaction sending to it which is broadcast to the network. If you then again ask blockchain.info (or any explorer) for that address, it will know that transaction, and thus show you a non-zero balance.


text:
Bitcoin v23 is 10 times slower than v22 on macos for basic regtest tests
This is how I start the node (I always start it from a clean state):
rm -rf /tmp/regtest1/bitcoind
mkdir -p /tmp/regtest1/bitcoind

#/Applications/Bitcoin\ Core\ 22.app/Contents/MacOS/Bitcoin-Qt \
/Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt \
  -datadir=/tmp/regtest1/bitcoind \
  -regtest \
  -server \
  -txindex \
  -fallbackfee=0.0002 \
  -zmqpubhashtx=tcp://127.0.0.1:30001 \
  -zmqpubhashblock=tcp://127.0.0.1:30001

Then I create a wallet and mine some blocks:
bitcoin-cli -regtest -datadir=/tmp/regtest1/bitcoind createwallet farvault_tests
GEN_ADDRESS=$(bitcoin-cli -regtest -datadir=/tmp/regtest1/bitcoind getnewaddress)
bitcoin-cli -regtest -datadir=/tmp/regtest1/bitcoind generatetoaddress 101 $GEN_ADDRESS

For some reason the App downloaded here (v22) is x10 faster than the one downloaded here (v23).
The new address and the 101 blocks are created in under 2 secs on v22 while it takes 17 secs on v23.
I also compiled bitcoind 23 with these options:
git clone https://github.com/bitcoin/bitcoin.git
cd bitcoin
./autogen.sh
./configure --enable-hardening --with-gui=no
make

which provides also the same bad performance as the v23 downloaded App.
Do you have any idea why v22 would be so much faster? Any clues as to how I should address the issue?
My computer is a 2.8 GHz quad-core Intel Core i7 running Macos Big Sur.
EDIT: I upgraded to Monterey and nothing changed: v22 is 10x faster than v23.
I have not checked performance on testnet and mainnet. I'm mostly interested in running integration tests for a project and it looks like I cannot upgrade to the new version yet without solving this.

This is behavior I can reproduce on v22 and v23

Good sources say this is likely fixed by: https://github.com/bitcoin/bitcoin/pull/25985

My results from running the PR, dramatic improvement on m1 mac: https://github.com/bitcoin/bitcoin/pull/25985#issuecomment-1245942400

I’m voting to close because this isn't the right place for Bitcoin Core bug reports.

Thanks @ChrisStewart. I will do the tests and update the question with my findings. Ideally, the Pull Request should be accepted and then we could close this issue explaining there's a compilation flag that fixes this problem.


text:
When is a Miniscript solution malleable?
I'm having some trouble understanding malleability in miniscript. Specifically I cannot get why some solutions can be used instead of other.
I think using an example may help.
Say, for instance, this miniscript:
and_v(v:pk(key),or_b(l:after(100),al:after(200))), which produces:
<key> OP_CHECKSIGVERIFY OP_IF
  0
OP_ELSE
  <64> OP_CHECKLOCKTIMEVERIFY
OP_ENDIF
OP_TOALTSTACK OP_IF
  0
OP_ELSE
  <c800> OP_CHECKLOCKTIMEVERIFY
OP_ENDIF
OP_FROMALTSTACK OP_BOOLOR

These are some witnesses that would solve the script above:
      { script: 'OP_0 OP_0 <sig(key)>', nLockTime: 200 },
      { script: 'OP_1 OP_0 <sig(key)>', nLockTime: 100 },
      { script: 'OP_0 OP_1 <sig(key)>', nLockTime: 200 }

However, the "Non-malleable satisfaction algorithm" would mark solution OP_0 OP_0 <sig(key)> as DONTUSE (if I'm not mistaken; see more below) and, thus, this solution should not be used.
This is because OP_0 OP_0 <sig(key)> is produced using a branch where a non-canonical satisfaction for or_b is used and the algorithm says:

The non-canonical options for and_b, or_b, and thresh are always overcomplete (reason 3), so instead use DONTUSE there

BTW, I am making the assumption that there in the quote above means that the DONTUSE marker must set only on that particular non-canonical sat of or_b: [sat(Z) sat(X)] (and not to the rest of canonical siblings: dsat(Z) sat(X); sat(Z) dsat(X);). I'm not sure about this interpretation.
That said, could you explain to me what would be the problem if OP_0 OP_0 <sig(key)> was used instead of OP_0 OP_1 <sig(key)>?
What advantage would it give attackers? Both are interchangeable.
Or does perhaps there mean all or_b sats should be marked as DONTUSE?

Malleability in the context of Miniscript
Malleability is the possibility for a third party to turn a valid satisfaction into another valid satisfaction. That is, to change the witness in the input of a transaction without making the transaction invalid.
There are various shortcomings to malleable witnesses. Witnesses add to the size of the transaction, so if a witness can be malleated such as to inflate the size of a transaction it could hinder its confirmation by reducing its feerate. Note this may "just" be a simple nuisance for regular usage of onchain transactions, but this could have more serious consequences for contracts that rely on the timely confirmation of a transaction.
In addition, using malleable satisfactions can have negative external effects on the network modified witness can affect BIP152 block propagation (which is based on the wtxid for Segwit transactions).
Malleability is discussed in more details here.
Malleability static analysis in Miniscript
Malleability appears whenever two valid satisfaction for a fragment are available to a third party. Note that a fragment's satisfaction may contain a dissatisfaction of a sub-fragment.
There are 3 ways that malleability may be introduced:

Two valid solutions are directly available to the third party. For instance let's say the third party knows the preimage to SHA256 hashes H1 and H2 and a script like and_v(v:or_i(sha256(H1),sha256(H2)),pk(A)) is used.
A single valid solution is directly available to the third party, but a participant in the Script uses another one. For instance let's say the third party knows the preimage to SHA256 hash H1 but not to SHA256 hash H2 and a script like and_v(v:or_i(sha256(H1),sha256(H2)),pk(A)) is used. If the participant satisfies this script by providing the preimage for H2, the third-party can replace the satisfaction by one providing the preimage for H1.
The participant provides a witness containing a satisfaction for a certain sub-fragment that can be turned into a dissatisfaction. For instance let's say the third party knows nothing, but or_b(pk(A),a:pk(B)) is used and a participant spends by providing both a signature for keys A and B. A third party can turn the signature for either A or B to the empty vector without invalidating the witness.

In order to make sure malleability may not be inadvertently introduced when spending from a Miniscript, new properties are introduced in the type system based on a set of general assumptions about what material may be available to a third party.
It is assumed:

they don't have access to any private key in the script;
they don't have access to more hash preimages than those revealed in the initial witness;
they only get to see a single witness produced by participants (otherwise they can mix-and-match);
no public keys are repeated in the script (otherwise a signature for a fragment may be "replayed" for satisfying another fragment).

The properties are:

whether satisfying this fragment requires a signature (that is, the satisfaction is not available to a third party);
whether dissatisfying this fragment requires a signature (same but for dissatisfaction);
whether a single dissatisfaction that does not require a signature exists, and others, if there is any, require a signature (that is, the fragment may be safely dissatisfied).

Non-malleable satisfaction algorithm and your example
Malleability is checked at creation time, and a Miniscript that does not contain at least one non-malleable satisfaction per spending path will be marked as unsafe (/insane). Note this does not rule out the existence of malleable satisfactions in addition to non-malleable ones. The satisfier needs to take care to only use satisfactions that are non malleable.
Your interpretation of the algorithm is correct. The non-malleable satisfier will refuse to use the satisfaction for or_b that satisfies both branches, even if it has the required material. However it will use any of the two non-malleable satisfactions available.

That said, could you explain to me what would be the problem if OP_0 OP_0 <sig(key)> was used instead of OP_0 OP_1 <sig(key)>?

It would allow a third party to change a valid witness into another one, see the section above for rationale.

Or does perhaps there mean all or_b sats should be marked as DONTUSE?

No, otherwise there would be no point in having an or_b fragment. :) Only all non-canonical satisfactions of or_b need to be marked as DONTUSE.
Related notes
Also note that malleability analysis assumes common standardness rules, such as MINIMALIF. So a miner could still malleate some witnesses even if they are treated as non-malleable by Miniscript.

Thanks Antoine. I kind of follow the general reasoning but then fail to understand how it applies to the particular example I provided. I guess I'm still not fully understanding it. What exactly could do an attacker if he saw OP_0 OP_0 <sig(key)> in the mempool (I guess this is the idea) that could not do if he saw OP_0 OP_1 <sig(key)>? The attacker can convert one into the other. Why is one then considered malleable and not the other? Also the attacker could convert both solutions to a dissatisfaction by replacing them with OP_1 OP_1  for example.

First note that your Miniscript here is malleable in any case, so it's not a surprise it may be malleated in various ways. Both the satisfactions in your comment are malleable. What an attacker can do if you use that is add more roundtrips to compact blocks or transaction relay on the network. Converting a top-level satisfaction to a dissatisfaction by definition makes the transaction invalid, so it isn't a concern. :)

Makes sense! My feeling was solutions were malleable in various ways. I could not get why OP_0 OP_1 <sig(key)> was not malleable. I was applying the "Non-malleable satisfaction algorithm" assuming the miniscript was sane. I had put the miniscript into the tool at: https://bitcoin.sipa.be/miniscript/, which provided a valid Bitcoin script and I assumed that this meant it was sane.


text:
What is a Feeler Connection? When is it used?
The bitcoin client hard codes a limit of 8 outbound connections and 2 block-only connections. Your node will try to always maintain these 10 outbound connections with reliable peers as a defense against network attacks. But there is an ephemeral 11th outbound connection called a feeler connection. What is the purpose of a feeler connection and how does it work?

I think it's 8 regular outbound, 2 blocks-only and a feeler connection. :)

A feeler connection is a short-lived outbound connection that only starts up after your node has established the required 8 outbound connections and 2 block-relay-only outbound connections. The purpose of a feeler connection is to regularly test addresses from the "new" table to see if they are connectable bitcoin nodes. Essentially, the feeler connection cleans the trash out of "new" and populates the "tried" table with valid addresses.

The "new" table contains untested addresses that the node has learned about from the gossip network.
The "tried" table contains addresses that the node has successfully connected to.

Every 2 minutes the feeler connection will do one of two things:

Pull a random peer from the eviction buffer (list of addresses considered for eviction because a new peer is mapped to the same slot in "tried"). Test the address by trying to connect to it and, if successful, remove that entry from the buffer. If this address is not connectable, evict it from "tried" and replace with a different address (previously pulled from "new").
If the eviction buffer is empty, test a random connection from "new" and, if successful, move it to "tried". If unsuccessful, update the address connection statistics accordingly. Tangentially, if an address fails to connect enough times (among other criteria) it will be labelled "terrible". If an incoming address collides with a terrible address, the terrible address will be evicted from the "new" table.

Feeler connections are disabled when no new blocks have been received for 30 minutes. In this case, the feeler connection is turned off and its connection slot is used every 10 minutes to try to find a node that knows about a new block. This is to try to detect and circumvent a network partition without overloading the number of inbound connection slots available on the network. Once a new block is discovered, the feeler connection reverts to cleaning out the eviction buffer and the "new" table.
History
Feeler connections are one of the suggested countermeasures of the paper "Eclipse Attacks on Bitcoin’s Peer-to-Peer Network" and were introduced with PR#8282 to increase the number of online addresses in the tried table and later PR#9037 implemented the test-before-evict functionality.

One addendum to your otherwise great answer: If we try a feeler connection and the attempt is unsuccessful, the address is not immediately evicted from new. Instead, its statistics are updated similar to non-feeler connection attempts (by calling Attempt() in addrman), which may lead to it being "Terrible" and evicted at some later point in time - but only in the case of a collision with another added address that would occupy the same position in addrman. In the absence of collisions, it will stay addrman, no matter how often we fail to connect to it.

Thanks for the feedback, @Lightlike! I have updated my answer accordingly. :)

The inspiration for feeler connections (and related eclipse mitigation techniques) comes from botnet designs observed in the wild.
From the original eclipse attack paper (Ethan Heilman):

.. many botnets, like bitcoin, use unstructured peer-to-peer networks and gossip (i.e., ADDR messages), and describes how botnets defend against attacks that flood local address tables with bogus information. The Sality botnet refuses to evict “high-reputation” addresses; our anchor countermeasure is similar (Section 7). Storm uses test-before-evict [30], which we have also recommended for bitcoin. Zeus [12] disallows connections from multiple IP in the same /20, and regularly clean tables by testing if peers are online; our feeler connections are similar.


text:
How to build a raw signed transaction with a FIXED fee?
I was wondering how can we build a transaction with a fixed amount of fees already FIXED.
Let's have this configuration
2 Inputs (X:0 = 520 BTC, X:1 = 102 BTC) => 1 RECEIVER (+510 BTC)
Fees are: 0.001 BTC / byte
How can we build a transaction wheras we don't even know the signature size ? Can you show your steps please ?

Do you mean a “fixed feerate [sat/vB]” rather than a “fixed fee [sat]”?

I think the instructions I wrote here just earlier today would also work for you: https://bitcoin.stackexchange.com/a/118302/5406

Your answer uses RPC interactions. But, I'd like to know the steps to BUILD a new transaction in Python or something like that by specifying all conditions. This is more an algorithm conception.

Please edit your question to incorporate that information, drop the “bitcoin-core”-tag and instead add “python”.

Okay, I finally found an algorithm which can fit to my wishes.
Available at : Calculating fee based on fee rate for bitcoin transaction
This can be easily converted into a Python code in order to build a transaction correctly.


text:
Is there a way I can reach the owner of the wallet address
I mistakenly sent some bitcoins to a wrong address. The mistake was from the wallet address I was given. An extra letter was added, making the address 35 digits. Is there a way I can reach the owner of the wallet address I mistakenly sent it to? Please help me.
This is the wrong address that bitcoin was sent to
114dW3JX2sPPLVDnX4H8u2vsMc4CEJ3rVYf
It's a blockchain wallet.

This is, for all intents, impossible. Adding an extra character will make an address invalid. If against all odds you managed to make a single character typo and end up with a valid encoding, the address is a black hole that nobody owns.

In this particular case, any sane wallet would not create a transaction at all, and your coins should be in the address where they were before you attempted this transaction

Removing the last letter it would be a valid BTC address:
114dW3JX2sPPLVDnX4H8u2vsMc4CEJ3rVY
But it was never used so no funds ended up there. So I wonder if your coins really left your wallet.

Is there a way I can reach the owner of the wallet address

No, There is no general way to find the contact details of an owner of a mistyped address. At least none that are likely to succeed for any arbitrary address.
You can check an address at any Blockchain Explorer - this will tell you if any bitcoins were really sent there - but will not identify the identity of any person.
There are many possible valid addresses, only a very tiny few of them are in use.
If you send bitcoin to a valid address that no-one is using, those bitcoin are lost forever unless you can re-spend the inputs using a much higher fee (or miner cooperation) before your transaction is confirmed.

An extra letter was added, making the address 35 digits.

Most wallets make it impossible or difficult to mistype an address by using a checksum.

The probability that a mistyped address is accepted as being valid is 1 in 232, that is, approximately 1 in 4.29 billion.

(from Bitcoin Wiki)
114dW3JX2sPPLVDnX4H8u2vsMc4CEJ3rVY is a valid address but has a balance of zero and no transactions.
114dW3JX2sPPLVDnX4H8u2vsMc4CEJ3rVYf is not a valid address. I don't see how any Bitcoin can possibly have been sent to it.

It's a blockchain wallet.

If your wallet shows an amount has been "spent" to that invalid address and deducted from your "balance", you should contact the company that call themselves "Blockchain Luxemburg S.A.R.L." and who presumably provide your wallet.
I recommend not using custodial wallets. See types of Wallet

See also

Can a bitcoin transaction be reversed?
Is it possible to cancel an unconfirmed transaction?
What happens if I mistype the address when making a payment?
Possibly sent Bitcoin to wrong address
Is there any way for me to recover or reclaim a confirmed but unspent transaction that was sent to the wrong address?


text:
Why doesn't RBF include restrictions on the outputs?
Why didn't the RBF specification include additional constraints on the replacing transaction, such as that it would need to contain the same outputs (with at least the original output amounts) as the transaction being replaced? Couldn't this have made it safer to assume that zero-confirmation RBF transactions would eventually settle on-chain?
The one downside I can think of is that every RBF replacement would then need an additional input since the fee increase needs to come from somewhere. Are there any others?

Why didn't the RBF specification include additional constraints on the replacing transaction, such as that it would need to contain the same outputs (with at least the original output amounts) as the transaction being replaced?

Because it is not as effective to do this. What you describe is known as First Seen Safe RBF (FSS-RBF). However this imposes additional restrictions on transactions that make fee bumping difficult, if not impossible to do.
FSS-RBF notably requires spending an additional input. However if no input is available (e.g. user has one input, or is sweeping their wallet), then the transaction cannot be replaced. Or users may wish to retain their privacy by avoiding to spend certain inputs together and so if they have no inputs they are willing to add to the transaction, then it cannot be replaced.
Furthermore, this increases the size of a transaction with each bump thereby taking up more and more block space for little utility. The cost to continuously bump a transaction's fee also will grow non-linearly. In addition to the new feerate you are targeting, you also have to pay for the input you've just added at that feerate.
It also means that continuously bumping the transaction fee is annoying to do, and eventually, impossible (due to lack of inputs). If you lowball the fee, then decide to bump it later, and that is still too low, to bump it again requires another input. And so on and so forth. Bumping the fee like this reduces your future ability to FSS-RBF transactions too as you will be consolidating inputs.
Conversely, Full RBF does not require extra inputs, so as long as you have a change output, you can keep decrementing that to get the new fee. This means that the fee will only grow as the fee rate grows, and it does not require more block space. Since it does not require more inputs, you can fee bump transactions when you have no additional inputs available.

Couldn't this have made it safer to assume that zero-confirmation RBF transactions would eventually settle on-chain?

No, in fact, it would have made it worse.
To assume that a 0-confirmation transaction is safe means that you are willing to spend its outputs. In that spending transaction, you will be explicitly referencing the txid of the transaction whose output(s) are being spent. Replacing a transaction (in both RBF and FSS-RBF) means creating a new transaction that spends the same inputs, i.e. a double spend. This new transaction will have a different txid because it, at the very least, changes the amounts of the outputs and thus results in different data being hashed. So if the bumped transaction becomes confirmed, then any transaction the spent the outputs of the lower fee transaction instantly becomes invalid. This is not safe at all.
The fact that people will think that unconfirmed transactions are safe to accept if FSS-RBF were used (as you did) is far more dangerous than Full RBF. With Full RBF, people know to just wait for confirmations. With FSS-RBF, people will think that unconfirmed transactions are safe to accept, spent its outputs, and then find out that their transaction is invalidated when a bumped version of the original unconfirmed transaction is mined instead. It is a false sense of security.

In general, unconfirmed transactions are not safe to accept, regardless of RBF, FSS-RBF, or no RBF at all. Either way, an unconfirmed transaction could be replaced with a conflicting one and result in any transaction that spent from the original unconfirmed transaction to become invalid. Because the dangers are all the same regardless of RBF and which type of RBF is used, Full RBF where any outputs can be replaced is better as it is more space and fee efficient.

There is some discussion of the motivation for Full RBF over FSS-RBF in BIP 125 itself.


text:
where is the adjustment calculation for the target value in the source code?
Can someone point me to the source code and explain how the average is calculated for the adjustment of difficulty that takes place every 2016 ?
Update: i have consulted with previous questions but it has not been documented properly and I am not expert so would be much appreciated.

The function is CalculateNextWorkRequired in pow.cpp L#49:
unsigned int CalculateNextWorkRequired(const CBlockIndex* pindexLast, int64_t nFirstBlockTime, const Consensus::Params& params)
{
    if (params.fPowNoRetargeting)
        return pindexLast->nBits;

    // Limit adjustment step
    int64_t nActualTimespan = pindexLast->GetBlockTime() - nFirstBlockTime;
    if (nActualTimespan < params.nPowTargetTimespan/4)
        nActualTimespan = params.nPowTargetTimespan/4;
    if (nActualTimespan > params.nPowTargetTimespan*4)
        nActualTimespan = params.nPowTargetTimespan*4;

    // Retarget
    const arith_uint256 bnPowLimit = UintToArith256(params.powLimit);
    arith_uint256 bnNew;
    bnNew.SetCompact(pindexLast->nBits);
    bnNew *= nActualTimespan;
    bnNew /= params.nPowTargetTimespan;

    if (bnNew > bnPowLimit)
        bnNew = bnPowLimit;

    return bnNew.GetCompact();
}

Explanation:
1. If retargeting is disabled, return the last difficulty.
2. Calculate the timespan between the last block and 2016 blocks ago
3. Truncate the timespan to no less than 1/4 of the target timespan (3.5 days) or no greater than 4x the target timespan (8 weeks).
4. Multiply the last difficulty target by the ratio actualTimespan:targetTimespan
5. Truncate to the maximum allowed target (bnPowLimit) if the resulting target is too high (very low difficulty)

thank you. When would retargeting be disabled ? How does this pop in ?

And where in this code is the legendary broken and unfixed bug that causes updates every 2015 rather than 2016 blocks ?

https://github.com/bitcoin/bitcoin/blob/v0.17.0.1/src/chainparams.cpp#L294

https://github.com/bitcoin/bitcoin/blob/v0.17.0.1/src/pow.cpp#L41


text:
crypto.com defiwallet sends bitcoin to random segwit address if a bitcoin taproot address is selected after confirmation of the correct address
UPDATE: Crypto.com acknowledge the bug and refunded the full amount, at the time of writing this update the crypto.com team confirmed that they are working on fixing the bug and the defi wallet will hopefully be fixed ASAP.
Lesson learned; test every transaction even with wallet and address that you know are safe and already used in the past.
When scanning the QR code of a taproot address with the DefiWallet of crypto.com the app will correctly show the taproot address, not give any warning of unsupported format or other error message (screenshot from my second attempt to recreate the bug with different taproot address https://i.sstatic.net/yl95C.jpg), it will give a first confirmation with a reference transaction ID that the bitcoin transaction was broadcasted to the network with the correct recipient address, but in reality it will automatically convert the taproot address to a segwit address and send the bitcoin to this random generated address making the coin lost forever.

taproot address generated from ledger - https://i.sstatic.net/KiwBE.jpg

first confirmation showing the correct taproot address scanned in the previous step with a reference transaction ID https://i.sstatic.net/MuVMa.jpg  transaction ID: https://blockchair.com/bitcoin/transaction/c834fb3bc1e849b1e708b15728e55796adb7d44bf1b83b2b35dcaba4eb87b54b?from=crypto.com

After the transaction has been broadcasted to the network and it receives the first confirmation the defiwallet updates the home-screen showing the converted segwit address where it actually sent the bitcoin with the same transaction ID as reference, proving that the first confirmation screen is the result of a bug. https://i.sstatic.net/D4sLa.jpg - https://i.sstatic.net/NreRT.jpg

Video on my second attempt to recreate the bug and using a second bitcoin software wallet (trustwallet) to show that the problem is not my phone or some malicious software installed on the phone but the actual crypto.com defiwallet - https://streamable.com/91ksgg

since my first chat with them the defiwallet has been under "maintenance for bitcoin transaction" - https://i.sstatic.net/osqWF.jpg

I understand something similar has already happened Is it possible to convert a taproot address into a native segwit address? I have contacted the crypto.com support chat, I have sent them the same information and for the last 12 days they have been "investigating" the issue. I'm aware the coin are lost forever but the lack of response from crypto.com team is awful and I have no idea how many people have already lost and will lose their bitcoin because of crypto.com.
my segwit address bc1q3exlju6gr6cwu3s3hxnjssjpxnmafnxtlms6cm

If what you say is true, I'm sorry for what happened to you, and I stand by my response in https://bitcoin.stackexchange.com/questions/111440/is-it-possible-to-convert-a-taproot-address-into-a-native-segwit-address: this is painfully incompetent, and you should demand your money back. That said, I don't think there is any new question here. It also sounds like they may be working on fixing it already.

Yes I believe the problem is the same experienced by the other guy, I have not found anything else apart from the previous post, I hope this post will help someone in the future if they happen to be in my same situation, this is more of a warning post than a question honestly, i've made peace with myself and think of the 0.21btc as a donation to the network.

@froginspace: You have good grounds in demanding that crypto.com reimburse you. That's what happened in the prior case with Binance. The error is solidly on the end of the service here.

Note that we'll probably close this topic eventually either as a duplicate of the linked one, or because you didn't actually ask a question. But meanwhile I interpreted your post as a request for making some noise about this: https://twitter.com/murchandamus/status/1526668237529878528

I am having a remotely similar dispute with an exchange, did you manage to solve this? Text me on twitter, maybe we can help each other: @pedr0fr

I’m voting to close this topic because it is a recount of events and not asking a question.

@froginspace: Did you ever hear back from Crypto•com since?


text:
Why can't P2PKH's scriptPubKey be shortened to only OP_CHECKSIG?
For P2PKH, the scriptPubKey is OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG. Why can't it check the signature only? Why can't it be shortened to just one opcode — OP_CHECKSIG?
Why does the public key need to be presented in addition to the signature when unlocking?

Can you clarify what you mean by "just one opcode OP_CHECKSIG"? If that was the entire scriptPubKey, anyone could spend any output (as the attacker could provide their own public key rather than the coin owner's).

Why can't [the unlocking script] be shortened to just one opcode — OP_CHECKSIG?

The OP_CHECKSIG function pulls two arguments off of the stack - a public key and a signature. It then verifies that the specified public key was used to generate the provided signature, and that the signature matches the transaction that it is in.
So if you make an output with a locking script that was shortened to only OP_CHECKSIG, then I could could spend that output using this unlock script...
<sig> <my_public_key>
This pushes the signature of the spend transaction that I generate using my private key, and then my public key onto the stack. Next the unlock script would run and the OP_CHECKSIG would pop those and verify that the signature that I generated and my private key match. Note that at no point did I need to know any of your keys to spend your output. This is not what you want. You want only someone who knows your private key to be able to spend your outputs.
So the minimum lock script you can use with bitcoin that will require your private key to unlock is...
<your_public_key> OP_CHECKSIG
To spend this output, you would then need the following unlock script...
<sig>.
Since you know your private key, you can generate a signature that will validate against the public key you put the locking script. This is, in fact, a standard (but rarely used) lock/unlock script.
So if we can use these much simpler locking and unlocking script, why do the standard script have all that extra stuff?
A bitcoin public key is at least 257 bits long, and you'd have to give that long number to anyone who was going to send you bitcoin. The standard script instead includes a 160 bit hash of your public key, which is much shorter.

Why does the public key need to be presented in addition to the signature when unlocking?

The extra stuff in the standard scripts do the work so that only the shorter hash needs to be in the lock script. But the OP_CHECKSIG still needs to know the full public key to be able to check that the signature matches it. So the public key instead shows up in the (now longer) unlock script which you do not need to give out to people. The rest of the code hashes the full public key to check that it was really you that make the locking script, and then gives the full public key to the OP_CHECKSIG.

Excellent! Could you walk me through a step-by-step execution of OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG? I think that would really help in clearing up all remaining doubt.

I have found a step-by-step execution example on https://en.bitcoin.it/wiki/Script#Script_examples

The script achieves two things:

Ensures the provided public key matches the provided signature
Ensures the provided public key leads to the same address script the utxo was locked with.

A P2PKH script contains the hash of the public key. When you spend the coins, you provide a public key, and a signature.
First, the script duplicates the provided public key, then runs it through hash160, and compares the output to the hash embedded in the locking script.
Once that check passes, it validates the provided signature against the same public key. This ensures that the signature comes from the same key that was used to generate the address.


text:
Why this transaction is invalid?
I issued this transaction on testnet (for a homework later solved with another script). python-bitcoinlib validates the transaction but when i submit it to blockcypher it gets rejected with error:
{"error": "Error validating transaction: Error running script for input 0 referencing e96a1ae8aaff2920601fdfd8cb12289d77bad2a4d595e2093d9d828107023705 at 0: Script was NOT verified successfully.."}
My first transaction scriptPubKey: (transaction hash: e96a1ae8aaff2920601fdfd8cb12289d77bad2a4d595e2093d9d828107023705)
    [2, j1_public_key, j2_public_key, j3_public_key, 3, OP_CHECKMULTISIGVERIFY,
      1, my_public_key, p2_public_key, 2, OP_CHECKMULTISIG]

And the failed transaction scriptSig is:
[0, my_sig, 0, sig_j1, sig_j2]

and failed transaction hex is:
01000000010537020781829d3d09e295d5a4d2ba779d2812cbd8df1f602029ffaae81a6ae900000000dc0047304402206558714362318ff5aa05bd1849b82726f4d3ab2545bc15379b73de1fca4ef6c002206ea00f130ea54d6e85f233a3d031bdf03d35a10319362fe41866d5c59c7d7b1b0100483045022100b9daea5e3da41e305b2a283825c45c7eef169364413af043115797124033f1ce022004ae32ecab1937fac90e904be684f893ccdd1d925d6b898aef7f275dcb9791ea01483045022100e54c2f805c5ba5025c375053c4604910a30e5bf86eb16a5c9ba35cd9f817aef802201f92da76cf31562ae28e527bd537ecf930139224a8d91d10886383958aadd6bd01ffffffff01b8ed0400000000001976a914a8305457f8965a5a60a8ebe1968fb9019b42fe6c88ac00000000

You should definitely post the transaction hex that you're trying to redeem with, and the steps you took to sign it.  You can edit your question to add those in.

Scripts look good to me.

I have one observation, not sure if this leads to the error. Multisig scripts start with a hex "0", which compensates for a very early "off by one error" in the execution routines of the checksig routines. An element too much was popped off the stack. This "bug" is so long in the system, that everyone got accustomed to it, and removing it requires an enormous effort. So it became a feature :-)
Looking at your tx, I see the third signature doesn't have this zero:
TX_IN[0] Script Sig (uchar[])
1) 0047304402206558714362318FF5AA05BD1849B82726F4D3AB2545BC15379B73DE1FCA4EF6C002206EA00F130EA54D6E85F233A3D031BDF03D35A10319362FE41866D5C59C7D7B1B01
2) 00483045022100B9DAEA5E3DA41E305B2A283825C45C7EEF169364413AF043115797124033F1CE022004AE32ECAB1937FAC90E904BE684F893CCDD1D925D6B898AEF7F275DCB9791EA01
3) 483045022100E54C2F805C5BA5025C375053C4604910A30E5BF86EB16A5C9BA35CD9F817AEF802201F92DA76CF31562AE28E527BD537ECF930139224A8D91D10886383958AADD6BD01

which is disassembled sig1:
    00: OP_0, OP_FALSE:      an empty array is pushed onto the stack.
    47: OP_DATA_0x47:        push hex 47 (decimal 71) bytes on stack
    30: DER_SEQUENCE_0x30:    type tag indicating SEQUENCE, begin sigscript
    44: DER_LENGTH_0x44:      length of R + S
    02: DER_INT_0x02:         type tag INTEGER indicating length
    20: DER_LENGTH_0x20:      this is SIG R (32 Bytes)
        6558714362318FF5:AA05BD1849B82726
        F4D3AB2545BC1537:9B73DE1FCA4EF6C0
    02: DER_INT_0x02:         type tag INTEGER indicating length
    20: DER_LENGTH_0x20:      this is SIG S (32 Bytes)
        6EA00F130EA54D6E:85F233A3D031BDF0
        3D35A10319362FE4:1866D5C59C7D7B1B
    01: OP_SIGHASHALL:       this terminates the ECDSA signature (ASN1-DER structure)

and sig2:
00: OP_0, OP_FALSE:      an empty array is pushed onto the stack.
48: OP_DATA_0x48:        push hex 48 (decimal 72) bytes on stack
30: DER_SEQUENCE_0x30:    type tag indicating SEQUENCE, begin sigscript
45: DER_LENGTH_0x45:      length of R + S
02: DER_INT_0x02:         type tag INTEGER indicating length
21: DER_LENGTH_0x21:      this is SIG R (33 Bytes)
    00B9DAEA5E3DA41E:305B2A283825C45C
    7EEF169364413AF0:43115797124033F1
    CE
02: DER_INT_0x02:         type tag INTEGER indicating length
20: DER_LENGTH_0x20:      this is SIG S (32 Bytes)
    04AE32ECAB1937FA:C90E904BE684F893
    CCDD1D925D6B898A:EF7F275DCB9791EA
01: OP_SIGHASHALL:       this terminates the ECDSA signature (ASN1-DER structure)

and sig3:
48: OP_DATA_0x48:        push hex 48 (decimal 72) bytes on stack
30: OP_SEQUENCE_0x30:    type tag indicating SEQUENCE, begin sigscript
45: DER_LENGTH_0x45:      length of R + S
02: DER_INT_0x02:         type tag INTEGER indicating length
21: DER_LENGTH_0x21:      this is SIG R (33 Bytes)
    00E54C2F805C5BA5:025C375053C46049
    10A30E5BF86EB16A:5C9BA35CD9F817AE
    F8
02: DER_INT_0x02:         type tag INTEGER indicating length
20: DER_LENGTH_0x20:      this is SIG S (32 Bytes)
    1F92DA76CF31562A:E28E527BD537ECF9
    30139224A8D91D10:886383958AADD6BD
01: OP_SIGHASHALL:       this terminates the ECDSA signature (ASN1-DER structure)

I currently can't find the details here in stackexchange on this off-by-one error, I am sure Pieter Wille or G.Maxwell explained it. Maybe it was over at bitcointalk.org...

Thnx. I checked my code again looking where i ignored and found a bug in my signing process. i am not sure that bug resulted this issue but as this answer lead me to checking signatures i mark it as correct.


text:
How to import private key of a P2SH-P2PKH address to Bitcoincore 0.18.0?
I have a privkey of a P2SH-P2PKH address, how to import it to Bitcoin core 0.18.0? In previous versions, I could call importprivatekey and then addwitnessaddress but the addwitnessaddress was removed.
Edit: seems like Bitcoin core 0.18.0 auto calls addwitnessaddress when I use 'importprivatekey' but I found no official documentation of that.

Since Bitcoin Core 0.16, every private key gives rise to a supported P2PKH (1...), P2SH-P2WPKH (3...), and P2WPKH (bc1...) address.
All you need to do is import the private key with importprivkey; the corresponding segwit address will automatically be supported.
A more reliable method is using importmulti, where you specify the address you want together with the private key; if they mismatch, or information is missing, it will complain (since 0.18).


text:
Detect received transactions of thousands of Bitcoin addresses
I'm implementing a Bitcoin payment system that generates bitcoin address for each user to deposit.
I use BitcoinJ to generate user's addresses and rawblock API from Blockchain.com to get every single block to check if my addresses are in any transaction output, then my system increases the user's internal balance.
I save scanned block height in the database and send a request for a new block every 10 minutes.
Is that solution correct? (I need testnet so I cannot use their Wallet Service)
Thank you.

This doesn't sound correct to me.

You're relying on a centralized service to fetch blocks.  What if their system has an error and sends you incorrect data?
What if their service is unreachable?
It doesn't seem like you have any way to handle blockchain reorganization.  You might end up crediting a payment twice, or crediting where a double spend was successful in a competing chain.

Consider looking into something like BTCpay which FOSS self-hosted bitcoin payment processor.

I've been thinking Blockchain.com is a trusted service and we can rely on them and I don't want to maintain a node on my server.
For the (2.), I fetch only blocks that have at least n confirmations and fetch only 1 block (1 time) at any height. I haven't known any other mechanism to handle blockchain reorganization.
Do you think electrum.org or a centralized service is a better choice in my case? Thank you.

Blockchain[dot]com is definitely not a trusted service.  Really there are not any trusted services in bitcoin.  WRT electrum, it's a bit better but you will lose all your privacy in the process.   I still believe something like BTCpay is your best bet.


text:
Does difficulty target remains static for 2016 blocks in Bitcoin?
I know that in Bitcoin the difficulty target adjust after creating 2016 blocks. So, it means that within these 2016 block the difficulty target remains same (static). Am I correct?
If this is correct then the miners has to find the right Hash of the header. Header=version+hash of previous blockheader+merkle tree root+timestamp+difficulty target+nonce variable.
Now, it seems that within these 2016 blocks the input (block header) to the hash function will be different but the output (difficulty target) remains the same. Therefore it seems to me that it breaks the property of "strong collision resistance" property of the hash. Am I correct? In other word, Bitcoin uses this property of the hash function to make it difficult to find solution of the puzzle.

OK. it does [not] breaks the property of "strong collision resistance" property because the  output of the hash function can be less than the target value.

May I remind downvoters that they must provide a reason why they downvoted and if they vote to close.

The target is adjusted every 2016 blocks but the hash of mined blocks does not have to equal the target. For the block to be valid, its hash must be less than or equal to the target.
So in that run of 2016 blocks, each block has a different output from the hash function. All are less than the target.
I imagine that it is incredibly unlikely that any block hash has ever exactly equalled the target.

Does difficulty target remains static for 2016 blocks in Bitcoin?

Yes. Since it is only recalculated every 2016 blocks, for those 2016 blocks the target is static / unchanging / the same / a constant / invariant.


text:
Is it Safe to Share a Wallet File Between Multiple Bitcoin Core Instances Using the New Wallet DB Technology?
I have a setup where a single stateful Bitcoin node (with a watch-only wallet) is no longer sufficient due to being a single point of failure and the increasing load of requests. Consequently, I need to run multiple bitcoind server instances.
Around 6.5 years ago, in this question, it was stated that sharing a wallet.dat file between multiple bitcoind servers was not possible due to the risk of wallet corruption and potential loss of funds. Specifically, Ava Chow noted that:

"You should not share a wallet.dat file between two servers. It may not even work and may result in wallet corruption and loss of funds. If you are planning on having the two instances open the same wallet file, that is not allowed. BDB (the database system used by Bitcoin Core) does not allow a database to be opened by multiple software simultaneously. If you are somehow able to do so, you can corrupt your wallet.

Furthermore, even if the wallet file is not accessed simultaneously, the two nodes will have different sync states which will result in the software being confused and potentially have to rescan every time you start up one of the nodes. It may also have other issues."

Given that Bitcoin Core 26.0 Release Notes state:

"The createwallet RPC will no longer create legacy (BDB) wallets when setting descriptors=false without also providing the -deprecatedrpc=create_bdb option. This is because the legacy wallet is being deprecated in a future release."

With the change in wallet DB technology, is it now possible to safely share one or more wallet files between multiple bitcoind instances, ensuring that changes made on one server are reflected on the others without causing corruption? Does the new wallet technology support this use case or does it still have the same restrictions as the legacy BDB wallets?
If sharing wallet files is still not allowed, what are the recommended ways to scale a stateful Bitcoin Core setup (with wallet) to handle increased load and avoid a single point of failure?
Thank you for your insights.

Where is the increased load coming from? What are you using the wallet for?

The increased load is coming from applications invoking RPC commands to get blockchain and watch-only wallet information. The wallet is used as a watch-only wallet.

@JeffTrimmer Is the question about having the same wallet file open by different wallet instances (e.g. network drive), or about two servers both with their own copy of the same wallet? The text you quote is about the first (which indeed is absolutely not possible) but depending on what you're doing, the second may be okay, especially in watch-only scenarios.

@PieterWuille The question is about having the same wallet file open by different wallet instances, but I now know this is not possible. I'm trying to scale bitcoind to multiple instances in a cluster with a watch-only wallet, where importing a descriptor into one instance is recognized by all nodes. I need the wallet state to synchronize without importing into each node. The nodes will be behind a load balancer, and I won't know the individual host addresses or how many nodes exist at any given time.

Can you elaborate one what "synchronizing the wallet state" means? Different wallets with the same descriptor(s) imported will eventually see the same transactions, and the same balance. But if you're constructing new transactions on both, it's possible that one will use UTXOs that the other is in the process of spending already, for example. Or, if you invoke getnewaddress on both, they'll give out addresses the other instance has already given out.

You have identified the exact problem I am trying to solve. Constructing new transactions on both should not use UTXOs that the other is in the process of spending already. The invocation of getnewaddress should not give out an addresses that another instance has already given out.

No.
The switch to a different database for the wallet does not change the issues that would arise with multiple nodes having slightly different sync states.

If sharing wallet files is still not feasible, what are the recommended ways to scale a Bitcoin setup to handle increased load and avoid a single point of failure?


text:
Is it possible to run RPC commands without installing the entire Bitcoind
I am interested to run bitcoin mining https://github.com/jgarzik/pyminer/blob/master/pyminer.py , I understand that it inherently calls bitcoind to run some RPC commands to broadcast once a nonce is achieved etc... Is it possible to run RPC commands without installing the entire blockchain

Does this answer your question? Do I need to download the entire blockchain in order to use bitcoin-cli?


text:
Where exactly is the mining code in Bitcoin Core?
I've been looking for months for the real mining code in the Bitcoin Core source code for the function/s that implement the incrementing of the nonce and hashing blocks for mining and never found anything useful. Can anyone Help me find it?

Most of the mining code was removed from Bitcoin Core as CPU mining gave way to GPU, FPGA and ASIC mining. The minimal amount of code that's left is intended for testing purposes, i.e. creating blocks on regtest. This code is in src/rpc/mining.cpp, and the function that handles incrementing the nonce is GenerateBlock.


text:
Does the user not need to specify the amount in the transaction creation process as the amount is implicitly determined by the UTXOs they select?
I'm trying to understand the Bitcoin transaction creation process and how inputs and outputs work. From what I know, when a user creates a Bitcoin transaction, they typically select UTXOs (Unspent Transaction Outputs) as inputs to the transaction.
Given this, it seems that the amount of the transaction is implicitly determined by the UTXOs selected, since the sum of the inputs is what gets spent. In other words, the total amount of Bitcoin being sent would be based on the value of the UTXOs used in the inputs, while the user doesn't need to explicitly specify the amount.
Is that correct? Does the user really need to specify the amount at all, or is it entirely determined by the selected UTXOs? And if there's any difference, what is the role of specifying the amount in some wallet interfaces?

From the perspective of a transaction, there is no one "amount". A transaction has one or more inputs of certain amounts (determined by the transactions that created those UTXOs) and one or more outputs of certain amounts (determined in the transaction itself). The difference of the sum of input and output amounts is the transaction fee.
From the perspective of a wallet user, however, there usually is one specific "amount" that they want to send in a transaction, which becomes the amount in the output that goes to the recipient. After a desirable fee rate is determined, the wallet selects UTXOs to fund the transaction (see coin-selection). In most cases a combination of UTXOs with a perfectly matching amount will not be found, in which case a change output will be added that sends the remainder back to the sender (see change).

Alice has 2 UTXOs of 10.000 sats each.
She wants to pay Bob 15.000 sats.
The wallet will:

select both UTXOs as inputs (total 20.000 sats)
define 2 outputs:

15.000 sats to Bob
5.000 sats to Alice

The wallet needs to know the amount from Alice to know how to divide sats between outputs.

Reading this again after @amaclin’s answer, I realize that you might have indeed been asking about the input amounts rather than the output amounts. If so, you are correct. The input amounts are not explicitly specified in the transaction as they are specified by the prior transaction that created the UTXOs. A spending transaction only needs to specify which UTXOs it exactly spends, but the information about the output script and amount are already present in each node’s UTXO set.

If you were asking about output amounts, see my original answer below:
It depends on the type of transaction you are building.
If you are sweeping a wallet, consolidating into a single output or depositing several whole UTXOs to a service, you probably do not care about specifying the amount of the output. Rather, it is implicitly defined by the inputs and fees.
However, in my experience, most transactions are created to make one or multiple payments. When you make a payment transaction, you do want to send a specific amount to each receiver of the payment. Only the potential change output amount would then be determined by what remains from the inputs after deducting the payment amount and the fees.

Does the user really need to specify the amount at all

No. Transaction itself does not contain the amounts on inputs. But these values are used while creating ecdsa/schnorr signatures


text:
Is a spent UTXO immediately deleted from the UTXO set?
Suppose A spends a UTXO of 5 BTC. The transaction is sent to the mempool. Will the 5 BTC UTXO be instantly deleted from the UTXO set? If no, can this UTXO still in the UTXO set be used to make another transaction? Can this UTXO be used while it is in the mempool (unconfirmed transaction)?

For nodes that maintain their own mempool there really are two "UTXO sets", one that only considers confirmed transactions and one that also considers mempool transactions. UTXOs that are spent by a yet unconfirmed transaction can be spent in a different transaction, provided some rules are met (e.g. the transaction fee is increased, see BIP125 for more details), in which case the previous transaction is replaced.


text:
Is there any way to stop forwarding payments through my LDK node?
I can't seem to find a config option for discarding all forwards.

There's deliberately no way to refuse to forward payments over "public" channels because that's the definition of a "public" channel - one which you are saying you want to accept forwards over.
If you have opted to open private channels (not announced) then  accept_forwards_to_priv_channels is what you want (and keep the channels private!).
You can read more about that in our API docs.
https://docs.rs/lightning/0.0.113/lightning/util/config/struct.UserConfig.html#structfield.accept_forwards_to_priv_channels

This question was originally asked by deb.dasit2013 and answered by Matt Corallo on Discord

There is a bit of a leap in the explanation between public channels being meant for forwarding, and the recommended setting for private channels. Could you perhaps fill in a bit more context?

By default LDK opens private channels unless setting the announced_channel flag to true. There is no option for discarding all forwards for publicly announced channels. A user must ensure the channel is private from the outset and accept_forwards_to_priv_channels, generally HTLC intercept will be supported soon.