Bitcoin client behavior in event of a fork

In the case of a reorganization, the transactions that were 'lost' in the previous longer chain are moved back to the memory pool, under the condition that they are valid in the new chain. This means that if the inputs do not exist anymore in the new chain, they are lost. This is precisely how a "double spend attack" works: try to fork the chain, and spend the coins in both branches.

The effect of moving transactions back to the memory pool is only that the client does not forget them (it will not reannounce, or download them from peers when told about them), and if the node is a miner, they will be candidates for inclusion in the next block created.

In general, this means that there are no retransmits: miners and the rest of the network try their best to not forget about these lost transactions. If that fails however, and for some reason (too little fee, for example) the transaction does not survive, it is the responsibility of the node that originally sent the transaction out to rebroadcast. So yes, there are retransmits as well, but only by the original owner, and only when it detects the transaction is not or no longer in the block chain.

It's always a byte-for-byte identical transaction, not an equivalent using different inputs.


how Bitcoin Benefits from giving u s currency(other then money from ads)

"Bitcoin" is not a company. Bitcoin is an open-source project and a lot of people are working on it. And an open-source project does not need to get rich. The intention of a big part of that community is more like "changing something".

  How does Bitcoin benefit from giving us money for solving math problems?

You did probably not understand that "solving the sha256-algorithm (that's what solving math problems means)" secures the network by preventing double-spends.


In what ways could Bitcoin prevent "deficit financing of wars"?

There are two meanings to "deficit financing":

Funding something by minting new currency.
Funding something by borrowing.

Obviously, you can't change how fast you mint Bitcoins. Perhaps that's what he meant. It tends to not be very useful, though.

However, it's very possible to have debts denominated in Bitcoin, just as you can have debts denominated in silver or gold. In the Seven Year's War, which lasted from 1754 to 1763, France ran up quite a lot of debt, and they didn't need any of your fancy financial institutions to do it.


When was the first GPU miner made available publicly?

This post from SmokesTooMuch seems to be the first time GPU mining was suggested:

Suggestion :
Since the coins are generated faster on fast machines, many people will want to use their GPU power to do this, too.
So, my suggestion is to implement a GPU-computing support using ATI Stream and Nvidia CUDA.

Here's satoshi in December 2009 asking for people not to use GPUs to mine:

We should have a gentleman's agreement to postpone the GPU arms race as long as we can for the good of the network.  It's much easer to get new users up to speed if they don't have to worry about GPU drivers and compatibility.  It's nice how anyone with just a CPU can compete fairly equally right now.

So it seems the idea was around for a long time before the savages broke the gentleman's agreement.  :)


How to set Bitcoin-Qt setgenerate mining recipient?

By default, Bitcoin-QT will generate new addresses to mine to.  If you use the Encrypt Wallet feature, it appears to always mine to the same address instead, but it's still not user-selectable.

If you do want to CPU mine to a specific address (e.g. for testing on the RegTest mode), you can use mining software like cpuminer/minerd in "solo mining" mode to do so.


How do I find out the reward value of a generated block

The information you get for a getblock call doesn't seem to include the block reward. You could find it with a gettransaction call for the first transaction, but bitcoind only allows lookup for transactions in your own wallet, so that won't work either.

So indeed, as Diego points out, the only option is to look at the block height. This wiki page lists the different reward values for the different block height intervals.


Bitcoin -> prepaid VISA/Mastercard service (2014 edition)?

There is not a single available solution to go to a general VISA/MC/AMEX card in the US today. Money Transmitter laws (and a host of other regulations) make this a very difficult proposition at the moment.

Some other countries don't have the same issues today, like Canada http://paymentweek.com/2013-11-4-canada-introduces-bitcoin-debit-card-services-238461/ but these solutions are also still in development.


How to make a transaction with locktime on testnet?

Note: Although this answer is written for testnet, it is absolutely valid for the mainnet as well. The script will be similar, just the address encoding will be different (P2PKH start with 1 vs m for testnet as we use 0x00 as prefix in address base58check in mainnet).

  I tried to make transaction with Locktime on bitcoin testnet. I am not able to broadcast it.

When nLocktime is specified, you cannot broadcast the transaction until that nLocktime value is reached. In your case, when writing this answer, the testnet height was at 1567414 while nLocktime is set as 1567415. Other than that your transaction is correct from a script point of view.

  And how to use CLTV and CSV?

CLTV and CSV are script level timelocks, unlike nLocktime and nSequence which are transaction and input level timelocks. CLTV or CSV are specified in the output locking script, and when spending those outputs, the user must set the nLocktime or the nSequence value to satisfy the locking condition.

CLTV

Using your example, below will be the script for CLTV in the outputs and the hex of the outputs. The desired block height is 1567415 which is 0x17eab7 in hexadecimal and 0xb7ea17 in little-endian. nLocktime value should be equal or greater to this number in order to spend the outputs that are locked with CLTV. So, for this transaction to go through nLocktime value should be equal to or lower than the current block height which is equal to 0x0017eaae (1567406) or 0xaeea1700 in little-endian. However, do note that when spending this output that is locked with CLTV as an input in a transaction your nsequence should be between 0xf0000000 to 0xfffffffe. Using 0xffffffff disables timelock.

"vout": [
            {
                "value": 0.01700000,
                "n": 0,
                "scriptPubKey": {
                    "asm": "b7ea17 OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 083b56fb8b320a6373d4738bb81496b096e8034c OP_EQUALVERIFY OP_CHECKSIG",
                    "hex": "03b7ea17b17576a914083b56fb8b320a6373d4738bb81496b096e8034c88ac",
                    "reqSigs": 1,
                    "type": "pubkeyhash",
                    "addresses": [
                        "mgGUnb6BhgxzrjWau4X4WD9Lfp9YS4kMy7 "
                    ]
                }
            }
        ]

Using this output to your unsigned transaction hex, it gives the following script:

Raw transaction before signing:
020000000140c96a4c43a5db3c57be3fd92f491a5d40ccf00afe349c596bc35fac7bbee59a000000001976a914a9156a64ea643e7c4db772c96c6a570712e0cc1988acfeffffff01a0f01900000000001f03b7ea17b17576a914083b56fb8b320a6373d4738bb81496b096e8034c88acaeea170001000000

CSV

CSV is a relative timelock, so the height of the blocks in relative sense is provided. For example, in your case the testnet height was at 1567406 while you wanted the transaction to be spent at height 1567415. So your relative height is 9 blocks. We are using nLocktime for the current transaction to be the current block height which is 0xaeea1700 in little-endian.

"vout": [
            {
                "value": 0.01700000,
                "n": 0,
                "scriptPubKey": {
                    "asm": "09 OP_CHECKSEQUENCEVERIFY OP_DROP OP_DUP OP_HASH160 083b56fb8b320a6373d4738bb81496b096e8034c OP_EQUALVERIFY OP_CHECKSIG",
                    "hex": "0109b27576a914083b56fb8b320a6373d4738bb81496b096e8034c88ac",
                    "reqSigs": 1,
                    "type": "pubkeyhash",
                    "addresses": [
                        "mgGUnb6BhgxzrjWau4X4WD9Lfp9YS4kMy7 "
                    ]
                }
            }
        ]

Using this output script in the unsigned transaction hex you specified gives us:

Raw transaction before signing:
020000000140c96a4c43a5db3c57be3fd92f491a5d40ccf00afe349c596bc35fac7bbee59a000000001976a914a9156a64ea643e7c4db772c96c6a570712e0cc1988acfeffffff01a0f01900000000001d0109b27576a914083b56fb8b320a6373d4738bb81496b096e8034c88acaeea170001000000

When spending this CSV locked outputs, you will need to keep a few things in mind: (1) nSequence <= 0xEFFFFFFF; (2) nSequence's 22nd bit determines if the relative lock-time is time-based or block based. This bit should be set to 0 since your CSV is locked in blocks; (3) The value of the relative locktime, is then interpreted from the first 16 bits of the nSequence.

Although I have shown the locking scripts in its raw form (using CLTV/CSV) in scriptPubKey, it is recommended to create a P2SH locking script out of this raw script. This not only ensures that you pay lower fees for making this transaction, but also ensures your privacy (nobody will know that they transaction is timelocked) until you spend that transaction.


Where is a tx located before finalized with the sequence number or locktime?

The tx is located with the person who created it. Nodes will not hold onto the transaction because it is not ready for the mempool. The only places a node will hold someone else's transaction is in the mempool or in the blockchain so a node will not store a non-final transaction anywhere.

It is up to the transaction creator to hold onto the transaction and not lose it until they can broadcast it after the lock time has passed.


The current testnet is on its third iteration, somewhat unimaginatively titled testnet3.

It was put that way by this commit:

  Testnet, Mark III

  gavinandresen authored 2012-04-12

