text:
Transaction signing and security: Different signing approaches
I am currently studying for an exam and reviewing a past one from the CS 251: Bitcoin and Crypto Currencies course in Stanford with the following question on transaction signing. I have written my answers afterwards and would appreciate it if you could feedback if this correct or if something would need to be considered differently:
Recall that a Bitcoin transaction has a set of input addresses and a set
of output addresses. Usually, each input address signs the entire transaction (minus the signatures) to
authorize payment. This signature type is called SIGHASH_ALL.
In this question we explore other signature types where only portions of the transaction are signed.
Some of these types are already supported by the Bitcoin network and some are new. Whenever a
Bitcoin node validates a transaction, it checks the signatures on exactly what was signed and rejects the
transaction if any of the signatures are invalid.
For each transaction signing method listed below, decide if an attacker can steal funds from an input
address of a transaction submitted to the Bitcoin network. If so, explain how; if not, explain why not.
A. The secret key of each input address is used to sign the entire Txin (the input part of the
transaction, minus the signatures) and nothing else. That is, the Txout (the output part of the
transaction) is not signed. (this signature type is called SIGHASH_NONE)

This is not secure since a miner could simply change the Txout and thus change the payment to his address.

B. The secret key of each input address is used to sign the entire Txout and nothing else.
Hint: consider an address C for which there are 50 valid UTXOs that each credit C with 2 BTC (so
that address C is worth 100 BTC). Is there a situation where a Bitcoin user can drain Bitcoin from
address C without the owner’s authorization?

I do not see a risk there since the Txout is secured and thus cannot be changed. It should not matter that the Txout is not secured as a whole.

C. Suppose there are two inputs and two outputs. The secret key of the first input is used to sign
the entire Txin and the first output UTXO, and nothing else. The secret key of the second input
is used to sign the entire Txin and the second output UTXO, and nothing else. (this signature
type is called SIGHASH_SINGLE)

I assume that the same issue can occur as for D that miners can add further outputs and thus make the transaction invalid. However, they should not be able to steel funds as each output is signed.

D. Suppose there are two inputs and two outputs. The secret key of the first input is used to sign
the first input in Txin and the first output UTXO, and nothing else. The secret key of the second
input is used to sign the second input Txin and the second output UTXO, and nothing else.

I assume that a miner could add additional in- and outputs to the transaction since it is not secured as a whole. However, he could not steal funds with this approach but only make a transaction invalid, e.g. by adding more outputs and thus having outputs>inputs.

Thank you very much in advance for your help! I would also appreciate hints if you just have an idea on one part.

Do we have a policy on answering assignment questions?

@sanket1729 this is just for understanding and practice. It is a past exam and I will not submit any comments/solution anywhere. Thanks for your help!


text:
My transaction is in review for over 24hrs on blockchain, I want to cancel it
Please I want to cancel my in review transaction on blockchain. How will I go about it. Please help me,I need answers as soon as possible.

You can't cancel a transaction. You can broadcast another transaction with a higher transaction fee (replace-by-fee) sending back to an address you own and hope that gets confirmed before the original transaction (miner is incentivized to mine this replacement transaction rather than the original one). Or alternatively you can ask the recipient to send the funds back to you after it has been confirmed. But once you have broadcast a transaction there is no way of cancelling it and instantly removing it from other people's mempools.

How will I broadcast another transaction by replace by fee because when I try initiating another transaction all I got is insufficient fund. And the receiver is a scam, I sent him another fund on another platform and he end up blocking me with payment hoping he will get this too since have already initiated the transaction

Right most wallets won't support this. You'd need to be able to construct a transaction manually I think rather than using existing wallet functionality. Even the wallets that support RBF will be for bumping a fee to the original destination rather than attempting to change the destination of the funds. https://www.reddit.com/r/Bitcoin/comments/b8qf4c/what_wallets_today_support_fee_bumping_ie/

Apparently BlueWallet has RBF support implemented as "Bump Fee" and "Cancel Transaction" if you can import your keys into a BlueWallet. If these are all your funds at stake then you've got nothing to lose. But if these are only a percentage of your funds be careful not to lose the rest of your funds by botching an attempted RBF, cancel transaction. Rushing isn't a great idea normally when you don't know what you are doing and haven't researched.

I’m new to this and don’t really know what to do…. Can you help me with some video to guild me on what to do?? You can send the video link to my mail please @ susw219@gmail.com

I don't think there are any good videos for RBF. Is your wallet a blockchain.com wallet?

source: Stack Exchange

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

sort: votes


text:
What are miners signalling for when the block header nversion field ends in 4 i.e. 0x3fffe004?
I've been researching into Overt (Version rolling) ASICBoost and tracking some of the latest mined blocks on https://asicboost.dance.
I've noticed that all recently mined blocks have the version ending in 4 i.e. by setting bit 2. I know that miners are signalling support for Segwit by setting bit 1. So, I'm not sure what they're signalling by setting bit 2?
I have been through many of the BIP documentations, but cannot seem to find any references for bit 2 being set. I've also reviewed a similar question already asked but the answer does not focus on bit 2. Some miners set the nVersion field of the block header to 0x8000004. What were they signalling for? Was this an error?

They are signaling for Taproot. BIP 341 specifies that signaling occurs on bit 2.

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


text:
How can I generate expiring transactions?
I want to generate a transaction that spends funds to a wallet controlled by a third party,  but for this transaction to only remain valid for a certain window of time. This could mean a transaction that excecutes successfully if it is accepted within the next three blocks but fails if it is executed after the next three blocks. Let's assume that information such as block height information is known.
I understand that the default response is to say "Bitcoin transactions do not expire [...] so you should just give up." Any creative solution would be appreciated, consider this a challenge if need be.
A few things that come to my mind that may help you deliver a solution:

Spending funds to a wallet that a third party controls is not the same thing as spending to an address that a third-party provides.

You could potentially make use of the public key to generate an address with weirdness or make use of bitcoin script.

You could potentially make use of two-way communication between the sender and reciever here.

Related: https://bitcoin.stackexchange.com/a/116927/5406

It is not possible to make a transaction which is valid in the past invalid in the future (except in specific cases around soft fork activation). The best you can do is to make it more likely that a conflicting transaction is accepted.
What you could do is making a double spending transaction that has a timelock (so it can't be confirmed until the "expiration") and pays a higher transaction fee rate. So once the timelock is passed, the transaction becomes a RBF transaction for the original, making it much more likely to become confirmed. Once confirmed, it would cause the original to become invalid and thus "expired".

Huh. Bitcoin "stop payment".


text:
Can transactions be held for a long time without being processed?
I am learning a little bit about the bitcoin technology and I have some basic questions about its p2p and transaction processing.
First imagine that a bitcoin transaction has included a fee (maybe a high one). If a node, which can mine blocks receives it, why should it broadcast this information into the network? Wouldn't it be better for the miner just to add the transaction to the block and start mining as soon as possible without revealing this to the competition?
If this happens and the information is not propagated, it can happen that the miners who included this transaction are unlucky and can't find proof-of-work before others and the transaction gets stuck for a certain time. So my other question is: if only a part of the network knows about a transaction due to technical issues or malicious behavior, is it possible for the transaction to become stuck for quite a number of blocks before it enters into the blockchain?
Thank you!

Does this answer your question? Is it possible to use Selfish Mining to steal bitcoins?

@RedGrittyBrick it's not about selfish mining but tx propagation to miners


text:
Bitcoin mining for the regular person?
Is it feasible for a regular person to mine crypto like Bitcoin with just a couple of machines?  Or is the wear and tear to those machines coupled with the electricity costs just too much to make it a worthwhile endeavor?


text:
Same seed on multiple hardware wallets
Let's say I have two Ledger hardware wallets.  Can I use the same seed phrase on both simultaneously and be able to work with my crypto on either whenever I want having access to the same accounts?

Yes, by using the same seed phrase (and derivation path), you can have multiple instances of the same wallet. A wallet does not 'contain your bitcoin', it just contains the keys that allow you to spend your bitcoin. So you can create multiple wallets that hold those same keys, and then use any of those wallets to perform wallet functions (like sending, receiving, etc).
Keep in mind: every instance of a wallet is also increased potential for your bitcoin to be stolen/etc. Make sure that you fully trust whatever hardware/software you are entering your seed phrase into, and also make sure you keep track of and handle all instances of your wallet(s) appropriately.

This is what I was thinking but I wanted confirmation.  Thank you :)


text:
How do i properly encode and decode base58 in python?
I was following the tutorial here : https://hackernoon.com/how-to-generate-bitcoin-addresses-technical-address-generation-explanation-rus3z9e
i imported base58 to my python project :
import base58

I tried to convert the private key at the tutorial into the base58 version
privatekey = "a4f228d49910e8ecb53ba6f23f33fbfd2bad442e902ea20b8cf89c473237bf9f"

# expected : C6t2iJ7AXA2X1KQVnqw3r7NKtKaERdLnaGmbDZNqxXjk
privatekey_base58 = base58.b58encode(privatekey)

But it didn't give me the expected value like in the tutorial , instead it gives me this

How do i properly encode a string to base58 and decode base58 to original string ?

You need to convert string hex to bytes hex format before feeding it to b58encode to produce C6t2iJ7AXA2X1KQVnqw3r7NKtKaERdLnaGmbDZNqxXjk.
import base58

privatekey_base58 = base58.b58encode(bytes.fromhex(
    "a4f228d49910e8ecb53ba6f23f33fbfd2bad442e902ea20b8cf89c473237bf9f"
))

The tutorial you linked to is not accessible anymore, so I am not sure whether they talked about it there, but there are actually several steps between generation private key and conversion to Wallet Import Format (WIF). You can see more details about it at https://en.bitcoin.it/wiki/Wallet_import_format. According to the wiki page, you need to extend private key with 0x80 (for mainnet addresses). Extended private key is then passed through double sha256 to extract a checksum (first 4 bytes). Finally, extended private key and checksum are concatenated and Base58 check encoding is applied to produce WIF private key. Surprisingly enough, their tutorial does not use Base58 check encoding, but Base58 encoding.

Use b58encode_check instead of non-check version and convert your hex to binary before passing it to the library.

And how do i decode base58 string ? Should i turn the string to binary too before decoding ?

No, but to decode convert the decode result to hex because it'll be in binary

help it doesnt work , i tried base58.b58encode_check(bin(int("0x000c2c910a661178ef63e276dd0e239883b862f58cc3c0439f", 16))) but it doesnt gives 127NVqnjf8gB9BFAW2dnQeM6wqmy1gbGtv like in the tutorial

Does this give you any inspiration https://stackoverflow.com/a/23565829 ?

As of Python 3.10.8
Here's how to derive the addresses from 3 randomly generated private keys from bitaddress.org.
Example Bitcoin addresses with private keys:

Private Key: L5Mssn1ANiFXuWrYpSohHfbvZzuUNZ7Px8x4vCLCFthihhEVwowM
Address: 1FbFJHvT3xE2i5TDqtyCUuCiAjVJMV9XPt
Private Key: L3jg9jj7SBfoU5qiLunjuES1f6aoSjvQMYBXHqR4b7HBv92dnHsq
Address: 1PSds68vNzCeYvJNB6axnN8VnrLSnJC6S1
Private Key: KwmT38RYZe55mM1TjY8dy41VpzerunJMoLt4Z97tF33rxHUsejLT
Address: 1GPqjz4qQxz7ZWnvSN5Gc2H5hkhd5va95i

In the shell:
pip install ecdsa base58 hashlib

In Python:
import ecdsa
import hashlib
import base58

# These are the 3 private keys in base58check encoding.
privkey_b58_1 = "L5Mssn1ANiFXuWrYpSohHfbvZzuUNZ7Px8x4vCLCFthihhEVwowM"
privkey_b58_2 = "L3jg9jj7SBfoU5qiLunjuES1f6aoSjvQMYBXHqR4b7HBv92dnHsq"
privkey_b58_3 = "KwmT38RYZe55mM1TjY8dy41VpzerunJMoLt4Z97tF33rxHUsejLT"

# Remove the \x80 version prefix and x\01 compression suffix.
privkey_bin_1 = base58.b58decode_check(privkey_b58_1.encode())[1:-1]
privkey_bin_2 = base58.b58decode_check(privkey_b58_2.encode())[1:-1]
privkey_bin_3 = base58.b58decode_check(privkey_b58_3.encode())[1:-1]

# Create signing keys using the SECP256k1 curve in ECDSA.
sk_bin_1 = ecdsa.SigningKey.from_string(privkey_bin_1, ecdsa.SECP256k1)
sk_bin_2 = ecdsa.SigningKey.from_string(privkey_bin_2, ecdsa.SECP256k1)
sk_bin_3 = ecdsa.SigningKey.from_string(privkey_bin_3, ecdsa.SECP256k1)

# Derive verifying keys from the signing keys.
vk_bin_1 = sk_bin_1.verifying_key.to_string()
vk_bin_2 = sk_bin_2.verifying_key.to_string()
vk_bin_3 = sk_bin_3.verifying_key.to_string()

# Determine if the Y value is even. This is required for compression.
vk_iseven_1 = int(vk_bin_1.hex(), base=16) % 2 == 0
vk_iseven_2 = int(vk_bin_2.hex(), base=16) % 2 == 0
vk_iseven_3 = int(vk_bin_3.hex(), base=16) % 2 == 0

# Determine the prefix for the X value based on whether the Y value is even.
vk_prefix_1 = b"\x02" if vk_iseven_1 else b"\x03"
vk_prefix_2 = b"\x02" if vk_iseven_2 else b"\x03"
vk_prefix_3 = b"\x02" if vk_iseven_3 else b"\x03"

# Extract the X value from the verifying key. X is the first 32 bytes.
vk_xval_1 = vk_bin_1[:32]
vk_xval_2 = vk_bin_2[:32]
vk_xval_3 = vk_bin_3[:32]

# Get the SHA256 hash of the X value with the even/odd prefix.
vk_sha256_1 = hashlib.sha256(vk_prefix_1 + vk_xval_1).digest()
vk_sha256_2 = hashlib.sha256(vk_prefix_2 + vk_xval_2).digest()
vk_sha256_3 = hashlib.sha256(vk_prefix_3 + vk_xval_3).digest()

# Get the RIPEMD-160 hash of the SHA256 hash, then add the address prefix.
ripemd160_1 = hashlib.new("ripemd160")
ripemd160_1.update(vk_sha256_1)
address_1 = b"\x00" + ripemd160_1.digest()

ripemd160_2 = hashlib.new("ripemd160")
ripemd160_2.update(vk_sha256_2)
address_2 = b"\x00" + ripemd160_2.digest()

ripemd160_3 = hashlib.new("ripemd160")
ripemd160_3.update(vk_sha256_3)
address_3 = b"\x00" + ripemd160_3.digest()

# Get the base58check encoding for each address.
address_b58_1 = base58.b58encode_check(address_1)
address_b58_2 = base58.b58encode_check(address_2)
address_b58_3 = base58.b58encode_check(address_3)

# Show the addresses.
for x in [address_b58_1, address_b58_2, address_b58_3]:
    print(x.decode())

# 1FbFJHvT3xE2i5TDqtyCUuCiAjVJMV9XPt
# 1PSds68vNzCeYvJNB6axnN8VnrLSnJC6S1
# 1GPqjz4qQxz7ZWnvSN5Gc2H5hkhd5va95i


text:
Bitcoin transaction validation is not based on a static pattern, but instead is achieved through the execution of a scripting language
What is static pattern and why it is not used in transaction validation  and why execution pattern is used through the scripting language i am a bit confused need a clear explanation.

What is static pattern

Each type of Bitcoin transaction has a certain pattern, the chunk of data can be broken down into pieces. The size, form and sequence of these these pieces are a pattern. Static means this pattern does not change from one transaction to another of the same type.  All transactions of the same type have the same pattern.

why it is not used in transaction validation

It is.

why execution pattern is used through the scripting language

Bitcoin's scripting language allows for flexibility in creating new types of transactions. Each different script is a rule that specifies how the network can recognise that someone is entitled to spend money in a transaction output. Nodes check that scripts are well-formed and that people spending outputs have provided data that satisfies that script (e.g. proving they know a secret number called a private-key). All this checking is called validation (which is very different from confirmation - people sometimes get confused about this).


text:
Can I create a P2PK tx?
Is it still possible to send to a pub key directly?
How would I construct such a tx in raw hex, and would the mempool accept it?
Thanks

It is still possible, and quite a few p2pk outputs still show up in the blockchain. d3d3b3545712d2eec3c0fcc35c0e34cf34b6ae92ca86c1d5e6cc5b3d59692273 is an example of a transaction from this year that contains 10 p2pk outputs.
If you can find a wallet that still supports p2pk, that would probably be your best option for sending such a transaction. But basically, this is the raw hex for the transaction referenced above. The first ten outputs are all p2pk.
01000000

01

26708707719ad3e0fc9412efcbe92c2d15ee01e9ad6fce8538cc738624208350
0b000000
6a4730440220118a0f02c2080f0a6a0f5e58b17f6d12fef4d32277fc816603557767b27bb2be02205ca1e44cefe79580330271b764ba1b1798048af8872eaaed1ce0138edaa0f0d80121037c394f2adceafcdc5e429218f410f164a80918a185becf7cb314b120dd0cb740
ffffffff

0b

8813000000000000
2321037c394f2adceafcdc5e429218f410f164a80918a185becf7cb314b120dd0cb740ac

8813000000000000
2321037c394f2adceafcdc5e429218f410f164a80918a185becf7cb314b120dd0cb740ac

8813000000000000
2321037c394f2adceafcdc5e429218f410f164a80918a185becf7cb314b120dd0cb740ac

8813000000000000
2321037c394f2adceafcdc5e429218f410f164a80918a185becf7cb314b120dd0cb740ac

8813000000000000
2321037c394f2adceafcdc5e429218f410f164a80918a185becf7cb314b120dd0cb740ac

8813000000000000
2321037c394f2adceafcdc5e429218f410f164a80918a185becf7cb314b120dd0cb740ac

8813000000000000
2321037c394f2adceafcdc5e429218f410f164a80918a185becf7cb314b120dd0cb740ac

8813000000000000
2321037c394f2adceafcdc5e429218f410f164a80918a185becf7cb314b120dd0cb740ac

8813000000000000
2321037c394f2adceafcdc5e429218f410f164a80918a185becf7cb314b120dd0cb740ac

8813000000000000
2321037c394f2adceafcdc5e429218f410f164a80918a185becf7cb314b120dd0cb740ac

11b7190000000000
1976a9147ca88db7ef2b1a164fe5f5be3a2c94265d9e002688ac

00000000

If it is formatted correctly, the mempool would probably accept it. This transaction type is not used as often anymore, but there are still hundreds of them that are accepted.


text:
Is there some way to use Bitcoin Core to "batch-extract" CSV data from a bunch of wallet.dats?
I have a ton of old backed up wallet.dat files with zero BTC in them, but (probably) the records of my old Bitcoin transactions in them, which I'm trying to extract as CSV data.
I already looked at the command line options and found no instance of "extract" or "CSV", but is there some way to do something simple on the command line such as:
bitcoincore.exe --extract-csv-transactions-from-wallet=wallet1.dat -o wallet1.csv
bitcoincore.exe --extract-csv-transactions-from-wallet=wallet2.dat -o wallet2.csv
bitcoincore.exe --extract-csv-transactions-from-wallet=wallet3.dat -o wallet3.csv
...

?
My current method of manually loading four of them in at a time, manually adding them to the config file and starting Bitcoin Core, is a nightmare. It has been saying "Rescanning" for an hour now with no sign of it ever stopping and that's just for the first batch of four wallets... out of tons.
This is going to be a multi-weeker nightmare project, isn't it?

I would instead look at other utilities or libraries such as btcutils or pywallet.

Does this answer your question? Dumping private keys from wallet.dat from command line (pywallet.py alternatives) (note the answers cover dumping all wallet data, not just keys)

@RedGrittyBrick I don't trust anything but Bitcoin Core. And I'm not trying to dump any private keys.

Why does it have to "Rescan"? Can't this be skipped?

From elsewhere: 'The wallet file stores up to which block it has "seen" the chain. At
startup, an automatic rescan happens for exactly the missing part.'  I guess this is because the prime purpose of Bitcoin core is to function as a wallet, not to export CSV data from multiple wallet.dat files. It is presumably optimised for the former task, not the latter.

You can load wallets without restarting Bitcoin Core by using the loadwallet and unloadwallet RPCs. You can use the listtransactions RPC to get all of the transactions in JSON form and convert that into whatever format you want.

Rescan is required in order for the wallets to have gotten any transactions that were made during the time the wallet was offline. A workaround to avoid that is to remove all blockchain data and then start Bitcoin Core with -connect=0. This will force it to not make any network connections so that it doesn't sync the blockchain, and hence any loaded wallets will not have anything to rescan. However this may miss some transactions, and some functionality may be disabled as it will not be synced.

Some reviewers supposed that this is a duplicate of a question about getting the private keys, but that is not the asker's goal.  @AndrewChow provided good and helpful answers which the asker could work into a helpful answer to his own question.  I vote to keep it open in the hope that one of them will do that.

