Performance and modularity of Bitcore vs Toshi I have been reading about both, BitPay's Bitcore and Coinbase Toshi, and although they both claim to be highly scalable I could not find information in order to compare them in terms of performance and modularity. Does anybody knows about this?

Both are implementations of the Bitcoin protocol, however they are customized to make it easier to develop with. They are able to do this by storing all transaction and blockchain data in a database for quick queries, and along with this comes large disk space requirements (200-300GB).

Bitcore (I have used)
- NodeJS
- 200+GB required for storage as it holds all transaction data.
- Bitcore also has a library-only version (not a node), and a public API.
- Add-ons available (Block explorer API, UI & and Wallet Service)

Toshi (I have not used)
- Ruby
- 300+GB required for storage as it holds all transaction data.
- Toshi has a public API. As far as I can tell it does not have a library-only version like bitcore.
- A block explorer API and UI available. No wallet service, that has to go through coinbase which requires an application, credit check, etc.

As for your question about performance I can't really say since I haven't used Toshi, but Toshi's Github hasn't been worked on in over a year with only 200 commits. Bitcore is constantly being worked on with over 1,600 commits some as recent as 6 days ago.

Also I'd say outside usage would be a good guide as to which one performs better. I'm not aware of any well-known service using Toshi.

Localbitcoins uses Bitcore for their explorer.  https://www.localbitcoinschain.com/
Counterparty uses Bitcore http://counterparty.io/news/counterparty-uses-bitcores-insight/
SatoshiLabs(TREZOR) uses Bitcore http://themerkle.com/satoshilabs-unveils-mytrezor-beta-and-switches-to-bitcore/


bitcoind bulk import private keys to different wallets and update with one rescan I was wondering if someone already has this thoughts or problems:

I generate bitcoin addresses and private keys by a script - to not depend on the bitcoin daemon and manage them in a database. By generating the bitcoin addresses, I generate one address and also select a wallet name by some criterias.

BITCOIN ADDRESS | PRIVATE KEY | WALLETNAME

After a specific time i want to import the private keys to the given wallets ("WALLET NAMES") (to the wallets defined in the database before.)

I do this import with importprivkey without a rescan. I was wondering if it's possible to import the private keys to the wallets and to rescan one time and update all wallets with this one rescan to avoid for every wallet a explicit rescans each one and a half hour time.

Is it possible to import the private keys rescan=false and after this to run bitcoind with all wallets loaded and do the rescan which should be affecting all the wallets and update all of them in one rescan?

Has anyone thought about this before and has a solution for this?

You really should use the newer importmulti RPC.

It lets you import multiple private keys at once (and since 0.18, also supports BIP32 derivation etc), and will do the rescan (if desired) once for all keys simultaneously.

If you have accurate birthday information for your keys (a lower bound on the time when the corresponding addresses might be first used on the network), importmulti will even only rescan the relevant part of the chain.


How secure is blockchain.info? How secure is using a wallet on blockchain.info?

How do you evaluate the different sites that provide wallets?

As the operator of the site I will try and answer the first question.

Server Side

The site currently runs on 4 dedicated servers, hosted in a locked cabinet. All servers run  behind a dedicated cisco security appliance with intrusion detection. On the servers themselves various "booby traps" are set to alert the webmaster if an intrusion is detected.
The java code deployed to the Site is deployed in a single war (zip) file. Each server monitors the checksum of this file to detect any unauthorised changes to the code. In order to make reverse engineering our encryption schemes more difficult the the java class files are obfuscated using proguard.
A copy of every wallet is stored all our servers. Additionally the latest 50 versions of a wallet are stored on Amazon S3 and can be restored from the [Import / Export] section.
The server side code that handles wallets is open source.
The site is not vulnerable to CSRF requests as no login details or sensitive data is ever saved in session cookies.
In the time the Site has been running there has been handful of XSS vulnerabilities reported. None of these were on a wallet page and could not have resulted in any direct loss of funds.

Client Side

The Site uses javascript the encrypt and decrypt wallet client side in the user's browser. The encryption is done using AES-256 which is likely to be secure for the foreseeable future.

Wallets are simply json files containing private keys. The entire json file is encrypted by the users browser before being uploaded to us. So when a wallet reaches our server is appears as random Base64 string. This means we cannot view your balance, see your transactions or addresses and cannot make transactions on your behalf.

The encryption is only as strong as the users password. The minimum password length is 10 characters however if the a weak password is chosen e.g. "1234567890" using a dictionary attack the wallet would likely be broken quickly. Rainbow tables will not work as each wallet is prepended with a unique salt combined with the users password using PBKDF2 to derive the actual encryption key.

As everything is done using javascript in the site is particularly vulnerable to browser exploits including malicious browser extensions. Modern web browsers are much more secure than the internet explorer 6 generation.
The private keys in a wallet can be "double encrypted" using a second password. One password is then required to login and another password is required to send funds. This makes wallets significantly harder to brute force and also makes key logging more difficult.
If our servers were compromised the attacker could theoretically alter the javascript files to intercept the users password next time they login. For this to be effective the attack would have to go unnoticed for an extended period of time. In addition to the server side checks we perform there is also the My Wallet verifier browser extension which can be optionally installed for added security. Before login it will transparently verify all the javascript files running on the page match those hosted on github. If any errors are found the extension will prevent the user from logging in.
You can backup a wallet via Email, Dropbox, Google Drive and Download. With a backup funds can be accessed without blockchain.info using the multibit desktop client.
The Site supports a variety of two factor authentication methods and the ability to lock down a wallet to a specific ip address. We will not give out your wallet to anyone who cannot authenticate themselves fully, however we cannot prevent someone from using your wallet if they gain access to it another way. For example if you keep a wallet backup in your email account and that is compromised.

This has got a little technical but it isn't an easy answer. There are many factors involved including the security of your own computer. The site has been running for over a year and currently hosts nearly 40,000 wallets. There have been reports of some individual wallets being compromised (reusing passwords) but no major security incidents.

Finally a couple of recommendations for using our service:

Upon sign up print a "Paper Wallet", store it somewhere safe and hidden.
Never reuse the same password on another site. Or if using double encryption it is acceptable to use a slightly weaker main password but ensure the second password is unique.
If storing large amounts generate a private key offline (bitaddress.org is great for this). Print it on a paper wallet, then import the address as "Watch Only" address. When you attempt to spend the funds you can scan the private key off the paper wallet using a webcam.

In future multisig will be available for even greater security but this isn't quite ready yet.

-Ben


Is it profitable to mine any Altcoin in the Cloud? Amazon aws has servers with GPU. As title says, I would like to mine in the cloud. Is it profitable? I don't mean bitcoin because the network hash power is too high at the moment. I'd like to mine, for example, Dogecoin in the cloud. Is it possible and profitable? Thanks!

If it were profitable, everyone would be doing it, increasing the difficulty, and making it no longer profitable. Mining is only profitable for you if you have some advantage over other miners.


Generating blocks in regtest: "hash doesn't match nBits" I'm getting this error in regtest mode after setgenerate RPC:

  ERROR: CheckProofOfWork() : hash doesn't match nBits

After looking for error text in src I found a match in pow.cpp (obviously standing for proof of work) with following extract from code:

// Check proof of work matches claimed amount
if (hash > bnTarget)
     return error("CheckProofOfWork() : hash doesn't match nBits");

Does it mean there's a target in regtest?If yes, isn't it contradicting to difficulty being 0?

The regtest difficulty is not 0. It is around 0.0000000005 initially (corresponding to 1 hash in 2 being valid), and retargets the same way that the main network does, every 2016 blocks.

The fact that you see this error is a bug though, which will probably be fixed in Bitcoin Core 0.11.


Is there a way to get the node's local time when a block was received? As in, not the miner's timestamp in the blockheader which can be +/- 2 hours, but the receiving node's local time. My concern is the real-world time that elapses between blocks.

When your bitcoin node connects to another node it requests the current timestamp from the node.  It stores this value to calculate the offset from your PC's clock.  As you may be aware the bitcoin network calculates the network time based upon the average offset of the peers that it is connected to.  This will never alter the systems clock more than 70 minutes in regards to network time calculations.

References:
Block timestamp


How does a Trezor passphrase prevent restoration of a wallet if an attacker knows the seed? Trezor User Manual says

  if you forget the passphrase there will be no way to recover your bitcoins. Not even the Recovery seed.

How is it that you (or an attacker who knows the seed) can't just restore a soft wallet with some other application and recover the bitcoins with the other application?

The seed is protected with a password or PIN; it precludes the possibility of stolen devices being decrypted whilst online malware/rootkits are precluded by the hardware device being separate from the compromised OS's memory pool.

From Trezor:

  TREZOR’s PIN based security system is a powerful tool to keep your
  bitcoin’s safe. If your TREZOR is stolen, the only thing between the
  thief and your bitcoins is your PIN and/or passphrase. It is
  imperative that you choose a good PIN!


What is the purpose of the announcement_signatures message as specified by the Lightning Network RFC? Isn't the channel_announcement message enough for channel advertisement? Why is the announcement_signatures message required?

Reference BOLT #7

As far as I understand the process the channel is constructed between two peers. For privacy reasons one of the two peers could decide to keep the channel private.

