text:
Is it possible to restrict Bitcoin's network traffic?
Bitcoin is just a software running on a computer communicating securely with peers on the internet.
What will it take purely in technical terms to ban Bitcoin nodes from communicating with the network?

Assuming a node is starting for the first time, I believe it uses DNS seeds to find peers. If those DNS seeds are blocked, is it possible to prevent bitcoin node discovery ?
Is it possible to block certain ports to avoid bitcoin communication ?
Any other ways ISPs can detect bitcoin traffic ?

If these hard-coded seed values are blocked, it's easy to provide fresh input in bitcoin.conf. I'm sure you will find many seeds online to use. Also, you can run Bitcoin Core purely over Tor. So you would have to block Tor as well to catch that. And then, there is the Blockstream satellite service. It really depends on how serious you are on banning it and what escape routes the community has left and will invent.

Banning peer to peer networks is very difficult in general.

Assuming a node is starting for the first time, I believe it uses DNS seeds to find peers. If those DNS seeds are blocked, is it possible to prevent bitcoin node discovery ?

This is possible but all you need in order to bypass it is one IP address of one peer and then you can connect to it manually and join the network

Is it possible to block certain ports to avoid bitcoin communication ?

Again that's possible but easily circumvented by changing the default ports

Any other ways ISPs can detect bitcoin traffic ?

Peer traffic is not encrypted so ISPs can flag bitcoin traffic by performing some inspection on the data being sent. But again this is bypassed by using a VPN or TOR.
Another way someone might try to stop you is blocking your internet access completely but this can be circumvented too because bitcoin is accessible via satellite, all you need is a dish and you don't rely on your ISP any more.

The top answer here isn't very good. The idea that a motivated regulatory infrastructure intent on banning Bitcoin would be permanently thwarted by VPN connections is very wishful thinking.
Is every end user with a wallet also supposed to use VPN connections?
It also wouldn't be much of a challenge for regulators to target the increasingly centralized mining operations and shut down their VPNs.
The fact of the matter remains: a sufficiently motivated government could probably very easily ban, and certainly massively disrupt, the Bitcoin network if they wanted to. This is one of the primary concerns with the protocol, and the idea that it could ever be used to protect you in a serious financial crisis is probably wishful thinking by people who don't understand how centralized the routing infrastructure of the internet truly is.
Basically, a small number of ISPs already control the internet, and through packet inspection and other means, they could very easily shut down the Bitcoin network for 99.99% of users if ordered to do so.


text:
How isn't blockchain fundamentally broken?
This question is a good 3 to 5 years late on the crypto trend but nevertheless I'm still having trouble to understand.
The chain works by verifying every previous block, right? How does this not become an exponential problem?
Say I want to join the network and start a node, I have to fetch the entire block chain which:

Can grow to unlimited size?
I have to verify, by checking every block of theoretically unlimited count?

I do believe the crypto currency can not grow as it does by having such fundamental flaws, but I seem to not be able to find the solutions to them.

I just recently downloaded and started a fresh copy of Bitcoin Core.  Yes, it started by downloading the entire blockchain, and validating every single transaction since way-back-when (2009?).  It took a bit less than 1/2 Terabyte, and about 2 days on a modern desktop PC.

@abelenky indeed, and that will only get worse. There surely must be a solution for this?

Not sure what you mean by worse:  1/2 terabyte and 2 days to start up a new node after 10 years (without even using a massive computer network) is no big deal.  In another 10 years, computing power, networking and storage will all be cheaper and faster.  The overhead just isn't that worrisome.

People said the same thing in 2015, and it still takes me roughly the same amount of time to start a fresh node today. Technology improvements exist and have allowed bitcoin to scale despite the growing size of the blockchain.

The chain works by verifying every previous block, right? How does this not become an exponential problem?

I think you are assuming Blockchain growth is exponential with time, but it is linear with time (1MB / 10 min).

I have to verify, by checking every block of theoretically unlimited count?

In an extreme scenario, you are right. In the year 3000, we will have ~100 TBs to download and verify and it will keep on increasing ever after. But it's not as bad as it sounds like.

The rate of growth is low: Because it grows linearly with time, at a given time you will always have a finite amount of data to download and verify. As others have mentioned, there are solutions like SPV and node pruning in order to avoid full storage. If you want to run a full node with entire blockchain stored locally, this rate of increase 1MB/10min is considered small relative to the rate of growth of technology.

Increased efficiencies of node resource utilization: A lot of effort goes into managing the node resources to optimize network bandwidth, disk block compression, verification speed in order to mitigate to downfalls of ever-increasing blockchain size. In fact, if you look at the historical bitcoin-core Initial Block Download times, you will find these times have kept the same or improved over time despite the increasing blockchain size.

But if rate is limited linearly then it will be unable to fulfill an exponential increase in adoption?

There are other layer 2 scaling solutions like Lightning network that don't require everything to be published on blockchain.

We have a saying - "patched work". I'm not really sure how that would translate to English but that's very much what this looks like to me. Everyone is free to draw their own conclusions, thank you for your time you took to answer :)

Running Bitcoin Core is not a problem for modern computers, and as computer technology is always improving, it will be able to keep up. Computers are very good at processing blockchain data, and that data will be finite not infinite.
If you get involved with Bitcoin core on GitHub, you will get an insight into how it works and you will find other people that can explain that what you are worried about is not a problem (better than me).
https://bitcoincore.org/
https://developer.bitcoin.org/
https://github.com/bitcoin/bitcoin

Can grow to unlimited size?

The bitcoin blockchain is designed to produce 1 block (1-2 MB) every 10 minutes. The difficulty of producing blocks is readjusted about every 2 weeks, so that this frequency does not change.

I have to verify, by checking every block of theoretically unlimited count?

Since the size is limited, the blockchain growth can be kept under control, but yes, if you want to be 100% sure that you are verifying your bitcoin transaction properly, you are going to have to use a bitcoin full node and download the full blockchain which is around 321Gb as of today.
There are of course lots of solution to avoid this, and most bitcoin user don't run their own full node but use Simplified Payment verification or the pruned mode that allow you to avoid having to store the full blockchain.

You right, I fixed it

Thank you, but I still don't understand how the problem of infinite size is solved? SPV seems to still query the chain even if from the network, how are nodes going to keep up if the size increases to infinity?

@php_nub_qq, I have written another answer detailing your comment

Say I want to join the network and start a node, I have to fetch the entire block chain which:

Can grow to unlimited size?
I have to verify, by checking every block of theoretically unlimited count?

You only have to do that if you want to verify that none of the system's rules were violated at any point in its history. If you don't want to verify that, then don't bother. Nothing requires you to fetch them and check them.
If you don't care about ancient history, you can fetch the state of the blockchain as of some point in time. You can ask other people who have checked the history what the hash of the UTXO set was at that point. And then you can fetch that set and all the blocks after that.
If you only care that no more coins are in existence than are supposed to be and that the system's rules aren't broken after you start using the system, then you can fetch a minimal history set and not every block ever produced.
Another problem that you didn't mention is that if you were going to verify the full validity of every block ever produced, you would also have to understand the system's rules (including any bugs) for all previous times in the blockchain's history. For complex and evolving blockchains, that's also a huge problem.

source: Stack Exchange

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

sort: votes


text:
How to make RBF with changed output address per CLI?
Please, can anyone explain to me how to make an RBF with changing the output address exactly? Which commands should I use for that? I tried to use the 'send' command to send the same amount with a higher fee, but it says "Insufficient funds." What should I do exactly? I'm using Bitcoin Core 25.0 full node.

I found what I need  sendall command do that for more
info about using it exactly look here

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