There is no way to export all of the transactions to a csv. However you can get the transaction in JSON using the listtransactions RPC.
Bitcoin Core will always rescan when a wallet is loaded because it must be sure that it has seen all of the wallet's transactions so that the user does not appear to have lost any funds. For old wallets, it ends up having to rescan a significant portion of the blockchain. There is no way to disable this behavior.
However, if you are sure that no rescan is necessary, it is possible to force Bitcoin Core to not have any blockchain data so that the rescan completes quickly and does not do anything. You can do this by removing all blockchain data from the datadir and starting Bitcoin Core with -connect=0. This will force Bitcoin Core to not connect to the network so it will not be able to download the blockchain. Additionally, because you have removed any previous blockchain data, Bitcoin Core will be reset to the genesis block as the only block in the blockchain. Loading a wallet at this point will result in no rescan.
Lastly, to speed things up, instead of constantly stopping and starting Bitcoin Core to load new wallets, you can use the loadwallet RPC to load a wallet, and unloadwallet to unload the wallet when you are done with it.
Some python-like pseudocode that shows what this would look like:
for wallet in wallets:
    rpc.loadwallet(wallet)
    print(rpc.listtransactions())
    rpc.unloadwallet(wallet)


text:
What is the correct way to calculate timestamp for a Block(125552)?
I am just learning mining process.
Today I learned that we have to find nonce for given block header.
And for block header we need timestamp in UTC
I took the timestamp data from below link of 125552 block
https://www.blockchain.com/btc/block/00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d
And used the below linke to convert it from UTC to seconds
https://www.epochconverter.com/
And I am getting 1305998760
But according to the example in the below link its 1305998791
https://en.bitcoin.it/wiki/Block_hashing_algorithm
And what is endian in the above link
Can anyone please help me what am I missing
Thanks in advance

Displayed precision ≠ Stored precision
Note that the block timestamp is stored as a 4-byte number of seconds since 1970-01-01T00:00 UTC (the Unix epoch). However Blockchain.com show this in a more human readable form rounded or truncated to the nearest minute (2011-05-21 18:26). So if you convert that human readable time back to an integer, you will get a value that is different by a number of seconds between 0 and 59
Endianness
See Wikipedia article on endianness. There are two possible orderings of the bytes of a multi-byte integer. You can start with least significant byte (LSB) or with most significant byte (MSB). Internet standard "Network Order" is big-endian. X86 architecture computers use little-endian byte-order. Some other hardware architectures use big-endian byte-order.
Bitcoin
Bitcoin mostly uses little endian. Even for data transmitted over the Internet. See documentation for block hashing. Note that it talks about the use of big-endian for hexadecimal display of values and little-endian for storage.
Timestamps are not accurate
See Why don't the timestamps in the block chain always increase?

A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you.

So don't be surprised if later blocks sometimes have earlier timestamps. Children can be older than their parents.

Thank you for the info. can you help me where can i get the correct time stamp with seconds for any block

E.g. Blockstream gives seconds.  Remember that block timestamps are not meant to be an accurate representation of the time a block was created, they can vary from actual time by an hour or more. Miners can tweak them as an extra nonce. Miners don't have to keep accurate time.

wow so timestamp is also a parameter that miners have the control? and it can be used as extra nonce? that's interesting

Thank you i again worked considering the timestamp with including seconds
and i got blockheader like
0100000081cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122bc7f5d74df2b9441a42a14695
same as the 125552 showed in link
https://en.bitcoin.it/wiki/Block_hashing_algorithm
when i applied double hash to it using https://xorbin.com/tools/sha256-hash-calculator
i am not getting same result
can you please help me

This website works best when you ask one question at a time so It would probably best if you ask a new question showing exactly what you want to do, how you did the calculations and exactly how the results differ from what you expected. In your new question you can include a link back to this one if you think it will help people understand your new question.

Yeah i think you correct sir, Thank you i will ask a new questions


text:
Version 0.10.0 2009-2015
I downloaded Bitcoin Core Version 0.10.0 back in 2000 something.  I bought $ 100back then.  I forgot about it and I found the program, downloaded and its been syncing for 1 week.

Does this answer your question? Sync with bitcoin-qt very slow (0,01%). Time taken to sync can easily exceed a week. It depends in part on your PC specification and also on your Internet connection speed.

You should run updated versions for security reasons.


text:
Is it normal the Trader ask money to withdraw the profits
The investor asking $2000 dollars fee to withdraw my profits.When I refused to pay them from couple of days then they said other way to withdraw is via Trust Wallet. Trader asked to download the app & send them the screenshot.I really don’t have any idea on this and how I can withdraw my investments. How to deal with this senario. Please help how to proceed and withdraw.
Thanks

What is Trust Wallet? Did "investor"/"Trader" gave you a link to it?

No, asked to download from App.

I am certain you are being scammed. The profits are fictional. There is no way to get back any money you invested. Any attempt to get your money back will just lose more money. Report the "investor" to your local police.


text:
Can we consider all these satoshi-era wallet being re-activated a good or bad thing for Bitcoin?
More and more I am seeing news about addresses that was dormant for around 10 years being (re)activated.
Is it positive or negative for bitcoin in the long run ?
Also, how many of those dormant addresses still exist ?

Q1 is opinion and off-topic. Q2 answered elsewhere, example

Q1 is not offtopic and elsewhere in q2 is not a correct approach.


text:
Why isn't it safe to run bitcoin core on a laptop?
I have read on some twitter posts that it was not safe to run bitcoin core on a laptop. That it was better to run it on a rasberry pie for example.
What are the main reasons this is not safe? How storing your btc on a laptop is more dangerous that storing them on a rasberry or another hardware (which most are not open source) ?
Thanks.

Can you link to where you read this? It may make sense with a bit more context.

Yes It was a debate around Coldcard: https://twitter.com/silentlink1/status/1455323246983852032?s=20.

I have no clue where that's coming from. You're probably better off debating this on twitter than here...

Ok nothing to worry then. There is no more risks running bitcoin core on a laptop with an unix distro that on a rasberry if I understand well.


text:
EstimateFee - Invalid Length Destination Key
Background
I have setup a regnet test network with two LND nodes. One to send money and the second (lnd2) to generate invoices on. I am writing code to simulate a mobile app. I'm currently trying to calculate the fee to pay an invoice and attempting to call /v2/router/route/estimatefee
I'm getting this error when I execute the code below:
{'code': 2, 'message': 'invalid length destination key', 'details': []}
I'll admit the byte to raw to decode has me a bit confused.  But I'm not sure I'm feeding the correct address.
import base64
import codecs
import json
import requests
r_hash = 'UOpjz7mxf2r5gv7MNkoEBZL84CwM3CjJI8TFfPfkInA='
payment_alias = b'02183a81bfb5ce3a221d'
payment_destination = '02183a81bfb5ce3a221d15ffa67c2a1d796746ac89f1c81850577b52ec1633e339'

payment_addr = "iDPo2lElCqV9qx0GMB0SMfraU9CGOoGU4xSTNN9hYoM="
qrinvoice = "lnbcrt7u1psa67zapp52r4x8naek9lk47vzlmxrvjsyqkf0ecpvpnwz3jfrcnzhealyyfcqdqlw3jhxapqw35xjueqda6hggr5wfujqdqcqzpgxqyz5vqsp53qe73kj3y5922ldtr5rrq8gjx8ad557sscagr98rzjfnfhmpv2ps9qyyssq2sn9wg448t083sxqzsckc2l3jt26k5zy5l8g4ufeqgg53kxhule3p7dcwmd77v324jmd4z8r87tx9fal3a47vv344qsx03pjy43m2ysqy58usq"

lnd2 = "10.142.0.21:8180"
lnd1 = "10.142.0.21:8080"

url = 'https://{}/v2/router/route/estimatefee'.format(lnd1)
data = {
             'dest': base64.b64encode(payment_alias).decode(),
             'amt_sat': 200
         }

cert_path = './tls.cert'

macaroonhex = <a macaroon>
headers = {'Grpc-Metadata-macaroon': macaroonhex}

r = requests.post(url, data=json.dumps(
    data), headers=headers, verify=cert_path)

print(r.json())

Your environment
Two LND nodes on Debian 10.
Linux #1 SMP Debian 4.19.208-1 (2021-09-29) x86_64 GNU/Linux
LND "version": "0.14.0-beta commit=v0.14.0-beta",
bitcoind version: 220000
Steps to reproduce
Create an invoice.
Run above code
Expected behaviour
I should get a fee back but just get error.

According to this github answer it looks your encoding method is not quite right, dest should be:
 data = {
      'dest': base64.b64encode(bytes.fromhex(payment_destination)).decode('utf-8'),
      'amt_sat': "200"
 }


text:
Lightning On Chain Wallet - How do I get my Bitcoin back out
I've setup a Lightning Network Node.  Funded the wallet.  Played with channels and sent a few payments back and forth with a mobile wallet.  I recorded all the pass phrases when I make the Lightning wallet on the Lightning node.  But it didn't seem the private key was exposed to me while I set things up.
I've closed the channels and all my Bitcoin is now back in my on chain LND wallet.   How do I extract the Bitcoin out and send to my normal Bitcoin wallet.
Right now I'm beginning to wonder if Bitcoin moved to lightning network has to stay in the lightning network.
Can anyone "validate" if that is the case?
Thank you for your time and knowledge!!

I'm beginning to wonder if Bitcoin moved to lightning network has to stay in the lightning network.

When you close the channel, the remaining committed Bitcoin amounts are returned in an on-chain transaction.

Thank you for you response.  Yes.  They are returned to your lightning on chain wallet.   But how do you transfer them to a non-lightning on chain wallet.   I did not see any keys for transfe.

Found it.
lightning-cli withdraw
https://lightning.readthedocs.io/lightning-withdraw.7.html
withdraws and sends wallet funds to specified bitcoin address.


text:
Basic Lightning Network Questions re: fees, channel management
Background
Long time Bitcoin holder and user, but exclusively on-chain. I'm completely new to the Lightning Network.
While waiting for my Mastering Lightning Network book to arrive, I'm just trying to pick up the basics via podcasts and articles. A particular podcast I listened to yesterday was one entitled Exploring Bitcoin's Lightning Network.
At one point the chick hosting the podcast asked something along the lines of, "What if I don't want to send Bitcoin? What if I just want to receive it?" It's a good question because that's the position a lot of vendors will be in. To which one of the experts replied something along the lines of: if you want the wallet provider to establish a channel with you, they'll charge a 1% commission. I've found a similar thread on Reddit complaining about this high wallet fee so I'd like to get to the bottom of it.
Specific Questions
A customer owes me 1 BTC for services rendered. We've never done business before. As I understand it, he opens a "channel" to me, funds it with 1 BTC, and executes the transaction. Opening that channel costs him an on-chain transaction fee so he hasn't really saved any money yet by using Lightning Network.
Now I want to spend 2 BTC to buy a gold-plated figurine of Dennis Rodman. If I understand the podcast and articles correctly, I can't use the 1 BTC received from my customer to contribute toward that purchase. That 1 BTC is all locked up. Unless I close that channel, the only thing I can do is send it back to my customer, or some other third party downstream from him, and only if the amount is less than 1 BTC, and only if every channel between the source and destination have 1 BTC of capacity. Is this correct?
If this is correct, then it means to make LN viable, pretty much everyone needs to be connected to well-connected hubs, as opposed to just creating a bunch of highly specific customer-to-vendor channels. But that's where I get lost.
I, as the service provider, would expect to open a channel to the hub with zero BTC. After all, I don't owe anyone anything. My goal is to receive. The hub presumably wouldn't be responsible for funding the channel either (would they?) since they have no part in the transaction. But an empty channel can't conduct business.
So how does this work? It sounds almost like I'd have to front an amount of BTC equal to what I expect to receive from my customers over the long-term, fund the channel to the hub with it, keeping the BTC on the remote side of the channel which incurs counterparty risk, and then pay a fee to the hub/wallet 1% for the privilege. I hope I'm missing something. Is this indeed the way things work? If not, how should a vendor coordinate with his customers who want to pay via LN? How should the channels be established and funded, preferably in a way that bypasses the high wallet fees mentioned above?