Before that, we had testnet2: (though we didn't call it that back then)

  Reset testnet with a new genesis block

  davout authored 2011-02-03

Before that, testnet:

  Gavin's TEST network as -testnet switch, misc fixes
  git-svn-id: https://bitcoin.svn.sourceforge.net/svnroot/bitcoin/trunk@168 1a98c847-1fd6-4fd8-948a-caf3550aa51b

  s_nakamoto authored 2010-10-19

Man, sourceforge. Brings ya back, doesn't it?

Essentially, the devs want testnet coins to be worthless for two reasons:

to make them easy to mine
because it's nice to have a place to demonstrate attacks against bitcoin without actually disrupting the network. You can show that an attack is valid without costing people real money.

Now that I think of it, we're due for a new testnet soon. Sell those testnet coins!


Bitcoin Core client upgrade from V0.7 2-beta to latest 0.15.X (Oct2017) - ‘wallet.dat’?

You don’t need to touch the wallet file (but back it up), the format hasn’t changed and is safe to upgrade on top of.


I'm not completely sure if this is what you are looking for, but it may be.

Here you have a type of transaction that takes 3 minutes to verify, and that was reported back in 2013. (CVE-2013-2292). Moreover, in Sergio Demian Lener's blog you can find a related topic, where he explains how he found a vulnerability that used the FindAndDelete function and OP_CODESEPARATOR to create a transaction that toke up more than 5 hours to verify.


bitcoin listunspent showing an address which does not belong to my wallet

If you have sent and received Bitcoin before, then this output is likely a change output.


TL;DR Bitcoin already is a currency because it's a generally accepted medium of exchange among certain communities. As those communities grow and usage spreads to other communities, its strength as a currency solidifies.

This requires a little bit of history. I am not a numismatist, but I have studied this a little even before the advent of Bitcoin.

Currency is a set of things that are a generally accepted medium of exchange.

Throughout history, an accepted medium of exchange has been anything of value to both people involved in the transaction. Typically, these are physical goods that have some semblance of inherent usefulness and a degree of rarity. Also, there is typically a perceived finite supply of the thing. Lastly, the importance of portability is generally high: if it is cumbersome to carry enough of the thing to make daily purchases, it is less likely to be an acceptable medium of exchange because no one will want to carry it around with them!

So, I've set the stage for most world currencies: small, portable coins comprised of precious metals. The metals can be used in products and are rare in that it takes work to extract them from the earth. The supply is thus finite, until another deposit of the metal is discovered. That's when the overall value of the coin may drop compared to other things, but at its simplest explanation means that
the coin metal has become less rare.

This kind of coinage started organically. People could give each other a weight of metal and know what its value was to them. Eventually, as governments were established, governments would gather up all the metals they wanted by whatever means necessary, and then melt the metals in order to mint coins with an intended, consistent value because of their weight.

As the price of goods increased steadily, it was impractical for a person to carry a sack of coins, so someone contrived the bright idea of paper money, and later, a bank note.  These are simply a promise that a person can exchange that note for the coins related to it. Thus, this paper money or bank note used to be simply a proxy to more valuable coins or other forms of metal.

However, this is prone to interference by those who print the notes and the governments that oversee it all. Eventually, paper notes became backed by promises for coins and metals that didn't exist. So, the value of the notes in relation to the coins and metals decreased. Then banks stopped accepting notes in exchange for coins.

What resulted is called fiat currency, which has a value simply because some government declares it to have value. It actually more closely related to debt, but that's a complex subject for another question.

A chief problem of fiat currency is that a bank or a government can simply print more bank notes in order to create more money. This works in the short term, but any savvy person will realize the similarity of this to someone finding a new deposit of a metal. When there is suddenly more of something, what existed of that something is suddenly less valuable because it is less rare. This does not matter a whole lot when there is only one thing of value. When there are many things of value, e.g. silver, gold, platinum, diamonds, oil, other fiat currencies, the value of our something compared to those will be affected.

All of these things are usable as currency but some are more practical than others.

Bitcoin is similar, but more abstract. Bitcoin has no inherent usefulness: it's just data. It does have rarity: the supply is finite because only 21M coins can exist. The available supply is growing by the minute, but there will be a day when no more will be "found" there by halting its inflation in value. Instead, at that time, its value will begin to deflate as coins are permanently lost for one reason or another.

Bitcoin's inherent uselessness as a physical good -- data -- contributes to another factor: its portability. It's just data and we can sure store a lot of data in a small physical space. This property makes it almost infinitely portable. A billionaire could carry their life savings in their pocket on a Flash drive and no one else could have control of the physical thing that is their life savings.

Creating a currency when the physical thing has no inherent usefulness requires that initial participants assign a value to it. It's a fiat currency, but the value isn't controlled by any central authority. No central authority can create more of it. No central authority can destroy it. This is not to say that an authority cannot destroy it, because a government sure could pass laws to prohibit its exchange/possession/production.

In its infancy, Bitcoin has limited intra-economy value, that is, it has limited value as something that can be exchanged for payment for work or goods simply because not a lot of people have boldly decided to accept it with the hopes that they can spend it on something they need. This value grows daily as more businesses start and more people believe that they can spend what they accept in it.

Bitcoin at this stage is no different from arcade tokens, in-game currency, or Monopoly money used in schools to teach children how money works: it has a limited value to a limited audience. It is currency to those who participate in this limited audience, and its inherent value (not necessarily its value relative to other traditional currencies) grows as the audience grows.

To add another question to the original: How can the strength of Bitcoin as a currency grow? The answer is quite simple: use it! Find something to buy with it, find something to sell and accept it as payment. Keep this cycle going and get others involved.


Does bitcoin mining need a lot of internet bandwidth

Bitcoin mining doesn't require much bandwidth at all!

It's worth noting that the higher the hash-rate of your rig, the more bandwidth it will require (as you will get through work units faster - downloading new ones and feeding back more frequently).

Seeing as though you are planning to use guiminer, you most likely won't use much bandwidth (most high-performance mining is now done with dedicated equipment as opposed to GPU/CPU mining).

If you're new to mining bitcoins, these sites might be of interest to you:

https://www.bitcoinmining.com/
https://en.bitcoin.it/wiki/Mining


Cant start bitcoind - "Block files have previously been pruned"

The message says

2018-11-16T09:16:48Z LoadBlockIndexDB(): Block files have previously been pruned
2018-11-16T09:16:48Z : You need to rebuild the database using -reindex to go back to unpruned mode.  This will redownload the entire blockchain.
Please restart with -reindex or -reindex-chainstate to recover.

If you have been running in pruned mode, bitcoind has been pruning the blockchain. This means it has discarded data to save disk space.
To run in non-pruned mode you must recover the missing data. The method provided is to download the entire blockchain again.
The only obvious alternative is, presumably, to run in pruned mode.

Related questions:

How can I run bitcoind in pruning mode?

Related links:

https://bitcointalk.org/index.php?topic=1599458.0 (August 2016)

OK, I have a question. Say: I enabled prune mode and Bitcoin Core effectively started working in this mode. But it is one way ticket if I ever want to go back to 'full' mode I need to download and verify whole blockchain once again there is no shortcuts?

Yes, you will have to redownload the entire blockchain, there are no shortcuts


Where can I find a complete list of Bitcoin forks (soft, hard, intentional and unintentional)

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

Here is the list of Forks so far,

The following content is sourced from the above paper,

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


How can I test if a bitcoin address is compressed or not?

You cannot determine (from only a base58check address) if the corresponding public key is compressed.

A "normal" pay-to-public-key-hash (P2PKH) is a cryptographic hash of either a compressed or an uncompressed public key. Because hashes cannot be feasibly reversed, you cannot tell if the public key, before being hashed, was compressed or uncompressed.

More specifically, a public key in Bitcoin is a pair integers (x,y). For uncompressed public keys, these integers are encoded as 256-bit unsigned big-endian ints, concatenated together, and then prepended with a single 0x04 byte. The result is 65 bytes long.

For compressed public keys, only the x coordinate is encoded (like above, as 256-bit unsigned big-endian int). It turns out that the y coordinate can only be one of two values, one even and one odd. Instead of prepending a single 0x04 byte, a single 0x02 or 0x03 byte is prepended depending on y's value (0x02 for even, 0x03 for odd). The result is 33 bytes long.

Finally, these bytes (from one of the two paragraphs above) go through the address conversion process described here in the bitcoin.org Developer Guide, which includes taking an irreversible cryptographic hash (actually, two hashes).

Note that in order to redeem a UTXO associated with a P2PKH address, the redeemer must create a transaction which includes the unhashed public key, either compressed or uncompressed. If such a tx exists in the blockchain, it can be connected to its "normal" base58check address. This is one of the reasons why address reuse is discouraged: once you redeem a UTXO, you "reveal" your public key, which is slightly more sensitive than your bitcoin address.


How to get destination address from bitcoinj TransactionOutput?

TransactionOutput.getScriptPubKey.getToAddress.toString

Unfortunately, this gives an exception when dealing with an oldstyle pay-to-IP script, so you might have to deal with these yourself if you need them (which in your use case you probably won't). An example can be found in the Scala code from the link below (from line 120 on):

https://github.com/stefanwouldgo/Bitcoin-Graph-Explorer/blob/master/src/main/scala/Graph.scala


Bitcoin client 0.4.1.1 stuck at block 176947

I just downloaded version 4.4.1.1 to try to reproduce your problem, but couldn't.  Here's the beginning, and relevant mid-section of the debug.log file when I ran it on a machine which I hadn't used for a month or so:

Bitcoin version 0.4.1.1-beta
Default data directory /home/user/.bitcoin
Bound to port 8333
Loading addresses...
dbenv.open strLogDir=/home/user/.bitcoin/database strErrorFile=/home/user/.bitcoin/db.log
Loaded 19026 addresses
 addresses              1337ms
Loading block index...
LoadBlockIndex(): hashBestChain=000000000000052e27b6  height=173760
 block index           13603ms
Loading wallet...
[...]
SetBestChain: new best=0000000000000959beb5  height=176945  work=302325188992488282894
SetBestChain: new best=000000000000011c616f  height=176946  work=302331966182716897933
SetBestChain: new best=000000000000052c233f  height=176947  work=302338743372945512972
SetBestChain: new best=00000000000002c5eaa8  height=176948  work=302345520563174128011
SetBestChain: new best=000000000000089bf6dd  height=176949  work=302352297753402743050

Maybe you could show us yours?  I tend to agree with Stephen that it's likely a disk space problem.


Multibit transactions unconformed since august. Where is my money?

Probably it's due to a low fee. If you see the TX in blockchain.info or similar, you can view the satoshis per byte you paid for fee. Today (12Dec17), it's recommended to pay at least 100 satoshis per byte.

To try to fix your problem, you can reset multibit by clicking on Tools > Reset Blockchain and transactions, and wait to re-sync, as seen here

Hope it helps you


How could a lightweight wallet determine the validity of 0-conf transaction?

Zero-confirmation transactions can easily be double-spent by another signed transaction spending the same UTXO, but with an arbitrarily higher fee, thereby achieving a higher likelihood of being mined first, rendering the original transaction invalid.

A merchant still needs a full-node to accept new transactions to the mem-pool, because it needs to validate each new transaction it sees.

A lightweight wallet does not have the same security as a full-node, because it relies on verifying the accumulated POW, and not the actual transaction validity. The assumption is that the chain with the most accumulated POW must be valid.


Get last price from Comkort exchange PHP-JSON

This is probably due to your web server php configuration that disallow you to open a remote url (see this thread https://stackoverflow.com/q/3488425/2652054 )


You can use the "File | Open" menu option to open an existing wallet.
A file chooser opens and you can navigate to where your wallet is stored to open it.

Note that in the older code (v0.4.23 and before) your wallet does not automatically resync when you open it. You have to do this manually with a 'Tools | Reset blockchain and transactions'.

The current version (v0.5.9 or later) automatically resyncs wallets when you open them.


Bitcoin transactions over Ripple Network

As you already have described, Ripple transactions are based on exchanging IOUs. As such, when you trade bitcoins on the ripple network, you are trading IOUs denominated in Bitcoin owed to you by some party, e.g. BTC owed to you by Bitstamp. Therefore, as long as the transaction is between Ripple users, it is completely off-chain and can be confirmed within seconds.

However, there is at least one Ripple Bitcoin bridge which is offered by Bitstamp. This bridge allows Ripple transactions to directly end in on-chain Bitcoin payouts. It works by having a Ripple transaction send money to Bitstamp, who then converts the amount and sends Bitcoin to the recipient. The Ripple side takes the regular short time to confirm, the Bitcoin side is a regular on-chain transaction though, which will be confirmed as usual in the next Bitcoin block.


How bitcoin protocol checks transaction is valid (in particular that inputs are unspent)?

Yes, you've basically got it.

Regarding multiple outputs, the solution is quite simple.  Your input, instead of just specifying a transaction to spend, instead specifies a particular output of a transaction.  So instead of your input saying "I am spending transaction abc123", it says "I am spending output #2 of transaction abc123".

Every full node on the Bitcoin network maintains a database of unspent transaction outputs or UTXOs.  It is indexed by transaction ID and output number.  So when a node sees your transaction, it will mark transaction abc123 output #2 as spent.  Outputs #0 and #1 of that same transaction have their own independent entries in the database and so their states are unchanged; if they have not been spent previously, they can be spent by some later transaction.


How to get transaction with Bitcoin Core?

Can you right now put txindex=1 in your bitcoin.conf on both, and restart your node? That will cause a failure if the database was not created with txindex. If it continues, and there are still transactions that can't be found by getrawtransaction, file a bug report on https://github.com/bitcoin/bitcoin/issues.


My guess is that you are using weak passphrases to generate your keys. This is a common mistake with brain wallets. It is well known that there are bots that scan the blockchain for any unspent coins contained in an address generated from a weak passphrase and takes it for itself. I've not heard of a bot that looks at multisig p2sh addresses for weak passphrases, but I'm not surprised that it exists. It's not that much different than looking for weak passphrases in a standard pay to pub key transaction.

The reason why I think this is the case is because your coins get taken from the multisig address after you've made one transaction from the multisig address. When you make a transaction from the multisig address, you reveal all the public keys that the multisig address is associated with. If the passphrase associated with the key is weak, the private key can be cracked by the bots and your coins will be gone.

If your coins were taken before you've made a transaction from the multisig address, this could mean that your computer or the brainwallet generator is compromised. It is also possible that there is a bot that can crack a p2sh multisig address without knowing the public keys (this is doable but since the search space is bigger it would be harder for the bot).  But since this is not the case, it seems pretty clear that you are using weak passphrases to generate your keys.


Lightning Network `channel_update` message Flag clarification

The flags field (2 bytes) has been split into two different (1 byte) fields, the message_flags (most significant bits) and the channel_flags field (least significant bits). Hence the flags value displayed in lnd has the message_flags byte set to 0x00 and the message_flags set to 0x01.

message_flags indicates that this channel_update has some optional fields appended to the end. In this case it has the 0th bit set, which corresponds to the option_channel_htlc_max option, hence the channel_update has an additional field htlc_maximum_msat appended.


Can anyone explain me why I can not buy coins at the advertised price

That was the lowest price in the past day, not the market price.


How key chain works for Bitgo multi-signature wallet?

Anyone who has 2 out of the 3 private keychains (the private component of each keychain) can spend the Bitcoin. If you were hacked and the hacker was able to obtain 2 out of the 3, then they can spend your Bitcoin.


Can a miner's hashrate be derived from shares submitted at a given difficulty?

hashes = shares * share_difficulty * 2**48 / 65535

thus:

megahash_per_second = shares_per_second * share_difficulty * 4295.032833


How can a sender know receiver's public key when creating "Pay To Public Key" tx?

In most cases, if you really want to use a P2PK transaction, you would have to ask the receiver to tell you their public key.

You can't determine the public key from the address alone.   The address is a hash of the public key, and hash functions are one-way.  So if all you have is an address, you can't use a P2PK transaction.

If the receiver has previously had other transactions sent to the desired address, and has spent at least one of those transactions, then the public key was included as part of the spending transaction's signature.  So in that case, the public key is in the blockchain, and you could use it to make a P2PK transaction.

I'm not sure why you would bother, though.  P2PK transactions are pretty much obsolete, and P2PKH should be used for all normal purposes.


To participate in Silk Road, users had to deposit funds with Silk Road. The FBI gained access to the private keys corresponding to these user balances. Thus, the FBI was able to transmit the funds to an FBI controlled wallet and confiscate the assets.
Following up on the question how they might have gained access:
The software running on the Silk Road server must have had spending access to the Silk Road users' internal balances. Therefore, there must have been a mechanism to unlock the wallet (assuming an encrypted wallet was used). The passphrase would have been available to the program, concluding from the outcome, likely in the files on the server. As the server was probably running when it was seized, the FBI might have been able to access the files directly and thus gain access.


how to add a buy transaction using bitcoin @ cryptocompare.com

I'm also using cryptocompare.com to track my crypto investments. However, it turns out that they do not have a functionality where the currency you entered to buy another currency gets auto-debited from your portfolio. You'll have to manually select that currency and enter the sale. I know that's not ideal. Hope the developers correct this soon.


How do I develop web applications for Bitcoin?

All points by Nefario are spot-on.  In addition to these, here are some Bitcoin-specific suggestions from Camp BX's experience so far:

1) Use testnet.
Testnet is an excellent resource, that unfortunately does not see as much use as it should outside the core development team.  Make sure you launch your project on testnet, and test all major subsequent releases there as well.

2) Bounties are overrated.
If you want to find bugs in your Bitcoin project, do not rely on bounties.  Perform L&P testing, Unit testing, System testing on all your code and hire professional security auditors if possible.

3) Use 64-bit architecture
 (This may not apply to all projects.)  Many developers use an old 32-bit server for testing and 64-bit system as production server.  It is worth the extra investment to make sure your test server is 64-bit architecture as well.