Bolt7 uses the following quote with a reference to the open message of Bolt2

  The willingness of the initiating node to announce the channel is signaled during channel opening by setting the announce_channel bit in channel_flags (see BOLT #2).

In that case the peer would not sign the channel and disalowing the other party to have a channel_announcement message. In this way the channel cannot be public as others would not react to the announcement as there are signatures missing.

So to summarize: the message with the signatures is a message between the channel partners allowing for a gossip message of the peer2peer protocol to announce the channel. Hope that made it clear (:


If i have rpcuser and rpcpassword of a remote bitcoin server,can i transfer that server's bitcoin to other address? I don't know if this can be done.
Thanks!

If the server is allowing remote connections to the rpc port (usually 8332) and they have rpcallowip set so that your IP address is allowed (e.g. it's set to 0.0.0.0/0), then yes, you can connect to the server and transfer all of the Bitcoin from the server to an address.


How do I connect my `bcoin` wallet to `bitcoind`? I have bitcoind running in regtest mode. I want to connect my bcoin wallet to it and retrieve all UTXOs relevant to the sender's address.

How can I do that?

To run two full nodes on the same machine, they'll need to be bound to different ports. Luckily, bitcoind and bcoin run regtest on different ports already by default (18444 and 48444 respectively). Just note this wouldn't be the case for testnet or main net.

Launch bitcoind

$ bitcoind -daemon -regtest

Launch bcoin in SPV mode

$ bcoin --spv --daemon --network=regtest

Connect bcoin to bitcoind:

$ bcoin-cli --network=regtest rpc addnode 127.0.0.1:18444 add

Get a wallet address from bcoin:

$ bwallet-cli --network=regtest account get default
{
  ...
  "receiveAddress": "n4C5ikvkn5HUNjqAPrPB1udnZPjm9p6xGY",
  ...
}

Generate a block with bitcoind, sending coinbase subsidy to the wallet address:

$ bitcoin-cli -regtest generatetoaddress 1 n4C5ikvkn5HUNjqAPrPB1udnZPjm9p6xGY

Check bcoin wallet balance:

$ bwallet-cli --network=regtest balance
{
  "account": -1,
  "tx": 1,
  "coin": 1,
  "unconfirmed": 5000000000,
  "confirmed": 5000000000
}


Why is there sometimes no output that sends funds back to the sender's address? 'A' has one bitcoin.
'A' tries to send a 0.5 bit coin to 'B'.

Two utxo are created.

First, "utxo" sends "B" 0.5 bitcoin.
Second, "utxo" where "A" remits remaining bitcoins to "A" except for 0.5 bitcoins and fees.

utxo 1) A-->B

utxo 2) A-->A

The url below is the URL to see how UTXO is reflected in the Bitcoin block detector.
https://www.blockchain.com/ko/btc/address/1JK1MAseF6TRjBidxz45T1VnYVFummCTBZ?offset=5250&filter=6

https://www.blockchain.com/ko/btc/address/17YVBuR8oCaC78xQtWbx1gkfmhjt52UMK7

https://www.blockchain.com/ko/btc/address/1HpyyzMwq1QZqS43guyy9GvLdc6jMWoy8z

Sometimes when you look at a block detector, there's some TX information that you don't understand.

For the following URL, the coin in the wallet is used to transfer the same bitcoin from several wallets to another.

There is also a "TX" that displays only the amount of coins received from one wallet.

In the case of the url below, I transfer Coin from my wallet "13E3dBUWUHV8XpgJib795yqRTmyX47jWMk" and there is no utxo sent to my wallet.

utxo 1) A---->B

utxo 2) A---->C

If this is how the money is transferred, can we know why this is happening?

https://www.blockchain.com/ko/btc/address/13E3dBUWUHV8XpgJib795yqRTmYX47jWMk

You are confusing addresses and UTXOs. What you are talking about are addresses, not UTXOs.

The inputs of a transaction have no effect on the outputs. There is no requirement that a transaction must have an output that corresponds to an address that is an input. In fact, what you described first is known as address reuse which is highly discouraged. The behavior you see in the address you have a question about is exactly the kind of behavior that is encouraged: the change is sent to a newly generated address.


Privacy of sending CoinJoined UTXOs from wallet with unCoinJoined UTXOs If I use something like Wasabi to CoinJoin my UTXOs and then send the outputs to a wallet with addresses containing UTXOs that haven't been coinjoined does this present a privacy risk?

...does this present a privacy risk?

Privacy concerns can be boiled down to the following questions: what information am I giving up by engaging in this transaction? And who am I sacrificing this information to?

When you engage with some counterparty to make a payment, they will gain knowledge about your involvement in the bitcoin transaction that includes said payment. An unrelated third party can also watch over all transactions, but they will not necessarily know that you are involved in said transaction specifically. By following the history of transactions and using some (imperfect) heuristics, a third party can potentially trace your coins through time, and given information about your involvement in some prior transaction, they can thus potentially link future transactions to you as well.

A coinjoin helps to sever the ability of any party to trace your coins through time (thus providing privacy). It does this by breaking the heuristics used to track a coin’s history, by effectively creating many possible histories for each output. With enough possible histories, it becomes ineffective to attempt to track a coin’s history through time.

So to answer your question more directly, let’s assume that you spend a coinjoined UTXO to some other wallet you control, and then eventually that UTXO is combined with a non-coinjoined UTXO in order to make a payment to some counterparty.

The counterparty you are engaging with could assume that you most likely control all inputs to the transaction (this is one of the mentioned heuristics), so they will now potentially have knowledge of: your use of coinjoin transactions, and your involvement in a specific coinjoin transaction. Additionally, they will have knowledge of your involvement in the transaction that created the other UTXO you spent. The counterparty could trace this other UTXO back through time, and probabilistically (using the heuristics mentioned) unveil some amount of your financial history.

For an unrelated third party, the same sort of analysis is possible, but they may not be privy to the fact of your involvement in said transactions. They may just be able to determine (probabilistically) that some group of transactions surrounding the transaction in question likely belong to a single user/wallet.

Example: the privacy granted by coinjoin transactions can be truly broken when a third party gains knowledge of your involvement with a transaction on both sides of a coinjoin. For example, if you bought coins from a KYC’d exchange, transferred them to an external wallet, coinjoined, and then sent the coinjoin UTXO straight back to the exchange (to the same user account), then your use of a coinjoin would be useless in protecting your privacy against the exchange. Further, the anonymity set for each other participant in the coinjoin would now be reduced slightly, since the link between least one input and output in the transaction would be known.

———————

So, coinjoin transactions can be effective if used properly, and the more they are used, the more effective they become. But they are not a silver bullet against privacy snoops! Improper use can completely destroy the privacy gains, and so a user must practice careful coin control in order to maintain their privacy most effectively. In the example above, if the user never combined the coinjoin UTXO with any other UTXO that is traceable back to them, then the coinjoin would be quite effective in preserving their privacy. But by combining it with unjoined UTXOs, some privacy may be sacrificed.


Understanding private keys, public keys, adresses and transactions I need some claryfication about the things, here it goes:
1. For what I've read, for generate a bitcoin address is following this flow:(General speaking) Private Key (SK) -> Public Key (PK) -> Address (A). Some say that SK -> PK == A. Which one is correct?
2. Now, in a transaction when X to Y of "n" bitcoins happens this: X signs (digitally) the transaction "t" with its SK and this the part that I don't get it. How "Y" does to open and verify that the transaction was send from X? or besides that X signs the transaction he encrypts? the transaction again with the PK/A of Y for Y can open it? There's something that I missing?

Note that my native language it's not english and it's hard for me to understand this complex topic.

Thanks in advance

Private Key (SK) -> Public Key (PK) -> Address (A). Some say that SK -> PK == A. Which one is correct?

The first one. An address is not a public key. It is some encoding (Base 58 Check encoding or Bech32, depending on the address type) of the RIPEMD160 hash of the SHA256 hash of the public key. The address comes from the public key, but it is not the public key itself. A public key can have multiple addresses.

  Now, in a transaction when X to Y of "n" bitcoins happens this: X signs (digitally) the transaction "t" with its SK and this the part that I don't get it. How "Y" does to open and verify that the transaction was send from X? or besides that X signs the transaction he encrypts? the transaction again with the PK/A of Y for Y can open it? There's something that I missing?

Signing is not the same thing as encrypting. Transactions are not encrypted, no data in a transaction is secret. It can all be read by everyone.

A digital signature can be verified by knowing the message that was signed and the public key corresponding to the private key that signed the message. In the case of Bitcoin, the message is defined by the consensus rules (it is the hash of certain parts of the transaction), and the public key is provided in the transaction itself. Those three things (the public key, signature, and message) can then be used to verify that the signature is valid.


What are bitcoin "confirmations"? When I receive bitcoins I see a certain number of "confirmations" in the client. What do these mean? Why do most sites make me wait for 6 "confirmations" before a purchase will go through?

Bitcoin confirmations represent the number of blocks in the block chain that have been accepted by the network since the block that includes the transaction.

In simpler terms it represents the difficulty of a double spend attack. With zero confirmations no proof of work has been done, so you can't tell if anyone considers the transaction valid.  Even with a single transaction it is possible for an attacker to pre compute a single block.

With zero or even one confirmation a double spend is very possible since the next block that is solved may confirm a different block instead of the one that has the transaction.  That different block my show the coins being spent elsewhere.  The odds that a double spend has occurred gets exponentially smaller with each confirmation.

An attacker must match the power of the entire bitcoin network to keep up with block creation so as time goes by it becomes increasingly difficult to forge a transaction.

It is generally accepted for most transactions that 6 confirmations represent enough security to assure the transition is valid.


How the difficulty of the network affect the average block mining time if we have static hash power? Let's suppose that I have 500 KH/s of hash power overall from my mining rig. I'm about to start mining coin X and its network difficulty is Y. Current hashrate of the whole network is 100 KH/s and calculations are showing that average time of mining one block by my rig is about 1 minute.

I've connected my rig to mine this coin and mined 10 blocks within 10 minutes and let's suppose that difficulty gradually was doubled and became 2Y. Will my rig have to mine next block for 2 minutes instead of the last one?

The rate of you finding blocks solely depends on your own hashrate and the network difficulty, nothing else.

The overall network hashrate influences the difficulty with a delay, which on its turn influences your rate of block finding. However, that's the only effect.


How to enable wallet encryption from the command line? Which command should I use to encrypt a previously unencrypted wallet from the command line?

The command is: bitcoin-cli encryptwallet mypassphrase.

The list with all commands exposed through bitcoind's RPC API can be found here: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list or can be fetched with the command: bitcoin-cli help.

It's worth noting that the encryptwallet command will not show up in bitcoin-cli help's results once your wallet is encrypted, instead you will get three new commands: walletlock,
walletpassphrase and walletpassphrasechange.


Does input and output size vary by address type? For instance, we have two outputs, output X sends to a P2SH address, and output Z sends to a P2PKH address.

Would output X have a different transaction size than output Z? What about the size of the inputs, is that affected by the address type?

Both outputs and inputs differ in size depending on the address format.

P2PKH outputs are 34 bytes and P2SH outputs are 32 bytes.

P2PKH inputs are 148 bytes (180 bytes for uncompressed keys), and P2SH inputs are of variable size depending on the redeem script they need to fulfill. For example, a 2-of-3 multisig P2SH input (a very common P2SH use) has 297 bytes.


How can a ripple wallet trust server? How can a wallet using ripple-lib to interact with the ledger be certain it is seeing the real consensus ledger?  If an attacker has control of the rippled server, or the connection to it, what is to stop them from falsely verifying that funds have been received?

Is it just a matter of trusting server operator + certificate authority + https?  If you are currently connected to a legitimate server is there some data you can save that would confirm that future transactions were verified by the same entity?