he opens a "channel" to me, funds it with 1 BTC, and executes the transaction. Opening that channel costs him an on-chain transaction fee so he hasn't really saved any money yet by using Lightning Network

Right, lightning channels are interesting in part because they allow users to send a huge number of payments over time, effectively amortizing the on-chain transaction fees over that huge number of payments. Opening a channel to make a single payment is wasteful.

I can't use the 1 BTC received from my customer to contribute toward that purchase. That 1 BTC is all locked up. Unless I close that channel, the only thing I can do is send it back to my customer, or some other third party downstream from him, and only if the amount is less than 1 BTC, and only if every channel between the source and destination have 1 BTC of capacity. Is this correct?

Not quite correct, for example 'multi path payments' allow a user to send a payment using the capacity in several different channels at once, atomically. So you could perhaps use some of that 1BTC channel to complete the payment, but of course you'll need other channels with capacity as well, and your node will need to find routes for each part of the payment.

then it means to make LN viable, pretty much everyone needs to be connected to well-connected hubs, as opposed to just creating a bunch of highly specific customer-to-vendor channels

The lightning network is constantly evolving, so it is tough to give a definitive answer for what it might look like in the future, but there seems to be some consensus around the idea that it is a good idea to look for certain attributes in a channel partner. Good connectivity to the network graph, good liquidity, and good uptime are examples of attributes you may look for when selecting someone to open a channel with. You don't necessarily even need to open channels directly to your customer/vendor, though in some cases it certainly may make sense to.

I, as the service provider, would expect to open a channel to the hub with zero BTC. After all, I don't owe anyone anything. My goal is to receive. The hub presumably wouldn't be responsible for funding the channel either (would they?) since they have no part in the transaction

There are several ideas already implemented to deal with this, for example check out lightning pools, which is a market that allows you to rent incoming liquidity from other lightning users. There are also several service providers operating in the space that offer this inbound liquidity rental service as well.

Looks like I'm neither allowed to upvote, nor mark as a correct answer (I create a new account for each StackExchange question; restriction has something to do with account age) but just want to thank you for the reply. This has pointed me in the right direction. Multipath payments sounds awesome and changes the whole ballgame. Love it. Looks like I've got some reading to do! Thanks again.


text:
2009-2011 digital wallets
Is there away to find digital wallets online from 2009-2011. With the wallet ID - 12 words - 64 private n public - bit address - hash - signature. - my friend who died left me to remember before he died?
Also how do I find old e-mail addresses I had in 2009-2011 because he also sent me all the info and scan to the email?

What wallets were available in 2009-2011

Is there away to find digital wallets online from 2009-2011.

In general no.
You have to have some idea of the particular wallet software that was downloaded onto a PC or phone and access to the device or to backups of the device or backups of it's recovery-phrase or private-keys. Alternatively you need to know a company name and account details for an online account if a custodial account was used instead of a self-managed wallet.
See I have lost my wallet, what can I do?

With the wallet ID - 12 words

I think only Blockchain.com use the term "Wallet-ID".
See how to recover funds from blockchain

Thank you, what were the digital wallets between 2009-2011. I have every character for everything. Privat, public, bit address, wallet Id, 12 word phrase .
Know how to find old email accounts? I Need to get into old email account he sent me.


text:
How do segwit nodes behave when they receive a transaction between two legacy nodes?
Segwit nodes know about the move of the witnesses to another part of the transaction block.
What would happen when they receive a transaction between two legacy nodes, knowing that they will build it following the "old" format, with a txid.
While segwit nodes are looking for a wtxid and witnesses (scriptsig and redeem script) being on another place.
Also, how would the miners consider this particular transaction, currently ?

Segwit did not change the rules for existing output types. The non-segwit standard output types P2PKH (Pay to Public Key Hash) and P2SH (Pay to Script Hash) still work exactly as they always have. Legacy nodes that don't understand segwit will only create addresses for non-segwit output types, and thus any transactions created by legacy nodes will never include any witness data.
Naturally, the more modern segwit nodes are backwards-compatible and can read non-segwit transactions just fine. Only transactions that spend segwit outputs include witness data.

Segwit nodes can recognise legacy transaction types and will handle them in the traditional way.
A legacy node would create a transaction that omits the optional segwit flag. When this transaction data is received by a segwit node, it can see that the segwit flag is not present and therefore knows to treat it using the old rules.
See What are the parts of a Bitcoin transaction in segwit format? for details of Segwit flag.

Ok so Segwit nodes are not capable of fighting against transaction malleability in this case, as they are still judging by the old rules ?

Yes, only transactions that solely spend segwit outputs are covered by segwit's malleability protections. Inputs which spend legacy outputs do not have their behavior modified.

But it seems like wtxids are also malleable before the transaction confirmation, according to this: https://bitcoin.stackexchange.com/questions/83677/why-is-the-wtxid-considered-malleable.


text:
What determines the size of a hash during mining?
I have been struggling with this quite a bit. From what I understand is that a miner generates nonces to find a nonce that is smaller than the target hash. However, how does one determine the size of that nonce/hash? Does every digit has a different size or how should I interpret this?

From what I understand is that a miner generates nonces to find a nonce that is smaller than the target hash.

No a miner repeatedly assembles data and chooses a value for one datum called a nonce, then calculates the hash of this data (including the nonce). The miner repeats this until the calculated hash, not the nonce, is smaller than the target value.

However, how does one determine the size of that nonce/hash?

The hash is a number. You can compare numbers numerically to see which is larger. For example, 52 is smaller than 57. The original code was
if (hash <= hashTarget)

See How does solving a block work in relation to the first letter/number after the 0's?

Okay, so the nonce is hashed into the final hash? So for instance, the hash of block 708493 is 00000000000000000004c8d2e38f9e9dc89c16948a05db243207745e86619e8e which has the nonce of 2,905,666,658.
https://www.blockchain.com/btc/block/00000000000000000004c8d2e38f9e9dc89c16948a05db243207745e86619e8e

@lodeboon the block header is the part of the block that is hashed, and the nonce is part of the block header. The value of the nonce doesn't matter in regards to the hash target though, only the value of the hash (the output) does.


text:
How can a block validate a merkle-root if it is all hashed?
I am trying to understand how another block validates the transactions through the merkle root. Shouldn't it be impossible to know what hashes the merkle root is hashed from because you can't reverse it?
For instance, if there are 4 transactions. 0 and 1 are hashed together, 2 and 3 are hashed together and combining these together they are the merkle root. Yet, due to it all being hashed, how can another block or someone validate transaction 2?

When validating a block, the verifier has to know all the transactions in full.
So they can just recompute the Merkle root from the transaction hashes, and compare it with the one stored in the block header.

Hi Pieter,
Thanks for answering.
So when a block gets confirmed/validated, is it the miner that checks the transactions, rather than next block? Because the block itself won't hold all the transactions from the previous block.

When verifying/mining a block, you check all the transactions in the block itself. The transactions from previous blocks have already been verified in the past.


text:
Coinbase to Blockchain Transaction
Hello everyone!

Recently i received a cryptocurrency to my Blockchain Wallet.

The Bitcoin was sent from Coinbase to my address - I waited for about an hour.
And i don't see the transaction and the funds are not updating.
What could be the problem?
I know, that Coinbase has some delay, before authorizing the transaction.

Thanks!

Does this answer your question? Coinbase to Block Chain Transfer Delay

Did you set up your wallet yourself? Blockchain wallet's are often used by scammers, because it's easy to set up watch-only wallets where you are actually seeing funds controlled by someone else. If you did not set up your wallet yourself, you should check whether this is the case.
Otherwise, check on a block explorer whether the transaction went to the address you expected and has actually been confirmed. If it's just not showing up on your blockchain wallet, you may want to find some support articles on "How to rescan".

I've sent the default wallet address, which is "bitcoinwallet".
The one, automatically generated by Blockchain upon the creation of the account.
I've examined my address in Explorer, but i can't see anything in there - transaction, nor the funds are updating.
[EDIT: What other company do you recommend for any future use, if i switch to something else in the future?]

If the funds have actually not been sent, it sounds like the problem is on Coinbase's end and you should contact their customer support.


text:
Does Bitcoin Core 0.21.1 support taproot?
Now the node use Bitcoin Core 0.21.1.

When wondering if version X of software Y supports feature Z, I find it useful to search for "release notes" Y X
https://bitcoin.org/en/releases/0.21.1/

Notable changes
Taproot Soft Fork
Included in this release are the mainnet and testnet activation parameters for the taproot soft fork (BIP341) which also adds support for schnorr signatures (BIP340) and tapscript (BIP342).
If activated, these improvements will allow users of single-signature scripts, multisignature scripts, and complex contracts to all use identical-appearing commitments that enhance their privacy and the fungibility of all bitcoins. Spenders will enjoy lower fees and the ability to resolve many multisig scripts and complex contracts with the same efficiency, low fees, and large anonymity set as single-sig users. Taproot and schnorr also include efficiency improvements for full nodes such as the ability to batch signature verification. Together, the improvements lay the groundwork for future potential upgrades that may improve efficiency, privacy, and fungibility further.
Activation for taproot is being managed using a variation of BIP9 versionbits called Speedy Trial (described in BIP341). Taproot’s versionbit is bit 2, and nodes will begin tracking which blocks signal support for taproot at the beginning of the first retarget period after taproot’s start date of 24 April 2021. If 90% of blocks within a 2,016-block retarget period (about two weeks) signal support for taproot prior to the first retarget period beginning after the time of 11 August 2021, the soft fork will be locked in, and taproot will then be active as of block 709632 (expected in early or mid November).
Should taproot not be locked in via Speedy Trial activation, it is expected that a follow-up activation mechanism will be deployed, with changes to address the reasons the Speedy Trial method failed.
This release includes the ability to pay taproot addresses, although payments to such addresses are not secure until taproot activates. It also includes the ability to relay and mine taproot transactions after activation. Beyond those two basic capabilities, this release does not include any code that allows anyone to directly use taproot. The addition of taproot-related features to Bitcoin Core’s wallet is expected in later releases once taproot activation is assured.
All users, businesses, and miners are encouraged to upgrade to this release (or a subsequent compatible release) unless they object to activation of taproot. If taproot is locked in, then upgrading before block 709632 is highly recommended to help enforce taproot’s new rules and to avoid the unlikely case of seeing falsely confirmed transactions.
...