text:
Why doesn't the getrawtransaction command with the verbose flag include the confirmations field?
According to the official Bitcoin documentation, getrawtransaction should return a confirmations field, but I don't see that field in the response.
https://developer.bitcoin.org/reference/rpc/getrawtransaction.html
My response is:
{
'txid': 'dcee66416a499013e1898dbb9eeb297af0ea721990dfd114471c810b24d9c914',
'hash': '6aee71cbbe9a9573fea25dbc6765b619d2c568e434fb642ceee4864ad527282d',
'version': 1,
'size': 770,
'vsize': 688,
'weight': 2750,
'locktime': 0,
'vin': [{
    'txid': '4ab11d2c30cb7d60d335914026ca8a7b11f9b90c5ea403b14ef5bdf33707eef2',
    'vout': 0,
    'scriptSig': {'asm': '', 'hex': ''},
    'txinwitness': [
        '3045022100be6e832262d847871d5ca58790fd6731a148bf8282ae71b39cdfe6befd859f4102201c0f8ccb451bdb8c0e2f7cc02d7a7018882e478aa23aed15f2ccce75ad88e50a01',
        '02174ee672429ff94304321cdae1fc1e487edf658b34bd1d36da03761658a2bb09'],
    'sequence': 4294967295}],
'vout': [{
    'value': 0.0022,
    'n': 0,
    'scriptPubKey': {
        'asm': '0 34cc50701f55633fa883d5e763d7ef699a9e2bff',
        'desc': 'addr(bc1qxnx9quql243nl2yr6hnk84l0dxdfu2llmqydxh)#0j0l9gs3',
        'hex': '001434cc50701f55633fa883d5e763d7ef699a9e2bff',
        'address': 'bc1qxnx9quql243nl2yr6hnk84l0dxdfu2llmqydxh',
        'type': 'witness_v0_keyhash'}}, {
    'value': 0.09642829,
    'n': 1,
    'scriptPubKey': {
        'asm': '0 dc6bf86354105de2fcd9868a2b0376d6731cb92f',
        'desc': 'addr(bc1qm34lsc65zpw79lxes69zkqmk6ee3ewf0j77s3h)#t4dkz7rz',
        'hex': '0014dc6bf86354105de2fcd9868a2b0376d6731cb92f',
        'address': 'bc1qm34lsc65zpw79lxes69zkqmk6ee3ewf0j77s3h',
        'type': 'witness_v0_keyhash'}}, {
    'value': 0.00656953,
    'n': 2,
    'scriptPubKey': {
        'asm': '0 97db6940960345d01bcd9829c890e63cb591d906',
        'desc': 'addr(bc1qjldkjsykqdzaqx7dnq5u3y8x8j6erkgxq4rk3s)#da7p060e',
        'hex': '001497db6940960345d01bcd9829c890e63cb591d906',
        'address': 'bc1qjldkjsykqdzaqx7dnq5u3y8x8j6erkgxq4rk3s',
        'type': 'witness_v0_keyhash'}}, {
    'value': 0.01133746,
    'n': 3,
    'scriptPubKey': {
        'asm': 'OP_HASH160 bce27a3df6ed27a9e1829ba637fbbb2ba58b2119 OP_EQUAL',
        'desc': 'addr(3JukGYLAunYfGsWBgCXrLY2QZMDqyBCX4m)#lc27xek3',
        'hex': 'a914bce27a3df6ed27a9e1829ba637fbbb2ba58b211987',
        'address': '3JukGYLAunYfGsWBgCXrLY2QZMDqyBCX4m',
        'type': 'scripthash'}}, {
    'value': 0.00358816,
    'n': 4,
    'scriptPubKey': {
        'asm': 'OP_DUP OP_HASH160 688ac3f6acb233537fd02225ac830eed3a1e0015 OP_EQUALVERIFY OP_CHECKSIG',
        'desc': 'addr(1AXmWYcpWYrFZvCMcFJXYFqBaM83msjzLZ)#qfc9tky9',
        'hex': '76a914688ac3f6acb233537fd02225ac830eed3a1e001588ac',
        'address': '1AXmWYcpWYrFZvCMcFJXYFqBaM83msjzLZ',
        'type': 'pubkeyhash'}}, {
    'value': 0.0036425,
    'n': 5,
    'scriptPubKey': {
        'asm': 'OP_DUP OP_HASH160 4c32aa1bf49890401602eafb4f21d543e7861997 OP_EQUALVERIFY OP_CHECKSIG',
        'desc': 'addr(17wu3oxFEq1pdQSA8Ym17ExHEr2h7CCH9r)#v45ww8xp',
        'hex': '76a9144c32aa1bf49890401602eafb4f21d543e786199788ac',
        'address': '17wu3oxFEq1pdQSA8Ym17ExHEr2h7CCH9r',
        'type': 'pubkeyhash'}}, {
    'value': 0.01822233,
    'n': 6,
    'scriptPubKey': {
        'asm': 'OP_DUP OP_HASH160 595e840a8971c756a7048b58546c5d682ab8fd4f OP_EQUALVERIFY OP_CHECKSIG',
        'desc': 'addr(199YN9QDSBaeAEnzs4vXGNnrhp7GujcpTv)#ccy6x25y',
        'hex': '76a914595e840a8971c756a7048b58546c5d682ab8fd4f88ac',
        'address': '199YN9QDSBaeAEnzs4vXGNnrhp7GujcpTv',
        'type': 'pubkeyhash'}}, {
    'value': 0.01246382,
    'n': 7,
    'scriptPubKey': {
        'asm': '0 c67052c931f4fe27d8ad41f5530748e906119f70',
        'desc': 'addr(bc1qcec99jf37nlz0k9dg864xp6gayrpr8msq7uf8v)#fcxddsjw',
        'hex': '0014c67052c931f4fe27d8ad41f5530748e906119f70',
        'address': 'bc1qcec99jf37nlz0k9dg864xp6gayrpr8msq7uf8v',
        'type': 'witness_v0_keyhash'}}, {
    'value': 0.00115586,
    'n': 8,
    'scriptPubKey': {
        'asm': 'OP_HASH160 15ca0ae6571f7409828c1a632a12337023522e2e OP_EQUAL',
        'desc': 'addr(33gE9jg3whjTgx34X5CtDMzHhceAnTDedY)#te8pfcrg',
        'hex': 'a91415ca0ae6571f7409828c1a632a12337023522e2e87',
        'address': '33gE9jg3whjTgx34X5CtDMzHhceAnTDedY',
        'type': 'scripthash'}}, {
    'value': 0.00016101,
    'n': 9,
    'scriptPubKey': {
        'asm': 'OP_HASH160 f4f34136a58f50e5ef91cbf0b974d94526f967fb OP_EQUAL',
        'desc': 'addr(3Q2CCz9EfCLmGL8fPyYkx331ShyWiVBe5F)#jvya2pyl',
        'hex': 'a914f4f34136a58f50e5ef91cbf0b974d94526f967fb87',
        'address': '3Q2CCz9EfCLmGL8fPyYkx331ShyWiVBe5F',
        'type': 'scripthash'}}, {
    'value': 0.1998,
    'n': 10,
    'scriptPubKey': {
        'asm': 'OP_HASH160 5d75cb96d82cb1b30ebe30b0da798ef432860e1c OP_EQUAL',
        'desc': 'addr(3ADBswe2jxr9XaLJq491BdDiQXDMinBjZB)#2e484r49',
        'hex': 'a9145d75cb96d82cb1b30ebe30b0da798ef432860e1c87',
        'address': '3ADBswe2jxr9XaLJq491BdDiQXDMinBjZB',
        'type': 'scripthash'}}, {
    'value': 0.36000101,
    'n': 11,
    'scriptPubKey': {
        'asm': 'OP_DUP OP_HASH160 9e04a763f86d7c775080c82cb868744df17ffd69 OP_EQUALVERIFY OP_CHECKSIG',
        'desc': 'addr(1FQXLfcS9XfbE4ocYZDFPJUHS8VPb1Twot)#jwtnh5zs',
        'hex': '76a9149e04a763f86d7c775080c82cb868744df17ffd6988ac',
        'address': '1FQXLfcS9XfbE4ocYZDFPJUHS8VPb1Twot',
        'type': 'pubkeyhash'}}, {
    'value': 0.0079,
    'n': 12,
    'scriptPubKey': {
        'asm': 'OP_HASH160 9153604006c8e7766077e63b382b938e946f1f21 OP_EQUAL',
        'desc': 'addr(3EwRnRXFo5BsHGtxG2vyZaSfdpyMkTL1ni)#f4kmy4h0',
        'hex': 'a9149153604006c8e7766077e63b382b938e946f1f2187',
        'address': '3EwRnRXFo5BsHGtxG2vyZaSfdpyMkTL1ni',
        'type': 'scripthash'}}, {
    'value': 0.0023,
    'n': 13,
    'scriptPubKey': {
        'asm': 'OP_HASH160 72b9cd3b44ac06af4b634d8946b8050287face0d OP_EQUAL',
        'desc': 'addr(3C9dY94k9sGG3umKvmuXfsPvXhbygqiZP5)#ryq7mrt7',
        'hex': 'a91472b9cd3b44ac06af4b634d8946b8050287face0d87',
        'address': '3C9dY94k9sGG3umKvmuXfsPvXhbygqiZP5',
        'type': 'scripthash'}}, {
    'value': 0.0113,
    'n': 14,
    'scriptPubKey': {
        'asm': 'OP_HASH160 2707f01590dfbf62c09f7b4d20066ec476d3e305 OP_EQUAL',
        'desc': 'addr(35FPnZ9rZ89U3ERsJEcL6qLRcFqR7BnBNE)#v3uvz2g8',
        'hex': 'a9142707f01590dfbf62c09f7b4d20066ec476d3e30587',
        'address': '35FPnZ9rZ89U3ERsJEcL6qLRcFqR7BnBNE',
        'type': 'scripthash'}}, {
    'value': 0.03622237,
    'n': 15,
    'scriptPubKey': {
        'asm': '0 8052c878f073cec9a99dbe8f43dcacbbbe7f3745',
        'desc': 'addr(bc1qspfvs78sw08vn2vah6858h9vhwl87d69w3wt8w)#0culwng7',
        'hex': '00148052c878f073cec9a99dbe8f43dcacbbbe7f3745',
        'address': 'bc1qspfvs78sw08vn2vah6858h9vhwl87d69w3wt8w',
        'type': 'witness_v0_keyhash'}}, {
    'value': 0.01776,
    'n': 16,
    'scriptPubKey': {
        'asm': '0 2326e0fbefaf598fa6cd25e9df54939a6864edcf',
        'desc': 'addr(bc1qyvnwp7l04avclfkdyh5a74ynnf5xfmw098ue4j)#lgk3vvks',
        'hex': '00142326e0fbefaf598fa6cd25e9df54939a6864edcf',
        'address': 'bc1qyvnwp7l04avclfkdyh5a74ynnf5xfmw098ue4j',
        'type': 'witness_v0_keyhash'}}, {
    'value': 0.00269325,
    'n': 17,
    'scriptPubKey': {
        'asm': 'OP_HASH160 0a158c71f81a11f28e9d0f779e0ab9e850b17316 OP_EQUAL',
        'desc': 'addr(32cLVgjzF6wK2M9WqCjpEBF27rZRt1fp2a)#ad7mark9',
        'hex': 'a9140a158c71f81a11f28e9d0f779e0ab9e850b1731687',
        'address': '32cLVgjzF6wK2M9WqCjpEBF27rZRt1fp2a',
        'type': 'scripthash'}}, {
    'value': 0.00364159,
    'n': 18,
    'scriptPubKey': {
        'asm': '0 ef8169ec58bfb23773e6c280a23923b332773887',
        'desc': 'addr(bc1qa7qknmzch7erwulxc2q2ywfrkve8wwy8z6mtsk)#n0rm7tvu',
        'hex': '0014ef8169ec58bfb23773e6c280a23923b332773887',
        'address': 'bc1qa7qknmzch7erwulxc2q2ywfrkve8wwy8z6mtsk',
        'type': 'witness_v0_keyhash'}}],
'hex': '01000000000101f2ee0737f3bdf54eb103a45e0cb9f9117b8aca26409135d3607dcb302c1db14a0000000000ffffffff13605b03000000000016001434cc50701f55633fa883d5e763d7ef699a9e2bff4d23930000000000160014dc6bf86354105de2fcd9868a2b0376d6731cb92f39060a000000000016001497db6940960345d01bcd9829c890e63cb591d906b24c11000000000017a914bce27a3df6ed27a9e1829ba637fbbb2ba58b211987a0790500000000001976a914688ac3f6acb233537fd02225ac830eed3a1e001588acda8e0500000000001976a9144c32aa1bf49890401602eafb4f21d543e786199788ac19ce1b00000000001976a914595e840a8971c756a7048b58546c5d682ab8fd4f88acae04130000000000160014c67052c931f4fe27d8ad41f5530748e906119f7082c301000000000017a91415ca0ae6571f7409828c1a632a12337023522e2e87e53e00000000000017a914f4f34136a58f50e5ef91cbf0b974d94526f967fb87e0de30010000000017a9145d75cb96d82cb1b30ebe30b0da798ef432860e1c8765512502000000001976a9149e04a763f86d7c775080c82cb868744df17ffd6988acf00d0c000000000017a9149153604006c8e7766077e63b382b938e946f1f2187708203000000000017a91472b9cd3b44ac06af4b634d8946b8050287face0d87103e11000000000017a9142707f01590dfbf62c09f7b4d20066ec476d3e305875d453700000000001600148052c878f073cec9a99dbe8f43dcacbbbe7f374580191b00000000001600142326e0fbefaf598fa6cd25e9df54939a6864edcf0d1c04000000000017a9140a158c71f81a11f28e9d0f779e0ab9e850b17316877f8e050000000000160014ef8169ec58bfb23773e6c280a23923b33277388702483045022100be6e832262d847871d5ca58790fd6731a148bf8282ae71b39cdfe6befd859f4102201c0f8ccb451bdb8c0e2f7cc02d7a7018882e478aa23aed15f2ccce75ad88e50a012102174ee672429ff94304321cdae1fc1e487edf658b34bd1d36da03761658a2bb0900000000'

}