One option would be to ask multiple servers: that way you can as sure as you want that. Or you could just run a server—it’s quite simple—and point the wallet to it since, presumably, you wouldn’t lie to yourself.


Why does the "global lottery" prove the validity of the blockchain? As far as I understand it currently, when winning the "lottery" (mining) you can add a block, sum of transactions, to the blockchain. This block is in the first instance verified by all network users.

BUT can`t a lottery winner also add a fraudulent block to the chain?

What does this lottery contribute to the validity of the chain?

Or in other words: How are miners approving a bitcoin transaction, besides adding it to the blockchain when they win? Potentially, they could also add a lot of "sh**" to the blockchain.

Miners do not prove validity. They solve the problem of needing to decide between two potentially conflicting but otherwise valid versions of history.

The rule that full nodes follows is that they accept the longest valid block chain, where valid is defined by the network's consensus rules, and long is defined as having more mining work performed. If a miner produces a block that is invalid according to those rules (for example, it spends a coin without valid signature), full nodes will ignore the block and any block built on top.

There are also lightweight nodes ("SPV nodes") which do not verify validity at all, and will accept whatever block chain has most work. Their security however relies on the fact that blocks are expensive to produce, so a miner wouldn't create one that isn't accepted by full nodes.


How do they put several bitcoins into a block? I recently read that there is an auction to sell almost 24,000 bitcoins, and that they have put them in blocks, each containing 2000 coins. What does that mean to put 2000 BTCs in a block? Can somebody clarify please?

By block they are not referring to the blockchain. They just mean that the 24,518 BTC will be divided into 12 different lots (or blocks) with each auction containing about 2,000 BTC.

https://news.bitcoin.com/ernst-young-auction-24-thousand-btc/

"Ernst & Young will be selling the confiscated cryptocurrency in auction form, allowing bidders to compete for 24 thousand coins in 11 lots of 2,000 BTC. One lot will amount to 2,518 Bitcoins,"


Blockchain.info automatic transaction On Sep 17 I wanted to transfer 0.001 BTC from one Blockchain.info account (bitcoin address 1BFFtYPgtaZUHujDqiehqSseZvuUzJQxki) to another Blockchain.info account (bitcoin address 1DE4VjkipjVEoevVJCpLQARZcYdDvZgcow): transaction 2e358fe6cd80b998eeb3f4378ab0fdbcc8d78e5898a8ebf232394a96908d84be.

I got an email notification about this transaction:

  Subject: Bitcoin Payment Received
  Date: Wed, 17 Sep 2014 18:41:17 +0000 (UTC)

  Payment Received Notification
  A Payment has been received into your bitcoin wallet.
  2e358fe6cd80b998eeb3f4378ab0fdbcc8d78e5898a8ebf232394a96908d84be
  1BFFtYPgtaZUHujDqiehqSseZvuUzJQxki -> 1DE4VjkipjVEoevVJCpLQARZcYdDvZgcow 0.001 BTC

Some days later I got the following email:

  Subject: Bitcoin Transaction Failed
  Date: Fri, 19 Sep 2014 19:03:34 +0000 (UTC)

  Transaction Confirmation Failed
  A transaction made through Blockchain.info has been removed from our database because it was taking a long time to be included in a block.
  Any funds have been returned to your wallet and you can now spend the coins again. Please consider including a larger fee in future transactions.

This happend because I have not included any transaction fee, I know. But I also got this email:

  Subject: Bitcoin Payment Received
  Date: Sat, 20 Sep 2014 02:41:23 +0000 (UTC)

  Payment Received Notification
  A Payment has been received into your bitcoin wallet.
  2e358fe6cd80b998eeb3f4378ab0fdbcc8d78e5898a8ebf232394a96908d84be
  1BFFtYPgtaZUHujDqiehqSseZvuUzJQxki -> 1DE4VjkipjVEoevVJCpLQARZcYdDvZgcow 0.001 BTC

I took no action on the evening of Sep 19. I noticed the latest 2 mails on the morning of Sep 20. This new transaction was created automatically by Blockcain.info. Since the second email said A transaction made through Blockchain.info has been removed from our database [...] I thought the transaction has been deleted but the new transaction ID is the same as on Sep 17.

If you look at Blockchain.info Transaction 2e358fe6cd80b998eeb3f4378ab0fdbcc8d78e5898a8ebf232394a96908d84be you can see Received Time 2014-09-20 02:41:16, not the original date 2014-09-17.

Why have both transactions the same ID?
Why do Blockchain.info automatically create a transaction without asking the user?

You do not understand correctly how does bitcoin network work. Your first transaction was sent to a network and will live there until all it is valid or all nodes forget about it.

Blockchain.info just notifies you that it was not confirmed into a block in reasonable time. Blockchain.info removed it from its memory, but there are nodes on the network which do not forget about it and one of them broadcasted this transaction to its peers.

  Why have both transactions the same ID?

These are not two transactions. This is one transacton, received by blockchain.info twice. First time you sent it. Second time blockchain.info received it fron one of peers.

  Why do Blockchain.info automatically create a transaction without asking the user?

They did not.


How does mining work on the moving target (variables change every second)? In bitcoin, miners hash the header twice with the SHA256 function. This header consists of the fields listed below:

version (v)
previousHashBlock (p)
merkleRoot (m)
time (t)
difficulty (d)
nonce (n)

Let's simplify and say that I am a pool miner with nonce range from 1-100. So if I do my share and find that on 9th minute the Nonce value of 91, solves the puzzle (proof of work). But by the time I send to network, merkleRoot and time has changed, so the nonce that I've found is not true anymore. We know that hash changes dramatically with slightest change of input, but in this formula, not one but TWO variable change constantly throughout my mining period (in this case 9 minute). Transaction occured and time changed.
So how does this formula hold true thoughout the mining time?

SHA256(v + p + m + t + d + n(91)) => 0000000asd8f686asd6das

Where m and t changes constantly? Wouldn't 91 be irrelevant at the time of finding?

Realistic miners run through all 2^32 possible nonces in much less than a second.

If a transaction occurred after you started your nonce search, then your block won't include that transaction. There's no problem with that.

If the time changed after you mined your block, then your block won't have the exact right time. Again, no problem with that.

And if you think about it, there can't be any problem with that. How would anyone know when you mined the block or whether the transaction occurred before or after you mined the block? It's mining that allows bitcoin to agree on these things, so if you mined the block, you're the one who gets to choose.


When will the last block halving happen and when will the block reward fall to 0? I could not find an answer for these questions:

I found out that there are 33 periods of 210,000 blocks?!?!? First one gave the miner 50 bitcoins per block, then 25, 12.5 ... and the last one 1 satoshi.

My questions:

So there must be 32 block halvings, right?
When will the last block halving happen?
When will the block reward fall to 0?

For questions 2 & 3:

After which block will it happen?
In which year will it happen?

I created a Google doc to calculate some metrics of the Bitcoin reward schedule including e.g. the number of halvings, their first blocks, and how much supply is left to be mined.

As you can see, there will be 33 epochs of 210,000 blocks with a block subsidy. Bitcoin doesn't end there, after that the block reward will be composed only of transaction fees.

The block subsidy will be reduced 33 times, 32 times halving the block reward, and the last event ("33rd halving") reducing the block subsidy from 1 satoshi per block to zero satoshis per block. The limit of the block subsidy is accounted in a whole number of satoshis. The protocol does not allow partial satoshis to be created.

The last (32nd) halving will occur on block 6,720,000 reducing the block subsidy from 2 sats to 1 sat, approximately in 2136, the 33rd "halving" will reduce the block subsidy to zero in block 6,930,000 approximately in year 2140. This means that the last block with a block subsidy will be block 6,929,999.

Related:

How many Halving Days will there be?
How many Bitcoin are mined per day?
How much inflation does Bitcoin have, year by year?

Terminology:

Block subsidy: newly minted coins in a block
Block reward: the miner's total yield from a block composed of block subsidy plus transaction fees


Checking if transaction is RBF A transaction can be RBF if itself is a RBF, or it spends outputs from a RBF transaction.

Is there a way to use bitcoin RPC node to check if a transaction is spending outputs from a RBF transcation?

The getrawmempool RPC command, in verbose mode, produces an output that contains all known mempool transactions for your nodes. This output contains a bip125-replaceable boolean field which you can use to determine if a tx is explicitly or implicitly replaceable by fee.


In blockchain, particular bitcoin why is difficulty not part of the Block but merkleroothash is After some consideration I came up with two assumptions, please correct me if I am way off here.

The merkleroot being part of the block information is a validation shortcut?
Difficulty not being part of the block information is due to the fact this can be derrived from the version header? (but this would require to have all difficulties being hardcoded forever into the code? This doesn't rhyme with dynamic difficulty, so basically I am wondering how a block can be validated without seemingly "knowing" its difficulty)

Actually it kinda is, the nBits field encodes the target threshold in the block header, which is directly related to, and more directly useful than, the difficulty itself.


Use json-rpc without full blockchain So i want trying to use both bitcoin and bitcoin-abc json-rpc on raspberry pi but they will overload the whole pi when downloading and sync @ same time.

So is there anyway to use json-rpc without downloading and sync the whole blockchain or overload the raspberry pi?

if you want to use bitcoin core, you have to install blockchain. maybe you can use prune mode after its totally synced.

If you want to use JSON-RPC without installing the blockchain, I suggest you use electrum servers. You can send JSON-RPC commands without installing anything. You just connect to someone's server.

the commands not the same as bitcoin-core, for instance, you can't createrawtransaction but you can get any address balance or transaction details.

if you want to work with bitcoin-cash, You can connect to electrum bitcoin-cash servers.

check electrum protocol methods here.


I can't send a transaction from electrums cli I am trying to send a transaction in the cli using electrum with the command ~$

  electrum --testnet payto mvYrQck9VfujSanmwvQxiLab3fLuywGdvh 0.01 -f 0.002

Password: (I entered the correct password here)
Q

{
    "complete": true,
    "final": true,
    "hex": "0100000001c36cdc20a497f12731f96b89f830d2743245c4adc1f4a622b8c2e234821cd76e7f0000006a4730440220028106ef3432af605c882db4d9065e318ee6a7513e7731d83a01d3a156985c1d0220256e6213c0bc59f63239a9375636228a6e601b02822bfb28f31adcc15d42e7da0121031720b63d82383198cf67c770d6f8c00877d2721bcb2308ad0717685d706aba55feffffff0240420f00000000001976a914a4e5cdf9a742245b2cb4254640ee2aa16e95809e88ac2cd1cf00000000001976a91457054c8af735007871b7a3697c5736280f59183f88acbd8d1500"
}

but when I open electrums gui I don't see the transaction in the history tab and my balance remains the same.


Is 8 the maximum number of incoming peer connections? The reference here for running the bitcoin daemon does not really clarify what maxconnections mean.

maxconnections=  Maintain at most  connections to peers (default: 125)

Is this the max connection for all inbound and outbound peer connections? Or is it just to one or the other? If I understand correctly, inbound connections are others trying to connect to your node for information (e.g. transaction) propagation, while outbound connections are your bitcoin daemon node connecting to others for information.

Here's another reference in one of the posted answers that stated 8 outbound peer connections is the max; it seems to imply that the number of outbound peer connections is unconfigurable. Furthermore, that maxconnections only controls the number of inbound connections and not outbound. Is this true?

I don't intend on being connected to by other peers (this decision is rather selfish, but that's besides the point), so I've blocked port 8333. I believe, effectively, blocking port 8333 will only stop peers from connecting to me (stops inbound) and not me connecting to peers (does not stop outbound). Is this right?

What implications do blocking port 8333 have on my bitcoin daemon from getting transactions? Does it get less transactions or get transactions slower? I've been noticing that for relatively long stretches of time (e.g. 20 seconds or so), sometimes I see no transactions come through.

The reference here for running the bitcoin daemon does not really clarify what maxconnections mean.
Furthermore, that maxconnections only controls the number of inbound connections and not outbound. Is this true?

maxconnections counts both inbound and outbound connections. If you have 8 outbound connections, you can only have 117 inbound connections.

Is 8 the maximum number of incoming peer connections?

No, 8 is the maximum number of outgoing connections.

I believe, effectively, blocking port 8333 will only stop peers from connecting to me (stops inbound) and not me connecting to peers (does not stop outbound). Is this right?

Yes, that's correct. Also, there's a setting to do this without firewall software - set listen=0

What implications do blocking port 8333 have on my bitcoin daemon from getting transactions? Does it get less transactions or get transactions slower?

That could happen in theory, but in my experience it still works pretty well.


Can I use Armory without having the Blockchain in my laptop? I just started (to try) to use Bitcoin and the first issue I face is that I need to download the 100+ GB blockchain in order to use any of the wallets, such as Armory. This can take a very long time due to my internet speed.

I successfully installed bitcoin and bitcoin-qt in my laptop, as well as Armory, but now I have to download the blockchain in order to be able to make any transaction.

So I wonder, Is there any possibility to use Bitcoin (and have a wallet, client, such as Armory) for buying and selling bitcoins without having the entire blockchain downloaded in my laptop ?

PS: I'm new to this, so any help is greatly appreciated!

No. Armory requires you to download the entire blockchain. You cannot use pruning either as Armory requires the entire blockchain to be present in order for it to work properly.


Bitcoind Keypool Best Practices For Web App I'm creating a web application where many, many transactions will take place in a day. I have the bitcoin daemon running on a VPS and talking to my web app via JSON-RPC.

The users on my website will be generating many different addresses and sending many different bitcoins to these addresses (much more than the 100 keys by default in the keypool).

Should I simply set the keypool size to be something like 100,000 (or the max number of addresses generated per day) then perform a daily backup? Or what other method is the best when dealing with a very large amount of address generations?

Consider using hierarchical BIP32 wallets. You can generate the addresses with various tools (e.g. sx) or natively in your web app. Then you can import the keys to your bitcoind node in order to manage them. If needed, you can have multiple bitcoind nodes and load-balance the keys among them (e.g. having X customers per node).

The great advantage of BIP32 wallets is that you only need to perform the backup once - at the beginning, since all the keys are derived from the initial seed.


Probability of Finding a Block I've been using cryptocurrency revenue calculators and have appeared to figure out that for all of the major algorithms, the probability of a hash being valid is 1/(D*2^u) where u is either 0, 13 (weird), or 32 and D is the network difficulty. I used the formula (my_hashrateblock_rewardtime) * 1/D * 1/2^u to find revenue. I believe the following is true:

u = 32 for SHA-256, Scrypt, X11, Groestl, X11Ghost, Lyra2Rev2, NeoScrypt, Blake (14r)
u = 13 for Equihash
u = 0 for CryptoNight, Ethash

Can someone explain this phenomenon? Will the constant part of the probability change over time or will the difficulty adjust?

To look at it a different way, the probability for solving a block in Bitcoin is approximately:

1 / ({total network hash per second} x {average block time in seconds})

Note that block time is the average.

As of writing, this is:

Probability = 1 / (24,667,167,000,000,000 x 600)
= 1 / 1.48003002×10¹⁹
= 6.75661970694351186200939356621969059789746697164966964... × 10^-20 (WolframAlpha)

Data source: blockchain.info


Verifying transation inputs I have a question about practical implementation of one part of Bitcoin protocol.

I'm reading the Protocol Rules for Bitcoin - "tx" messages and point 14 states that "For each input, if the referenced output has already been spent by a transaction in the main branch, reject this transaction".

How does the client validate that output has not been spent? It seems that it should remember all transations and amount of Bitcoins for all known addresses. This would take a lot of memory to store them all. Is there an optimization I'm not aware of?

Actually, that is exactly what happens, and it is the reason why synchronizing the block chain is so slow: we download all blocks, with all transaction history in it, and build and maintain an index that states which transaction output was spent or not, and even where it was spent.

As of 0.8, the reference client will switch to a new model where no such index is maintained anymore. Instead, it will maintain a copy of the set of transactions, but only with their not-yet-spent outputs, which is much smaller than the full data (around 150 MiB as of writing, december 10, 2012).


How do you verify a block manually? From my understanding, you simply need to use a SHA256 function to hash the block's header (Block hash and merkle root) then add the nonce at the end like this article explains.

However, I can't manage to get the correct next block hash.
By using the block #505400 :

Hash : 00000000000000000023b89dd18f6be5a6c03a71cd864ccbdf024683114b9ce3

Merkle root :  a3defcaa713d267eacab786c4cc9c0df895d8ac02066df6c84c7aec437ae17ae

Nonce : 2816816696

Next block hash : 0000000000000000007625ff74171cf53e301c3e5013bf2184e2629a2da0fc8d

What I am expecting : sha256(Hash + Merkle Root + Nonce) = Next Block Hash

However I get this : 10345cb85ffed406a47e1faf31eb8ba1160aac0fbaae3cae0cd66889f9c9f49e

What did I do wrong?

That isn't the way a block header is created. The block header is constructed as

the version
the hash of the previous block
the merkle root
the timestamp
the nBits field
and the nonce.

Once serialized in bytes, the header is hashed twice with SHA256 not just once.

A common mistake is to hash the string of hex representation of the bytes, you must hash the bytes themselves.

See here for more info: https://en.bitcoin.it/wiki/Block_hashing_algorithm

The hash is the hash of that block. It does not give the hash of the next block following it, there is no way to know what the next block hash will be and there are many possible hashes it could be.


segwit nested in p2sh I understand that P2SH addresses are used to allow "segwit unaware" wallets to create outputs spendable by segwit wallets (please correct me if I got something wrong). For new clients I think I got it: they will check that the script cointaned in the witness matches the script hash and execute it.

What I do not understand is how this  output is spendable by a segwit aware client to the eyes of an old client. Because it clearly doesn't look like an anyone can spend. How does it work?

Thanks.

There was a longer discussion thread in bitcointalk, I proide two references:

https://bitcointalk.org/index.php?topic=2333913.msg23758008#msg23758008

https://bitcointalk.org/index.php?topic=1682183.msg21389041#msg21389041

(Both threads are worthwhile to read in it's entirety).
In short: before nodes talk to each other, they verify the capabilities. And a segwit node would reduce the information for a non-segwit node, so that he can understand the transaction details.


When does the main client relay its knowledge of TXs in INV message? The inv message is used to relay one's knowledge of blocks and txs to other clients in the Network. When a new Client connects to the Network, it first receives information about all the blocks in form of an inv message, as a response to getblocks messages. As there is no gettx message, I presume the information about transactions is  relayed in the last inv response to getblocks. Is that indeed the way the Standard Client operates, or does it just relay the tx messages only when they arrive, making newly connected Clients wait to catch up with the information about the txs?

ThreadMessageHandler2() calls SendMessages() every 100 seconds, which causes inv messages to be sent to the client's peers.

One peer is picked at random to receive inv messages which reference all the pending transactions that we know about and it doesn't, including the ones we created ourselves.  The rest of the peers receive a inv messages which only reference around 25% of the pending transactions that we know about and they don't, not including any of the ones we created.

A comment in the code explains that this "trickling" of transaction inventory is to protect privacy.

Edit: I just noticed this thread which also describes the process of advertising transactions.  Luckily it agrees with my description here.


Create Sign and send bitcoin transaction using HD wallet I am new in bitcoin. I want to implement a bitcoin payment system. I am using blockcypher's API. Suppose we have an hd wallet "myhdwallet" and we have driven 2 addresses using xpub for my hd wallet. (address A=> m/0/1 ,address B=>m/0/2,...). I want to create a transaction and send some bitcoins from my wallet's addresses to destination address C. How can I do that? I was successful in sending bitcoin using private keys. But here I do not have any private key for addresses. I just have wallet name and xpub. How can I do that using blockcypher's API?

To spend any coins, you’ll need the private key corresponding to that bitcoin address.

In the case of an address derived from an xpub, you’ll need to use the xpriv that created the xpub to derive the child privkeys (they’ll be the same child pubkeys that the xpub derived, but this time you’ll have access to both child privkeys and pubkeys). As you know, it is not possible to derive the child privkeys from an xpub itself.


Is there an API that exchanges USD to Bitcoin? I'm looking for an API that literally exchanges USD to Bitcoin, not only value.

I've been looking all over for an exchange that accepts USD in it's API.

I've found tons that will do Crypto => Crypto but none that would do USD => Crypto.

Can someone share a service that does that? Or is there another way to exchange USD to Crypto programmatically?

This looks like a service that does what you're asking for, if I'm understanding your ask and this page correctly: https://developers.coinbase.com/docs/wallet/guides/send-receive

This would require you to already have USD on deposit in your Coinbase account.  The page says they are working on a feature to automatically withdraw USD from a linked bank account (I wouldn't hold my breath for this).

Since you explicitly asked about doing this via an API, I looked into this aspect a little bit, too:
https://developers.coinbase.com/api/v2#transactions

In the example json on the right, I'm seeing that it has separate "amount" and "native amount" sections specifying BTC and USD respectively, and there's an "instant_exchange" field.  This leads me to believe it can do exactly what you're asking for, provided you have USD on deposit and instantly available:

Hold USD, not BTC
Create a new transaction to send BTC, via API
USD is converted to BTC "just-in-time" at time of transaction

I didn't look into converting a USD amount to BTC based on the current price via Coinbase's API, but of course their API will provide for that (via a previous request).

blockchain.info also offers a free API to do this, although I'm sure the precise exchange rate on Coinbase will vary slightly from what blockchain.info reports: https://blockchain.info/tobtc?currency=USD&value=500

Hope that helps.. although I imagine you've probably answered this yourself since posting this question.


What is the difference between PPS+ and PPS? Some pools do offer such a payment method as PPS+. This method is claimed as better than the PPS method, it should insure against losses on orphans and blocks with bad luck. But this explanation is too fuzzy and obscure for me so I do not understand how to calculate exact payments.
Is it true that the PPS+ is not only insure against the losses on the bad-luck blocks but also prevent to earn a surplus on the block with high luck? And I need a formula to calculate rewards on per-block basis.

PPS+ meaning that you receive payment per each share + block fee reward distributed using PPLNS.


Transaction validity clause: output must exist I'm reading through the Mastering Bitcoin book and the section talking about what nodes check for to ensure a transaction is valid before accepting it refers to this:

  Each node verifies every transaction against a long checklist of
  criteria:

  ...

  For each input, the referenced output must exist and
  cannot already be spent.

However, I'm not sure exactly what it means for "an output to exist". How can an output exist if I am creating it now with this transaction?

After reviewing the structure of a transaction, I now understand what is meant by that statement.

The input is the UTXO, and the output is the output of that UTXO. So when it says the output must exist and cannot already be spent, it's saying the output of the UTXO must exist and not already be spent.


How to securely update and verify C-Lightning release? Recently, a new version (v0.7.3) of C-Lightning was released. The GitHub page has detailed instructions on how to build the software from source, but does not provide much details as to how to update the software from the pre-built binaries from the release page.

I'm looking for instructions as to how to update the C-lightning software from the pre-built binaries for different OS (Windows, Linux, Mac etc.)

How do I verify the release signatures of the C-Lightning pre-built binaries?

I have divided this post into three sections: Download, Verification and Installation to make it easier for people needing help with specific sections. The installation steps have been reproduced using Ubuntu 18.04 but can easily be used for other versions as well. Just make sure to download the specific pre-built binaries from the release page for the OS you are using.

Download

C-lightning implementation is designed to work effectively only in Linux environment as of now. All the c-lightning releases gets posted on the GitHub’s release page. You can download them directly from the browser or use the below terminal commands:

# Download the Ubuntu release of C-lightning from the release page
ubuntu@user:~/Downloads$ wget https://github.com/ElementsProject/lightning/releases/download/v0.7.3/clightning-v0.7.3-Ubuntu-18.04.tar.xz

# Download the SHA256SUMS file that contains the hashes of the release
ubuntu@user:~/Downloads$ wget https://github.com/ElementsProject/lightning/releases/download/v0.7.3/SHA256SUMS

# Download the digital signature file SHA256SUMS.asc
ubuntu@user:~/Downloads$ wget https://github.com/ElementsProject/lightning/releases/download/v0.7.3/SHA256SUMS.asc

Verification

Before installing the software it is a MUST to check the signatures of the release. This ensures that the software has not been modified by a third party on the release page or has been tampered during the download process via a man-in-the-middle attack.

Following steps are followed to check the authenticity of the file:

Compute the SHA256 hash of the main file
Check that the hash matches that in the SHA256SUMS file we downloaded
Verify that this hash has been signed by a trusted developer

The first step is to check whether the SHA256 hash of the file that we have downloaded matches the hash produced in the SHA256SUMS file. Since SHA256 is a one way mathematical function it helps ensure that the downloaded file has not been modified as its hash matches that in the SHA256SUMS file.

# Calculate the SHA256 of the file that we downloaded in the last step
ubuntu@user:~/Downloads$ sha256sum clightning-v0.7.3-Ubuntu-18.04.tar.xz
e36d259696ad172d509be712c0ee96b64a454d9a836b7a576d0bc26a580b313e  clightning-v0.7.3-Ubuntu-18.04.tar.xz

# Verify that the above hash matches the hash in the SHA256SUMS file
ubuntu@user:~/Downloads$ cat SHA256SUMS | grep clightning-v0.7.3-Ubuntu-18.04.tar.xz
e36d259696ad172d509be712c0ee96b64a454d9a836b7a576d0bc26a580b313e  release/clightning-v0.7.3-Ubuntu-18.04.tar.xz

As you can see above, the hashes matched. However, just matching the hashes is insufficient. An attacker could have modified the zip file, and reproduced its changed hash in the SHA256SUMS file. Thus we need to ensure that the hash that is in the SHA256SUMS file has actually been signed by a trusted person. For this, we need to verify the signatures.

You can do that by using gpg. First we will need to import public keys of the developers who signs these releases. You can find them here.

# import Rusty Russell's key
ubuntu@user:~/Downloads gpg --recv-keys 15EE8D6CAB0E7F0CF999BFCBD9200E6CD1ADB8F1

# import Christian Decker's key
ubuntu@user:~/Downloads gpg --recv-keys B7C4BE81184FC203D52C35C51416D83DC4F0E86D

# import Lisa Neigut's key
ubuntu@user:~/Downloads gpg --recv-keys 30DE693AE0DE9E37B3E7EB6BBFF0F67810C1EED1

The below step checks the signatures against the hashes in the SHA256SUMS file. If the SHA256SUMS file is missing you will get a can't hash datafile: No data error.

ubuntu@user:~/Downloads gpg --verify SHA256SUMS.asc
gpg: assuming signed data in 'SHA256SUMS'
gpg: Signature made Mon 28 Oct 2019 11:15:50 PM UTC
gpg:                using RSA key 30DE693AE0DE9E37B3E7EB6BBFF0F67810C1EED1
gpg: Good signature from "Lisa Neigut <niftynei@gmail.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 30DE 693A E0DE 9E37 B3E7  EB6B BFF0 F678 10C1 EED1
gpg: Signature made Mon 28 Oct 2019 11:51:59 PM UTC
gpg:                using RSA key 15EE8D6CAB0E7F0CF999BFCBD9200E6CD1ADB8F1
gpg: Good signature from "Rusty Russell <rusty@rustcorp.com.au>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 15EE 8D6C AB0E 7F0C F999  BFCB D920 0E6C D1AD B8F1
gpg: Signature made Tue 29 Oct 2019 08:07:39 PM UTC
gpg:                using RSA key B7C4BE81184FC203D52C35C51416D83DC4F0E86D
gpg: Good signature from "Christian Decker <decker.christian@gmail.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: B731 AAC5 21B0 1385 9313  F674 A26D 6D9F E088 ED58
     Subkey fingerprint: B7C4 BE81 184F C203 D52C  35C5 1416 D83D C4F0 E86D

Installation

Now that we have verified the authenticity of the file, we can safely extract the zip file using the command tar xf clightning-v0.7.3-Ubuntu-18.04.tar.xz. The extracted folder will have folders bin, libexec and share as its contents. Paste the contents of these folders in the /usr/ directory (or /usr/local/). Note: Just replace the files within these folders. Do not directly replace these folders as these folders generally contain binaries of other critical software as well.


Getting "Can't run the JVM" when starting Ardor on Windows 10 When running Ardor 2.2.1 on Windows 10, I'm getting "Can't run the JVM" error. Also tried going to the command line and going to:

C:\Program Files\Ardor

and running run.bat

It just pops open a window and closes.

If you edit the run.bat file you'll notice the last line that begins with start

I copied that line and made the java.exe paths absolute instead of relative and pasted this line into the command line window:

  "C:\Program Files\Java\jre1.8.0_191\bin\java.exe" -cp classes;lib*;conf;addons\classes;addons\lib* -Dnxt.runtime.mode=desktop nxt.Nxt

If Ardor starts, that just means your java paths are not working properly in windows.


How to parse transaction script to address the correct way? i am currently parsing blockchain transaction data from the raw hex blk00000.dat files downloaded by Bitcoin core. In order to validate, i compare my results with blockchain.info from time to time.

While the major part of my parsing is already correct, i came accross a problem with the conversion of the output script to the corresponding address.

Many of the addresses are already correctly parsed, as well, however there are some exceptions where the results are not the same as listed on blockchain.info. In my mind, it seems to be a problem with the transaction type. Apparently, for a transaction different from P2PKH, the output script will look differently, such that i cannot run the script through the same function that converts to the address all the time.

I think to have figured out that the public keys in P2PKH-transactions scripts begin with 76 all the time, is that enough to determine the type as P2PKH?

Furthermore, i came across some few transactions that begin with 4104 and end with ac. For those ones, I have to use a different function to convert to the address, then it works.

Lastly, i wanted to ask, what other transaction types i could come across? I need to parse every transaction script to an address 100% correctly, thus i need to cover all possible cases.

When searching on the web for pre-written code, i found many partly useful, but also false or maybe old snippets.
What i am searching for is a general function that i can parse the output script (or the complete raw transaction string) to and that delivers the output addresses and values of BTC / Satoshi sent to these.

Of course, if you can recommend an overall python parser for the rawtx hex strings from the .dat-files, i would be also glad :)
The main info i need for each transaction:
- the hash of the corresponding block
- transaction time (block time)
- number of inputs and outputs
- inputs [(block index (vout), txid), (...)]
- outputs [(value, address), (...)]
- the overall transaction hash

Thank you.

I think to have figured out that the public keys in P2PKH-transactions scripts begin with 76 all the time, is that enough to determine the type as P2PKH?

No. The 0x76 is the number of the first opcode, OP_DUP. A full P2PKH transaction has the template OP_DUP OP_HASH160 0x14 <pkh> OP_EQUALVERIFY OP_CHECKSIG.

  Lastly, i wanted to ask, what other transaction types i could come across? I need to parse every transaction script to an address 100% correctly, thus i need to cover all possible cases.

Scripts can contain anything and there's not necessarily an address for them. Addresses represent specific data in standard transactions, of which there are only a few different types.

P2PKH (as above)
P2SH (OP_HASH160, 0x14 followed by the 20-byte hash of the redeem script and OP_EQUAL)
P2WPKH (witness version 0x00 followed by PKH)
P2WSH (witness version 0x00 followed by script hash)
P2MultiSig (OP_N, <pubKey1>..<pubKeyN> OP_M OP_CHECKMULTISIG where N <= 3)
OP_RETURN <data>

The first two, P2PKH and P2SH use base58 addresses beginning with 1 and 3 respectively on mainnet.

P2WPKH and P2WSH use bech32 addresses beginning with bc1 on mainnet. You can determine the difference based on their length. Witness versions > 0 are also standard, but have no known meaning - this is intended for future extensibility.

OP_RETURN and P2MS don't have standard addresses. Nor do any non-standard transactions which do not fit any of the above conventions. Addresses are intended for human readability and parsing, so that software can simply recognize what kind of output is used, and how to create the relevant scriptSig to spend them.

Standard transactions are only a policy in software used to determine which kinds of unconfirmed transactions can be accepted into the mempool. Transactions confirmed in blocks can ignore these standardness rules and contain arbitrary scripts, as long as they evaluate to true.

The full details for parsing the standard script types are defined in standard.cpp in Bitcoin Core.


How to generate a Litecoin testnet addresses (Segwit also) (Derivation path, bip32) I'm creating a wallet that generates address for litecoin mainnet in two ways.

One is using bitcoinjs-lib. This library has an object with all the data need it to create private keys and address:

import Bitcoin from 'bitcoinjs-lib'

console.log(Bitcoin.networks.litecoin)
{
    messagePrefix: '\x18Bitcoin Signed Message:\n',
    bip32: {
        public: 71979618,
        private: 71978536
    },
    pubKeyHash: 111,
    scriptHash: 196,
    wif: 239
}

This ok for the mainnet, but I am not able to find on internet the same version of this for testnet.

The other way is using derivation paths. But again, I only could find the mainnet version of this.

mainnet: `m/44'/2'/0'/0/${index}`
mainnet_segwit: `m/49'/2'/0'/0/${index}`