(my emphasis)
Sometimes I have to look at older release notes too, or other forms of documentation. But, as you can see above, this approach is fruitful.

Note that 0.21.1 does not contain any taproot wallet support, so it cannot construct taproot addresses or spend them. That (rudimentary) functionality was added in 22.0 and will likely be expanded to be far more user friendly in 23.0.


text:
Flag -deprecatedrpc=addressess - Bitcoin core
How long do we will have the -deprecatedrpc=addressess flag for Bitcoin core. Is it just for the v22.0 or will it be available for all minor and patch releases until v23.0?

Generally, deprecated RPCs are available for one major release. That would mean this specific one will not be present in Bitcoin Core 23.0 anymore, but will be in any 22.x releases.

Thank you so much, Pieter!


text:
Replicate bitcoin core for backup
I want to know if possible to have the same bitcoin core and his same wallet running at the same time in two different machines, can I use the same RPC user/pass, I have o machine running but I want to have a backup running in case the main is offline then I can switch to the second one and can send/receive bitcoins in the same wallet is used by both, that's possible? how can I do that? I will appreciate your help. regards.

The source of truth will always be the blockchain, so I think you just need to run your software on two different machines, with both of them referring to the same wallet, address, etc. An action by one should be reflected by the other.


text:
Send transaction with 2 inputs and 2 outputs using Blockcypher
I'm using a node.js client of Blockcypher in order to broadcast a Bitcoin transaction.
My code:
const originWalletBalance = getBalance(originAddress)
const fee = calculateFee()
const txBody = {
        fees: fee,
        inputs: [{ addresses: [originAddress] }],
        outputs: [
          { addresses: [targetAddress], value: amountToSend }
        ]
      }

    //@see https://www.blockcypher.com/dev/bitcoin/#creating-transactions

    const txSkeleton = await this.bcapi.newTX(body)
    // build signer from WIF
    let keys: ECPair = ECPair.fromWIF(signingKey)
    //signing the transaction
    let tmptx = txSkeleton
    tmptx.pubkeys = []
    const SIGHASH_ALL = 0x01
    tmptx["signatures"] = tmptx["tosign"].map((tosign) => {
      tmptx["pubkeys"].push(keys.publicKey.toString("hex"))
      return bitcoin.script.signature.encode(
        keys.sign(Buffer.from(tosign, "hex")),
        SIGHASH_ALL
      ).toString("hex")
    })
    //broadcast tx
    return await this.bcapi.sendTX(tmptx)

Where the balance of the origin wallet is 190689, the amount to send is 74500, the fee is 25500.
txSkeleton is crated with 2 inputs and 2 outputs (one for the target address and the change to the origin address, as expected):

It all seem right, but I'm getting the following errors:
"error": "Error building input: Error generating scriptsig when building transaction: Invalid signature: Non-canonical signature: wrong length marker."
"error": "Error building input: Error generating scriptsig when building transaction: Invalid signature: Non-canonical signature: wrong length marker."
"error": "Not enough funds in 2 inputs to pay for 2 outputs, missing -74500."
"error": "Not enough funds in 2 inputs to pay for 2 outputs, missing -122500."
"error": "Not enough funds after fees in 0 inputs to pay for 2 outputs, missing -148000."

Any idea what am I doing wrong here?


text:
Transfer all funds to another wallet with node.js
I have a segwit address (starts with bc...) and its private key, that holds some BTC value.
Using node.js I would like to transfer all my funds to another address.
This should be pretty straight forward - create a transaction  and broadcast to the network.
I've found a few libraries that does it but for some reason was not able to successfully execute.
2 questions:

Must I have a running Bitcoin node for that or is there some "public" node which I can work with?
Is there a working code reference for this simple transaction? Suppose that my wallet has 0.001 (unspent) BTC, how do I transfer this amount to another address? How does the fee calculation come to place?

Regarding first question,
No, you don't have to run your own node. What I know is blockstream esplora provides public API with documentation you can work with.
Regarding second question,
It depends on what kind of segwit address(p2wpkh, p2wsh, p2tr) it is, but I guess what you want to spend would be the most common segwit transaction, which is p2wpkh(single signature with public key).
For p2wpkh segwit spend, you can refer below code working for nodejs, which you can find here, too.
import * as bitcoin from 'bitcoin-sdk-js';

const privkey =
  'e6c58327b4bf1314296bba7adb66f94c36ea5611ac07830c229aa7ee6f9caac3';
const toAddress = 'tb1qmjqyknun9umlwlle5nuy8jz9ms7v85cp7k2nfe';
const toValue = 300000; // unit is satoshi
const txHash =
  '8bcd197873dbff5cc67cb3e0b1cbbdf097c7af94b0e9365adecb424e408294bf';
const inputValue = 310981; // fee is input value - total value

const tx = new bitcoin.Transaction();

await tx.addInput({
  txHash: txHash,
  index: n, // it should be vout of utxo, index of utxo in transation
  value: inputValue,
});
await tx.addOutput({
  address: toAddress,
  value: toValue,
});
await tx.signInput(privkey, 0);

const txHex = await tx.getSignedHex();

For other type of segwit address, it really varies on unlocking script, so there's not really one way solution for it.


text:
Watch incoming transaction with node.js
I would like to watch a set of Bitcoin addresses and be able to execute some logic as they receive a payment.
According to this answer it can be done using blockchain.info:
const Socket = require('blockchain.info/Socket');
const mySocket = new Socket();
mySocket.onTransaction(function() {
  console.log(arguments);
});

The code works just fine and I'm getting notified about transactions, I can even filter and watch specific addresses (using an options parameter) but I'm not clear at all about the meaning of the fields.
There are multiple fields in a transaction (here is an example one below). Which fields should I inspect in order to know the target address, the amount that came in and if it is confirmed?

Which fields should I inspect in order to know the target address, the amount that came in and if it is confirmed?

The answer seems obvious, so I may be missing some aspect of your question

the target address

That would be both JSON.0.out.0.addr and JSON.0.out.1.addr plus any other JSON.0.out.*.addr
Remember that not all Bitcoin scripts can be represented as an address.

the amount ...

The corresponding value fields show the amount of Satoshi being sent to each address.

...that came in

The input amount of the transaction is provided by the sum of the  JSON.0.inputs.*.prev_out.value

and if it is confirmed?

You need to refer to other data to count confirmations. At a minimum you'd need to know the current block height and the block height of the first block containing this transaction.
I'm not  familiar with this API so can't make any suggestion. Maybe the API includes a function to which you can pass the transaction ID (JSON.0.hash) to get information about the block containing that transaction. Maybe there is an onBlock() method you can use to process block data?


text:
Creating HD wallet using Blockcypher
I'm using Blockcypher to create an HD wallet, which requires me to send extended_public_key.
How do I create the extended keys?
While generating a new address using the API I'm getting something like:
{
  "private": "696785dc619c5f493ba72aa1ded581771ac7360fcf49903a0dc96a381d460182",
  "public": "03d6ff03e21b81a7f5c7e678130845a94ba1ca15316bc0d9635c8cc3e51aa26a8a",
  "address": "bc1q446jd78q2nmpxt25puv7h8lwcwsw9dmkgf5sgp",
  "wif": "KzkbwXy4PS8mEAnZZC5LcVnhe64LCWaqUfsc4Fuj1AKak4qgBPcJ"
}

How can I use this data to create extended private and public keys?
Should I use a different method to generate the extended keys?

You do not use the single key pair data to create an extended public key. The single address you generated with the API is not relevant in this situation.  The HD Wallet Endpoint is a feature where you can provide your own extended public key from an external wallet (not blockcyphers).
Related question/answer on extended public keys: How to generate a new extended public key (xpub)?