Hope this helps.


The network wide Alert system is being retired. No Bitcoins are at risk and this warning may be safely ignored. Upgrade to the newest version of your wallet software to no longer see the alert.

Read more here.


Is it possible to mine altcoin with antminer?

If an altcoin uses the SHA256 double hash algorithm for their proof of work algorithm, then yes, you can use antminers or any other Bitcoin mining hardware to mine those altcoins. You will need to modify the antminer in order to use other mining software (you should be able to ssh into it and load whichever mining software you want).


Why are certain transaction not visible on blockchain.info?

Every node builds it's own blocks. Blockchain.info is simply unaware of the existence of this transaction, it will be aware when it will be implemented in a block that will be broadcasted to the network. In other terms, it will show up on Blockchain.info when it is confirmed.


Who is a first miner that receive a transaction from end-user?

who is a first miner that receive a transaction

Each full-node ends up sharing information with a small number of other active full-nodes. I believe there is a node discovery process primed by an initial list hardcoded into the node software. The nodes thus form a dynamic self-organising network with multiple hops between distantly connected nodes. Which miner first receives a transaction therefore depends somewhat on where the transaction originated. It is effectively somewhat random, or at least undirected.

  SPV node are End-users that use wallet program such as Bitcoin-core

I believe Bitcoin core is a full-node not SPV. Electrum is an example of an SPV node.

  Does End-user has full-node list

No

Note that an SPV node is a lightweight node which does not have a copy of the full Blockchain, a journal (list) of all transactions. SPV nodes effectively  ask other nodes they know about to verify transactions for them.

Bitcoin nodes do not need a list of all other nodes, only of a few nodes nearby (in a topological sense).

See How do Bitcoin clients find each other?

  how SPV node can provide transaction information to full-node without full-node list

By telling an interesting fact to three friends who each talk to three of their friends who all talk to three of their friends  (and so on), you can start a rumour that spreads across a school, across a city or to millions of people across the planet.


Are addresses which start with 3 multisig addresses?

Those are P2SH (Pay-to-script-hash) addresses. You can read more about different address prefixes here: https://en.bitcoin.it/wiki/List_of_address_prefixes

Decimal prefix  Hex Example use                 Leading symbol(s)   Example
0               00  Pubkey hash (P2PKH address) 1                   17VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem
5               05  Script hash (P2SH address)  3                   3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQX

Multisig addresses will be a P2SH address type so they will also start with a 3, because you cannot create an address out of a script unless it is either a P2PKH or P2SH (or segwit script with Bech32 address type). You can send Bitcoin to a multisig script, but if it is not hashed, and put into a pay-to-script-hash script, it cannot be represented as a standard address type.


As you described, a valid transaction must be submitted to the network to change ownership of funds. Mt.Gox P2PKH addresses, so spending the funds indeed required a signature of the corresponding private key to move the funds.
As Nate Eldredge commented above, this can be achieved either through gaining control of the key, or by causing the owner to use the key in the attacker's favor. Both occurred in the context of MtGox.
First, MtGox got hacked in 2011 where the attacker attained a copy of the service's hot wallet. Not only did they take the funds available at the time, but Mt.Gox continued to get deposits to tho addresses the attacker had keys for, which the attacker immediately redirected for the next two years.
Later, MtGox described losing funds due to attackers malleating withdrawal transactions. In such an attack, one or multiple signatures on a transaction get modified which results in an equivalent transaction with a different transaction id (txid). MtGox was tracking withdrawals by txid. Since the original transaction never confirmed, MtGox misinterpreted the corresponding withrdrawals to have failed and reissued the same withdrawal again, paying out the withdrawal twice. Later research showed that this caused a much smaller portion of the losses than initially suspected.
If you are interested in reading more about the MtGox saga specifically, I would recommend the corresponding article series on the WizSec blog.