Any idea where I can find it?

const ltcnet = {
    messagePrefix: '\x19Litecoin Signed Message:\n',
    bip32: {
      public: 0x043587cf,
      private: 0x04358394
    },
    pubKeyHash: 0x6f,
    scriptHash: 0xc4, //  for segwit (start with 2)
    wif: 0xef
  }

use it like this:

var key = bitcoin.HDNode.fromSeedHex(seed, ltcnet)


What complexity class is Bitcoin's proof-of-work (hashcash) in? To formulate this question precisely, I will define an idealized hypothetical "perfect" hash function H(n) which has nice scalability properties, and will formulate a problem PERFECT HASHCASH in terms of that, understanding that practical considerations may end up yielding only an approximation of this ideal.

To keep it simple, we will say that our hash function H(n) takes as input a single natural number n. Then we say that H(n) is a perfect hash function iff:

H(n) maps each natural number to an infinite binary sequence, of which the time complexity to compute any initial segment s is polynomial in the size of n and s, (making it a sponge function).
For any initial segment of length d, the set of all natural numbers n such that H(n) shares that initial segment has natural density = 1/(2^d).

The first thing formalizes the scalability of our function, and the second thing formalizes the idea that we want all hashes to appear roughly "equally often" as an output. Other than that, our perfect hash function is a black box, and we don't care much about exactly how it works, so long as it meets the above properties, as well as the usual desiderata applying to hash functions (easy to compute, hard to invert, hard to find collisions, etc).