text:
Stumped on finding checksum for 12 word Bip39 mnemonic
I read Pseudo code to find Bip39 checksum? and followed the steps outlined by the answer and arrived at the correct checksum.
But when I went to try it on a 128 bit entropy that were all 1s: 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
I got the wrong checksum (checking with https://iancoleman.io/bip39/ and https://learnmeabitcoin.com/technical/mnemonic).
On ubuntu 20.04, I ran:
echo "11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111" | shasum -a 256 -b

and my hash was
951354377d60faddeaf27bbc864565a2fef8db8da4b4bdf5c21a2c6f6ac9a06f
so, reading from the Bip39 spec (https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#Generating_the_mnemonic), it says "A checksum is generated by taking the first ENT / 32 bits of its SHA256 hash. This checksum is appended to the end of the initial entropy."
So I took the first four bits of the hash, 9 in hex is 1001, and appended it to the 128 1s so now the checksum word should be 11111111001, and checking it on https://github.com/hatgit/BIP39-wordlist-printable-en/blob/master/BIP39-en-printable.txt tells me that my checksum word should be "you".
Therefore, shouldn't my 12 word mnemonic now be:
zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo you
?
But importing the 128 1s as entropy into https://iancoleman.io/bip39/ (checking the box for "Show entropy details"), tells me my last word should be "wrong", so "you" is incorrect.
Can someone please point out what I'm doing wrong?  This is driving me a little crazy.  Thanks!

To read a string of bits with shasum you need to use -0, not -b:
echo "11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111" | shasum -a 256 -0

The hash comes out as 5ac6a5945f16500911219129984ba8b387a06f24fe383ce4e81a73294065461b which indeed makes the last word "wrong".

Thanks!  So this means that chytrik (answering https://bitcoin.stackexchange.com/questions/99765/pseudo-code-to-find-bip39-checksum?rq=1), was using the wrong command line flags for shasum but got the correct first four bits, he got 3043b02ceb37bb00ab48c91f76bb23d487e1ec822c90e1575967e8838a655f7c when he should have gotten 3beeaf4009651c2fdcf083ddc2ae8f224e74f1adc40bbc1783ebf4bac56e20b7 (funny how it has beeaf in it).


text:
Identify Wallet based upon word phrase
I have my 12 words and used Trust wallet to import my (unidentified) wallet but I'm not sure of which wallet site it comes from.
Is there anyway to identify which wallet it is by my 12 words in using the Trust wallet app or by any other method?
Thank you,
Paul

We can rule out  Bitcoin-core since no version of that, to date, has any support for mnemonic phrases.
If the words come from the old Electrum wordlist or new Electrum wordlist the phrase was probably generated by Electrum.
If all twelve words come from the BIP39 word list they could have been generated by any of the wallets that support BIP-39. So there is no way to tell which wallet was used.


text:
Is it possible to use Bitcoin Script to implement a quantum-resistant locking script that would be safe to spend from?
Stewart, I., et. al. (2018). "Committing to quantum resistance: A slow defence for Bitcoin against a fast quantum computing attack" described a method by which funds could be safely moved from vulnerable locking scripts that use elliptic curve signatures:

We then propose a simple but slow commit–delay–reveal protocol, which
allows users to securely move their funds from old (non-quantum-resistant)
outputs to those adhering to a quantum-resistant digital signature scheme.
The transition protocol functions even if ECDSA has already been com-
promised. While our scheme requires modifications to the Bitcoin proto-
col, these can be implemented as a soft fork.

I wonder, is it possible, using Bitcoin Script, to implement something similar: a smart-contract that would implement a commit-delay-reveal protocol?

With current version of Bitcoin Script, that is not possible.
However, with some upgrades to Bitcoin's ScriptVM it would become possible, the prerequisites are:

A way to commit to transaction's outputs (e.g. OP_CHECKTEMPLATEVERIFY or TX introspection opcodes + OP_CAT)
A way to split & concatenate stack items (OP_CAT & OP_SPLIT)
A way for inputs to "see" each other (introspection opcodes)

With that, one could code a hash-lock but with an additional requirement: another input must reveal an aged commitment to (prevout + output contents of the TX). This is something only the person who knows the secret would be able to produce ahead of revealing the secret. Once he spends from the contract he will reveal it, but he'll already have the aged commitment and others won't be able to steal his funds.
Once posted to mempool, security would rely on the spending TX getting mined before an attacker would be able to age an alternative commitment and post an alternative spending TX.
A proof-of-concept for such a contract exists for Bitcoin Cash (BCH), a blockchain fork of Bitcoin (BTC) which upgraded the ScriptVM with the required L1 primitives in '18 (OP_CAT & OP_SPLIT) and '22 (introspection opcodes) network upgrades.
The "lock" redeem script, placed on the UTXO which would hold the balance
(note: there's no unlocking data, the input's unlocking script is just the redeem script push)
// sha256(one_time_secret + commit_script_tail)
<93168bb98087a29aeb40733ef301f907c3e4125568dd0ddf851f304b43438a14>

// slice associated input's script
OP_INPUTINDEX OP_1ADD
OP_INPUTBYTECODE
<1> OP_SPLIT
OP_SWAP OP_SPLIT
<2> OP_SPLIT
<1> OP_SPLIT
<32> OP_SPLIT
<1> OP_SPLIT
<1> OP_SPLIT

// verify sha256(one_time_secret + commit_script_tail)
<6> OP_ROLL OP_SWAP OP_CAT OP_SHA256
<6> OP_ROLL OP_EQUALVERIFY

// verify input script head format
<0x51> <0x61> OP_WITHIN OP_VERIFY
<0x51> <0x61> OP_WITHIN OP_VERIFY
OP_SIZE <32> OP_EQUALVERIFY
OP_DROP <32> OP_EQUALVERIFY
<0x4c72> OP_EQUAL

The "commit" redeem script, placed on the UTXO which would reveal the aged commitment
(note: the unlocking data is just the one_time_secret)
// sha256(associated_outpoint + one_time_secret + {first 3 outputs})
<0x8bda8c89d438b6da3fd9d289da59532736bfb23d93bba1e2e8da41c194ea43e9>
// age_reveal
<2>
// age_cleanup
<4>

OP_DEPTH <4> OP_LESSTHAN
// if no secret is provided then this is a cleanup spend
OP_IF
    // once redeem script is revealed and utxo aged beyond age_cleanup,
    // any miner can claim the dust to himself

    // verify age_cleanup
    OP_CHECKSEQUENCEVERIFY OP_DROP
    OP_2DROP
// else it is a reveal spend
OP_ELSE
    // drop age_cleanup, not needed here
    OP_DROP
    // verify age_spend
    OP_CHECKSEQUENCEVERIFY OP_DROP
    // get associated outpoint on top of stack
    OP_INPUTINDEX OP_1SUB OP_DUP
    OP_OUTPOINTTXHASH
    OP_SWAP OP_OUTPOINTINDEX OP_CAT
    // get one_time_secret on top of stack and concatenate
    OP_ROT OP_CAT
    // concatenate outputs 00 [& 01 [& 02]]
    <0> OP_OUTPUTVALUE OP_CAT
    <0> OP_OUTPUTTOKENCATEGORY OP_CAT
    <0> OP_OUTPUTTOKENCOMMITMENT OP_CAT
    <0> OP_OUTPUTTOKENAMOUNT OP_CAT
    <0> OP_OUTPUTBYTECODE OP_CAT
    OP_TXOUTPUTCOUNT <2> OP_GREATERTHANOREQUAL
    OP_IF
        <1> OP_OUTPUTVALUE OP_CAT
        <1> OP_OUTPUTTOKENCATEGORY OP_CAT
        <1> OP_OUTPUTTOKENCOMMITMENT OP_CAT
        <1> OP_OUTPUTTOKENAMOUNT OP_CAT
        <1> OP_OUTPUTBYTECODE OP_CAT
    OP_ENDIF
    OP_TXOUTPUTCOUNT <3> OP_GREATERTHANOREQUAL
    OP_IF
        <2> OP_OUTPUTVALUE OP_CAT
        <2> OP_OUTPUTTOKENCATEGORY OP_CAT
        <2> OP_OUTPUTTOKENCOMMITMENT OP_CAT
        <2> OP_OUTPUTTOKENAMOUNT OP_CAT
        <2> OP_OUTPUTBYTECODE OP_CAT
    OP_ENDIF
    OP_SHA256
    // verify against embedded pre-commitment
    OP_EQUALVERIFY
OP_ENDIF
OP_1

The contracts can be loaded into BitAuthIDE debugger using this link.
The contracts have been successfully spent from on BCH mainnet:

Fund the lock: aa1f9a7187fe096051f41e40f9133bebb843132b9fba3bdcac6625ab80f41e3a
Commit: 735c90d6e335491e883f41bd6dc987e5b923ee8cb0fcda877263d0190d93996a
Reveal & unlock: 9938671a934a85ef9877ab7df5468559966789d3eb8a1fa41463ebc9514919ce
Unusable commitment (committed to wrong output amount, scripts would still validate but such TX would violate general consensus rules): c3e385c89f450ced144b4a59c19bea24f852c5b6a08713d547f4d6257ab9caf2
Clean-up unusable commitment: 44667265d6203b1b9485635cfbf430d29bf18a4313cedf6431d435ad56febd63

This proof-of-concept was first published here

https://bitcoincashresearch.org/t/quantum-resistant-one-time-use-lock/1197


text:
How can I obtain relayed_by IP via Blockchain Data API?
I have tried to look for "relayed_by" IP address via the Blockchain Data API for a few transactions but it always returns "relayed_by":"0.0.0.0". For example,
https://blockchain.info/rawtx/b6f6991d03df0e2e04dafffcd6bc418aac66049e2cd74b80f14ac86db1e3f0da
Not sure whether I have made anything mistakenly. Any advice on alternative API for relayed by IP address please?
Thanks a lot.


text:
Looking for file 0.3.19
I am looking for this update to the Bitcoin core that Satoshi Nakamoto attached to his final message on 12.13.2010.

I did some searching:

archive.org...sf/projects
-> unfortunately these are all redirects.

archive.org...downloads.sf
-> unfortunately these were captured much too recently, when the files had already disappeared on sf.net

I assume you already found the git tag, that way you can build it your self. But I think you mean to get the actual binary built by Satoshi?
You could also try linux distributions, like debian, but I think they have build this themselves from source.
UPDATE: I found the linux version here: https://bitcoin.ninja/ancient-bitcoind/


text:
Withdrew Bitcoin from Binance to someone's wallet. They said they never received it
I sent 0.3061 BTC from Binance 4 days ago to a wallet but the recipient said they never got anything. The address is bc1qsx2w6u4vgwmadp964s66yu6nuu85cdg58a9kpf. Every blockchain site says the transaction is confirmed but they said nothing came. I've sent many times to this person in the past and never had an issue until now. They are not a scammer. This was, however the FIRST instance where I withdrew directly into the person's wallet instead of first sending it to my hot wallet(coinbase) and then sending it to their wallet. I fear that that one step I skipped caused this problem and I just want to know if there's anything we can do.

Looking this up, I can see that address bc1qsx2w6u4vgwmadp964s66yu6nuu85cdg58a9kpf was paid 0.3061 BTC in transaction a05ac2bc83db0f51433b9b96220bc7bc7e7ea75a09d6487282f6c3877d7106cf.
5 blocks later, these funds were then sent to 3KeaXjhEfHrNdcQWp8ZyFgyzD7fQ7QoXMt, etc.
So there is no doubt the payment was made. Considering the funds have already been moved, we can assume the issue is not the recipient's wallet not being properly sync'd with the network. The most obvious remaining possibility is that they are being dishonest.

This was, however the FIRST instance where I withdrew directly into the person's wallet instead of first sending it to my hot wallet(coinbase) and then sending it to their wallet. I fear that that one step I skipped caused this problem and I just want to know if there's anything we can do.

This makes no difference. The transaction was confirmed, the payment was sent. There was no issue there.


text:
Is It normal for a transaction fee to be 235% higher than the amount being sent?
I had 2 transactions for the same amount of 0.0021 btc sent out to two different btc addresses and the transaction fees were 0.0048 btc for each of the transactions.  Is this normal?  Is there any way to get my funds back on these fees because this is just ridiculous.
I am fairly new to using btc so I was unaware of the 3 different sending price ranges usually offered, I can assure you I have never sent any other way but normal. so that leaves me even more puzzled, that my fees could have actually been a lot higher.  This just doesn't sound right to me.  Am I missing something?

Did your transaction have a lot of inputs?

It isn't normal to have fees exceed the value of the amount being sent. However it is up to the sender to choose the fee, no-one else. Whichever wallet you are using may have ways to suggest fees and different ways to specify fee levels - it is up to you to make sure that you choose a fee you feel is appropriate for the transaction and that will get the transaction confirmed in a timescale that is acceptable to you.
There is no way to claim back transaction fees. Confirmed Bitcoin transactions can't be undone, reversed or picked apart.
There are cheaper ways to make Bitcoin transactions by using something like the Lightning Network - which can make a series of transactions at low cost off-chain and eventually record the final overall change of balance on the Bitcoin blockchain. But if you are fairly new to Bitcoin, you should probably take your time to thoroughly understand these off-chain systems before using them.


text:
Why does the Bitcoin network encrypt the transaction data?
The whole process of encryption sounds useless to me. Miners/validators and full nodes need to verify each transaction. They need two pieces of information:

The original transaction data
The encrypted version of its hash.

But why is encryption necessary?
The signer uses his/hers private key to encrypt the transaction data and broadcast the public key into the network, so it's fair to assume a large population of people in the network have access to their public key so everyone can decrypt the transaction data.
If everyone can verify and decrypt, why bother encrypting the transaction data in the first place?
My source is Chainlink:
https://blog.chain.link/what-is-cryptographic-truth/

Ironically, encryption is not an important part of bitcoin (?)

Transactions are not encrypted. They're just signed.
Please check the answer to the following question: How are transactions verified by nodes other than the initial receiver?


text:
Why are there transactions before full synchronization?
Do you know why there are several transactions before end of full synchronization ?

From the screenshot (in french) i think Romain is asking about why there are 70 transactions in the mempool although IBD isn't complete yet.

Yep, exactly :)

Is this syncing from scratch or catching up after being offline for some time?

It was pruned before and then I reloaded the whole blockchain.


text:
Fees file for miners?
Among its name, this file (fee_estimates.dat) should contain fees for the miner.
Am I right ?
Do you know when it will be integrated in the wallet balance ?

No, it has nothing to do with receiving fees. It is not a wallet and has nothing to do with your wallet balance.
When you make a transaction you have to pay a transaction fee. The question is, what fee should you pay? To deal with that, Bitcoin Core has a feerate estimator which looks at transactions in the mempool and how long it takes for those transactions to confirm. It then produces an estimate for various confirmation time targets. These estimates are stored in the fee_estimates.dat file.


text:
Raw data vs information encoded in OP_RETURNs
Imagine I want to fill the 80 bytes of OP_RETURN data with zeroes, so that the resulting data is 640 bits set to 0, or 160 hex digits set to 0.
The data is 640 bits but the information encoded is much smaller, and can be represented with less data. Is the P2P network optimized to relay the OP_RETURN information as "write 0 a hundred sixty times" (compressed way) or would it relay the whole string of zeroes (raw data)?
Also imagine that a whole Bitcoin block is filled with such OP_RETURNs. If the P2P network relays compressed data, and although this block is ~1MB of raw data, the actual data downloaded and stored by full/archival nodes is significantly lower. Is this hypothetically possible?

Related: https://bitcoin.stackexchange.com/q/103100/5292

The current Bitcoin P2P protocol has no concept of compression, though there have been some proposals to incorporate it. The transaction data is sent as-is.
Some earlier discussion:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015851.html for specialized compression for headers sync.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011837.html for general LZO-based compression.
Blockstream Satellite uses a custom transaction compression scheme, which I privately know was once considered to be proposed as a general P2P protocol extension, though I don't think it ever made it that far.

Where can I find these proposals?

@SonKaos999: I fed Google "bitcoin compression bip", it gave me https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011837.html and a few other relevant documents among some non-relevant stuff.

I added a few links.


text:
Is it possible to have LDK announce multiple IPv4 addresses?
I'd like to be able to accept inbound connections on multiple addresses.

Could you give us more information about what you want to do ?

Yes, you can have LDK announce your node with several network addresses.
Node announcements are broadcast by calling PeerManager::broadcast_node_announcement, which simply takes an addresses: Vec<NetAddress>, allowing to announce multiple addresses.
The given NetAddress might be an IPv4/IPv6 address, a hostname, or an onion service (V3) address.


text:
Is Curve25519 better option than Secp256k1?
Are signatures over Curve25519 better than over Secp256k1 or are there major drawbacks?
How do, for instance, EdDSA/Schnorr using Curve25519 compare with ECDSA/Schnorr for Secp256k1?

I do prefer the new phrasing, but you could have just edited the prior post instead of creating a new question. :)

Okay  I just thought it would be better this way


text:
Why is witness data downloaded during IBD in prune mode?
Why do pruned nodes download (segregated) witness data during IBD if much of that data is marked as Assumevalid?
These nodes seem to be downloading witness data just to prune it. Since we already know that such witnesses are valid, and we plan to discard all historic data but recent blocks, why not skip downloading old witnesses? It seems pointless to download witness data in this case.

Why do pruned nodes download (segregated) witness data during IBD if much of that data is marked as Assumevalid?

Good question, probably because nobody implemented it. Honestly, I had never considered this possibility.

These nodes seem to be downloading witness data just to prune it. Since we already know that such witnesses are valid, and we plan to discard all historic data but recent blocks, why not skip downloading old witnesses? It seems pointless to download witness data in this case.

You're right.
We can't just generally drop downloading witness data in full nodes, because NODE_NETWORK + NODE_WITNESS promise to other nodes the availability of all historical block and witness data.
But in the case of pruned nodes, the witness data that is both (a) before the assumevalid point and (b) sufficiently buried to be past the prune point, there is indeed little to gain from having it, as the data will be deleted soon.
One tiny change this implies is that not downloading the witness data implies the witness data cannot be validated at all, while assumevalid currently in Bitcoin Core only skips script validation. But there are other rules that involve witness data, such as resource limits and the rule that no witness data is allowed for non-witness inputs. If we treat assumevalid as also considering these pre-validated, that's a fine change though.

Yes, I think this would allow a non-trivial speed up of IBD for pruned nodes. Nowadays witness data is a big part of each block that pruned nodes are pointlessly downloading. In the extreme case of a 4MB block, a pruned node could just download a really small fraction of it. Intuitively, with Assumevalid CPU is less likely to be the bottleneck, but bandwidth and I/O, which is further reduced by downloading less data.

This was described in the "Segregated Witness Benefits" article on bitcoincore.org (from Jan 2016, prior to Segwit's activation):

Efficiency gains when not verifying signatures
Signatures for historical transactions may be less interesting than signatures for future transactions – for example, Bitcoin Core does not check signatures for transactions prior to the most recent checkpoint by default, and some SPV clients simply don’t check signatures themselves at all, trusting that has already been done by miners or other nodes. At present, however, signature data is an integral part of the transaction and must be present in order to calculate the transaction hash.
Segregating the signature data allows nodes that aren’t interested in signature data to prune it from the disk, or to avoid downloading it in the first place, saving resources.

(Emphasis mine)


text:
Message signing with airgapped wallet that doesn't support it
I need to implement message signing for various HWs, many of them support it on a firmware level, but some airgapped wallets like SeedSigner or Jade still don't. I was wondering if there's a way to trick those wallets into signing some dummy PSBT and then use it as a proof of PK ownership? If yes how do I construct that PSBT. What do I use for input's witness data and txid?


text:
I was withdrawing my bitcoins and told to contact these to these addresses am I being scammed
bitcoin:bc1qesx9ft0kjv43eagnhv0tf063pzryhec3eww3v6?amount=0.00383635 I was contacted until that it was time to withdraw my bitcoins and was told to send them to these addresses, but nothings happened. Am I being scammed?

Who contacted you? Where did that address come from?

Am I being scammed?

Yes.
Bitcoin was designed as digital cash that you can keep hold of in your own personal electronic wallet on your own personal electronic gadget (pc, phone etc) that no one else has any access to or control over.
You can however choose to give your electronic cash to someone else to look after for you, a custodian. Typically these are businesses that describe themselves as exchanges but which act like a bank in that they keep your cash in an account from which you can withdraw your cash.
In the case of a genuine Bitcoin exchange (there are also many fake ones) you typically withdraw cash by downloading a Bitcoin wallet app to your phone or PC, click the "receive money" button to get a new address in your own wallet and give that address to the exchange when it asks where you want to withdraw money to.
If you give the exchange an address created by someone else, that person is scamming you and tricking you into giving your money to them. I believe this is very clearly deceitful and that you should not trust anyone who asks you to do anything like this.
If you want to convert your digital cash into cash in a traditional currency like US dollars, Euros, etc. Some exchanges can do this for you. Again you need to be extremely careful when you choose a business to do the exchange for you. There are many tricksters and fake exchanges set up by criminals.
See

How to tell if a cryptocurrency exchange or trading platform is trustworthy?

The address you mentioned can be examined at any blockchain explorer.
For example, Blockchair says that as of 2022-01-03 11:24 UTC that address has no money (a zero "balance") and was involved in no historical transactions.
My advice is:

Dont send any money to that address.
Block all contact from the person who gave you that address.


text:
What are the limits for European banks to allow crypto trading?
What became clear last couple of years, is that European banks want to restrict crypto trading. Here are some examples:

Santander UK started to block sending money to exchanges completely.
Belgian banks block receiving money on IBAN coming from selling crypto
A Dutch bank blocked crypto transactions that are approved by an accountant
Another Dutch bank considers crypto transactions as unethical
Bank of Spain warns for blocking crypto sales

So what are the right European  banks to have an account to do crypto trading? And what are their limits to allow transactions?

Here's a link that has a list of various banks in Europe that are fine with crypto trading:
https://thebanks.eu/articles/crypto-friendly-banks-in-Europe
Most definitely DYOR, I'm not sure how trustworthy these banks are.
Speaking of trust, it seems to me that those five articles you linked show pretty clearly that major European banks are willing to and can easily control what you do with "your" money.
A trust-minimized solution would be buying bitcoin off of a decentralized exchange such as Bisq and using your own Bitcoin node for sending and receiving your coins. Just my two sats :)

Thanks Marco. This is comes close to what I need. Is thebanks.eu reliable? Who´s funding it?

Do you have an idea of limits? What amounts do they block?


text:
DoS attack and MAX_BLOCKS_IN_TRANSIT_PER_PEER
I was reading Mastering Bitcoin and I found, in the section Exchanging "Inventory", this:

"The node keeps track of how many blocks are "in transit" per peer connection, meaning blocks that it has requested but not received, checking that it does not exceed a limit (MAX_BLOCKS_IN_TRANSIT_PER_PEER)"

this limit implies and allows

"[...] spreading the load and ensuring that it doesn't overwhelm any peer with requests."

and

"[...] allowing the peers to control the pace of updates and not
overwhelm the networks."

But what would happen if someone removes this limit or sets it very high? Could it end in a DoS attack?

this limit implies and allows

"[...] spreading the load and ensuring that it doesn't overwhelm any peer with requests."

and

"[...] allowing the peers to control the pace of updates and not
overwhelm the networks."

That's incorrect. The sole reason for the MAX_BLOCKS_IN_TRANSIT_PER_PEER constant and associated logic in the Bitcoin Core P2P block fetching code to exist is to speed up initial download for them. It causes block fetches to be spread out over multiple peers, so that if one or a few of the peers are slow, it doesn't slow down block download overall. There is an associated mechanism that causes peers which are noticeably slower than other peers to be disconnected and replaced with other ones too.
Source: I wrote that code.

But what would happen if someone removes this limit or sets it very high? Could it end in a DoS attack?

No, removing it wouldn't hurt anyone but the person running without it. Other nodes aren't bound to use the same code anyway, so whether or not this mechanism exists in Bitcoin Core has no bearing on people not using Bitcoin Core, and thus we can't rely on it as a DoS protection mechanism.

Thanks you very much, so removing the limit could cause other nodes flooding me of blocks, so like dossing myself?

@Paro No, the result wouldn't flood you any more or less with or without the limit ("flooding" implies it's undesirable, but during initial block download you want to get the blocks as quickly as possible). The only point of having a limit it to prevent requesting all blocks from the same peer (as opposed to spread out over many peers), because if you're only downloading from one peer, and that peer is slow, your synchronization will be slow.