How hard is it to transfer money between Bitcoin exchanges?

That's exactly the service https://www.bitinstant.com/ provide, it should be fairly simple and I think they and mtgox have the API necessary to do this by a bot.


When a miner finds a valid block, the coinbase transaction they included in their block pays out the mining reward to their own address. Mining rewards can be sent to any type of output. The only special restriction on coinbase transaction outputs is that they can only be spent after a maturation period of 100 confirmations.
You are looking at two different address types:

bc1q403w7zrj74azzunk89srt2m3vuajatlmskcktm is a Pay to Witness Public Key Hash (P2WPKH) address
1KFHE7w8BhaENAswwryaoccDb6qcT6DbYY is a Pay to Public Key Hash
(P2PKH) address.

P2WPKH addresses are the more block weight efficient successor of P2PKH addresses. Spending funds received to P2WPKH addresses takes less than half the blockweight as spending funds received to P2PKH addresses.

The inferred PubKey hash of the miner address is c825a1ecf2a6830c4401620c3a16f1995057c2ab. Would my PubKey hash be abe2ef0872f57a217276396035ab71673b2eaffb?

Yes, that's correct.


How much transaction fees are taken by bitcore for API use?

Bitcore is open source software provided at no charge, so there is no fee you have to pay to the BitCore software authors.

When creating a Bitcoin transaction, it is highly recommend that you pay a fee to Bitcoin miners to encourage them to include your transaction in a block.  How much fee you pay is optional, and there are a number of fee estimation services that will recommend a fee for you.  See also other questions on Bitcoin StackExchange for more information about transaction fees in general.


I accidentally sent bitcoins twice to the same address

It is not clear what exactly happened.

If you've made two subsequent transactions to the same address that should not be a problem. Addresses can be used more than once to receive money.
If you created two transactions that spend the same transaction outputs, there is no problem, because only one of them can confirm.
If your transaction simply didn't get confirmed yet, there is little to no problem: Transactions either have confirmed or have not. Since both wallets are your own, the money is still in your sending wallet until it is in your receiving wallet. If you wish to get help about fixing a stuck unconfirmed transaction please refer to: Why is my transaction not getting confirmed and what can I do about it?

If your question is not covered by these three scenarios, please edit your post to clarify what you're asking.


This is simply practically not possible; it's one of the basic premises of public-key cryptography:

  The strength of a public key cryptography system relies on the computational effort (work factor in cryptography) required to find the private key from its paired public key. If so, effective security only requires keeping the private key private; the public key can be openly distributed without compromising security.

Unless somebody breaks the cryptographic algorithm used to generate the keys, your best bet is to simply generate random keys and check whether the corresponding public key matches the one you already have. (Well, that's a slight exaggeration but you get the point.)


Value of `vout` in vin exceeds number of vout elements. Why?

It points to the output 'n' in the transaction which that input spends from, not the spending one.


How do I load wallet.dat on new PC and import everything into Electrum?

You can also import the wallet.dat directly into Electrum. Bitcoin Core needs to download the whole chain (as you mentioned) so that'll take a while. Without the chain, your transaction are indeed illegal/conflicted. Since you have the wallet, you can just install Electrum and import it there. Electrum doesn't need to download the chain, so your balance would be visible (and accessible, even more important) immediately.


Trying to recover a blockchain.info wallet from 2013 w/ a 29 (or 13?) word phrase

I ended up adapting gist.github.com/fcicq/3368495 to read from a file with a hundred thousand possible passwords (which I generated by permuting the inputs I was pretty sure I used to generate it in the first place).

It turns out that the wallet was double-encrypted, but this at least took care of the first layer, and then wallet-key-tool took me the rest of the way, by trying a few passwords by hand (once I found out the first password, the second was easier to guess/recall).


You don't need to send the coins anywhere. Just recreate the old wallet with the recovery phrase.

Digital assets aren't literally in wallets. Wallets just hold the keys necessary to access to assets.


How Do Attackers Forge Bitcoin Blocks And How Do You Identify Forge Bitcoin Blocks?

I assume that when you say an attacker can forge blocks, you mean that a dishonest miner can create invalid blocks.

The answer is no for a very simple reason. When a miner's bitcoin node (the computer which runs the bitcoin software) creates a block, it must follow all of the consensus rules. Let's say, for example, he tries to create a coinbase transaction with 13 bitcoin, plus fees. Note that, at the time of writing this, the block reward is 12.5 bitcoin.

Then it finds Proof of Work and sends the block to the rest of the network. Every node that receives this block will first check if it follows the rules. Since it doesn't, the node will reject that block. Therefore, it will not get included in the blockchain and the miner just lost the reward.

So, every node validates everything on its own. No node trusts information it recieves from other nodes.


What is the most optimal way to parse a raw bitcoin block with python?

We will compare modern libraries with segwit and bech32 support.

First will be pybtc from bitaps.com, second will be btcpy from chainside.net

Our test code:

import time
import pybtc

f = open('raw_block.txt')
fc = f.readline()
qt = time.time()
block_hex = fc[:-1]
bt = pybtc.Block(block_hex, format="decoded")
print("pybtc library parsed block in decoded format", time.time() - qt )

qt = time.time()
bt = pybtc.Block(block_hex, format="raw")
print("pybtc library parsed block in raw format", time.time() - qt )

from btcpy.structs.block import Block as btcpy_block

qt = time.time()
block = btcpy_block.unhexlify(block_hex)
print("btcpy library parsed block", time.time() - qt )

Raw block that used you can download here

Test results:

pybtc library parsed block in decoded format 0.3380300998687744
pybtc library parsed block in raw format 0.0953378677368164
btcpy library parsed block 0.6518878936767578

You can see that pybtc block parse performance is better. Decoded mode means that all bytes converted to hex and addresses to base58 or bech32. Raw mode faster, but all objects in raw bytes, addresses stored as hashes.


If I delay upgrading to the latest Bitcoin Core version post Taproot activation does my node ever verify early Taproot spends?

Your node will likely never re-verify those transactions according to the Taproot rules unless it is forced to do a new initial block download (IBD) due to database corruption etc. It verified them at the time as valid spends according to anyone-can-spend rules and so there is no need to revisit them.
SegWit was different to Taproot in that pre SegWit versions (< 0.13.1) weren't storing the witnesses and so when they upgraded to a post SegWit version (>= 0.13.1) they had to request these witnesses. With Taproot, the witnesses (SegWit v1) are already stored by post SegWit (>= 0.13.1) but pre Taproot versions, they just haven't been validated according to Taproot rules.
There is an open Bitcoin Core PR #21009 at the time of writing (February 2021) to remove the code that allowed for requesting witnesses after an upgrade to a post SegWit version (>= 0.13.1).
There is some interesting advice and observations on bitcoincore.org in the Segregated Witness Upgrade Guide. Some of it is specific to the SegWit soft fork (e.g. activation) rather than the proposed Taproot soft fork but much of it is applicable to both.
Thanks to Luke Dashjr and Suhas Daftuar for answering this question on IRC.


In macOS build instructions for Bitcoin Core, why do they recommend creating RPC configuration file?

I believe this suggestion is dates from before cookie authentication existed, and is not needed anymore.

Before, it was impossible to use the RPC protocol to send commands to a running bitcoind/bitcoin-qt instance if no username and password were configured.

Since the introduction of cookie authentication, this is no longer needed.


If you can buy using https://localbitcoins.com/ in both places then you can just buy some bitcoins locally before you leave and sell them locally when to get to where you are going.


Premine coins from genesis block are gone after one transaction from account/wallet

You need to do a few things to make the genesis block spendable, all in validation.cpp (untested):

Allow tx connection, L#2904:

if (*pindexPrev->phashBlock == chainparams.GetConsensus().hashGenesisBlock)
    // return true;

Skip coinbase amount check for genesis block, L#1933:

if (block.vtx[0]->GetValueOut() > blockReward && block.GetHash() != chainparams.GetConsensus().hashGenesisBlock)
    return state.DoS(100,
                     error("ConnectBlock(): coinbase pays too much (actual=%d vs limit=%d)", block.vtx[0]->GetValueOut(), blockReward),= REJECT_INVALID, "bad-cb-amount");

Skip writing undo data for genesis block L#1947:

if (block.GetHash() != chainparams.GetConsensus().hashGenesisBlock)
{
    if (pindex->GetUndoPos().IsNull() || !pindex->IsValid(BLOCK_VALID_SCRIPTS))
        {
            if (pindex->GetUndoPos().IsNull()) {
                CDiskBlockPos _pos;
                if (!FindUndoPos(state, pindex->nFile, _pos, ::GetSerializeSize(blockundo, SER_DISK, CLIENT_VERSION) + 40))
                    return error("ConnectBlock(): FindUndoPos failed");
                if (!UndoWriteToDisk(blockundo, _pos, pindex->pprev->GetBlockHash(), chainparams.MessageStart()))
                    return AbortNode(state, "Failed to write undo data");

                // update nUndoPos in block index
                pindex->nUndoPos = _pos.nPos;
                pindex->nStatus |= BLOCK_HAVE_UNDO;
            }

            pindex->RaiseValidity(BLOCK_VALID_SCRIPTS);
            setDirtyBlockIndex.insert(pindex);
    }
}


a miner has to solve a mathematical puzzle

Let's be specific: a miner has to find a block header (which you construct with the block content, i.e. transactions) whose hash (double sha256) is a number inferior to the target.

  But who decides what would be that puzzle for each block ?

This can be rephrased as: But who decide of the value of the target for each block ?

Short and abstract answer: The network sets the target value.

  Or How do the other miners verify that he really did find the winning hash?

Not only the other miners but all the participants of the network (full nodes) verify the PoW upon receiving a block, with "verifying the PoW" meaning "check that the hash (double sha256) of the block header represents a number below the current target.

So, how all the nodes can agree on the validity of the block ? Or, how all nodes can share the same target ?

The target is hardcoded for the genesis block and is adjusted (the higher the target, the lesser the difficulty. The lesser the target, the higher the difficulty) every 2016 blocks.
Since all participants share the same block chain and the same formula for adjusting the target, they share the same current target.
And since they share the same current target, they accept the same blocks and hence share the same block chain :-).