Predicated on the assumption that a perfect hash function exists, we can now define the problem PERFECT HASHCASH as follows: PERFECT HASHCASH takes as input a perfect hash function H, a natural number n, and an all-zeroes vector 0^d of length d, which can be thought of as a unary representation of d. A solution to PERFECT HASHCASH consists of an n and d such that H(n) starts with 0^d.

Given those inputs, it is clear that PERFECT HASHCASH is in the complexity class TFNP, since this is a function problem and a solution is guaranteed to exist.

Can we also identify PERFECT HASHCASH as a member of any complexity class finer than TFNP?

Could it perhaps be in PPP? PPA? PPAD? Something else?

For background, see Complexity class on Wikipedia.

EDIT: the above question has been overhauled, as in the way that I originally formulated it I assumed that SHA256 is what I'm now calling a perfect hash function. Many people have noted in the comments that this may not be true, so rather than place the emphasis in this question on whether SHA256 specifically has the nice scaling properties we want, I defined an idealized hash function that we hope SHA256 at least approximates nicely enough for real-world purposes, and rephrased the question in terms of that.

As a final note to clear up any potential confusion, to make PERFECT HASHCASH resemble real Hashcash, we'd have to make one more assumption: that there exists some way to start with a block of data (an email, a Bitcoin block, etc) and somehow derive a characteristic perfect hash function from that, perhaps by "salting" a different perfect hash function in a way that the result is also another perfect hash function. So in the case of a "perfect Bitcoin," all of the miners on the bitcoin network would be working with their own unique perfect hash functions H'(n) which are somehow tied to the block they're working on, and each miner would simply try H'(0), H'(1), H'(2), ... in order until they find something starting with enough 0's. Each H' would be a different input to PERFECT HASHCASH.