text:
Alternative methods to transfer BTC from an old Coinbase multisig Vault
Issue: I am trying to access funds I had stored in a legacy Coinbase Vault 2/3 multisig wallet using the Coinbase multisig recovery tool (https://coinbase.github.io/multisig-tool/) . I have all of the necessary information to access the wallet, including the Coinbase xpubkey, the Shared xpubkey and the User xpubkey. Additionally, I have both the User seed and the Shared seed (encrypted) including the password.
However, I am encountering an issue with the recovery tool whereby the Vault wallet balance is not displaying upon entering in the xpubkeys in Step 1. Upon further research, it appears that there is an issue with the recovery tool referencing a Bitpay API endpoint that is no longer active. As such, the Coinbase multisig recovery tool is no longer functional. For reference, see the Reddit post and Bitcointalk forum post I'm referring to. Note, that I am experiencing the same issue described in the Reddit post (i.e. I have all of the necessary information to access the vault wallet).

https://www.reddit.com/r/BitcoinBeginners/comments/ndvhom/coinbase_multisig_vault_recovery_tool_wtf/
https://bitcointalk.org/index.php?topic=5316286.0

Therefore, my question is, what are some other alternative methods to access the funds in my legacy Coinbase Vault 2/3 multisig wallet? Note, that the options should be prioritized in terms of technical complexity, with less technical methods preferred.
Thanks

This is not an "answer" but if you have everything you say you have it should be possible to access the BTC and send it to another wallet.
I thought I had the password but in testing it, the password did not work.  I reference that in this post.
how to test decryption of shared seed for a multisig vault
Before beginning attempts to liberate your BTC, I would advise you test your password on your encrypted shared seed.
If that works (meaning you do not get an error), congratulations, you have 2 of the 3 keys required to move the funds.  It gets more technical from here, especially to do this yourself.
I would advise reading through this post recover Coinbase multisig wallet to Electrum? and see if that helps out.  It doesn't spell out the process entirely but will give you an idea what needs to happen.

The original project has long been abandoned. Use this updated project that fixes the broken things in the original repo and is fully functional as of 2023

Looking at the repo, it is not immediately obvious whether it is safe to use as the commit history from the original project is not preserved. I would recommend carefully reviewing all of the code before using it.


text:
Does key derivation make (or help to make) Bitcoin "quantum safe"?
We have these two other questions that touch on the same subject of how safe is Bitcoin from quantum computing attacks, but I believe mine is specific enough to be a separate question:

What effects would a scalable Quantum Computer have on Bitcoin?
How vulnerable is bitcoin to quantum algorithms?

The accepted answer in the older question above states that "ECDSA is compromised, but hashing isn't", so therefore, by simply knowing the address an attacker could not "calculate" back the private key necessary to spend the BTC, but after creating a transaction and spending the BTC, the public key becomes known by the network and therefore and attacker could "calculate" the private key and all the UTXOs of that address would become compromised.
I was wondering if using one address per transaction would mitigate this problem, since apparently key-derivation functions (bcrypt, Scrypt, Argon2) are basically quantum-safe. My reasoning is that from your "master" private key, you'd derive a new one and from this one you'd generate the public key which finally generates the address, and then when this address spends any UTXO and consequently tells its public key to the network, an attacker would only be able to get the derived private key, but never the "master" one, meaning in the end the user is relatively safe as long as they don't reuse the same address and keep on generating one address each time they want to receive a UTXO.
Is the reasoning above correct? Or maybe at least partially correct?

I was wondering if using one address per transaction would mitigate this problem

No, because the public key is revealed at spending time still, even if you never reuse addresses. The time between broadcasting the spending transaction and it being sufficiently buried on-chain still exposes the user to risk if hypothetical machines that can compute the discrete logarithm exist. Since we're talking about hypothetical hardware, you can't make any assumptions about how fast it would work.
Furthermore, lots of use cases of Bitcoin involve sharing public keys with other not-fully-trusted parties. For example, multisig wallets require public keys to be shared between the participants. Lightweight clients reveal public keys to the servers that help them track their balance. Lightning channels involve shared node public keys and channel public keys on the network. In the presence of hypothetical hardware that can compute private keys, Bitcoin as it is used today would pretty much stop existing, as all these use cases disappear.
Lastly, even if you yourself manage to carefully avoid all these scenarios that involve sharing of public keys, and we somehow assume that transactions in flight don't pose a risk, you have to consider that an enormous amount of BTC is currently held in addresses for which the public keys are known, even if not your funds. In the presence of a hypothetical EC breaking machine, so many funds would become exposed that I cannot imagine BTC maintaining much value.

I was wondering if using one address per transaction would mitigate this problem, since apparently key-derivation functions (bcrypt, Scrypt, Argon2) are basically quantum-safe. My reasoning is that from your "master" private key, you'd derive a new one and from this one you'd generate the public key which finally generates the address, and then when this address spends any UTXO and consequently tells its public key to the network, an attacker would only be able to get the derived private key, but never the "master" one, meaning in the end the user is relatively safe as long as they don't reuse the same address and keep on generating one address each time they want to receive a UTXO.

Yes and no.

Master private keys that deterministically generate the actual address keys are used ubiquitously in Bitcoin, precisely because it permits using a new address for every transaction without needing a backup of each individual key. The reason is not security, but privacy however; reuse of addresses gratuitously reveals information about shared ownership of UTXOs on chain.
In theory, key derivation mechanisms do exist that are quantum-secure (or could be), in the sense that an attacker who learns (through whatever means) the private key to an address cannot learn the master key it was generated from. The common key derivation mechanism used in Bitcoin (BIP32) does not use such techniques however, because it's incompatible with xpubs. The (unhardened) BIP32 method supports sharing a master public key with another party (corresponding to your master private key which is never revealed), in such a way that those other parties can derive the public keys corresponding to the private keys you will derive. This enables watch-only wallets that can track funds on an online machine, while the private keys remain safe on an offline one.
All the arguments above still apply: even if attackers are prevented from computing the master private key from an address private key, it doesn't stop them from computing address private keys from public keys.

ECDSA, and other forms of EC-based cryptography are inherently not quantum-secure. It's enticing to think about ways to cover up this property or somehow reduce its impact, but it doesn't change the fact that the cryptography inherently just isn't designed for that. If we want post-quantum secure Bitcoin, we need to switch to actual cryptography designed for that, which is very actively being researched. I personally believe it is too early to push for that practically, as existing schemes today are very novel, are frequently broken still, and come with huge downsides (mostly size of keys or signatures), but given how rapidly the field is progressing I'm confident those concerns will reduce over time.


text:
Block Health at 94.82%, why do nodes accept this?
I see that Binance Pool has a Block Health of 94.82% (Block 795364).
Why do Nodes accept blocks that have so many intentionally excluded transactions?
Isn't that against the Bitcoin ethos in a sense since this is akin to censorship?
Do some nodes purposely attempt to not accept these miners blockchain?
Thanks and appreciate full answers with additional resources if possible :)