Why doesn’t Bitcoin use UDP to do Blockpropagation?

The Bitcoin system doesn't have just one network protocol:   Any way of obtaining the blocks is equally valid-- blocks over freenet, over satellite broadcast, over the P2P network, all work just as well and are used in practice.  UDP is used with bitcoin too, by the Fibre protocol.

As far the common Bitcoin P2P protocol goes UDP is not an especially good fit for most operations that it performs.  Bitcoin needs to reliably send messages far larger than an IP packet, like transactions and blocks. Although the internet is "reliable" packet loss rates of 1-3% are common. This means that any application needing to communicate large messages with UDP must implement packetization, retransmission, reordering, etc-- the same things that TCP already implements for us.  Many applications that have 'rolled their own TCP' in userspace have ended up with exploitable bugs in them, so it isn't something that should be done without good cause.

UDP also has the issue of NAT traversal:  Getting bidirectional communication across a NAT with UDP is not a simple matter. Crossing anything more complicated than a full cone nat requires considerable amounts of special code but without it there will be a many hosts that just can't talk to other peers with UDP.

You mention connectionlessness allowing you relay to a random host in the network, but in Bitcoin P2P we make use of the consistent relationship between nodes to make the network more reliable and efficient. Nodes have an idea what their peers already know and can avoid sending them redundant data. Nodes also know which peers have been fastest in sending them blocks in the past and handle them specially. Likewise, even if the protocol is connectionless there are costs to processing messages from peers by prioritizing handling messages from existing peers, Bitcoin reduces the impact of some kinds of DOS attack. Handling larger than one-packet messages, retransmissions, etc. also mean that even with a connectionless transport there still needs to be some kind of persistent state.

But an if implementation did want to randomly connect to send a message it could, at an extra cost is a couple round trips for the handshake. Or not even  that: there are only about 10,000 reachable nodes in the P2P network, there wouldn't be much of a challenge in holding open a mostly idle TCP connection to each and ever one of them if all the state retained were just the TCP state. So for that point the use of UDP would at best just be an optimization for something that could already be done but isn't done. I think it would be more interesting to demonstrate the usefulness of having all those connections first, before worrying about optimizing it.

So why might UDP transport be useful to the Bitcoin P2P protocol?

To get lowest latency block transfer possible there must be no round trips even in the face of packet loss which precludes TCP and which is why Fibre uses UDP. But to get no round trips the protocol must be able to handle loss without retransmission and to get low latency a block must be decodable with a minimum amount of data received. This requires very sophisticated error correction techniques which are an evolving area and haven't become mature enough yet to consider mainstreaming them. The latency benefits of fibre also exist so long as a small number of hosts are using it, since it does the heavy lifting of taking blocks all around the world.  Round trips don't cause much harm on low latency links. And this latency concern only applies to block relay.
Unlike TCP, UDP requires some amount of NAT traversal handling to simply get bidirectional communication working. But combined with full nat traversal handling UDP is often able to establish communication between hosts which are both behind different NATs.  This could be helpful for the Bitcoin P2P network since most hosts are unreachable behind a nat. So, ironically, one of UDP's challenges is also one of its uses. However, to connect hosts which are both behind a net the assistance of a third party non-natted host is required along with even more NAT traversal code.  Considering the complexity of traversal improving Bitcoin's support for TCP port mapping (e.g. implementing NAT-PMP) would probably be a better return on investment right now.
Use of UDP would allow for "worst than best effort" traffic handling. For low priority "bulk traffic" like syncing the blockchain it would be nice if the traffic carefully shaped itself to avoid interfering with other traffic on the network. Alternative congestion control algorithims like LEDBAT make it possible to transfer low priority data with minimal impact. But since TCP stacks don't yet commonly support these congestion control approaches, applications that want them currently need to implement their own transports. For Bitcoin it would be ideal if we could just flip a socket option and turn  LEDBAT on and off on existing connections (e.g. when the peer is requesting historical blocks or in the future when something like Fibre is being used by the node to relay new blocks) but that isn't an option yet.

[These last two reasons are the reasons that Bittorrent usually uses UDP]


blockcypher amount transacted larger than amount transferred

When you create a transaction, you have to specify where the bitcoins you are spending have come from, as well as prove you are allowed to spend them. That is known as an input to the transaction. Inputs refer to outputs of previous transactions, which have not yet been spent, called UTXOs (unspent transaction outputs). Each UTXO must be spent all at once, you cannot partially spend one, when it is used as input to a transaction. Thus you will generally need to choose a UTXO which is larger than the amount you are trying to spend, and then send yourself back some change to make up the difference. That is what the second output you see is, it is the change being sent back to your wallet. See also:

If bitcoin is indivisible, where does change come from?
How does change work in a bitcoin transaction?
Why does Bitcoin send the "change" to a different address?
How is it possible to say that a bitcoin was fully spent?


How to prioritize bitcoin transactions when solo mining using CPUMINER?

For this task you do not go solo but using an agent in between called the
Stratum

The node itself is supporting a custom script walletnotify which is executed whenever there is a new transaction found on the network. Then one could customise his stratum code to decide which tx actually to mine (per default they would sort them by the fees) or which ones to ignore.


As I understand it, the "stealth address" is intended to address a very specific problem.  If you wish to solicit payments from the public, say by posting a donation address on your website, then everyone can see on the block chain that all those payments went to you, and perhaps try to track how you spend them.

With a stealth address, you ask payers to generate a unique address in such a way that you (using some additional data which is attached to the transaction) can deduce the corresponding private key.  So although you publish a single "stealth address" on your website, the block chain sees all your incoming payments as going to separate addresses and has no way to correlate them.  (Of course, any individual payer knows their payment went to you, and can trace how you spend it, but they don't learn anything about other people's payments to you.)

But you can get the same effect another way: just give each payer a unique address.  Rather than posting a single public donation address on your website, have a button that generates a new unique address and saves the private key, or selects the next address from a long list of pre-generated addresses (whose private keys you hold somewhere safe).  Just as before, the payments all go to separate addresses and there is no way to correlate them, nor for one payer to see that other payments went to you.

So the only difference with stealth addresses is essentially to move the chore of producing a unique address from the server to the client.  Indeed, in some ways stealth addresses may be worse, since very few people use them, and if you are known to be one of them, it will be easier to connect stealth transactions with you.

It doesn't provide "100% anonymity".  The fundamental anonymity weakness of Bitcoin remains - that everyone can follow the chain of payments, and if you know something about one transaction or the parties to it, you can deduce something about where those coins came from or where they went.


Here is an example of how to set up a Masternode
https://medium.com/geekcash/how-to-setup-masternode-from-beginners-ea5f60686790


Can you make altcoin vanity addresses out of those of Bitcoin?

I want to make such ones for other coins, too. If I could make altcoin vanity addresses of the same key pair preserving the “TEST,” that would save some computational resources for me.

This would work for other coins with the exact same address alphabet as Bitcoin (which is most bitcoin clones), and the exact same version byte.

Addresses in bitcoin are derived by:

Taking the payload (which is the HASH160 of the pubkey or redeem script for p2pkh and p2sh addresses) and concatenate it with the version byte (0x00 for p2pkh, 0x05 for p2sh)
Sha256d(step 1) to get a hash of the payload and, taking the first four bytes as a checksum
Base 58 encoding the results of 1 and 2

While this is a simplified explanation (more details can be found here), it is immediately obvious that attempting to change the version byte will result in a different value for the checksum, which will lead to a completely different base58 encoding. Therefore, if your altcoin does not use the exact same version bytes for the same address type, it will not be able to encode the same vanity phrase for a given key.

Moreover, coins which don't follow Bitcoin's address schemes will also encode differently - for example, Ethereum takes the keccak256 hash of the pubkey, and selects the last 20 bytes as the address - this is also going to lead to a total loss of the vanity phrase (especially since the alphabet is now just 0-9A-F, so TEST is never possible in anycase).


Where can I find the core binaries for v.0.1.5 to v.0.3.21?

You have the files here and can follow the instructions mentioned in below links to build:
https://github.com/bitcoin/bitcoin/blob/master/doc/build-windows.md
https://github.com/bitcoin/bitcoin/blob/master/doc/build-osx.md


Is there network split risk for Taproot activation with two releases (Bitcoin Core and Bitcoin Taproot)?

No. With a softfork, a network split is only possible if miners create invalid blocks. This is something they can do with or without a softfork, so it is not an issue specific to softforks.
It is important for the economy to use their own full nodes to avoid the risk of being led off by a miner attack in the form of invalid blocks. This remains true with softforks, where upgrading is necessary to retain full node security.


How to create a physical/paper backup for bitcoin-core wallet?

if I generated 100 addresses and transferred some BTC to all of them, I need to backup all the 100 addresses.

Bitcoin core is an HD wallet. So you should only need to backup the extended master private key shown at the top of dumpwallet.

# Wallet dump created by Bitcoin v0.21.0
# * Created on 2021-05-05T17:57:09Z
# * Best block at time of backup was 627544 (000000000000000000045a465b959072a715f47047141108ef14db64e2ee9049),
#   mined on 2020-04-25T08:34:02Z

# extended private masterkey:
xprv1x23XxXX456X7XXXXxxXx8Xxx9XxXxXxX01234X5xxX6XxX7xXxxXXXXxXxxXxx8X9Xx0XX1XxxX2XXx3x45xx6xxxXXXxxxxX7XXXxx8XX

etc
Obviously you should practice recovery from this , and check the recovered balance, on a different computer, before relying on it. At least check that the generated subsidiary keys/addresses are the same.
It may be easier to recreate the wallet from an extended master private key (xprv) by using wallet software like Electrum, which has some support for this. Bitcoin core expects you to backup the wallet.data file rather than write down a number on paper.

Related