There's a reason cryptographic hash functions, like the double SHA256 used for proof-of-work in Bitcoin, are not usually described using these complexity classes that classify asymptotic behavior. In fact, there are several.

A technical reason is that hash functions often do not scale. For example, it is not defined how one would extend the proof-of-work to operate on 512 bits. A natural choice would be to use SHA512 then, but going from SHA256 to SHA512 takes alot of essentially arbitrary choices, like changing the number of rounds from 64 to 80, which are standardized but not in a naturally scaling way and not for arbitrarily large hash sizes.
It is not relevant for the cryptographer. Even a NP-complete hash function, which would be the strongest amongst the complexity cases you listed for building a strong hash, does not guarantee all what we want from either a cryptographic hash or a proof-of-work function. To qualify for NP-completeness is merely a strong heuristic that the problem cannot be solved by an algorithm that is, asymptotically, less than exponential. But for a good hash function we want it to be, at the very limited bitcount we choose to use it at, maximally exponential in the sense that solving it is really as hard as trying every possibility in a hash function. For its corresponding proof-of-work function with such a difficulty that only a fraction x of the output range is acceptable, this would mean that we should expect to require a number of attempts of x/2 times the size of full output range to find a proof-of-work. Anything better than that would prompt an academic to call the associated hash function broken, even if it merely reduces the number of tries in half, which would still put it in an exponential complexity class and would easily be possible even with a NP-complete function.

An impressive (but only superficially related) example of how picking something seemingly NP-complete is insufficient to get something cryptographically hard is knapsack cryptography. Of course, there the problem was that by picking special cases the complexity of the problem was reduced. The point is that even a NP-complete problem can be less difficult than indeed having to try every solution, despite it sometimes being described that way! For cryptography-grade quality, having to try every input is meant literally; for the complexity analysis, it is good enough if the asymptotic scaling remains exponential in the number of bits. So if you could reduce the problem to another NP-complete function taking only every 1000th bit as input, that would be good enough for classifying the problem as NP (and even NP-complete if a similar mapping worked in reverse), but not for being of interest for cryptographic applications.
It's difficult! And I think this difficulty has already let you astray: Even your arguments for placing this problem in TFNP are, whilst really close to the truth, not true in the mathematical sense. For example, if I specify x=0, no y can produce hash(y) < x, contradicting your assertion. If all other x are fine or if there is a required minimum value for x probably depends on how you define the "strings" y you want hashcash to operate on. For Bitcoin with a limited number of bits entering the double-SHA256, I wouldn't be surprised if x=1 also does not have a solution, i.e. if no block hash can become exactly zero. Of course we'll probably never know. In practice, it is desirable that a hash function should produce total proof-of-work functions in the way you describe, but I don't think it is a proven quality. Disclaimer: I honestly don't know. You really should ask a cryptographer.

What remains to be done to answer your question, after finding how the hash function scales and verifying that it remains polynomial for arbitrary large sizes, is just this proof that the corresponding proof-of-work function is total. If this proof can be done using the pigeon hole principle, you have shown that it is in PPP, etc.

So where is the difficulty? For example, if y has at least as many bits as x, and if we change your hashcash to have a less-than-or-equal rather just less-than, and if we are willing to multilate it further to the point that either finding a proof-of-work or the existence of a hash collision is good enough to make "hashcash" true, then the pigeon-hole principle as explained in the wikipedia article you linked to would obviously apply.

But anything less than that, as best as I can see, would not suffice to apply the pigeon-hole principle and hence would not answer the question if hashcash is in PPP or not. To again refer to your linked wikipedia article: Only for very few problems the answer is know, even for PPP. For the special cases of PPP, PPA and PPAD, it obviously gets even harder. If you find a solution, post it to an academic journal, not just here!


How to split fee between more than one miners? I found that some BTC blocks have more than one miners, for instance:
https://www.blockchain.com/btc/block/000000000000000049a0914d83df36982c77ac1f65ade6a52bdced2ce312aba9
there are two miners:
['coinbase']=========>[{'amount': Decimal('1E-8'), 'address': ['1BGbGFBhsXYq6kTyjSC9AHRe1dhe76tD6i']}, {'amount': Decimal('25.09323034'), 'address': ['1A73ExsM2doRwTLp82rv5U36QHbBFmHD1X']}]
My question are:

Basically, there should be only one miner for one block, why there are two miners?
Then, how to split transaction fee between these miners, according to their bonus ratio?

Thanks.

A coinbase transaction is allowed to have as many outputs as the miner wishes so long as the total amount in those outputs does not exceed the block subsidy + transaction fees for that block.
Thus a miner could create a coinbase transaction which has more than one output which pays to himself and someone else. It doesn't matter who the recipients of the outputs are. In fact, it doesn't matter if the outputs have invalid scripts. There are no rules on what the output scripts must be.
The amounts of each output are decided by the miner creating the coinbase transaction. They can choose to set the amounts as they wish. The only rule is that the sum of all of the output amounts cannot be larger than the reward (subsidy + fees) for that block.

While each block ostensibly has one miner, miners will typically team up in mining pools. This is effectively multiple miners mining one block. In reality, it is a single miner in that pool who gets lucky and finds the valid block, but the pool as a whole shares the block reward.
Some pools will pay out all of their miners with the coinbase transaction by creating multiple outputs that pay each miner in the pool. The amounts are determined by whatever the pool operator and miners have agreed for the distribution of the block reward.