Are you running Bitcoin Core? If so, what version of Bitcoin Core are you using?

Was the tx confirmed when you ran this? My node returns this, as expected:
  "blockhash": "000000000000000000033fa977be990449444794ecd5bb09826c9b5e8fcd8e4c",
  "confirmations": 146,
  "time": 1682292871,
  "blocktime": 1682292871

If the block isn't confirmed, those fields are omitted.

If the response does not include a confirmations field, you can assume that the transaction is still in the mempool, right?

@Andrei Mukhametvaleev, Yes


text:
Channel close fees too low
I closed a lot of channels in recent days - but for some of them I left the confirmation fee too low. I'm hoping the mempool will clear in the coming week and they will confirm.
Is there a way to speed up the closure process - or even force close them? I tried to force close two of them but it hasn't worked - they remain 'waiting close'. Also - running 'lncli pendingchannels' shows that those two channels now have a 'ChanStatusBorked' status flag. Also tried RBF using 'wallet bumpfee' command on one of the 'anchor' channels - but that also doesn't seem to work.

You may be able to reach out to the other party and have them initiate a force-close on their side. I had to do this once, they did not listen to my emails so a developer actually helped me reach out to them and they did the force close eventually which I am still grateful for.

I discovered the solution: just needed to learn how to properly use the lnd command 'wallet bumpfee' that can be used on cooperative close TXIDs that have confirmation fee set too low. Also note that there is a wallet bumpclosefee command for bumping force close commitment transactions - noting that this is only available on 'anchor' channels which can be looked up with the pendingclose command.

You may be able to manually create another closing transaction with a higher fee, but you will need to reach out to your channel partner for them to cosign it. This is because a mutual close transaction spends from the funding output, which is a 2-of-2 multisig between the two parties.


text:
What is the difference between Dogecoin and Bitcoin at the network level?
With all the Dogecoin hype, mainstream media has been comparing Doge with established cryptos like Bitcoin.
I'm trying to understand the difference at the technical level:

It comes up that Bitcoin network has better security. Is that due to the hashrate? If more miners start switching to Doge, wouldn't that solve the problem?

Doge's codebase is also almost same as Bitcoin.

Ignoring the coin supply factor, where Doge can continue creating 5 billion coins per year, is there any other reason that the Bitcoin network is superior? Does it boil down to simply which network gets more adoption?

TL;DR: small code differences, but many larger ecosystem differences
IIRC, Dogecoin is a fork of Luckycoin, which in turn was forked from Litecoin, which was forked from Tenebrix, which was forked from Bitcoin. As far as I can tell, the main differences to Bitcoin are:

Scrypt hashing algorithm:
Originally introduced to avoid being a minority-hashrate altcoin to Bitcoin, and for being thought to be ASIC resistant.
1-minute blocks:
Faster confirmation, but a shorter block interval may increase mining centralization.
accelerated reward schedule:
Full supply emission in less than 2 years via random rewards, then later changed to have a constant tail emission of 10,000 Doge per block.

Dogecoin is merge-mined with Litecoin, so it shares the protection of the hashrate of the incumbent Scrypt-coin and is therefore not trivially majority-attackable as some other minority-hashrate forks. Since Litecoin/Dogecoin use a different hashing algorithm (Scrypt) than Bitcoin (SHA256d), mining hardware does not transfer, it is only compatible with one or the other.
Presumably, people citing security concerns are alluding to Dogecoin Core being about 15,000 commits behind Bitcoin Core, with its master release citing inclusion of "changes from Bitcoin Core 0.14.3" (which was released in Sep 2018). I surmise that this means that a plethora of security fixes and performance improvements have not yet been backported to Dogecoin. The Dogecoin network has only about 220 public nodes at chain-tip. Allegedly, the software is struggling to synchronize the 3.7M block headers.
Dogecoin did also not backport segwit, which means that it still suffers from third-party transaction malleability, the quadratic hashing problem, and cannot support a Lightning Network. Since the upcoming Taproot soft fork builds on segwit, the resulting new features including Schnorr signatures, public key and signature aggregation, scriptless scripts, Merklized Alternative Script Tree (MAST), and Discreet Log Contracts (DLC) are also unlikely to become available.
So, Bitcoin and Dogecoin are practically the same, except that Dogecoin has no infrastructure, no ecosystem, a plethora of security and performance issues, maybe one developer, next to no code review, and none of the new shiny features. However, it is a great meme and a funny parody on all altcoins, so it will always have a special place in our hearts.

In the context of Doge, the phrase "tail emission" is a whole nother thing. ;)


text:
Pruning Blockchain, what does it remove?
I am trying to determine if I want to prune but I'm trying to figure out if it would interfere with anything.
Would it interfere with rpc calls to show info on a transaction/block? A full explorer?
Does it interfere with showing transaction histories?
I finally have the full blockchain downloaded and it takes a long time so i want to be sure. I don't need the extra space.

Pruning Blockchain, what does it remove?

What
Raw block data for blocks older than a given height.
If we look at https://bitcoincore.org/en/releases/0.11.0/, it says

This release supports running a fully validating node without maintaining a copy of the raw block and undo data on disk. To recap, there are four types of data related to the blockchain in the bitcoin system: the raw blocks as received over the network (blk???.dat), the undo data (rev???.dat), the block index and the UTXO set (both LevelDB databases). The databases are built from the raw data.
Block pruning allows Bitcoin Core to delete the raw block and undo data once it’s been validated and used to build the databases. At that point, the raw data is used only to relay blocks to other nodes, to handle reorganizations, to look up old transactions (if -txindex is enabled or via the RPC/REST interfaces), or for rescanning the wallet. The block index continues to hold the metadata about all blocks in the blockchain.

So if raw block data and undo data are deleted that presumably leaves the block index and the UTXO set as the two of the "four types of data" that are unaffected by pruning.

...
Modified RPC calls:
getblockchaininfo now includes whether we are in pruned mode or not.
getblock will check if the block’s data has been pruned and if so, return an error.
getrawtransaction will no longer be able to locate a transaction that has a UTXO but where its block file has been pruned.

So some RPC calls return an error for pruned data.
When
However the most recent 288 blocks are kept (approx 2 days worth) regardless of whether all their transaction outputs have been spent.
There are some additional details about the timing of deletion of files that contain multiple blocks that are individually marked for deletion. I don't think this substantially affects this answer but it may be something that you should study - depending on what you are trying to achieve.

Would it interfere with rpc calls to show info on a transaction/block?

Obviously, if the block has been pruned it would hamper the ability of the node to report on it. As mentioned above, some RPC calls will return an error if a block has been pruned.

a full explorer?

Ditto.

Does it interfere with showing transaction histories?