How to restore Bitcoin Core HD wallet private keys by master key?
How do I retrieve my backed up wallet to Bitcoin Core?


How to do tx.addInput without tx_hash if sending from address for the first time?

If not a coinbase transaction, you have to spend from an existing output. Thus the input must reference an existing transaction.

  cannot retrieve the previous tx_hash

Maybe the library you are using is the following common semantic:

txid for the transaction id (hash without the witness data)
tx_hash for the transaction hash (hash with the witness data)

You want the txid to reference a previous transaction in an input.


Transfer all funds out of the old wallet.
If on Windows, explore to %APPDATA%\Bitcoin, rename wallet.dat to wallet-old.dat.
On next launch of Bitcoin-QT a new, empty wallet.dat will be created.
This will not require re-downloading the blockchain.
Remember to use Settings, Encrypt Wallet on the new wallet.dat.


How does one "authenticate" a bitcoin user?

There are different KYC (Know Your Customer) laws in different jurisdictions, but generally it takes information that is difficult or very time consuming to falsify. License/ID scans, utility bills, and SSNs are examples

Suggesting "hashing" as a KYC solution suggests you do not know what hashing is (unless you were referring to the way a server should store such confidential information). I suggest you use the search function or explore bitcoin wikipedia to learn more.


What differences exist between the Lightning Network implementation versus the white paper?

So far I found two further differences between the Whitepaper and the BOLT specifications:

Funding

Whitepaper: One or both participants have to fund the channel (page 7)

BOLT: Only one participant can fund the channel (BOLT #2 - Channel Establishment)

Penalty handling

For a particular channel state, each participant has their own Commitment Transaction version which has two outputs: One for Alice and one for Bob. The output that is intended for oneself can only be spent after a delay. But the output for the other party can be spent immediately. For the sake of simplicity the following description considers just the view of one party who is Alice.

Whitepaper

Alice has her versions of the Commitment Transaction and Revocable Delivery Transaction. The output in the Commitment Transaction that is intended for Alice requires signatures from both parties and is referenced in the input of the Revocable Delivery Transaction. This input can only be spent after a delay which is specified by the sequence number (relative timelock via BIP 68)

Commitment TX 1 {Alice's version)

 Out 0: 2-of-2 multisig (Pubkey_Alice_1, Pubkey_Bob_1)
 Out 1: Pubkey_Bob_2

Revocable Delivery TX 1 (Alice's version)

 In: sig_Alice_1, sig_Bob_1   // timelocked via BIP 68 (nSequence < MAX_INT)
 Out: <Pubkey_Alice_2>

So Alice can (unilaterally) close the channel at anytime by broadcasting both of the above transactions. However, if she'd do that she'd have to wait for some time until she can actually spend the money from the Revocable Delivery Transaction.

Now, if both parties would like to update the channel state, they have to revoke their current commitment transactions. Alice revokes her Commitment Transaction by sending Bob her private key of her Commitment Transaction output. Now, if Alice tries to cheat by broadcasting her old Commitment Transaction and Revocable Delivery Transaction, she has to wait because she can only spend her money through her Revocable Delivery Transaction which is timelocked. However, as Bob now has both private keys for Alice's output of Commitment Transaction 1, he can immediately spend this output (and thereby invalidate Alice's Revocable Delivery Transaction) with the following transaction:

Breach Remedy TX

 In: sig_Alice_1, sig_Bob_1
 Out: Pubkey_Bob_3

In short: Alice revokes her Commitment Transaction by giving Bob her private key. Also the time delay for Alice is implemented in a separate transaction via a BIP 68 timelock.

BOLT

Alice has only a Commitment Transaction. The output that is intended for Alice has two possible redemption paths. The first path requires the revocation private key and the second path requires Alice's private key and is delayed with a relative timelock using OP_CHECKSEQUENCEVERIFY (BIP 112).

Commitment TX 1 (Alice's version)

 Out 0: IF
           <Revocation_Pubkey>   // first path
        ELSE
           <time_delay>          // second path
           <Pubkey_Alice>

 Out 1: <Pubkey_Bob>

When both parties proceed to the next channel state, they revoke their commitment transactions. Alice revokes her Commitment Transaction by sending her half of the revocation private key to Bob. So if Alice tries to cheat by broadcasting the old Commitment Transaction, Bob can broadcast a transaction that spends Alice's money through the first path as he now has the full revocation private key:

Breach Remedy TX 1

 In: <Revocation_Privkey>
 Out: <Pubkey_Bob>


When an IP address in *new* table is overwritten?

nRefCount indicates the number of slots in the new table that is occupied by the same IP address.


mining with one client on multiple mining pool

The hashes generated by your miner is only usable for a unique set of transactions that your pool decided to include.  In addition each pool orders transactions differently and that too will affect the resulting hash.

Unless the pools cooperate and synchronize all the details of a given block (nonce, merkle tree, etc)  then any hash that is generated is useless to any other pool.


Will this assumption allow individual bitcoin tracking possible?

This is only true if one does not mix transactions. Otherwise you will have coins that are for example 50% from source A, 10% from B, 40% from C and so forth.


Is there an altcoin generator with merged-mining support?

Yes, http://build-a-co.in/ is an alt coin generator that supports merged mining.

In general, I think it has more settings and is easier to correct settings.


If the concerns are related to performance, we can observe how the ethereum works and reaches about 1M tx per day (this is like 1M inputs per day in Bitcoin).

Ethereum is really not a good comparison considering that it is impossible to sync a fully validating archival Ethereum node.

Regardless, the concern isn't just "performance" but rather Denial of Service attack risk. Performing pubkey recovery is much more computationally expensive than computing a hash of something. Thus there is potentially a DoS attack where an attacker creates many transactions with invalid signatures which a node then has to perform pubkey recovery on only to discard the transaction because it is invalid. By requiring a node to do a lot of computations on invalid transactions, it can be prevented from doing any verification of actual transactions thus preventing the node from actually doing its job.

With key hashes, this is less of a risk because the attacker needs to know the pubkey in order to get a node to break on the invalid signature step. Thus an attacker could not just use any output that has the same format (as you could with any output using key recovery) but has to use specific outputs which he knows the pubkeys for which limits how many of these transactions can be created.


You don't need to modify the bitcoin client at all - you can use JSON-RPC and call getblockcount.


If you don't care about your privacy, you can always find the associated extended public key (xpub*) and enter it in a blockchain explorer site such as https://www.blockchain.com/explorer.

Here is how a Bitcoin account's (M/44'/0'/0'/) extended public key for a given set of 12 seed words can be computed on a trusted air gapped offline computer that could be operating in a Faraday cage:

% echo "radar blur cabbage chef fix engine embark joy scheme fiction master release" | bx mnemonic-to-seed | bx hd-new | bx hd-private -d -i 44 | bx hd-private -d -i 0 | bx hd-public -d -i 0
xpub6DHi64TFkDPx2AH4q2ku3vX9LJYNpTis5tLrET8Sb9irp174eCkgtAnvBpyzQXgrtmF31Lrq4gTMGFUGcjJicMu9LdueVdqt6FZ2Wzcg8Fj

Ledger and Trezor devices can be queried to gain access to your xpub key.

Otherwise, just apply the KISS principle and use your wallet application that will naturally provide you with an account balance.


static void test_sig ( )
{
  const MyByteArray pubkey ( QByteArray::fromHex ( "042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9" ) );
  const MyByteArray signat ( QByteArray::fromHex ( "30450220587ce0cf0252e2db3a7c3c91b355aa8f3385e128227cd8727c5f7777877ad772022100edc508b7c14891ed15ab38c687019d7ebaf5c12908cf21a83e8ae57e8c47e95c" ) );
  const MyKey32     digest ( QByteArray::fromHex ( "30f10a6468b7d98257af63fb40dfcf2cefe991346fd37c67cf7b51ff8d4404d3" ) );
  qDebug ( ) << ( digest.verify ( pubkey, signat ) ? "passed" : "failed" );
}

my result is:: passed

the signature is correct for digest and public key

may be something is wrong in your verification code with decoding hex values and/or byte order in digest?


Trying to claim my bitcoin cash but transaction history doesn't match

I figured out what was going on... sort of. At the very least I found where my Bitcoin Cash was and was able to sweep it into another wallet.

It is probably that I fundamentally misunderstood how Bitcoin Core works. I started investigating all of my Send transactions and Receive transactions on Blockchair and found that when I was sending a payment to another address, it would grab the funds from a receive address that had sufficient funds to cover the payment. I naively assumed that the remaining balance in my receive address would stay there, however I discovered that what Bitcoin Core was doing was liquidating the remaining balance from the receive address and sending it to a new address that was also in my wallet.

When I would do tge export of Receive Addresses from Bitcoin Core it would only list addresses that I received funds to, not addresses that still contained unspent Bitcoin. This was why Electron Cash and other BCH wallets showed a zero balance when I brought in the private keys for those addresses. Sure enough when i dumped the private keys for these hidden addresses listed in Blockchair, I was finally able to get the unspent balance and sweep the funds.


What is the timeline for Lightning Network's availability?

Roasbeef just announced the first Lightning transaction on Bitcoin mainnet today:
https://twitter.com/lightning/status/938453165967515648

It was using a multihop payment via all three major implementations (lnd, eclaire, c-lightning).

The Lightning Integration tests are now at 75/75 working:

The three teams are now working on a beta release each. I'd expect this to be released in the next months.


Bitcoin Core maintains two databases:

The block index
The chain state (or UTXO set)

The first one just contains a list of all blocks we know about, valid and invalid. It contains all forks we have ever heard about, and all branches that result from it. It also contains information about where on disk these are stored. It does however not contain any information about which blocks we consider part of the "best chain".

The second one contains a snapshot of all existing unspent transaction outputs up to one particular block (and it also stores the hash of this block it is "synchronized" to). The process of validating blocks consists of "applying" the effects of blocks to this state, and possibly undoing those effects when the block turns out to be invalid, or we need to reorganize to another branch.

At startup, it is possible that the first database contains blocks that could be valid but aren't part of the snapshot the second database represents. This can happen when you manually overwrite the block index (restoring from a backup, for example), but more commonly: because Bitcoin crashed after downloading some blocks that ended up being written to the block index, but the resulting chain state was never dumped to disk. When this happens, we will activate the best chain, loading blocks from the second database and applying them to the first (while doing full validation on them in the process).

Since Bitcoin Core heavily caches the chain state in memory, it is possible that there are hundreds or thousands of blocks missing from the chain state after an unclean shutdown. It can take a while to validate them again.

TL;DR: It's verifying blocks that were downloaded already but not processed yet (because the result of processing wasn't properly written to disk, most likely).


What order do transactions appear in a block? Is it up to the miner?

The first transaction has to be the miner's reward.  The other transactions can't be miner rewards.  Transactions have to appear after any transactions upon which they depend.  Other than that the order is up to the miner.  Changing the order of the transactions is one of the things a miner can do to change the block hash once he has tried all possible values of nonce.

I don't know what you're referring to with your "regenerating the block for later retrieval".  As far as I know blocks aren't regenerated.  They're created by a miner, passed around the network, and stored on disk.  There's no need to regenerate them.


How to make a profit doing 'spread trading'?

If the spread is $40 you will buy $1 above ask price, then when fulfilled immediately resell the btc at $1 below bid price. You keep $38 profit per btc


How to enable website users to trade bitcoins on my website?

What you would probably want to do is just create one wallet for yourself which you encrypt, and then create some kind of data type on your server called wallet that you could create arbitrarily many of.

When people want to deposite money onto "their" wallet you would generate a new address for your wallet, which you can do as many times as you want. Once the bitcoins arrive you will credit them however many bitcoins they deposited on their fake wallet, which just lives on your server.

Then when they want to withdraw money you send bitcoins from your main wallet, making sure to never allow them to withdraw more then they have been credited.

When people want to make a purchase with bitcoins on your site you just give them whatever they paid for and deduct from however many bitcoins are currently being credited to their account.

While this is all possible, unless your making a heavily bitcoin centric service such as an exchange, I would recommend using a third party service which already has tools built for merchants such as coinbase or coinlab.


First IBM Blockchain is IBM's branded version of it's Hyperledger Fabric blockchain software (which is Apache 2-licensed open source under the Linux Foundation). They are basically the same, with the exception of add-on services and configuration.

Unlike Bitcoin, Hyperledger Fabric is an enterprise blockchain intended for private use (such as consortiums).

The "plastics into money" is just marketing--it's an example of using blockchain in a "proof of concept" application.


The following program will show you the OpenCL-capable devices on a given Macintosh:

// clang -framework OpenCL dumpcl.c -o dumpcl && ./dumpcl

# include <stdio.h>
# include <stdlib.h>
# include <OpenCL/opencl.h>

int main(int argc, char* const argv[]) {
    cl_uint num_devices, i;
    clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, 0, NULL, &num_devices);

    cl_device_id* devices = calloc(sizeof(cl_device_id), num_devices);
    clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, num_devices, devices, NULL);

    char buf[128];
    for (i = 0; i < num_devices; i++) {
        clGetDeviceInfo(devices[i], CL_DEVICE_NAME, 128, buf, NULL);
        fprintf(stdout, "Device %s supports ", buf);

        clGetDeviceInfo(devices[i], CL_DEVICE_VERSION, 128, buf, NULL);
        fprintf(stdout, "%s\n", buf);
    }

    free(devices);
}