Is it possible to forward signed transaction using bitcoind prune mode? Summary:
Is it possible to perform createrawtranscation , signrawtransaction and sendrawtransaction rpc call using bitcoin in prune mode?
Detail :
I want to implement an API that performs p2p BTC transfer, and for this purpose, I don't want to run a full node in my AWS server as I have to buy extra space for this. I was exploring third-party applications but all of them are out of my budget. So I was curious if I could run prune mode BTC core to perform above mention RPC call?
I would be very thankful if you guys can give some advice as per my requirement.

Is it possible to perform createrawtranscation , signrawtransaction and sendrawtransaction rpc call using bitcoin in prune mode?

Yes
I did the transactions in below link using pruned node:
https://bitcoin.stackexchange.com/a/99679/103136
rescanblockchain might be required if you are using any imported addresses in the transactions and it will work only for blocks saved on disk
I had to use rescanblockchain in this example: https://bitcoin.stackexchange.com/a/99112/103136


What legal items should I know about if I am piggy-backing off of another bitcoin exchange? I am thinking of starting a crypto exchange in the US, and I am piggybacking off of AlphaPoint's exchange for liquidity's sake.

What legal documents should I be aware of if I am piggy-backing? FinCEN comes to mind, and I may have to reject customers from NY :(

Thanks for the help in advance, I just want to get a scope on the extreme regulation before I start

If you're worried about regulation, you should be contacting a lawyer to help you remain compliant.


How can a website detect when bitcoins have been deposited? If I want to have a website that can credit bitcoins to a user's account when they deposit bitcoins, how can I have the website automatically detect when the bitcoins have been received into to the wallet address given to that customer (belonging to me), and consequently update the website to reflect their new balance automatically - without having to manually check my wallet.

I'm not interested in using existing payment services for this, but rather I'm interested in the coding principles required.

If you're going to be running bitcoind, what you're looking for is the walletnotify configuration setting in bitcoin.conf.

If you enable walletnotify, you run an app like curl to post the data to a web page.  The data that you'll receive is the transaction id of an incoming transaction for an address in your wallet.  From that you can use bitcoind's json-rpc commands to get the address that received the transaction as well as other transaction details like the amount.

Walletnotify will execute twice.  It will execute the first time that a transaction appears, and then will get called again when a block is published that includes the transaction. You can use either or both of these notifications depending on your needs.

This is the curl command that I use in walletnofify.  You should make any changes for your own environment.

curl -X POST -H "Content-Type:application/json" -d '{"transactionId":"%s"}' http://127.0.0.1:81/api/v1/transactions


addrindex patch bitcoin core. it does not show unconfirmed tx I'd like to ask about addrindex patched bitcoin core by btcdrak. The diff between bitcoin core and the patch is the following.

https://github.com/bitcoin/bitcoin/compare/0.13...btcdrak:addrindex-0.13

My question is that searchrawtransactions RPC command does not retrieve my unconfirmed tx even though addrindex=1 is set and bitcoin-cli getrawmempool retrieve the tx.

The unconfirmed tx is retrieved by getrawmempool.

$ bitcoin-cli getrawmempool | grep 90e225e60dc36f3d323ffcf6897858e056681b8a9e015ee4371558c7b1f0241f
  "90e225e60dc36f3d323ffcf6897858e056681b8a9e015ee4371558c7b1f0241f",

$ bitcoin-cli getrawtransaction 90e225e60dc36f3d323ffcf6897858e056681b8a9e015ee4371558c7b1f0241f
 0100000001671739d93c88b190d7950ce0b63257bdd7e66a10c5c1e969402f7bd703b1e229010000006b483045022100e1c3bc36da8b6aecc80a0b5fd141dfb412292542d169183fdf5f2188a1079d8b022012f9ac6bec276a828bd8e2d1fa06be081aa60ceb1e8d942320970caeea0501a7012103340a2fe93a07103bc02f921614da30c01fccc829048f035ada9c6401d25d2235ffffffff0336150000000000001976a9144ae3ca1c9dfdcd199569aa9c58342cf760df743988ac00000000000000001e6a1c992d4d030f24781e242e04f8766691a18e781debac05baa08fcceb01ae532800000000001976a9141485d9d03b41aaa9dca7d70d7f63ff4a0826100e88ac00000000

However, searchrawtransactions does not retrieve the tx.

$curl --user 'xxx:xxx' --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"searchrawtransactions","params":["12sWrxRY7E7Nhmuyjbz4TtGE9jRewGqEZD", 1, 0, 100000]}' -H 'content-type:text/plain;' http://127.0.0.1:xxxx | grep 90e225e60dc36f3d323ffcf6897858e056681b8a9e015ee4371558c7b1f0241f

Have you ever seen this issue? I tried it on addrindex version 0.12.1 and 0.13.2.

I'm sure that unconfirmed txes are showed normally before. The recent high mempool size might be the cause.

I already posted this issue on github but I did not get answer for now. I need to fix it as soon as possible. So I posted this question here too. https://github.com/btcdrak/bitcoin/issues/20

I am not a dev, so I can't tell for sure, but it appears addresses are indexed as they enter the blockchain.

  I'm sure that unconfirmed txes are showed normally before.

How do you know? I mean, maybe you used this on a server where the state was different, and compared against a server which hadn't received the block by that time?

EDIT: see this https://www.bountysource.com/issues/6995691-jmcorgan-address-index-not-updated-immediately-upon-tx-broadcast


How can the wallet identify public addresses are linked to a private address As the wallet can generate many public addresses from a private address. How does the wallet know that any transaction from or to the wallet is for that private wallet if the in and out can be any number of public addresses.

While exact implementations between wallets might differ, the general approach is usually similar to the following:

A wallet generates a private key (or a set of keys) based on an HD wallet, or just individual random keys
The public keys for private keys generated in 1. are calculated, and used to create the desired address scripts (p2pkh, p2sh (wrapped segwit/multisig), p2wpkh, p2wsh).
The wallet stores the private key, along with a mapping to which address script uses that key.
The wallet constantly scans the mempool and new blocks for outputs that send Bitcoin to the address scripts calculated in 2. When it discovers such an output, it adds the coins to the wallet balance and informs the user.

There are implementation specific variations on this (for example, an HD wallet may not store individual private keys, and store a mapping of the derivation path from the root key and the address script instead).

For an actual example, let's say our wallet has the private key for the address 1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX. The HASH160 for the public key of this address is 99bc78ba577a95a11f1a344d4d2ae55f2f857b98, and the locking script is 76a91499bc78ba577a95a11f1a344d4d2ae55f2f857b9888ac. This locking script is what appears in the actual bitcoin transaction that sends coins to this address.

The wallet will store the private key, and make a note that the private key corresponds to that locking script. It will then scan the bitcoin blockchain for transactions which have an output that matches that locking script.


Why do transactions with lower input age require higher fees? I am trying to understand how bitcoin fees work. I have understood well why transaction with many inputs require higher fees but I can't figure out why transaction spending virgin bitcoins would require important fees as well.

The logic behind my thinking is the following:
If my inputs are a recent coinbase transaction, it is easier for the nodes to check their validity as they don't have to crawl the whole blockchain up. So it should require less time/processing power to validate them, which would mean lower fees.

Apparently there is something wrong in here :)

Does anybody have a better explanation?

There is no time difference to check old or new outputs, because the database of them (UTXO) is a HashTable. The reason to take obligatory fees from new funds is preventing useless transfers from one account to another wasting the blockchain and increasing its size without reasons.


Problem with value after OP_HASH160 I am trying to implement JavaScript interpreter for Bitcoin scripts, but I have problem with counting value of OP_HASH160. I found that

Hash160(x) = RIPEMD160(SHA256(x))

However, when I try to count it this way using CryptoJS library, I get different value than on page http://paulkernfeld.com/bse/.

CryptoJS.RIPEMD160(CryptoJS.SHA256("02c34538fc933799d972f55752d318c0328ca2bacccd5c7482119ea9da2df70a2f")).toString() = "e81794c3da1564a196665dd0f74483185f524fe2"

where "02c34538fc933799d972f55752d318c0328ca2bacccd5c7482119ea9da2df70a2f" is the first element on the top of the stack.

Could somebody explain how exactly operation OP_HASH160 works?

Thx! :)

If the output of SHA256 is hex, you must convert hex to bytes before passing that to RIPEMD160.

See http://procbits.com/2013/08/27/generating-a-bitcoin-address-with-javascript

 var hash160 = Crypto.RIPEMD160(Crypto.util.hexToBytes(Crypto.SHA256(publicKeyBytes)))


How to prevent specific method calls to bitcoin node I have setup a bitcoin node and can access RPC methods via curl or bitcoin-cli.

Now I don't want to share the node with multiple parties and in such case, I want to restict some functions from being executed, like listwallets, getbalance etc.

How can I restrict some method calls?

In Ethereum we have different rpcapi and we can remove personal if we don't want others to play around with it unsafely.

My first guess will be to wrap the wallet functionalities in an application server and allow users to access the blockchain node via that application server and hence we can put any restrictions we want. Is there any better solution?

Bitcoin-core has no built-in mechanisms for restricting access to the API.

For your goals, you need to use a proxy between the user and the node.

For example, https://github.com/rsksmart/rskj/wiki/Nginx-Proxy-Server-for-JSONRPC-Calls


Framework for designing Blockchain (in combination with secure multi-party computation) I'm looking for a framework where I can build my own blockchain. In my case I wan't to combine the blockchain with secure multi-party computation algorithm.
Means that two or more parties want to exchange data without revealing the input data...

are there any good framework you can recommend? (Free or academic access etc.)
I found Openchain and Nstratis... maybe there are better ones?

Thanks in advance.

You may find hyperledger fabric useful for your purposes : Hyperledger Fabric


How do "trustless third-party watchers" work in Lightning Network? The main point with LN is the need to monitor the blockchain. The reason for this is to detect if the counterparty misbehaves by publishing an old channel state to the blockchain. For a node running on a server, that is not a big problem since it is always online, but mobile nodes might go offline for days, so how do we deal with this issue?

The need to monitor the blockchain actually only exists if the channel is used in both directions: if you are only paying, any outdated commitment transaction will be more in your favor than the current one, so there is really nothing to do!

But in case of two-way payment channels, this seems to be resolved by "trustless third-party watchers". Since I can't find much literature on the internet about them, I was wondering, how do they work and how exactly are they trustless? For that matter, how do you actually trust that anybody is going to publish on your behalf, and why? Are there incentive mechanisms in place for this to be completely trustless?