It may interfere with showing the history of arbitrary transactions but you should still be able to view all transactions that were created by this wallet/node.
I think you wouldn't always be able to immediately retrieve full details of the sources of transaction inputs back through prior transactions all the way back to the "coinbase" transaction that created the money currently being controlled by the pruning node.
So it may depend what you mean by history?

transactions previously created by this node
historical transactions referred to by own "live" transactions directly or indirectly.

I think the intent of a pruning node is that it should be fully functional as a personal wallet but require much less disk storage space.
If you are using it as something other than a personal wallet you may find that there are significant disadvantages you have to explicitly work around. I guess it depends on the precise details of the intended usage.

See

How do I get old blocks while running a pruned node?

thanks for the clarification. if i want to copy my completed blockchain from windows to linux i just copy the blocks and chainstate folders? nothing else?

@Derek. That's a different question. Comments are mainly for suggesting improvements to questions or answers, not for asking new questions. See https://bitcoin.stackexchange.com/a/60807/13866. The search facility here is quite good. I recommend you try it out.

"Does it interfere with showing transaction histories?" No, I think he's referring to one's own transactions.

@MCCCS thanks for pointing out that possibility, I'll update accordingly.

I don't think this is correct. Since all consensus data is moved to chainstate (utxo set) you don't really need any blocks after they've been processed once. Prune mode only keeps a minimum of 288 blocks on disk to serve to peers. All older blocks are marked for deletion and when a .blk file contains only marked blocks the file can be deleted.

@RedGrittyBrick see https://github.com/bitcoin/bitcoin/pull/5863

@pinhead: OK, thanks for the clarification, updated.