If it fails to show you your GPU then its a driver issue.If it succeeds then its some kind of a configuration error.


Is there a way to estimate total number of bitcoin users/wallets?

The number of wallets is impossible to count, as they can contain zero to thousands of addresses each (zero, as there may be users who just want to observe, or clients that only create addresses when explicitly asked to).
Counting users by number of client downloads won't give you a good estimation either, with all the web wallets that are out there, plus of course the other clients that are out there, the alternative ways of downloading the client and the double downloads.
Counting connected clients will also give bad results, again because of the web wallets, plus people who don't broadcast their IP address or simply don't start the software unless they really need to.

You may be able to estimate the total user count by asking all web wallets for their user counts, and then adding the amount of nodes on the network over a relatively long period. But then you'd still need to compensate for those who don't broadcast their address, dynamic IP addresses, etc.

So yeah, it's hard to estimate the user count.


How are code changes (e.g. new features) to applications such as Bitcoin deployed and how is compatibility mainted?

Usually the code is written, tested, and merged into the release, and then deployed switched off.  Depending on the change, it can then be activated on a particular date, block, when the network has a consensus (certain %age of people agree to implement it), or when x number of blocks mined support the new change.

Code can be hard, or soft forked, and the developers attempt to make changes backwards compatible as much as possible to avoid client issues.

Occasionally incompatible clients can generate odd blocks (like for example a recent 1.01MB block) that get orphaned, or discarded by the rest of the network. Or even a chain of several blocks that get orphaned, this is one of the reasons you should wait for more than one successful confirmation after transferring money.


Multibit HD wallet - cannot open or restore, I have password and secret words

MultiBit HD bugs

There are several issues:

A correct password doesn't unlock the wallet (#753 on github).
The restore process doesn't work if there's already a wallet in the directory that MHD uses for the restore (the "CROSS. Wallet created.").

In my experience even a successful restore into a fresh new location won't help with the password problem, on any MHD version.

Coin recovery

It is only sensible to move the coins into a different wallet. This can be done by importing the private keys for the addresses that hold your coins.

You'll need the wallet recovery seed, i.e. the set of words the wallet gave you when you created it.

Getting the private keys

Go to https://iancoleman.github.io/bip39/, scroll down to 'Offline usage', create an offline copy and open it in browser.
Input your seed in 'BIP39 Mnemonic'.
Under 'Derivation Path', select 'BIP32'.
For 'Client' select 'Multibit HD'.
The 'Derived Addresses' list now has your wallet's usable addresses and their private keys. Figure out which addresses hold the coins (e.g. look up on blockchain.info). Copy those private keys.
Some coins may be on "change addresses", which have different derivation path:

For 'Client' select 'Custom derivation path'
For 'BIP32 Derivation Path' input "m/0'/1"
Repeat step 5. with the updated list of derived addresses.

Importing private keys

Pick another wallet software and consult its documentation about private keys import.

For instance, Electrum allows to create a seedless wallet that can do this. That should allow to control the coins again and send them into another wallet (use the seedless wallet only temporarily).


Your output is correct given the input that you used.

However, If you are expecting to get an output address of 39YteymR86cG7V3Kijg8Gm2ST1r4nTeM1b, it looks like your input is incorrect. It's missing the first byte and the last 4 bytes (encoded as hex):

  Your Input: --56379c7bcd6b41188854e74169f844e8676cf8b8--------
Proper Input: 0556379c7bcd6b41188854e74169f844e8676cf8b86e1b34ba

Try this tool for validating your expectations:


I read that wallet/account is not the same as bitcoin address.

A bitcoin-wallet is only a way to store multiple private keys (corresponding to multiple bitcoin-address).

  The address can be used only for single transaction. How do you receive donations on your address?

Addresses can be used for an infinite number of transactions. If you put a donation button somewhere referring to an bitcoin-address of yours, all those donations will get paid to this one.

  Are wallet addresses unique for the network so that I can generate my wallet in one service,
  eg. blockchain.info, and used it in different service?

With a wallet (like the bitcoin-core client) you can generate new bitcoin-addresses as well as using other services like blockchain.info. Those addresses are unique and by exporting/importing the private key you can use those addresses in other services as well.


I just made my altcoin, should I list my source code at Github?

Most users are not going to trust a closed-source altcoin, so you should make its code available to the public. This board also doesn't support closed-source cryptocurrencies.

GitHub provides free hosting for open-source projects and has become a standard in the open source community so (primary opinion-based statement follows) it's probably a good idea to put your code there.


If nonce can change the hash then it should be changing the next block's previous hash?

Miners don't change the hash of a published block, they change the nonce of a block template until the resulting hash is less than the target and only then publish the block.
So until then, there are no other copies that need changing and there are no other blocks that refer to the older failed versions of the published block.


Same seed from Electrum but generate different Bitcoin addresses

The problem is properly that you have a different account number because you said that you are using addresses starts with 1 (standard) so Purpose path is 44 and it's Bitcoins so coin path is correct (0)

You have to check that you are using the same account index while you importing the seed.

On your seed path try to increase account number by one and import your seed until you get your coins.

m/44'/0'/0'/0
m/44'/0'/1'/0


I have copy and pasted the command to my c-lighting node and it works producing the following output:

lightning-cli invoice 100 invoice20190126 payme
{
  "payment_hash": "af2a2e0a6f4924f755e296c219ade5f2c65616fcec5bb8e62b253b8a71a442cb",
  "expires_at": 1548528927,
  "bolt11": "lnbc1n1pwye8cdpp54u4zuzn0fyj0w40zjmppnt097tr9v9hua3dm3e3ty5ac5udygt9sdqgwpshjmt9cqp2rzjqgj8m8dsm7h75az7lry7zc0txghh8tpl3pvdsuctdlvhy4r50nnkkzrgpvqqf0cqqqqqqq05qqqqraqqjq9c06msw62wushzceav74p2zzmznmtud4c3hkw6keqvquxnm6kaxry4rm7aerwppl4jn5xm7tyjxvvyyve5w06slwm7fvxfspx363j9cqcevtr7"
}

Which version of c-lightning are you using?
Also there was recently a change of the JSON RPC API due to the new plugin system. Could it be that you have not updated lightning-cli but only lightningd?


On what pages is it slow? It only seems a little slower for me.

The "mirror" (which is actually usually the main server) went down for a while, so BBE switched to my server, which has much fewer resources.


Is the Electrum seed compatible with other wallets?

There are different "backup-standards".

Some use BIP39 (mnemonic) which lacks a flexible wordlist and versioning. It's used by Ledger, Trezor, Bitpay/Copay, etc.

Electrum uses a different – more flexible – mnemonic backup concept which is incompatible with BIP39.

There is also the BIP32 keypath which can be different among wallets. Example: you can restore a Trezor BIP39 mnemonic in iOS BreadWallet, but due to missing support of BIP44 in BreadWallet, the funds cannot be recovered there.