I suppose that when you refer to "third-party watchers" you mean watchtowers. I do agree that 'trustless' is probably an ambiguous word in this context. At the time of writing, the only actual proposal with a protocol that I am aware of is PISA, by Andrew Miller et al. PISA allows users to select a custodian that will be incentivised in publishing. Users pay the custodian, and the custodian loses funds if it does not perform (i.e. if the counterparty node manages to publish an old state).

At the moment, seems like Roger Wattenhofer is working on it too. However, They have not proposed a protocol yet. Their idea is to incentivise through rewards when channels are 'saved', instead of through penalisation when a watchtower does not save on time.

Both sides have pros and cons.

The con of Miller's proposal is that one must choose the watchtower, having to trust in it. The counterparty might try to bribe the watchtower, so that they both earn more than the penalisation.
Wattenhofer's proposal does not have this problem, as anyone in the network can retrieve the reward, and thus everyone is the watchtower. The problem of this proposal is that there are incentives for people to attack other people and prevent them from publishing themselves.

This is a work in progress. As for a self-claimed trustless watchtower, there has been some discussion in the ligthing-dev mailing list here and here, but it is yet a work in progress.


What happened to Bitcoin Core v0.20.1? About 11 days ago, I updated to v0.20.1 of Bitcoin Core from their "official" website (https://bitcoin.org/en/download).
Ever since, it's been syncing every day but just keeps lagging behind. Now it had reached 11 days, so I went to the same website to check if there's a new version which fixes the bug (which I assume is present in this version).
I was shocked to see not a v0.20.2, but rather: bitcoin-0.20.0-win64-setup.exe
It's gone back to v0.20.0... I felt a cold sensation down my spine, fanatically checking the GitHub issues for any clue that v0.20.1 was a "dud" or something, but found not one mention of it.
Now I'm starting to wonder if what I got was actually malware or something. Why would they just revert to an old version and pretend as if the v0.20.1 one never happened? It makes me feel uneasy to say the least. I installed the old version now, but so far, it still says the same thing:

Processing blocks on disk... 11 days behind...

This kind of thing is what makes me very worried about Bitcoin's future. With all the scams and scumbags everywhere, constantly trying to steal Bitcoins and/or give Bitcoin a bad name, the last thing we need is for the "official" project/client to be this flimsy and unstable. If I, a Bitcoin fanatic, gets this worried, what would an old granny be? She probably would never recover from this state, perpetually unable to make Bitcoin payments because Bitcoin Core has "locked" somehow.
I frankly don't know what to do now other than wait and hope for it to finish doing whatever it's doing. It seems locked/frozen again. I don't dare to click anything inside its GUI window because that tends to make it crash.
Update: At least it now, with the old version, slowly climbs down in the number of days left.

Are you sure you actually installed 0.20.1 before? It seems that the pull request to add the 0.20.1 release to bitcoin.org never got merged: https://github.com/bitcoin-dot-org/Bitcoin.org/pull/3435
If you look on the project's own site, https://bitcoincore.org, you'll see that 0.20.1 is available just fine.
I would be very surprised if anything at all changed regarding block chain synchronization in 0.20.1 vs 0.20.0. I suspect what happened is that your node initially just picked bad peers to synchronize from, but after (re)installing 0.20.0, that went away on its own.


What is "safe mode" and how does it affect RPC Commands? The source code here has a list of RPC commands and a "okSafeMode" parameter.

What is the purpose of this SafeMode and how does it affect the usage of the client?

When Bitcoin-Qt detects that something is seriously wrong with the network, it disables most RPC functionality in order to prevent automated Bitcoin sites from losing a lot of money due to network problems. (The okSafeMode functions are not disabled.) All versions since ~0.3 go into safe mode when the longest chain is invalid (illegal transaction, creating too much money, etc.). Upcoming versions will also go into safe mode when a large fork (valid or invalid) is in danger of overtaking the current chain.


Where are my coins after restart of blockchain and transactions (Multibit) One of my transactions didn't get confirmed. So I followed this: http://multibit.org/help_resetBlockchain.html

But now my coins are gone :-S where can I find them?

The transactions for your coins are stored on the blockchain.
What MultiBit has is the private keys that control whether you can spend them.

When you do a reset blockchain MultiBit resyncs to what is on the blockchain and shows you the transactions it finds.

You can always export you private keys and pull them into blockchain.info if you want - there is a help topic specifically for this.


What is a correct extranonce2 value in the stratum protocol? I'm developing a stratum mining client. I read on stratum v1 docs on braiins.com how mining work is done on the stratum protocol and that the coinbase is done by concatenating coinb1+extranonce1+extranonce2+coinb2. At the end, mining work is submitted by sending this JSON: {"params": ["<worker>", "<job_id>", "<extranonce2>", "<ntime>", "<nonce>"], "id": 4, "method": "mining.submit"}.
It says that the extranonce2 value is generated by the miner but must be based on the extranonce2 size provided by the pool. The extranonce2_size im getting from the pool is: 4 (4 bytes). So an extranonce2 value of 00000001(in hex) can be valid.
However, when i'm trying to submit a random miner work to the pool(just testing) by throwing in random nonce and extraonce2(but of course using the current jobId and ntime provided by the response i got from the pool) i keep getting this error response: 20,incorrect size of extranonce2.
The random extranonce2 i'm sending is '00000002' and random nonce is 'b2957c02'. Shouldn't i get a rejected share and not an incorrect extranonce2 size? I'm still new to this and don't yet understand exactly how everything works so where's my mistake here? or is it a pool problem? I know there's a lot of stuff to do before sending the miner work but here i'm trying to send a random miner work here.
btw is the request id always 4 in stratum for submitting work(or id: 'mining.submit')?
I'm authorizing the miner before submitting.

Turns out that there was a bug in my code and not the invalid extranonce2 value!


Number of main chain in a blockchain network I just have a very basic doubt. Suppose there's a public blockchain network like Bitcoin comprising several nodes. Would it be possible that this network consists of multiple mainchains??I am not talking about the situation where orphan nodes are created. My situation is say, there are 4 txns T1,T2,T3,T4. Now for each of these transactions, would there be 4 separate main chain for each transaction or one single mainblockchain which comprises these transactions in same/diff blocks that might have got generated after from the beginning of the genesis block.

The purpose of the blockchain is to reach consensus on the state of the network. Everybody has to be in agreement which money belongs to whom in order for the network to be useful. All four transactions would be collected in the same chain.


Are all 'metal wallets' functionally equivalent? Within the context of wallets, is it correct that a metal bitcoin wallet needs to store both public and private keys?
I'm looking at some metal wallets and want to clarify that the're all basically the same in that they'll give you different bits and bobs which are then must be physically arranged?
Or, are some metal wallets etched or otherwise "written" and then sent to the user?  Because that seems a very trusting act, to provide a private key to some third party.
Just dealing with bitcoin.  Perhaps naively thinking of storing public/private key "written" down with metal.
I would think something like:

minting physical bitcoins

would the point of such a wallet.  Obviously not minted, but just storing the public/private key on metal for reference.

Just to be clear/nitpick, the products you've linked to are designed to act as highly resilient physical backups for a bitcoin wallet. It doesn't really make much sense to refer to these metal plates/etc as 'metal wallets', as they cannot perform any normal wallet functions (send, receive, etc). Rather, they are just a way to store a backup for the seed that will (re)create your wallet using the appropriate software.

Within the context of wallets, is it correct that a metal bitcoin wallet needs to store both public and private keys?

Not explicitly. These days when you create a new wallet you will likely be presented with a mnemonic seed phrase, in the form of 12/24/etc words. These words are the backup for your wallet, if you input them into some wallet software (and follow the correct derivation path) then you will get access to your wallet.
So these metal backup plates are built to have your seed phrase engraved into them in some way or another. By using metal, you can protect your backup against things like fire or water damage.
Note that you could engrave a private key itself into metal, but given the chance of transcription error, you can perhaps see the reason that mnemonic seed phrases are very popular: they are human-readable and thus easier to error-check. A mistake could be extremely costly! You don't want to lose access to your bitcoin.

I'm looking at some metal wallets and want to clarify that the're all basically the same in that they'll give you different bits and bobs which are then must be physically arranged?

The function of them is the same: keep your mnemonic seed phrase safe. So if you use one, you should choose a design that you find to be:

durable
easy to set up
easy to understand
secure against accidental scrambling (what happens if you accidentally drop it? etc)
easy to store securely

Maybe there are some other considerations, but those are the obvious things that come to mind at least.

One consideration that is less obvious: purchasing a product like that can be really bad for your operational security / privacy. The company you purchase from will likely have a database of all past customer information. As example: not long ago, there was news that a major hardware wallet manufacturer' customer database was hacked, and customer information was stolen (note that no BTC was compromised). Since then there have been reports of phishing attacks targeting those people, since they are obviously bitcoin users.
With that in mind, consider the option of instead just purchasing:

an alphabetical metal punch set
a hammer
a stack of wide flange washers
a nut/bolt of appropriate size to fit the washers

You can then stamp each word onto a washer. Be sure to number them as well, so that you can ensure they don't get scrambled out of order (this would be very bad!). If you want, you can just stamp the first 3-4 letters of each word, since no two words in the BIP39 list have the same first 3 letters.
This is a very simple, secure, and private way of backing up your wallet, which will probably be cheaper than any of the products listed on that site, especially after considering the price of shipping.
This is what a metal punch set looks like, for reference:

Or, are some metal wallets etched or otherwise "written" and then sent to the user? Because that seems a very trusting act, to provide a private key to some third party.

NO. You should absolutely not ever use a pre-engraved product, creating private keys is something that the user should not be trusting a third party to do. You leave yourself at risk of theft from the third party, any one of their contractors, postal workers, customs agents, etc.

I would think something like: 'minting physical bitcoins' would the point of such a wallet. Obviously not minted, but just storing the public/private key on metal for reference.

The Casascius coins you linked were created as collectibles, more than secure offline storage, but in principle the function is similar. Note that those coins contain the info for private keys, that were generated by the coin's creator, so he is a trusted third party in this case (in spite of the warnings above).
You may also be interested in a product called the OpenDime (disclaimer: I have nothing to do with OpenDime, and have never used one, but they look cool), it allows for physical transfer of bitcoin without requiring trust that your counterparty will not keep a copy of the private keys. Note however, that the Opendime is NOT recommended for longterm physical storage, so while it is physical, it is functionally different than the backup methods described above.