I mean. Whether or not a blocks outputs have been spent is irrelevant (I'm pretty sure). Because that data is in the utxo set, a different data structure. 288 blocks are kept for network service and also reorg data ("undo" blocks)

@pinhead. I'll convert my answer to community wiki to encourage you to edit it (so I wont gain any rep if you do so). Alternatively, feel free to create a new answer that contains any parts of my answer that you consider useful. If the OP moves the accepted tick mark to a better answer I will be able to delete mine.

The wallet in Bitcoin Core has its own transaction list. Pruning does not interfere with having that list in the wallet; it does however interfere with the ability to rescan the chain for old transactions affecting the wallet.


text:
How to generate a legacy-compatible address using Ledger Live?
I'm trying to withdraw funds from Bittrex to my Ledger device, but it seems they do not accept native Segwit addresses.
Is it possible to generate a legacy-compatible address (for instance a P2SH-wrapped segwit address starting with 3...) using Ledger Live?

I assume you are using Ledger Live to generate the address?

I've significantly edited your post to make it clearer. Please feel free to revert the edit if i missed something.

Thank you for making it extra clear however i don't know if Bittrex  likes the wrapped segwit P2SH  or only  the P2PKH starting with 1

According to https://www.reddit.com/r/Bittrex/comments/my5zzl/depositing_to_bittrex_from_native_segwitbech32/, they support P2PKH and P2SH.

Thank you very much. I will work on that


text:
Using BIP32 derivations, can all seeds theoretically produce all public keys?
I was interested in how many possible combinations of BIP 32 derivation paths exist, which could result in a public key derived from a seed. While some people colloquially call it "unlimited," I don't think this is technically true.

Each level of a derivation path has 2^32 possibilities
A path can have up to 255 levels beyond the master

I believe the math then is (2^32)^255 which is 2^8160 unique paths.
Whereas the number of possible public keys is much smaller at only 2^256.
Therefore, it seems reasonable to conclude that each seed, using some unknown derivation, can produce every single possible public key (many times over, with collisions).
Obviously this isn't a practical concern, but it would be interesting from a trivia perspective. Can someone confirm or point out a flaw in my logic? Thank you!

I suspect you are interested in public keys rather than addresses since the number of address types grows every few years as new locking scripts etc are standardised, but the number of possible public keys has not changed since the inception of Bitcoin.

@RedGrittyBrick Good point, thank you, I've edited the question to discuss public keys instead of addresses.


text:
My issue is same as many others sent BTC but funds were not received
even though the transaction shows as confirmed the receiver has not received the funds. I looked on Blockchair by entering the receivers wallet address and doing a history search and guess what it shows my transaction fully completed..??? so where are the fund?s?


text:
Could the Bitcoin Core descriptor wallet recover and start spending UTXOs by only scanning the UTXO set?
In the case where you import a previously used BIP32 seed into a Bitcoin Core descriptor wallet, at the moment if I understand correctly, the only way to recover the UTXOs and spend them is by first calling the rescanblockchain RPC call. This can be quite time consuming, and requires all the blocks of the UTXOs' transactions to not be pruned.
Could the Bitcoin Core descriptor wallet use the scantxoutset call to get a similar outcome? I understand that this would fail to get the full transaction history of the BIP32 seed, but would this call be enough to just recover the wallet's current balance, and make valid transactions?


text:
Attack the network by having 51% of full nodes?
Tell me if I'm missing something here:
If a government recognised that an adversery of theirs had a lot of bitcoin reserves, couldn't they just 'crash' the bitcoin network by spinning up enough full nodes to gain 51% of the network (not a hard thing to do for a big government)? They obviously couldn't produce fraudulent transactions or anything (talking about non-mining full nodes obviously). But they could just stop receiving/validating/appending new blocks. How would any particular node that blindly connects to one of these 51%'ers know not to interact with it? How would a given node 'know' who to query for chain data? Btw, I understand the government would have NO economic interest in doing this. They'd be purely knocking out someone else, but that's valuable enough surely.

The question has the appearance of mixing up two different types of attack

The so-called "51% attack"
The "eclipse attack"

The first is where an attacker controls >50% of the global mining hashpower, not 51% of nodes. This is an attack on every node in the network simultaneously.
The second is where an attacker controls all of the peers of a node. This is a targeted attack on a single node. Since a node might only have ten peers, this does not necessarily involve creating a huge number of dishonest nodes. It is also foiled if the attacked node has contact with only one honest node. That way it will become aware of a chain with more work than the attackers'.

Ahhhh, I think I understand. So even if some government spins up 20,000 nodes tomorrow, provided each node has AT LEAST ONE neighbour with a longer chain, they will always trust that chain, and thus the network stays secure?

That is correct.

If a government recognised that an adversery of theirs had a lot of bitcoin reserves, couldn't they just 'crash' the bitcoin network by spinning up enough full nodes to gain 51% of the network (not a hard thing to do for a big government)?

Technically most of us citizens are this adversary due to fiat economics.

How would any particular node that blindly connects to one of these 51%'ers know not to interact with it?

Likely because of what you said

they could just stop receiving/validating/appending new blocks

This causes people to switch node endpoints if they notice such a thing.

How would a given node 'know' who to query for chain data?

They would do it as usual, using network consensus rules to verify the longest chain.

Btw, I understand the government would have NO economic interest in doing this.

It's not that they wouldn't have interest in doing it, it's that the current state of the network renders their attempts absolutely obsolete. 50% attacks on Bitcoin are highly unlikely for a variety of reasons:
the only relevant nodes in terms of establishing network consensus (about new blocks) would be nodes that miners submit their proof of work to which are generally considered "mining pools". These pools are actually chosen BECAUSE of how secure and decentralized they are, when any of these pools act out of the interest of the miners (ie ordinals filling a full block on luxor pool) it causes them to fall out of the top pool ranks ie miners go somewhere else. Not to mention since these pools are so big, having a central actor or even a hand full of them control the whole thing is highly unlikely, if they did anything wrong miners would notice within the hour max and switch to another pool. If they were in a proof of stake system they would be frozen from withdrawing from the attackers pool.
Considering this is the difference between pool maintainers making a good living and being bankrupt I would say the incentives are HIGH to keep it secure and decentralized.
I would really be entertained to see the counter arguments.


text:
I have Bitcoin core v 23.0 I have my 12 word seed how do I recover my wallet?
I have Bitcoin core version 23.0 I have my
12 word seed how do I recover my wallet?

Bitcoin Core does not use or support 12-word seed phrases (or any seed phrases), so it's unclear what these things have to do with each other.

Does this answer your question? How to restore my Bitcoin Core wallet from seed phrase

Which blockchain app do you make use of?

With a cold wallet or a hot wallet that supports BIP39 you should be able to restore your account using your 12-word seed. After you restore your account, you can send your coins to your Bitcoin Core address.
Note: Bitcoin Core itself does not support seed words.

This! Bitcoin Core doesn't use seed phrases.


text:
How do you sign an unsigned transaction using Electrum in a multisig setup?
I am experimenting with multisig in testNet between Electrum and Caravan by Unchained Capital. I created a 2-of-2 multisig in Electrum with BIP 39 seeds.
I then created a watch-only wallet in Caravan with master public keys. The issues occur when I try to make a transaction in Caravan. For each of the 2 private keys, I need to sign the raw transaction that Caravan provides, but I don't know how to perform that action in Electrum to create the signature. Is it possible to do this on Electrum or do I need some other software?


text:
How does the Casascius project make money?
How does the Casascius business model work? Can someone explain it to me?

If you're asking about the Casascius Physical Bitcoins business operated by Mike Caldwell, the simple answer: it doesn't, as it has been defunct since 2013. See the bitcoin wiki page.
The coins he produced were sold at a markup over the included BTC amount.

do you know how much?

@Tiago: an amount that was simultaneously too much for many buyers and too little to run a business on?

@RedGrittyBrick defunct because gov said stop, not because of bad business, afaiu

@chytrik, I'd forgotten that. I guess Mike Caldwell didn't want the hassle of registering as a money services business and getting state licences. He felt he was selling collectibles rather than transmitting money. So his collectibles business was profitable. Apparently he was also concerned that at around $1000 per coin (inc 1 BTC) his cost of inventory and theft risk was getting too high.

It's also just a bad business in general, there's 100% absolute trust that whoever is making the "coins" doesn't retain the private key for themselves. It sort of worked when the community was tiny, but it definitely shouldn't today. Nobody should be buying and trading those coins believing that they have any value other than the metal they are made from.


text:
What is coinbase script (arbitrary data)?
According to this site, in the coinbase input part, What is the coinbase script and where did it come from?
It is said that this is a arbitrary data, but I don't know how this string is generated?
Just below this section, in the example, the following string is reported:
062f503253482f0472d35454085fffedf2400000f90f54696d652026204865616c74682021
Thanks for any advice,
Best regards,

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

The miner chooses it, freely.
They can use it as an additional nonce (when the nonce is the block header overflows, the miner needs to switch to different transactions in the block to modify it further; the coinbase is an obvious place to make non-impactful, cheap, changes), or use it to publish messages.
In addition, BIP34 (active as a consensus rule since 2012) requires the coinbase scriptSig to start with the height of the block, in a particular encoding.

@ Pieter wuille.
Thank you for answering me so quickly.
When a new block is mined, miners can change the Merkel root, Nonce and time parameters to be able to mine the block.
In order to change the Merkel root, we need to increase or decrease the transactions.
You mean that in addition to these, the miner also has a long string at his disposal on coinbase, with which he can also change the Merkel root?

(it's named after Ralph Merkle, not Angela Merkel). Yes, it's yet another way to introduce variation to the block header, if timestamp and nonce don't suffice. Any change to the transaction set works (through the Merkle root), but having this otherwise ignored (apart from BIP34) field in the coinbase transaction is a convenient way of changing the Merkle root.

Thank you again for your reply.
I think it is very strange that there are 72 hex digits (in other words, 36 bytes) freely in the Coinbase transaction and there is no law for it.
This alone makes a (16^72 = 10^87) variation on block header.   Is it possible to remove this part altogether or reduce its length?

The consensus rules only require it to be between 2 and 100 bytes (I have no idea why this rule exists, but it does), and that it has to start with a push of the height in little-endian encoding (BIP34).

Some speculation on coinbase input script limits in another question

Thanks @RedGrittyBrick


text:
Will a USB mining device use my computer's processing power?
I know that if I use Pooler's CPUMiner it will use all my computer resources for mining purposes.
What if I use one of those Butterfly Labs 5 GH/s SC devices will it use 100% of my CPU power or the device does all the hard work?

If you are using dedicated mining hardware, then CPU is only used for dispatching work to ASIC and sending the result back to pool. Therefore, CPU usage in this case should be very small, certainly not 100%.
Own experience: Linux, cgminer, 2*5GH/s ASICs: the miner uses about 1 minute of CPU time per 24 hours walltime, much less then bitcoin client running mostly in background.

A picture is worth a thousand words.  Here is a screen capture of a Mac Mini rig with three BFL USB devices running just under 70 GH/s. The low-end Mac is not even breaking a sweat... You probably need to figure out what processes are sucking up your CPU resources and kill them. I highly recommend http://fabulouspanda.co.uk/macminer/ and doing STM P2Pool mining at http://pool.fabulouspanda.co.uk:9332.

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


text:
How to use a watch-only wallet in Bitcoin Core?
I'm using Bitcoin Core v23.0.
It seems to support watch-only wallets by setting disable_private_keys=true during wallet creation.
$ bitcoin-cli -regtest createwallet "test" true
{
  "name": "test",
  "warning": ""
}

But when I try to import an address into it, the command fails:
$ bitcoin-cli -regtest -rpcwallet=test importaddress "bcrt1qpsw3ts4v3srzxqk7f797sxhn22xhwcc3cdq0xe"
error code: -4
error message:
This type of wallet does not support this command

The importpubkey command fails, too
$ bitcoin-cli -regtest -rpcwallet=test importpubkey "035310a2af27b41544204c544b6df18a3a7cc217498d740fb9d1212c3af9fd8010"
error code: -4
error message:
This type of wallet does not support this command

So how can I add a watch-only address to Bitcoin Core?
And is it possible to derive HD addresses using a watch-only wallet? (I know it's possible because Coinkite can do it)

If you're using Bitcoin Core 23.0, and created a new wallet using that, it is by default a descriptor wallet. These are a new generation of wallets which use Output Descriptors to determine which keys/scripts/addresses "belong" to the wallet, as opposed to legacy wallets which use a much less well-defined process to determine this.
Several RPCs, like the importaddress, importpubkey, and importmulti are disabled for descriptor wallets, for the simple reason that the behavior they have for legacy wallets cannot be exactly replicated for descriptor wallets. This is a good thing - it was extremely complicated to reason about what that behavior is.
If you want to import something into a descriptor wallet, you need the importdescriptors RPC instead. This single RPC subsumes the functionality of
all legacy import commands in a single RPC, by using the Output Descriptor language to specify what to import. That includes the ability to import single addresses (using addr([ADDR]) descriptors), or ranges of HD key-derived scripts (e.g. wpkh([XPUB]/0/1/2/*) would import all P2WPKH addresses derived from xpub [XPUB], with derivation path m/0/1/2/0, m/0/1/2/1, m/0/1/2/2, ...).
The documentation on developer.bitcoin.org seems outdated. The Bitcoin Core 23.0 RPC documentation (accessible through the help RPC command) does say:

Note: This command is only compatible with legacy wallets. Use "importdescriptors" with "addr(X)" for descriptor wallets.

getdescriptorinfo( wpkh(zpub...) ) says the key is invalid. Could you please explain why?

You need to use BIP32 xpubs/xprvs in descriptors. All these zpubs/ypubs/vpubs/... are not supported (as they're redundant, they try to convey the same information about how the key is to be used as the descriptor itself)

If I'm given an zpub, is there a path to convert it to xpub?

You really shouldn't. Whatever gave you a zpub probably did so for a reason. Converting it to something else may well be incompatible with that.

I see. I have read here - https://github.com/satoshilabs/slips/blob/master/slip-0132.md - and it made an impression that zpub is just a more advanced and self-contained version. What we're trying to achieve is have one person (e.g. a vendor) give me an extended public key, and me (e.g. a market) generate one-per-order receiving addresses for them with using bitcoin core rpc and that extended public key. Is that doable with relying on bitcoin core rpc solely? P.S. I feel like it's related ot the topic of "watch-only" wallet, since I'm not given private keys by the vendor.

"Whatever gave you a zpub probably did so for a reason." - actually, just because electrum only gives that for the newer wallets.

The complete answer can be found at:

answer by Pieter Wuille at Aug 3, 2022 at 15:55

The following steps takes a more practical approach. It's hoped that future interface updates will simplify this process further (today: January 2024):

On Bitcoin-Qt, first create a Wallet with "disabled private keys".
go to Window -> Console.

Obs.: The next steps could also be done directly from bitcoin-cli.

getdescriptorinfo "addr(bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw5tk9)"
Get the "descriptor" result field to be used later. (something like: addr(bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw)#6rmdcqux)
importdescriptors '[{"desc": "addr(bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw)#6rmdcqux", "timestamp": "now", "watchonly": true}]' (replacing the "desc" field by the output of "getdescriptorinfo" field "descriptor").
The output should be: [{"success": true}]
(Optional) Consider going to Window -> Receiving Address and add labels to your watch-only addresses.
(Optional) Consider editing the config file and add the walletnotify=<script> %s if you want to be notified. For example: walletnotify=xmessage "Funds had been moved: %s" -center (where %s will be replaced by the txid).

Please note that by setting "timestamp": "now" the blockchain won't be rescanned. Meaning that the you won't see old transactions and therefore a wrong balance had some bitcoins transferred in the past to the address specified.
You can specify "timestamp": 0 to have the client rescan the chain and add all transactions or provide a specific timecode at which to start rescanning.

Now an extra tip (perhaps not so related), but a piece of advice:
This kind of thing can be useful for you to know if a system has been breached. You place a private key (or seed) completely open, without a password, in the exact location where you want it to be "monitored". Set a reasonable prize value. Monitor this address using the steps above.
If the balance of the address changes, you know that system has been breached and you can try to take measures to minimize further damage.


text:
How to resolve error when trying to sign and broadcast PSBT transaction via electrum - (Witness program hash mismatch code -26)?
I'm trying to generate a 2-of-2 multisig transaction as a PSBT so that both parties can easily sign their transaction. I'm doing this all on btc testnet as a p2sh p2wsh transaction
When initially generating my PSBT, I get the following
70736274ff010052010000000118c739a0c061b892aefb3b2d93f9bca72c564ece339bf221946bddbd4c5b64390100000000ffffffff01bced0600000000001600146f01b2a5c8028a29f9631b6d494535fbd907e37a000000000001042200204b29bdce823c1afde68cc26012e49a913fc005a629748afbea7285d7ac281b7c010547522102dbbedff721dcdc7737c0e931c0473db3aadf4690f01dd5fc6da65188e21ecffd2102f4e91f49be47c24571e100c501cc50e9c499e744a25e51e2153d26b85660595252ae0000

After signing it with the first party's electrum wallet, i get
70736274ff010052010000000118c739a0c061b892aefb3b2d93f9bca72c564ece339bf221946bddbd4c5b64390100000000ffffffff01bced0600000000001600146f01b2a5c8028a29f9631b6d494535fbd907e37a0000000000220202f4e91f49be47c24571e100c501cc50e9c499e744a25e51e2153d26b85660595247304402207bdd58e7e837818b1bac12ee6615e48775c0354e3e0d22dd8ccf2d8afa0280bd022038f94ad49b245145e676a69d0af0233f0188b2b4bc88faec310de51f42cc18670101042200204b29bdce823c1afde68cc26012e49a913fc005a629748afbea7285d7ac281b7c010547522102dbbedff721dcdc7737c0e931c0473db3aadf4690f01dd5fc6da65188e21ecffd2102f4e91f49be47c24571e100c501cc50e9c499e744a25e51e2153d26b85660595252ae0000

Finally after signing it with the second party
0100000000010118c739a0c061b892aefb3b2d93f9bca72c564ece339bf221946bddbd4c5b643901000000232200204b29bdce823c1afde68cc26012e49a913fc005a629748afbea7285d7ac281b7cffffffff01bced0600000000001600146f01b2a5c8028a29f9631b6d494535fbd907e37a040047304402207bdd58e7e837818b1bac12ee6615e48775c0354e3e0d22dd8ccf2d8afa0280bd022038f94ad49b245145e676a69d0af0233f0188b2b4bc88faec310de51f42cc18670147304402202d567c1419632774faf1ee6d49849fd2842e4b0017dc0643a68753384e937e8b02204d0bf0da935129e1bf5babb68a4d9d60a9b9939211961ccc93e2827349d8601d0147522102f4e91f49be47c24571e100c501cc50e9c499e744a25e51e2153d26b8566059522102dbbedff721dcdc7737c0e931c0473db3aadf4690f01dd5fc6da65188e21ecffd52ae00000000

When I attempt to broadcast this transaction, I get "sendrawtransaction RPC error: {"code":-26,"message":"non-mandatory-script-verify-flag (Witness program hash mismatch)"}".
I've double checked to make sure I am signing with the correct keys and the amounts are correct so I'm lost on how to fix this. Any help is appreciated :)

In signing with the second party, the multisig script that is your witness script got messed up.
In both the initial PSBT and the first signing, we see that the witness script is
522102dbbedff721dcdc7737c0e931c0473db3aadf4690f01dd5fc6da65188e21ecffd2102f4e91f49be47c24571e100c501cc50e9c499e744a25e51e2153d26b85660595252ae

which is decoded as
2 02dbbedff721dcdc7737c0e931c0473db3aadf4690f01dd5fc6da65188e21ecffd 02f4e91f49be47c24571e100c501cc50e9c499e744a25e51e2153d26b856605952 2 OP_CHECKMULTISIG

This script has a sha256 of 4b29bdce823c1afde68cc26012e49a913fc005a629748afbea7285d7ac281b7c which matches the hash given in the redeem script of the input, and the redeem script has a hash of 4d3a0d4465e19bb387df92f5e052f24370718117 which matches the hash in the output script of the output being spent. This is all correct.
But when we look at the final transaction, the script for some reason is changed to
522102f4e91f49be47c24571e100c501cc50e9c499e744a25e51e2153d26b8566059522102dbbedff721dcdc7737c0e931c0473db3aadf4690f01dd5fc6da65188e21ecffd52ae

which is obviously different from the witness script originally. It's sha256 is 64b235d9fd37f2d68cb6edf19a25cc7765ef9c7299e3b448c86196cecd60feb0 which doesn't match the hash in the redeem script, so the script interpreter fails here.
This script is decoded as
2 02f4e91f49be47c24571e100c501cc50e9c499e744a25e51e2153d26b856605952 02dbbedff721dcdc7737c0e931c0473db3aadf4690f01dd5fc6da65188e21ecffd 2 OP_CHECKMULTISIG

Looking at these two scripts, we can see the second one has the keys flipped around. For some reason, the software you used to finalize the PSBT changed the positioning of the keys in the script, which has resulted in the final transaction failing.


text:
how to get bitcoin off an exchange?
As a corollary to asking how to transfer from cold storage, how is bitcoin first put into a paper, or other wallet, when it originates on an exchange?
My primary concern is more getting the coins out of an exchange rather than into a specific type of wallet or storage.

Just make a withdrawal to the address provided by your hardware or paper wallet? What is your confusion here?

if it's that simple, then that was the question.

At 48:30 in this video, a person in Japan purchases some bitcoin that is printed on a QR code. How did that vendor know what to print? And I'm assuming that printing something didn't actually do the transfer.
https://www.amazon.com/Magic-Money-Revolution-Vivienne-Pettitt/dp/B01N9I4XLE

Receiving funds in Bitcoin is an asynchronous and passive process.
A sender creates a transaction which consumes some unspent transaction outputs (UTXO) and assigns the freed-up value to newly created UTXO. A UTXO generally specifies an amount of bitcoin and some spending conditions that must be fulfilled to consume the UTXO. The most common spending condition schemas are represented with addresses.
As users of exchanges give fiat and/or cryptocurrency into custody of the exchange to gain access to the exchanges order book, the user must request a withdrawal to retrieve their funds. In the withdrawal request, the user must specify how to lock the funds which they do by providing an address from their wallet. The sending of a transaction is fully controlled by the sender: they merely sign over some of their funds to a locking script specified by the recipient in advance. The receiver's wallet does not need to sign-off, nor does it have a veto. It is therefore perfectly possible for the recipient wallet to be not connected to the internet and transcribed to a piece of paper as long as the recipient just knows how the corresponding address.


text:
Am trying to start mining litecoin with litecoin-qt
I have downloaded the litecoin-qt, since I read on a forum, with that I could start mining directly.
But in my screen, there is not a button for mining.
Have downloaded the cpuminer and have placed the file 'minerd' next to the litecon-qt programm in applications. They are together in one folder.
Not sure I have understood it well.
Is there someone that could give some ligth on this matter?
Would be very much appreciated.
thnx Adithya!

At some point they removed the GUI for mining from the litecoin-qt client. So you have to run minerd from the command-line or terminal.  The actual command syntax seems to be loosely documented, however.
Two reasons for this:

cpu mining simply is relatively too slow and unprofitable to warrant much further development.
Nevertheless the general consensus (at least according to the wiki and other available info) is that pooler/cpuminer is by far a better client in terms of speed, compatibility, usability, etc.

Also you can pick up a USB ASIC miner for ~$15 (usd) that will far surpass what a CPU can do today.
As far as the command syntax goes for CPUminer check out
https://bitcointalk.org/index.php?topic=55038.0
And scroll down to basic usage examples. Also may want to register at a pool first and have your login details ready.

will look for an usb asic miner. thank you for the suggestion.

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


text:
Can any Script opcode be used in the witness program, or only specific ones?
I was wondering, can one use an OP_RETURN in the witness script? If not, why not? Also, how could I figure this out from reading Bitcoin Core source? I looked at this file, and it wasn't quite clear to me how I might determine which opcodes are allowed in the witness script from this:
https://github.com/bitcoin/bitcoin/blob/e9262ea32a6e1d364fb7974844fadc36f931f8c6/src/script/script.cpp
But maybe I'm missing something.
I also looked through a couple BIPs, including BIP 143 and BIP 341, but they're kind of beyond my current skill level to understand how they might apply to my question.

The validation rules of Taproot scripts are specified in BIP342, you might want to check that out.

@VojtěchStrnad Good thinking, thanks!

I was wondering, can one use an OP_RETURN in the witness script?

Yes, you can, though I believe it is pointless. Executing an OP_RETURN opcode causes the script to return false immediately, marking the spend as invalid. As witness scripts are revealed only at spending time, this can only occur in an unexecuted branch (e.g. OP_0 OP_IF OP_RETURN OP_ELSE ... OP_ENDIF, where the OP_RETURN does occur in the script but is never hit). So I believe that any script with an OP_RETURN in it can be rewritten in a simpler/shorter way without it.
This is different from having an OP_RETURN in a scriptPubKey, as scriptPubKeys are revealed at creation time, not at spending time. A scriptPubKey of the form OP_RETURN <...> can never be spent (because spending it will cause the scriptPubKey to be executed, and thus fail), but it doesn't prevent the output from existing.

I looked at this file, and it wasn't quite clear to me how I might determine which opcodes are allowed in the witness script from this:

The script/script.{h,cpp} files only define the CScript data structure and some related functions. The validation rules regarding script execution are in script/interpreter.{h,cpp}.

I also looked through a couple BIPs, including BIP 143 and BIP 341, but they're kind of beyond my current skill level to understand how they might apply to my question.

BIP141 introduced segwit outputs, scriptPubKeys or P2SH redeemScripts of the form OP_n <witness program>, and permitted a new type of inputs (segwit inputs, which spend such outputs) which provide witness data not in the normal scriptSig, but in a new segregated witness section of the transaction data. As of today, there are 3 separate types of such outputs, each with their own validation rules:

Also introduced in BIP141, P2WPKH outputs have a scriptPubKey or redeemScript of the form OP_0 <20-byte hash>, where the hash is a public key hash. These outputs can be spent by revealing the full public key plus a signature with that key. No "real" script (with user-chosen opcodes) is ever revealed. The signature hash for these signatures is in BIP143.
Also introduced in BIP141, P2WSH outputs have a scriptPubkey or redeemScript of the form OP_0 <32-byte hash>, where the hash is a script hash. These outputs can be spent by revealing the full script (called the witness script), plus inputs to that witness script that make it evaluate to true. The semantics of scripts here only differs very slightly from the normal scriptPubKey script validation rules (which predate the BIP process), including for OP_RETURN. See the BIP under "New script semantics" for details.
Introduced in BIP341 are taproot outputs; scriptPubKeys of the form OP_1 <32-byte x-only pubkey>. Each of these can be spent in two different ways:

Using a key-path spend (also introduced in BIP341). This involves just a signature (using a Schnorr signature instead of an ECDSA signature, defined in BIP340), and no script execution of any type is involved.
Using a script-path spend (also introduced in BIP341). This involves revealing one of the scripts the taproot output committed to, together with a script version number. BIP341 however leaves the semantics of these scripts unspecified.

BIP342 specifies the script semantics for taproot script-path spends with script version 0xc0, called tapscripts. They are mostly the same as the P2WSH script validation rules, but there are more differences than BIP141 had compared to legacy scripts. The major differences include BIP340 signatures, a new sighash scheme (mostly reusing the BIP341 one, but with a few extensions), the removal of OP_CHECKMULTISIG and OP_CHECKMULTIVSIGERIFY, the introduction of OP_CHECKSIGADD, new resource limitations, and a few miscellaneous changes. OP_RETURN is not affected.
taproot script path spends with a script version number other than 0xc0 don't have any script semantics associated with them (yet), and are anyone-can-spend (but nonstandard).

scriptPubKeys and redeemScripts of the form OP_n <witness program>, where n is between 1 and 16, excluding taproot outputs, don't have any script semantics (yet). They're anyone can spend, but non-standard.

Regarding terminology:

The witness program is the 20-byte or 32-byte data element (pubkey hash, script hash, or x-only public key) pushed after OP_0 or OP_1 in the segwit scriptPubKey or redeemScript.
The witness script is the script revealed in a P2WSH spend.
The revealed script in a BIP342 spend is called the tapscript.


text:
Is a P2TR address a compressed public key?
From what I understand, a public key can be compressed from 64 bytes into 32 bytes, but an additional byte is needed for the sign, so it usually winds up being 33 bytes total. But P2TR addresses only do a PUSHBYTES_32. Am I incorrect in my understanding how compressed public keys work?

Pay to Taproot uses x-only pubkeys.
In Bitcoin, a private key d is a scalar, and its corresponding public key Q is the elliptic curve point found by multiplying d with the generator G of secp256k1: Q = d×G
For every x-coordinate on the secp256k1 curve, there exist exactly two y-coordinates that are each other’s negations: Q = d×G and -Q = -d×G
The authors of the Taproot proposal noticed that they could save a whole byte by dropping what essentially amounts to the sign of the public key at no loss of security by introducing a new serialization format called x-only pubkeys.

SEC encoded public keys are either:

Uncompressed 65-byte encoding: 0x04 + [32-byte X coordinate] + [32-byte Y coordinate]
Compressed 33-byte encoding:

0x02 + [32-byte X coordinate] (if Y coordinate is even)
0x03 + [32-byte X coordinate] (if Y coordinate is odd).

P2TR outputs don't use SEC encoded public keys at all, but raw "x-only" public keys, in which only the 32-byte X coordinate itself is revealed. The used BIP340 signature scheme is constructed in such a way that the Y coordinate does not matter.


text:
Fund Umbrel lighting wallet with BlueWallet?
Just set up Umbrel node. How does one fund the lightning wallet? Besides funding the Bitcoin Core wallet and sending to the lightning wallet.
I added BlueWallet and tried to send from there to my own lightning wallet/node but I get an API error (error 10) asking "does the receiver have enough inbound/don't have inbound capacity"?
Yeah, well I don't have any channels set up as I am trying to fund the wallet? Catch 22
thanks


text:
Where are my lightning routing fees stored (lnd), when do they get payed out?
I watch my lightning node (lnd) routing some amounts. And with lncli feereport I see some sums, let's say 700 sats for this week. But where are those sats? How can I lookup the accumulated routing fees for one channel (not in lncli listchannels) and when do these fees get payed out to my wallet?

The routing fees are charged with successful forwardings. Let's say you received 11 sats on one channel and forward 10 on another you have earned 1 Satoshi. This satoshi increases the total balance of your node and is technically added to the incoming channel. You could of course account the fee to the outgoing channel as that one defines the fee your node charges.
In that sense there is no separate payout of your routing fees as they always directly are added to your nodes balance.
In c-lightning there is a command listforwardings with which you can examine every forwarding and earned fees on a per channel level. If lnd does not expose such an api you could look in their database as they have to store every old state but that might be tricky.

Thanks Rene, I have found my rewards by comparing an old report in the lncli listchannels balance fields. I still don't understand all numbers - but making progress :-)


text:
bech32 serialized lightning invoice from lnd rest endpoint /v1/invoices
I am using the LND Rest API to create an invoice. As response I get something like
{'r_hash': 'Wchr...E=',
 'payment_request': 'lnbc210n1p....z9s',
 'add_index': '4',
 'payment_addr': 'Lyn...50='
}

According to LUD06 https://github.com/lnurl/luds/blob/luds/06.md I have to create a "bech32-serialized lightning invoice" from this.
Is the payment_request already bech32? Cause I can paste it in WoS and pay (think it's bolt11). Or how can I achieve that in python?

Yes, the payment_request is a BOLT11 invoice, which uses Bech32 encoding.


text:
Generate public addresses (NBitcoin)
I'm trying to generate a public address and for that, I have the code:
var key = new Key();
var wif = key.GetWif(Network.Main);

Console.WriteLine($"WIF: {wif}");

var secret = new BitcoinSecret(key, Network.Main);
Console.WriteLine($"Private Key: {secret.ToWif()}");
Console.WriteLine($"Public Address (Legacy): {secret.GetAddress(ScriptPubKeyType.Legacy)}");
Console.WriteLine($"Public Address (Segwit): {secret.GetAddress(ScriptPubKeyType.Segwit)}");
Console.WriteLine($"Public Address (SegwitP2SH): {secret.GetAddress(ScriptPubKeyType.SegwitP2SH)}");

When I pick the WIF and import it to Blockchain.com (for example), I only get the Legacy public address. Can the same private key sign Segwit and SegwitP2SH transactions?
How can I import a private key and get the Segwit and SegwitP2SH public addresses?
My knowledge about how this works is limited and I'm trying to learn...

Question was posted & answered on the NBitcoin repo, so copying my answers here for the benefit of SE members:

This is a Blockchain.com-specific UX issue... They technically could generate a Segwit address, but they default to P2PKH (legacy) at the moment.
WIF is an old format that doesn't carry metadata about the kind of address that should be unwrapped from the private key, so when you import a private key WIF into a wallet, it's up to the wallet to decide what kind of address to give you for that private key.
ps: Some wallets are "smart" and check all possible addresses (Legacy, Segwit, SegwitP2SH, ...) and then pick whichever one has a balance, so you might want to put some satoshis on the Segwit address that you create before importing the private key WIF to a wallet.

Private keys can be associated with public keys that are either compressed (33 bytes) or uncompressed (65 bytes), and the WIF will be different if compressed/uncompressed. For instance, compressed public keys start with L or K on Mainnet and c on Testnet, whilst uncompressed public keys start with 5 on Mainnet and 9 on Testnet.
You can modify your code sample above to use uncompressed public keys (the default is compressed):
var key = new Key(fCompressedIn: false);
// ...


text:
I somehow sent a transaction to my own wallet address
I wanted to make a transaction to a vendor but somehow I made it to my own address?
It is yellow color and I put very very low fee.
It is unconfirmed yet because of the fees.
Should I just increase the fee by a lot to get my coins back, worth 60£?
And will the coins add automatically in my wallet if both are on the same address?
I only need that ''Yes'' because I'm a rookie and dunno how this will happen.
Thank you.

Welcome to Bitcoin. The "balances" in Bitcoin are actually explicitly tracked bits and pieces. You can think of it akin to the coins and bills of cash: when someone sends bitcoins, the transaction explicitly states which coins or bills get spent, and describes which new ones to create. We call these bits of bitcoin unspent transaction outputs (UTXOs). In most Bitcoin transactions, the UTXOs you have in your wallet will not perfectly fit the amount you are trying to pay. In that case, your wallet software will automatically create a new UTXO that sends the remainder back to yourself. Imagine if you go to the pub and pay for a £3 pint with a £10 note. The bartender gives you £7 change. In Bitcoin, the equivalent to the £10 note would be you spending a UTXO from a previous transaction as an input to your new transaction. The transaction input consumes the £10 note and the transaction then creates two new UTXOs, one worth £3 for the bartender and one worth £7 for yourself.
What I'm trying to get at is, that in most transactions you will pay the receiver and yourself: in order to return the remainder as change to yourself. I am wondering whether that's what you are seeing in this transaction.
If you in fact only paid yourself, you're fine as well. You may have split your bitcoin funds into two UTXOs now, but your wallet is capable of using multiple of them in a transaction together.


text:
Connecting an Antminer to Bitcoin core
I have this in my bitcoin.conf:
rpcallowip=my_ip
rcpport=<port>
rpcuser=<username>
rpcpassword=<password>

The problem I am having is my Antminer with Braiins OS says “pool protocol not supported” when I use http://my_ip:port
or “invalid format of pool URL” when I use
my_ip:port
I used https://bitcointalk.org/index.php?topic=417997.0 and Solo Mine with an AntMiner to start.
The issue I need solved is getting my Antminer to connect to my Bitcoin Core so I can solo mine using my Bitcoin Core instead of connecting to CKPool or other solo pools.

Does this answer your question? How to setup bitcoind 10.2 for solo mining on LAN with Bitmain S3

bfgminer will not run at all I found another way on bitcoin talk where you make a stratum proxy on a raspberry pi and point that at your computer and point your miner at the raspberry pi. I will test this method to see if it works.

if it works, please help other people like you by posting your solution in the "Your Answer" box below.


text:
Signing taproot key-path transaction from rust-bitcoin
I'm trying to make a taproot HTLC using rust-bitcoin for an atomic swap protocol. My plan is that in the "happy case" of my protocol, the coins are spent with the key-path, and then there is a tapleaf for the "refund" case (after n blocks, the original owner can spend), and a tapleaf with a hashlock.
Assuming I have functions to build up the hashlock and timelock scripts, I'm building some TaprootSpendInfo and a receive address as so:
let taproot_spend_info = TaprootBuilder::new()
        .add_leaf(
            1u8,
            build_hashlock_script(alice_hashlock.as_slice(), &bob.hl_keypair.x_only_public_key().0)
        )
        .expect("couldn't add hashlock leaf")
        .add_leaf(
            1u8,
            build_timelock_script(2, &alice.refund_keypair.x_only_public_key().0)
        )
        .expect("Couldn't add timelock leaf")
        .finalize(
            &secp,
            alice.escrow_keypair.x_only_public_key().0
        )
        .expect("Could not finalize taproot spend info");

    let alice2bob_addr = Address::p2tr_tweaked(taproot_spend_info.output_key(), Network::Regtest);

I go and fund that address. Then when I want to spend from that address with the key-path, I make a transaction and get the sighash as so:
    let mut keypath_tx = Transaction {
        version: 1,
        lock_time: PackedLockTime::ZERO,
        input: vec![ TxIn {
            previous_output: OutPoint {
                txid: first_funding_txid,
                vout: 0
            },
            script_sig: script::Builder::new().into_script(), // this might be wrong
            sequence: Sequence::ENABLE_RBF_NO_LOCKTIME,
            witness: Witness::new(),
        }],
        output: vec![ TxOut {
            value: Amount::from_btc(0.99).unwrap().to_sat(),
            script_pubkey: miner_address.script_pubkey()
        }]
    };
    let sighash = keypath_tx.signature_hash(0, &script::Builder::new().into_script(), 0x00);
    let hash_to_be_signed = sighash.as_hash();

And then I take that sighash and sign it with libsecp:
    let message = secp256k1::Message::from_slice(&hash_to_be_signed).unwrap();
    let signature = secp.sign_schnorr(&message, &alice.escrow_keypair.secret_key().add_tweak(&taproot_spend_info.tap_tweak().to_scalar()).unwrap().keypair(&secp));
    keypath_tx.input[0].witness.push(signature.as_ref());

When I try to broadcast this transaction, I get an error Invalid Schnorr signature.
I think I'm adding the signature to the witness correctly: BIP341 says that if after removing the annex from the witness (if it's there), if there is one item left, it's interpreted as a key-path spend and the item is interpreted as a signature. So I think pushing the signature into the otherwise empty witness is the right thing to do. I also checked that the signature is valid. That makes me think that I'm either signing the wrong thing or that I'm not tweaking the private key correctly at signing time.
My only taproot experience so far has been with descriptor wallets, so any tips about what I'm doing wrong would be greatly appreciated. Thanks!

It looks like you're using the Transaction::signature_hash method to compute your signature hash -- this is used to compute legacy (pre-segwit!) signature hashes, and we've been unfortunately very slow in deprecating it. I believe the next release of rust-bitcoin will have better documentation and a deprecation notice.
The new way to compute sighashes, which supports segwit and taproot, is to put your transaction into a SighashCache which can then be used to compute sighashes for each input. This structure caches hashed data which is the same for every input -- something both segwit and taproot sighashes were designed for, but legacy sighashes were not -- which is why it has a less convenient API. But on the other hand, it should be much faster.

That's helpful. Thanks!

For any future devs who stumble upon this, the other bit I was missing is you need to make sure the schnorr sig is properly encoded like so:
let final_sig = schnorr::SchnorrSig { sig: signature, hash_ty: SchnorrSighashType::All };

and then insert it into the witness like:
keypath_tx.input[0].witness.push(final_sig.serialize());

the answer above combined with the comments should be enough to have it working, I wanted also to share it all together in case it may be easier for others to follow through on it.
serialize and Prevouts imports are from bitcoin::psbt
fn sign_key_tx(
    secp: &Secp256k1<All>,
    tx_ref: &Transaction,
    prevouts: &Prevouts<TxOut>,
    key_pair_internal: &KeyPair,
    tap_info: &TaprootSpendInfo,
) -> Transaction {
    let mut tx = tx_ref.clone();
    let sighash_sig = SighashCache::new(&mut tx.clone())
        .taproot_key_spend_signature_hash(0, prevouts, SchnorrSighashType::AllPlusAnyoneCanPay) // or All
        .unwrap();

    let tweak_key_pair = key_pair_internal.tap_tweak(secp, tap_info.merkle_root());

    // then sig
    let msg = Message::from_slice(&sighash_sig).unwrap();

    let sig = secp.sign_schnorr(&msg, &tweak_key_pair.to_inner());

    //verify sig
    secp.verify_schnorr(&sig, &msg, &tweak_key_pair.to_inner().x_only_public_key().0)
        .unwrap();

    // then witness
    let schnorr_sig = SchnorrSig {
        sig,
        hash_ty: SchnorrSighashType::AllPlusAnyoneCanPay, // or All
    };

    tx.input[0].witness.push(schnorr_sig.serialize());

    tx
}

Hope it helps!


text:
How to restore a wallet with only the master private key
The wallet is damaged, I only have the encrypted master private key and password, is it possible to recover the wallet?

Which wallet software application (and version) were you using?

Generally a master private key and password sounds good, but it is hard to say more without a bit more background information.

@Murch,I am using bitcoin core

@Murch, I am asking for help because I am a novice.

@RedGrittyBrick ,Using bitcoin core

Uh, in the above comment, was that your private key or just an example? I have deleted so that fewer people can see it, and will look to redact it, but I hope you did not just post your private key.

@Murch , It's just an example key, do you have a way to retrieve the private key?

Ah good. I restored your prior comment. Sorry, I do not know from the top of my head how to restore a wallet just from a single key. I expect that someone will be able to help you out, though

The version is not clear, around 2011 bitcoin core

How to use this way to restore private key?https://bitcointalk.org/index.php?topic=5093956.0

The master private key is extracted from mine wallet.dat, now wallet.dat is damage and lost, who can help restore private key, can be rewarded

@RedGrittyBrick: Only the master private key similar to this example mkey:a978c07e3d05c91a5442ee2f8211e02e011f6abdec8e23032b7eb1298ed661fb9ebcd7388b3963b527a2923cce6800ea  like salt:e4aa72cd2bfa00cd  iterations: 60435

The key that you have retrieved from Bitcoin Core is not a master private key. It is the master encryption key for the wallet. This is local to that wallet file only and does not have any relation to the private keys that are used to spend the Bitcoin. If you have only that, there is nothing that can be recovered as the actual private key material is not present.

So far as I can tell, Bitcoin core (as of v23.0) has no obvious facility to import a master private key and use that key as the basis of a hierarchical deterministic (HD) wallet.
It has a facility for importing ordinary private keys of the sort that were generated before implementation of HD key derivation, but I doubt that would do anything useful with a master private key.
As we all know, what Bitcoin Core's developers intended us to do is to use the "Backup Wallet" option in the "File" menu and put copies of that in safe places on other devices. Then restore from one of those backups if the active wallet is damaged or lost.
In the "File" menu under "Create Wallet" there is a checkbox option to "Make Blank Wallet" whose tooltip says

"Blank wallets do not initially have private keys  or scripts. Private keys and addresses can be imported, or an HD seed can be set, at a later time".

However I believe you don't have the HD seed, only a master private key derived from such a seed (as I understand it from BIP32).
I suspect that in principle, it is theoretically possible to construct from a master private key, an empty wallet.dat file of the sort that Bitcoin core might create when first run and before it has started an initial blockchain download (IBD) or built any indexes or UTXO sets etc. Then that reconstructed wallet.dat file ought to be usable with Bitcoin core. However I do not know of any tool to do this.

Related:

Importing an arbitrarily created Master Private key to Bitcoin Core

Developer reference for sethdseed

Argument #2 - seed
Type: string, optional, default=random seed
The WIF private key to use as the new HD seed.
The seed value can be retrieved using the dumpwallet command. It is the private key marked hdseed=1

I find this confusing but I think the HD seed and master private key are different things

BIP32

Note: S is not m and HMAC-SHA512 is not reversible

Decrypting encrypted keys:

How to use OpenSSL to encrypt/decrypt files? especially the answers that mention the -iter, -salt and -K (key) options. I have not tried this myself. A careful search may reveal other specialised tools more suited to your purpose.

Can the primary private key be turned to hdseed? And this primary key hash with the AES256CBC plus SALT and iterations, how to decrypt?

@nikon: The BIP32 diagram shows m is derived from S using HMAC-SHA512 which is not reversible.

@nikon: to decrypt encrypted data you need any tool that supports the encryption algorithm (AES-256CBC), the parameters you have and the encryption key (for the wallet)

Yes, it is possible to recover (replicate) the wallet if you have a BIP-32 master private key. There is the command: [importdescriptors][1] to use the master key in a wallet in Bitcoin Core. It's not strightforward, though. The master key must be transformed into so-called Output Script Descriptor in order to be accepted by the command.
There are other software packages that will make it easier to use a BIP-32 master private key, e.g. Electrum, Sparrow, https://iancoleman.io/bip39/.