If you switch away from a wallet, consider sending all your funds to the new wallet (although this has some privacy implications, it's generally good for security due to the re-keying).

But as long as you keep your backup (seed / mnemonic), there will always be a (theoretical) option to recover your funds. If the wallet didn't stick to a standard and died (no maintenance, etc.), then you may need to contact an expert for a manual recovery.

If you use a mnemonic, make sure you use at least 24 words.


No inbound connections on my bitcoin full node with TOR

It generally takes a long time before the network "discovers" you're a good peer to connect to. It may be a few days before you get inbound connections.

I'm able to connect to you.


Avoiding Bitcoin malleable bug with implementation

Lower the confirmation.
The security reports are specific, 1 confirmation is not safe. 2 confirmations is considered 'safe'. More is considered 'safe'.
You can "rock'n roll" with 2 confirmation.
MtGox died the epic death because their custom made wallet was accepting coins after just 1 confirmation


Is "Dacoinminster's Second Bitcoin Whitepaper" logically/economically consistent?

It will fail for the same reason other attempts to stabilize currency values always fail. The first time there's a crisis, the regulator will have to decide whether to permit the crisis or prevent the crisis. If they permit the crisis, people will realize that the promised 'guarantees' are shams. If they try to prevent the crisis, they will run their reserves down to nothing, and the same thing will happen as if they permitted the crisis except they'll be broke.

If you make one small change though, I don't see any major technical flaws. Simply accept that the regulation will be maintained only under normal conditions and that crises may push the ratios out of bounds. The regulator should have a policy for how it detects a crisis, what it does during them, and how and to what extent it compensates people harmed by them afterwards, if at all.

For example, before banks were Federally insured, they would have a policy that the board of directors of the bank could declare a "crisis", suspend withdrawals, but later compensate people with extra interest.


Is difficult hashing algorithm necessary?

scrypt and scrypt-jane were chosen not because thay are "more difficult" then SHA-256, they are just different, and less suitable for GPU/ASIC implementation.

Whether using such algorithms is good or not is hard to tell. I'd say, since one can mine scrypt coins with commodity hardware now, while mining SHA256 coins even with decent GPU rig is futile, scrypt helps coin be more decentralized, which is a good thing.

One can of course create very difficult hashing algorithm (I'd say 10^80 rounds of bcrypt will be enough to ensure no one calculates a single hash ever). But cryptocurrency with such algorithm is unusable, and so would be forfeited.


It seems to be a witness transaction according to your screenshot (you can see the same missing scriptSig followed by witness here).

Segwit encodes the signature information slightly differently from the regular script sig, so it will not show up under that heading. A segwit transaction would still contain the information you would traditionally see in the scriptSig, but in the witness section instead.


How do you get the OP_HASH160 value from a bitcoin address?

Check the Wiki. I think what you are looking for is point 3:

  How to create Bitcoin Address

  0 - Having a private ECDSA key

  18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725

  1 - Take the corresponding public key generated with it (65 bytes, 1
  byte 0x04, 32 bytes corresponding to X coordinate, 32 bytes
  corresponding to Y coordinate)

  0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6

  2 - Perform SHA-256 hashing on the public key

  600FFE422B4E00731A59557A5CCA46CC183944191006324A447BDB2D98D4B408

  3 - Perform RIPEMD-160 hashing on the result of SHA-256

  010966776006953D5567439E5E39F86A0D273BEE

  4 - Add version byte in front of RIPEMD-160 hash (0x00 for Main
  Network)

  00010966776006953D5567439E5E39F86A0D273BEE

  5 - Perform SHA-256 hash on the extended RIPEMD-160 result

  445C7A8007A93D8733188288BB320A8FE2DEBD2AE1B47F0F50BC10BAE845C094

  6 - Perform SHA-256 hash on the result of the previous SHA-256 hash

  D61967F63C7DD183914A4AE452C9F6AD5D462CE3D277798075B107615C1A8A30

  7 - Take the first 4 bytes of the second SHA-256 hash. This is the
  address checksum

  D61967F6

  8 - Add the 4 checksum bytes from point 7 at the end of extended
  RIPEMD-160 hash from point 4. This is the 25-byte binary Bitcoin
  Address.

  00010966776006953D5567439E5E39F86A0D273BEED61967F6

  9 - Convert the result from a byte string into a base58 string using
  Base58Check encoding. This is the most commonly used Bitcoin Address
  format

  16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM

You can check your calculations against my testing suite.


ListAccounts JSON array data isn't consistently formatted (compared to ListReceivedByAccount)

JSON data structure supports lists (arrays).

http://en.wikipedia.org/wiki/JSON

In the first API command (ListAccounts) the result contents is an object which contains a string.  Inside this string is a set of data records, each of which is a key/value item.

In the second (ListReceivedByAccount) the result contents is an array of objects, each of which holds account data.

That does appear inconsistent, where perhaps the first call should have returned an array as well.

However a rule of thumb is that existing APIs should not change.  They can be deprecated and replaced but a call is expected to behave in a consistent manner.

The Bitcoin client is an open source project and thus an issue ticket for this inconsistency can be opened and a pull request with the source for a new API call submitted.  Whether such an issue is merged into the client depends on a number of factors, including severity of problem.


Where are the non-scriptPubKey outputs in the chainstate leveldb?

They're the same thing. The scriptPubKey is the script in the transaction output.


Notifications to watch only addresses in bitcoind

You can use the importaddress RPC to add addresses without associated private key to the wallet. The wallet code will now list transactions involve such addresses, and include them in balance calculations (though you may need to add an extra argument for includeWatchOnly to some RPC calls).

If you import an address that has existing confirmed transactions, you'll need to rescan, which is a lengthy and slow process. If you make sure you're importing before giving out the address anywhere (for example, because they're being generated on an offline treasure machine which you control), it's perfect though.

You'll get notifications in all the normal ways for these addresses, including using -walletnotify (with a shell script executed for each received or confirmed transaction), and ZMQ (if compiled and enabled).


How to download bitcoin blockchain without core?

If you torrent or otherwise download the blockchain but do not validate the data received, then you will be unable to know whether or not the data received is valid. This means you could easily download a chain which has been altered by an attacker, to include fake transactions, remove legitimate transactions, etc. You would have no way to know.

This is the reason that bitcoin-core takes some time to download and validate the chain: it is the only way to trustlessly know the current state of the network.

Note that bitcoin-core works most efficiently when it downloads the chain data as it goes. If you download a torrent of the chain and then attempt to validate using that, it will take even longer (you'll need to wait for the full download, and then the full validation, rather than doing parts of each in parallel).

I'm not aware of any software that can perform these validation steps more efficiently than bitcoin-core. You could try increasing the -dbcache option if you have under-utilized RAM. You could also try syncing to an SSD instead of an HDD, if you aren't already.


How to extract raw script from tx messages when the output script starts with 0xA9?

This seems to be a classical P2PKH script which start with op_dup flowed by op_hash160 if you look at the next byte there is the hex value 14 which is 20 in decimal and means read 20 byte of data and push it to the stack.

I have created a video in the past showing step by step how to dissect a P2PKH tx. Look: https://youtu.be/1n4g3eYX1UI


I have taken another crack at it, and ended up succeding.
I followed this guide: https://walletsrecovery.org/recovery-docs/bitcoinwallet-recovery.html
BUT i cloned and older repository, i choose release 0.11 as it came out in 2014 and i saw my backup was from 2013.
It is now succesfully syncing.


How do thin-clients know in which blocks to look?

SPV nodes usually only look at block headers, and then will download some of the actual block data of blocks which other peers have told them contain transactions relevant to them. SPV nodes are relying on at least one of their peers to be honest and report when a transaction appears on the network that is relevant to them.

But how do other peers know which transactions the SPV nodes want to know about?

SPV nodes essentially give their full-node peers a filter, called a bloom filter, that tells the nodes that download all the transaction data which transactions to send to the spv node. This filter also has a built-in false positive rate, so that the SPV nodes don't have to show exactly which addresses are theirs (essentially a built-in privacy level). Rather they make a filter that will validate a superset of transactions that the node is actually interested in.

The filteradd, filterclear, and filterload are the relevant p2p protocol methods. The bitcoin developer documentation goes into more detail here.


What ways does a miner differ from a wallet?

A wallet is a way of storing your private and public keypairs. It is used by various clients to check your balance and create new transactions. A client usually listens on port 8333, and has 8 other ports open for outgoing TCP/IP connections. It finds peers through various means - exchanging info with other peers, using fallback nodes, seed nodes and so forth. Its main purpose is to exchange information with its peers about new blocks, transactions and the like in a peer-to-peer fashion.

A miner is an application connected to a mining pool. The mining pool runs its own client to get the latest information on blocks and transactions, as well as handling the creation of new blocks. The pools generally use port 8332 for communicating with their miners. It is a server that communicates with a lot of miners through the use of HTTP JSON RPC, and usually comes with a website of some sorts. The miners find the pool, and the pool doesn't care about peers (it has a client for that).

A miner is an application that runs on local mining rigs (computers with high-end GPUs and other dedicated devices). It communicates with a mining pool through HTTP JSON RPC calls. The miner connects to (usually) one pool of a predetermined address, but the getwork protocol facilitates the use of backup pool addresses. The miner is responsible for getting "work" from a pool, processing it, and submitting shares back to the pool. A miner does not care about its peers, just the pool it is connected to.

I hope that clears out all the problems you had. You might also be interested in checking out my master thesis on Bitcoin for more information on numerous subjects related to Bitcoin, mining pools and security.


In Bitcoin core 0.21 which command replaces getaccountaddress

which command replace getaccountaddress ?

None, see the notification two and a half years ago in https://bitcoincore.org/en/releases/0.17.0/

Deprecated Method
New Method
Notes

getaccount
getaddressinfo
getaddressinfo returns a json object with address information instead of just the name of the account as a string.

getaccountaddress
n/a
There is no replacement for getaccountaddress since labels do not have an associated receive address.

getaddressesbyaccount
getaddressesbylabel
getaddressesbylabel returns a json object with the addresses as keys, instead of a list of strings.

etc.