Why do Nodes accept blocks that have so many intentionally excluded transactions?

Because nodes do not get do discriminate between blocks. If a block follows the consensus rules, it must be accepted. If it doesn't it must be rejected. If nodes instead each have their own rules, they risk getting forked off from the rest of the network, and the currency.
Now one can of course wonder: why don't the consensus rules say something about rejecting blocks that have too many expected but missing transactions? The simple answer is that that is not a consistently enforceable rule. Nodes' mempools (the set of unconfirmed transactions) are not, and cannot be, guaranteed to be consistent. There can be double-spends on the network for example, which cause some nodes to see one version first, and other nodes to see another first. When a block finally arrives, at least one of both sets will be wrong. Some transactions can also be slow to validate and to relay across the network, so when a block arrives with it in it, some nodes may simply not yet have heard about the transaction.
Simply put: an expectation of what is in the next block is only useable in consensus rules if we can guarantee that all nodes, at all times, agree on what that expectation is. And to achieve that, we'd need an algorithm for consistency across unconfirmed transactions. If we had that, we wouldn't need a blockchain anyway, as the blockchain's goal is a consensus algorithm, exactly with the purpose of getting everyone to agree on some piece of data (confirmed transactions, and their order).

Isn't that against the Bitcoin ethos in a sense since this is akin to censorship?

Quite possibly. But all it needs is some miner, possibly anonymous, to start mining these left behind transactions. The whole point of mining, as opposed to a central coordinator that decides which transactions are accepted in the presence of conflicts, is that anyone can participate.

Do some nodes purposely attempt to not accept these miners blockchain?

That too, would increase the risks of irreconciable forks. Unless a majority of the hashrate enforces such a rule, choosing not to build on top of some censored set of miners' blocks, is just creating a minority fork that will be ignores by the entire network. With a majority of the hashrate enforcing it, it is possible. But then we call is a 51% attack, because unless it happens with agreement of the whole network, that actually is censorship.

@user253751 Yes, that's the 51% attack I refer to.

@user253751 Note that the assumption that this does not cost anything is a fallacy because executing a 51% attack improperly can result in massive expenses on power usage that may not actually result in a more profitable scenario than mining fairly.

Why do Nodes accept blocks that have so many intentionally excluded transactions?

Bitcoin nodes do not implicitly discriminate against any nodes that are submitting new blocks and proper proof of work solutions, if it is the case that they mine the longest chain then the network will automatically accept it (assuming everything else is valid as well). So the only way to slow this down is convince miners to point their ASIC at a pool which does not do such things. Also a 6% censorship on one pools block is still much better than ETH where OFAC censorship is minimum 30% at any given moment on any validator(and funds which are akin hashpower in PoS are locked on the validators where in Bitcoin we are free to move to a different pool when we feel we are being censored).

Isn't that against the Bitcoin ethos in a sense since this is akin to censorship?

I agree that large entities like Binance censoring transactions is not within the ethos of Bitcoin, but neither is anything else they sell on their exchange/casino. So the only way to stop such things is get people to stop supporting it, otherwise they are just participating in Bitcoin like everyone else. I wont endorse everything in this article (partially because I have not read the whole thing) but generally the way to think about adversaries and Bitcoin is that "Bitcoin is money for enemies": https://bitcoinmagazine.com/business/bitcoin-is-money-for-enemies

Do some nodes purposely attempt to not accept these miners blockchain?

You cannot really do such a thing without creating a hardfork if you cannot create a longer chain by the time their chain propagates, which generally is done automatically and would not be something you could do on the fly.