(dis)Advantages of migrating funds to segwit? For offline pre-segwit wallets (addresses starting with 1) what might be the advantages of migrating or not migrating to segwit (addresses starting with 3)?

Even though segwit miner fees are or will be allegedly lower I didn't find any conclusive data on exactly how much lower they are at the moment, therefore I am assuming that keeping coins in 'legacy' format would still be cheaper in terms of future spending since the miner fee for moving to a segwit address would still be significantly higher than any future potential gains. Is this correct? Would this still be true if the coins are going to be spent e.g. in one year, two, or five?

Among current downsides to migrating to segwit wallets I see incomplete support in existing apps, also eg Mycelium won't work with a ledger nano if it is configured as segwit. This subreddit suggests to go with segwit.

Can segwit be considered ready for use?

I am assuming that keeping coins in 'legacy' format would still be cheaper in terms of future spending since the miner fee for moving to a segwit address would still be significantly higher than any future potential gains. Is this correct?

You still need to move the coins eventually, and the potential gains will be nullified by the fact that you still have to pay BTC in order to move the coins. The amount you pay will probably still be the same amount whether you move the coins now or move them later.

You can also just be very cheap on your transaction fees. Just pay a very low fee rate. Your transaction will take a long time to confirm, but if it's just for cold storage, there's nothing to worry about there.

  Among current downsides to migrating to segwit wallets I see incomplete support in existing apps, eg Mycelium won't work with a ledger nano/trezor if it is configured as segwit.

If you aren't planning on spending your Bitcoin, then that doesn't matter. Just use software that supports segwit. If you want to be compatible with non-segwit wallets, use a P2SH nested segwit address.

  Can segwit be considered ready for use?

Yes.


How to generate a valid bitcoin address for destroying bitcoins? (Following up to this question.)

In order to put a bitcoin beyond use, the answer was to select a made up address. As this isn't a formal destruction of bitcoins, there's a risk that the private keys could be found to spend those "destroyed" bitcoins.

If someone suggests an address, people might suspect that this address was selected because that person painstakingly looked for an address that looked like a made up address.

How can an address for bitcoin destruction be selected that everyone can be reasonably sure no-one's going to know the private keys to spend the destroyed bitcoins?

Start with an invalid public key

Bitcoin addresses are the pubkeyhash (not pubkey) plus version and checksum information, encoded in base 58.

Bitcoin address = version + RIPEMD-160(SHA-256( Public Key )) + checksum

The steps for converting a public key to an address can be found here:
https://en.bitcoin.it/wiki/Address

Since the address uses the pubkeyhash not the actual pubkey we can exploit this by hashing an invalid pubkey (one which can't possibly exist) and thus produce a valid address from an invalid pubkey.

So to start we find an invalid public key.  All valid public keys begin with 0x04 if uncompressed and 0x02 or 0x03 if compressed.  A pubkey beginning with any other value is undefined and thus there is no possible signature that can be created to satisfy that key requirement.  Since spending coins requires signing the transaction with the correct private key, an address which has no known private key is unspendable.  By using a public key which is known to not have a private key others can confirm that no private key exists.

A valid Bitcoin public key (not address):

  04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f

An invalid public key

  0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

There are other ways to produce a known invalid public key.  ECDSA keys must be exactly 65 bytes if uncompressed or 33 bytes if compressed so a key with a different length will also be invalid.  For uncompressed keys the y value must be correctly produced from the x value.  The point must also lie on the curve.  It also can't be above the modulus for the curve.  So there are a lot of ways to produce provably invalid keys but it best to choose one which is obviously invalid.  This is probably the simplest obviously invalid public key.

  0x00

This public key is invalid for a number of reasons (not produced by private key multiplied by the generator, not located on the curve, not a valid point, but even simpler it doesn't have a valid prefix and is not the correct length).

The important thing is this isn't just some probably invalid key it is a provably invalid key.

You should test your invalid public key against the reference client to ensure the client reports it as invalid as well.  The validity of keys is a consensus issue so this will not change short of a hard fork.

Produce a valid (but unspendable) address from your invalid public key

You may wonder why we want the address to be valid.  All clients should validate addresses given by users to avoid accidental loss of funds.  So an invalid address is also unspendable but most users will find it impossible to send funds to the address.  A P2PkH address is the pubkeyhash with version and checksum information encoded in base58.

When you provide an address to a Bitcoin client it decodes the address back down to the 'raw' pubkeyhash.  So producing a valid address means starting with a valid pubkeyhash.  This isn't a problem because the hash of anything is a valid hash.  Clients don't know what pubkey is hashed to produce the pubkeyhash as the underlying pubkey is not provided and hashing functions are one way.

The Bitcoin network only verifies that an address is in the right form, length, and has the right checksum when "validating it".  Producing an address from a pubkey is beyond the scope of this question but there are utilities and the link above provides the steps.  The resulting pubkeyhash and encoded address will be seen as valid by the network and client but it requires a provably impossible private key to spend funds sent to that address.

Now with just the address (and decoded pubkeyhash) a user can't verify that the underlying pubkey is invalid so you should publish the raw pubkey along with the address.  Users can recreate the address using any bitcoin client or tool and will produce the same address you provide.  Users now have a trustless way to verify that the coins indeed are unspendable.  Any coins sent to the address can never be spent and are effectively destroyed.

Hash collision

Technically it is possible but improbable for more than one public key to have the same Bitcoin address. This is called a hash collision.  If public key p1 and public key p2 both hash to the same address A then privates keys for either of these public keys can spend the funds.  However the likely of this happening is very low.  Unless RIPEMD hash algorithm is broken the probability of finding two public keys which generate the same hash (Bitcoin address) is 1 in 2^160 which is far beyond our computational power to locate.

A few words on why you should use a 'Nothing Up My Sleeve' number:

Using a "nothing up my sleeve number" (such as a single zero, all zeroes, single repeating digit, sequential numbers, digits of pi, etc) is not required as any invalid public key is equally unspendable but it would improve public confidence that you haven't already found a collision (as improbable as that is).

If you just take a random invalid key like say:

  00000fdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f

Some may question why you chose this specific key. The fear would be that you choose this key not randomly but because you have stumbled upon a collision between this key and a valid key.  There is no way to prove the key is random thus the fear will always remain.  Cryptographic functions (like RIPEMD or SHA-256) often use "nothing up my sleeve values" to provide security that a constant was not chosen to enable some cryptographic flaw or "backdoor" in the algorithm.  For example SHA-256 uses constants for the initial values of the block segments.  Technically these could be any random number but that would lead to concern that the 'random' number isn't actually random.  So SHA-256 uses first 32 bits of the fraction portion of the cube root of the first 8 prime numbers.  This allows verification when a pseudo random number is needed.  It is very unlikely there is some magical property between the fractional portion of the cube root of sequential prime numbers that undermines SHA-256.

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

Update (03/31/2015)

It is easier to do this now by using an OP_RETURN (null data) output and it doesn't bloat the UTXO with outputs that can't be spent but the network is unaware they can't be spent.  Any funds sent to an output which contains OP_RETURN are provably unspendable and the network will drop the output from the UTXO.  The UTXO (unspent tx output set) is a critical resources which is necessary for validating new transactions and blocks so destroying/burning coins using UTXO is a more responsible use of this shared resource.


How to create bidirectional channels using LND? I created a channel with following command.  But its not bidirectional by default.

lncli openchannel --node_key=02cdf83ef8e45908b1092125d25c68dcec7751ca8d39f557775cd842e5bc127469 --local_amt=390000

How can I make this channel bidirectional. And how can I create bidirectional channels?

Thank you so much for help and guidance.

It is bidirectional by default. In fact LND does not even allow for single-directional channels.

What you're experiencing though, is the drawback of having created a single-funded channel. That means, that all of the funds in your newly created channel are sitting on your side, which means that for now, you can only send money but not receive any money. Or in other words, you don't have any inbound capacity on that very channel. As soon as you do have both inbound and outbound capacity, you will be able to both send and receive money over that channel.

Note: For now the Lightning implementations do not allow for mutually funded channels, but this feature is in the works and soon to come.

So.. what are your possibilities now to circumvent this problem and get inbound capacity? Here are some options:

Wait until other nodes open channels to your node
Push money to the other side of the channel by buying something
Send money over Lightning to zigzag.io and receive it back on-chain.

Once you have inbound capacity and you are routing payments, your channels will get rebalanced in the process and you will hopefully get inbound capacity on all of your channels over time.


Question about Changing Passphrase In Bitcoin Core, the previous password is required in order to change to a newer password. Is this previous password used simply as a proof-of-ownership key (that doesn’t do anything but show proper access), or does it have any part in changing the password through a method of decryption or something along those lines?

It is not a superficial gate-keeping password. The password on your wallet is an encryption passphrase.
Related answer with more details: https://bitcoin.stackexchange.com/a/89278/26873


Can we drive the bitcoin transaction fee arbitrarily close to zero by keep increasing the block size limit? Can the bitcoin scalability problem be solved in the long run by increasing the block size limit (either dynamically or statically)?

No. The fees are the incentive for the miners to continue their work, verifying transactions and including them in blocks. Mining is expensive. Eventually, the block reward will reduce to zero and the fees will be the only payment that the miners will receive.

Whatever may change with Bitcoin in the future, the fees must be able to float to the market and that must be protected, although, I do disagree that the current auction model for limited bandwidth is the optimum model for Bitcoin to be using as it is nowhere near scalable.


Access funds on legacy address related to segwit address from which I have private key The situation

Hello. Our company running BTC pool. We've been mining BTC for a while and used segwit address 32Z3eXSPgxcHj2fnQy8d6dg66eVtZfxrBM as pool adress.

But when we finally found a first block (actually - two blocks) for some reason block reward got sent to different address:1s2iywx94HudryMHsU2g1K9x8DB1cahGc

Here are links for both generation transactions with rewards: the first and
 the second

The problem

We cannot get access to funds on 1s2iywx94HudryMHsU2g1K9x8DB1cahGc - we simple can't see that balance on the wallet.

The question

How can we access those funds on 1s2iywx94HudryMHsU2g1K9x8DB1cahGc?

More info

Using Bitcoin Core client command validateaddress we can inspect both addresses:

Output for 32Z3eXSPgxcHj2fnQy8d6dg66eVtZfxrBM is

{
  "isvalid": true,
  "address": "32Z3eXSPgxcHj2fnQy8d6dg66eVtZfxrBM",
  "scriptPubKey": "a91409763cb05dcea0f98f53b0f08651f92c5d2d2f3887",
  "ismine": true,
  "iswatchonly": false,
  "isscript": true,
  "iswitness": false,
  "script": "witness_v0_keyhash",
  "hex": "00142ee67d879ccf17daec87b4ed4a6cecdd9b3f64a0",
  "pubkey": "02835613e6e22843ce7dafc5d22a2763a8428b81f3d44dced0fd860f08be7a29df",
  "embedded": {
    "isscript": false,
    "iswitness": true,
    "witness_version": 0,
    "witness_program": "2ee67d879ccf17daec87b4ed4a6cecdd9b3f64a0",
    "pubkey": "02835613e6e22843ce7dafc5d22a2763a8428b81f3d44dced0fd860f08be7a29df",
    "address": "bc1q9mn8mpuueuta4my8knk55m8vmkdn7e9qmezkgv",
    "scriptPubKey": "00142ee67d879ccf17daec87b4ed4a6cecdd9b3f64a0"
  },
  "addresses": [
    "bc1q9mn8mpuueuta4my8knk55m8vmkdn7e9qmezkgv"
  ],
  "account": "",
  "timestamp": 1533473707,
  "hdkeypath": "m/0'/0'/0'",
  "hdmasterkeyid": "35e9670da1b28efe5621eb9cee2cf3e88b929968"
}

Output for 1s2iywx94HudryMHsU2g1K9x8DB1cahGc is

{
"isvalid": true,
"address": "1s2iywx94HudryMHsU2g1K9x8DB1cahGc",
"scriptPubKey": "76a91409763cb05dcea0f98f53b0f08651f92c5d2d2f3888ac",
"ismine": false,
"iswatchonly": false,
"isscript": false,
"iswitness": false
}

I can see three interesting points here:

scriptPubKey for both addresses contains 09763cb05dcea0f98f53b0f08651f92c5d2d2f38 part, which is, afaik, actuall public key. First byte differs, which makes sense, since it's prefix, 00 for legacy and 05 for segwit respectively.

regarding output for 1s2iywx94HudryMHsU2g1K9x8DB1cahGc :

pubkey property is missing, which is weird, because usually its included for legacy addresses
isMine property equals false, wich means that wallet does not recognize this address relation to wallet PK.

So, can anyone please provide some insight and tell us if (and how?) we can access those funds, or we've lost them for good?

P.S.

When I use base58 decode on both 32Z3eXSPgxcHj2fnQy8d6dg66eVtZfxrBM and 1s2iywx94HudryMHsU2g1K9x8DB1cahGc I get

0509763CB05DCEA0F98F53B0F08651F92C5D2D2F385CCEC0F4 and

0009763CB05DCEA0F98F53B0F08651F92C5D2D2F3861372301 respectively.

Again, you can clearly see same bytes, so addresses are definitely related.

I'm afraid you have a bug in your mining software, and your coins are gone.

Instead of sending to the P2SH address, a block was created with a P2PKH output script, reinterpreting the script hash from the P2SH address as a public key hash. This happens somewhere in broken software that doesn't support P2SH and additionally also fails to check the address version byte.

If this is the case, it is unrecoverable and those coins are lost forever. You can't find a public key whose hash matches that script.


How can I download the blockchain from own, trusted source? I have two computers with two different bitcoin-qt wallets:

Very heavy-weight desktop with a great internet connection.
Less powerful laptop with relatively slow internet.

I would like to download AND validate the blockchain only on the desktop. I can trust that blockchain to contain only valid data because it actually validates the input and it is a source under my control. So I figure I don't need to do the same for the laptop. How can I syncronize the blockchain on the laptop? Could I rsync the chainstate, blocks, and database directories for instance? And then I rescan on my laptop and we should be good to go! Would this work?

If you copy the blocks/ and chainstate/ directory, you're good to go. Rescanning the wallet will happen automatically. The database/ directory only contains temporary data.

You should make sure to shut down the node on your desktop before copying though, or the copy may be inconsistent.


How are sigops calculated? How are sigops calculated on a transaction? For example in the (randomly selected) following transaction:

https://btc.com/bc9384919ad5d08b2c66e31f29e7c63572c398a87631c03a4ce9e94ff1cbe62f

It says there were 5 sigops. What is the rule for calculating this number?

Each OP_CHECKSIG and OP_CHECKSIGVERIFY is counted as 1 sigop.

Each OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY, is counted as 20 sigops if they are found in an output or scriptSig and not part of a redeemScript, i.e. not P2SH.

If OP_CHECKMULTISIG or OP_CHECKMULTISIGVERIFY are in a redeemScript (i.e. it's P2SH), then the number of sigops is the number of public keys in the multisig redeemScript.

For non-segwit inputs, these numbers are multiplied by 4, so 4 sigops for OP_CHECKSIG and OP_CHECKSIGVERIFY, and 80 sigops forOP_CHECKMULTISIGand OP_CHECKMULTISIGVERIFY.

However segwit inputs don't use these scripts explicitly. So a segwit input where the witness program is version 0 and the program is 20 bytes (i.e. P2WPKH), the number of sigops is 1. If the witness program is version 0 and the program is 32 bytes (i.e. P2WSH), the witnessScript is interpreted and its sigop count is as above as that uses the opcodes explicitly.

So in your example transaction, the input spends a P2SH-P2WPKH and the output has an OP_CHECKSIG. Since the input is P2WPKH, it is counted as 1 sigop. The output as an OP_CHECKSIG, so that's another 1 sigop. However because that output is not a segwit output, its number of sigops is multiplied by 4. Thus the output is actually 4 sigops. Summing those is 1 + 4 = 5 sigops in the entire transaction.


What are the categories of a transaction, and what do they mean? I've only seen "receive", "send", and "immature". Are there other categories that I'm missing? And what do they mean? It seems that "receive" means a transaction that gave our account coins, and "send" means we gave someone else coins.

What you are seeing is not an inherent property of a transaction but how the transaction looks to you at the current time and how your Bitcoin client wants to display it.

A transaction contains inputs and outputs; if the transaction is considered a "send" or "receive" (or "transfer") depends on which of the input and output addresses are in your wallet and considered to be owned by yourself.

An "unconfirmed" transaction is one which is recent enough to not be considered a canonical part of the block chain.  Once enough blocks have been added to the block chain after the one in which your transaction is recorded it will be considered confirmed.  The number of blocks depends on your Bitcoin client.

An "immature" transaction is a generation transaction which is not old enough to be made available for spending.  Under the current specification a generation transaction must have at least 100 confirmations before it can be spent.


Is it possible to run out of nonce values? Miners can vary at least these things when searching for hashes:

A 32-bit nonce
Which transactions are included in the block.

Is it ever possible for a currency using the Bitcoin protocol to get 'stuck'? That is, can all combinations of parameters that miners are allowed to tweak not result in a hash that conforms to the difficulty?

One scenario using those parameters I listed could be an ASIC miner working on a brand new network. The difficulty should rise extremely quickly, but there would be very few transactions for him to work with.

Yes, it is possible to not find a valid block for all 2^32 possible nonces, and that is indeed the typical case. I believe only at the minimum difficulty level, sometimes still used as basis for finding shares in pooled mining, would you even average(!) one valid block out of all possible nonce values.

There is a timestamp field you can update, and there is an extra nonce that may not be so obvious because it goes into a hash calculation before being included, along nonce and timestamp, in the final double-SHA-256 hash.

Find more information here.


How to verify signed bitcoin messages on my own website? On my website, I want to be able to verify that messages are signed by a certain bitcoin address, similar to how it's done here. From my research it seems I have to use JSON RPC with some sort of verify_message(signature, message, addrtype) function?

Is this the only method for doing this? And if so, does this require me to install bitcoind or armory on my web server?

You don't need all of bitcoind just for this functionality. Look at the code on the brainwallet.org page you posted: http://brainwallet.org/js/bitcoinsig.js

It seems like you could take this exact code and implement it on the server-side with a JavaScript interpreter such as node.js.

It depends on the programming language you're using but I'm sure this functionality is available in most of the bitcoin libraries: https://en.bitcoin.it/wiki/Software#Libraries


SharedCoin vs JoinMarket, Pros and Cons of each Can someone please clearly specify the differences between SharedCoin and JoinMarket.

What are the advantages and disadvantages of each?

How is SharedCoin centralized while JoinMarket decentralized?

I'll do my best. SharedCoin is no longer around. It used to have a centralized server which collected inputs and outputs from users then merged them into one big coinjoin transaction. They allowed you to do multiple "rounds" where the outputs from one round would roll over into the next and be coinjoined again, and they charged a small fee. A few years ago it was demonstrated that this obfuscation could be solved using what was called "coinjoin sudoku" which allowed an observer to connect certain inputs to outputs with certainty, although the computational costs of doing so were very high. This was a significant weakness, not to mention that the SharedCoins servers knew a lot about the participants.

JoinMarket is open source software for people to make their own coinjoins. It is decentralized because it uses an IRC channel to announce orders and organize transactions amongst the participants themselves. It uses a system of makers and takers. Makers offer coins to be used in coinjoins and collect a small fee, takers specify the outgoing transaction size and pay a small fee. Unlike SharedCoin, each coinjoin transaction has a handful of identically sized outputs. If I'm a taker and I want to send 1.2345 bitcoins, my transaction will have a bunch of other outputs of exactly 1.2345 bitcoins going to the makers who participated in the transaction. As far as I know, an outside observer examining this coinjoin transaction alone would have no way of connecting the 1.2345 outputs to any of the participants or input addresses.

SharedCoin's advantages would have been simplicity and ease of use (you used to be able to do it straight out of a blockchain.info wallet), plus I believe it had many more users at its peak which increases the anonymity set. JoinMarket requires a decent bit of time and technical expertise to get set up properly, but its advantages are that it gives you stronger privacy, is decentralized, and allows you to earn a modest return on your idle coins. I'm a big fan of JoinMarket and I recommend you check it out, if you're already running a bitcoin node it's not too much more work to get JM set up.


how to track sendtoaddress / sendmany in case of network failure Suppose you call sendmany or sendtoaddress on bitcoind RPC.

Suppose the transaction is created and send to the network, but RPC time out and sender process unable to read the txid.

Suppose there are several send to same address with same btc amount.

How this can be tracked programically?

I know you can pass comment to each send but I am unsure how I can collect it programically.

In the event that bitcoind completes a transaction, but the RPC response is lost, the transaction details will still remain available. The wallet and transaction database is updated directly by bitcoind, and will be updated regardless of the RPC state.


Would it be possible to generate a memorized wallet address by using a batch of phone numbers? I was wondering if I was able to generate a bitcoin wallet by using a bunch of phone numbers i remember. I'm sure everyone can recall at least 5 or 10 phone numbers by memory. So in theory I can reference the wallet by just remembering the people thats associated with it. Say my wallet would consist of: john, sam, eva, jesse, and ben. but it would be referenced as phone numbers and in turn gets converted to a bitcoin wallet address.

You could use the phone numbers as a passphrase for a Brain Wallet.


Stable coins differences? (USDC - Coinbase / Circle, GUDS - Gemini, TUSD - Trust Token, PAX - PAXFUL, USDT - Tether) There has been a release of many stables coins recently. What are the differences from each? So far I know that Tether (usdt) is based out of the US banking system and everything else is in the US banking system and regulated. Also I read that the USDC and GUSD has a back door system to freeze and hold accounts if they wanted to. I wasn't sure if PAX had this same thing. What are all the listed pros/cons of each stable coin?

Indeed, USDC has a backdoor built in to allow for the freezing and/or seizure of funds if it is believed illicit activity is involved. In other words, any address can be blacklisted and funds frozen. Not very stable for a stable coin, right?


Is there any way to "revoke" a bitcoin address? Given e.g. one lost the private key to a specific bitcoin address, is there any way to make sure no more bitcoins can be transferred to it since it effectively became a bitcoin-furnace?

Unfortunately, there is no way to do any such thing. Your only option is to manually inform any business partners that the address has fallen out of use.

As the only way to proof indubitably that you were the owner of said address would be to sign a message with the respective private key, I don't see how anyone could justifiably shut down an address.


Should I trust bitaddress.org? AFAIK, the generation of the address pairs occurs on your computer but the concept still makes me nervous as it's occurring in the browser and I have to trust the owner of the site, I think.

You don't entirely have to trust the owner of the site. The site is client side Javascript based, which means you can probably save a copy of the code, then review it, and run it offline.

If you continue to use the website though, you're trusting the owner of the site to:

Not change the code in any way that compromises the security of the private key
Maintain adequate security so that no hacker can change the code in any way that compromises the security of the private key


Using bitcoin-qt in bitcoin-core: How to tie my wallet to my email address? I can send and receive money using listreceivedbyaddress.

How do I get my public address in Bitcoin Core?

However, I would like to connect this address to my email address.

Is this possible?
If this is possible, how to do this?

Normally, the software doesn't support such things. The wallet doesn't store any personal information.

However, there are web exchanges like coinbase, that lets you to use email address when sending cryptocurrency. But, it was only for clients under the same exchange.


Are there numbers on how many pre-orders (or total GH/s) ButterflyLabs already received? The whole Bitcoin world is waiting for ButterflyLabs' entree in the mining scene.

Their promised products are quite revolutionary and so they can cause great fluctuations in the BTC price when they finally arrive.

To know how the Bitcoin network would be affected, it would be very useful and interesting to have an idea on how much hashpower will enter for mining.

Calculations of the profits from their miners with the current difficulty are absurd (like a $ 1,299 miner being paid back in just 4 days) and make no sense.
When making estimates for your profit you need also to consider changes in the difficulty, which are predicted to be enormous when ButterflyLabs' hardware launches.

So, to come to my question, I know that Butterfly Labs is not the most transparent company and that they failed to keep most of their promises. But did they ever mentioned numbers or approximations of how many pre-orders they already received? Or how much hashpower they would account for?

I found this :

BFL SC Pre-Order Information

So. 6000 units ordered from june 2012 to june 2013. 100 were shipped, in june 2013. 5900 to go.


How transactions will take place once all the blocks have been mined I understand there can be maximum of 21M BTC. Also, new BTC are added into system as a reward of mining blocks. So is there any hardcap on the number of blocks that can be mined? Or there is no limit on blocks to be mined, instead, there would be no rewards for mining after 21M coins?

Let's say there is a cap on blocks, how the new transactions can be verified after 21M mined coins?

Or there is no limit on blocks to be mined, instead, there would be no rewards for mining after 21M coins?

This is correct, although the miners still get all the transaction fees as reward, there is just no block reward like there is now with 12.5 BTC


What is an «open Ponzi scheme»? I recently read that Nassim N. Taleb thinks that Bitcoin is an open Ponzi scheme. An influental and intelligent person like him surely doesn't say something without thinking about it first. Therefore I asked myself what he means with that term.
In my view the key ingredient of a Ponzi scheme is deception - deception of investors about the real source of their revenue. In order to keep this deception from becoming public knowledge, a Ponzi scheme must remain «closed» in that regard. An «open Ponzi scheme» would mean that there is no deception because «the secret» of the revenue is known to everyone. Isn't «openness» exactly the necessary ingredient which would legitimize even a Ponzi scheme by making it possible to investors to «add» fair value to it, which would most possibly be Zero?
Wouldn't any asset be an open Ponzi scheme by Nassim N. Talebs logic?
I mean every investor tries to make money by selling his investment to others for a higher price at some point.
I feel that following his Logic even gold, diamonds, company shares, etc.  are «open Ponzi schemes» - our whole economy would be an «open Ponzi scheme».
If my logic would be right, this term has no meaning and someone just added a total useless term to the vocabulary.
(I don't ask if Bitcoin is a Ponzi-Scheme - I'm interested in the logic behind the idea of «open ponzi sheme»)

It's commonplace that when there's an investment or monetary instrument someone doesn't like, they call it a "ponzi scheme".
For example, gold (ie gold bullion) is indeed often called a "ponzi scheme". Diamonds and gems certainly are.
Some folks think that conventional stock market shares in the current historical era .. ie "Apple shares" or "Ford shares" are a "ponzi scheme".
So, people buy APPL at a higher and higher price, there's no intrinsic value at all (they argue), and the one and only way to make money is to sell to the "greater fool."
Note that I do not know, do not care, and don't have an opinion either way on whether or not these things are indeed ponzi schemes.  The point is, it's completely commonplace to label things like gold, or even shares as "ponzi schemes".
You can find endless discussions where certian folks think government money ("fiat money!") is just a ponzi scheme.
(Just the other day someone commented that real estate in a certain city is "just a ponzi scheme"; ie they believe the prices are un-real and the only reason to buy is to sell to a "greater fool" - until someone is left holding the bag.)
So it's completely normal and commonplace to describe something as a "ponzi scheme"
Note that the term is now used very generally (to mean "a scam" or "something with no real value"). It is NOT used CAREFULLY in an exact sense of how "the original ponzi scheme" operated.
(If you object to "the exact meaning of words changing" - whatever, would have to go live on another planet. You can immediately list huge numbers of words in English that have no connection to their "older, precise" meaning.)
Regarding the talking head's appending the trendy word "open".
It's: an attempt to be clever and attract publicity, more TV appearances, and more book sales.
It would be wildly reading too much in to it, to try to tease out the exact "meaning" of adding "open".
Here are a few other clever! phrases in the same vein:

"it's a prime based ponzi!"

"ponzi mining!"

"a ponzi scheme that's listed on major indexes!"

and so on.

An influental and intelligent person like Nassim N. Taleb

Football players make money via: creating television programming which generates tv ad income.
Bakers make money via selling buns.
"Talking heads" like Taleb make money via: catchy soundbites which generate more interviews and book sales.
It's exactly like being a tiktok'er or youtuber and generating views with shlock.


How do hardware wallets integrate with software clients/nodes? It isn't clear to me how hardware wallets interact with software clients. Is there a standard defined for this? Is it similar to signing on an offline computer and then transmitting a signed message via a different online computer? Or (I hope not) do software authors have to write support for individual hardware wallets?

The tightest integration would be from the last option, but I'm wondering if there is a more manual approach similar to the "sign on the offline computer" workflow.

Sadly there is no standard yet.

But a wallet standards group is being formed and some meetings are planed (april 2017).

At the moment, each hardware wallet provider writes plugins for wallet-apps which is a strange development direction.
There are Trezor/Digitalbitbox/Ledger plugins for Electrum and Copay,... but the plugins are in the source code bundle of the corresponding wallet-app provider, leading to the problem, that the hardware wallet provide has no direct way of fixing bugs or even improving the plugin.

A standard would be the right direction.


How can I conveniently generate new addresses for my public key? I generated a private key using dice, then wrote a script to konvert that private key to its corresponding public key in its secp256k1 elliptic curve format (a 65-byte number beginning with 04).

Now, I read that there is a very large number of different addresses that one can generate from a single private key, so now I'd like to do exactly that: I would like to generate some random addresses, because I would like to use a different address for each transaction to my private key. Are thera already existing script that generate a certain number of addresses from a private/public key, or do any of you have instructions how I could write it myself?

Best regards

This is done using heirarchical deterministic (HD) wallets. Using an extended private key, you can generate an infinite number of children, grandchildren, etc. private and public keys. BIP 32 lays out exactly how this works.

A private key on its own cannot do this, you need an extended private key, which is a private key plus a chain code. So you will have to generate a chain code to go with your private key you've created, or use the private key you've created as a seed for a new extended private key as described in the Master Key Generation section of BIP 32. Once you've done this, you can use your private key and chain code to generate extended children keys, and use them to generate children of children (grandchildren) to your heart's content. Just remember to back up your master private key and chain code because if you lose that, you won't be able to regenerate the child keys.


Why is the length of the transport messages on the lightning network encrypted? From BOLT 08 we can see that every message is sent in the following way:

2 byte: length
16 byte: MAC
[length] byte: Encrypted message
16 byte: MAC

In reality these messages will be send over TCP/IP on the internet. The ip header specifies the length of the data package that is being sent. If we extract the length and subtract 34 byte for the header plus the two MACs we would know how long the message is.

Is the idea to always send a 2^16 byte ip package and fill the rest with junk data? If yes why isn't that specified in the BOLTs? If no: why encrypting the length anyway?

I assume that an attacker would be able track all tcp/ip packages on the lightning port and would at least be able to deduct which messages are being sent even though the messages themselves are safe.

Assume the message length can indeed be deduced can't that be used together with the MAC to reconstruct the session key for that message?

TCP and other stream based protocols do not have a 1-to-1 correlation of application level messages and IP packets. If you call send() 3 times, it might result in sending a single IP packet over the wire (eg, due to Nagle's algorithm which is enabled by default), it might get sent individually as 3 packets, as you would expect from a packet oriented protocol like UDP, or the messages might end up being split into several packets each because the IP layer has an MTU.

It is generally out of your control at the application layer. You therefore, cannot rely on reading the length from the IP header to tell you about the length of messages. You need to encode the lengths into the data stream and reconstruct the data coming in from the stream into the individual messages as understood by your protocol.

The reason to encode the length separately in the BOLT#8 specification is that each message must be decrypted as a single operation, because each decryption must increase the counter used in the ChaChaPoly cipher. You need to know the exact length of the message before calling the decrypt function on the encrypted payload.

In the BOLT#8 protocol, you send the exact lengths of the encrypted message+MAC, with no padding added. The receiver should first explicitly call recv(buffer, 18, ...), decrypt the result to get msg_len, then call recv(buffer, msg_len, ...) to retrieve the encrypted message, which can then be decrypted in full. recv may also return fewer bytes than requested, so in both cases, the result of recv must be checked and if less than the expected length is read, recv should be called again with the remaining expected length.


Help understanding the blockchain I am trying to better understand the fundamentals of the BLOCKCHAIN.
I am not technical and am hoping someone can offer up an explanation in LAY TERMS.

Thanks in advance.

There is a nice explanation on how it works in the bitcoin wiki, bitcoin.it :

A block chain is a transaction database shared by all nodes participating in a system based on the Bitcoin protocol. A full copy of a currency's block chain contains every transaction ever executed in the currency. With this information, one can find out how much value belonged to each address at any point in history.
Every block contains a hash of the previous block. This has the effect of creating a chain of blocks from the genesis block to the current block. Each block is guaranteed to come after the previous block chronologically because the previous block's hash would otherwise not be known. Each block is also computationally impractical to modify once it has been in the chain for a while because every block after it would also have to be regenerated. These properties are what make double-spending of bitcoins very difficult. The block chain is the main innovation of Bitcoin.
From https://en.bitcoin.it/wiki/Block_chain


What does "accepted shares" mean? I am running GUIMiner and Triplemining server. I currently have just under 100 "shares" accepted.

What does this mean? What are accepted shares used for? How do accepted shares relate to "blocks"? How does this relate to a Bitcoin?

An accepted share represents work that your miner did towards a round in a mining pool.

When the pool finds a block, it distributes the block reward (i.e. 25BTC) to the miners according to how many shares they have contributed during that round. The more shares you contributed, the more payback you get.

It is simply a way to keep score, and to attribute the reward proportionally to the amount of computing power that each miner contributed to the pool.

Edit: "accepted share" is one which is valid at the time the pool receives the work from the miner, but sometimes the work arrives too late and a new block has replaced the previous one. In these cases you will have some "invalid shares" which don't count towards the revenue share.


Download blocks in blk00000.dat format from a specific period For study purposes, I would like to download blocks from a specific period, i.e. January 2017 - June 2017, in blk.dat format (blk00000.dat, blk*.dat).
I downloaded blockchain.core but it makes me download the whole blockchain - correct me if I'm wrong.
Also I tried with blockchain.info but the problem is that I can only get one block at a time and just in Json or Hex format - don't need those.
So, do you know how could I do and with which program or API to use?
I'm a beginner, so please the more details you can give the better it is, even if they seems obvious.
For this work I'm coding in python.

Bitcoin Core is the only software that saves the blocks in the blk*.dat format. This format is not standardized and internal (i.e. not exposed to users). The contents of, for example, blk2342.dat can differ between multiple instances of Bitcoin Core.
The only option is to run Bitcoin Core yourself, or to find somebody who runs Bitcoin Core and can provide you with these files.


What is the benefit of forced signaling in a soft fork activation mechanism? What is the benefit of forced signaling in a soft fork activation mechanism? e.g. the MUST_SIGNAL phase in revised BIP 8.
I understand the benefits of setting lockinontimeout (LOT) to true (some of those benefits are described here) but why have a period of say two weeks when miners have to signal before the soft fork moves into the LOCKED_IN phase. Why not just define when that LOCKED_IN phase will begin (assuming miners fail to activate the soft fork before then) and ditch the MUST_SIGNAL phase?
Matt Corallo states "Forced signaling isn’t required for many flag day designs, and is the biggest single risk of any proposed feature for an uncontroversial activation."

It depends highly on who you ask. Indeed, I (and several others) have argued that there is no reason whatsoever for forced-signaling. Greg Maxwell wrote a long and in-depth piece about why it provides no additional assurances beyond what any soft fork provides on GitHub, which is likely of interest to anyone coming across this post. Ultimately, the point is all about "when is a soft fork active". Probably the best resource on the subject is Pieter Wuille's old post from 2015 on bitcoin-dev, but to summarize, the answer is, largely "when it is understood that the vast majority of economic nodes in the Bitcoin system are enforcing the rules via full node software which they run", in other words "when full nodes are enforcing it".
Some confusion has entered the discussion as, in many past soft forks, we've utilized miner signaling to bridge the gap between old full nodes unaware of an upgrade and new full nodes enforcing the rules. Effectively, we've said "the soft fork is active when new nodes have upgraded and miners have signaled readiness above a certain threshold" - ultimately it's about nodes having upgraded and enforcing the rules, but there's nothing to stop us saying "nodes only enforce the rules if miners upgrade". Similarly, there's nothing wrong with saying "nodes always enforce the rules, because miners aren't doing something users want".
In general, the argument in favor of forced-signaling basically goes like this: "if we start by assuming users are running software which interprets the signaling bit, then ensuring the bit is signaled on ensures that users are enforcing the rules". However, there's not a lot of reason to make that initial assumption. The reason we do use miner signaling in the first place is it reduces the risk of forks and reorgs visible to un-upgraded nodes - something that could expose some users to fund thefts due to double-spend. However, if we use forced-signaling, that advantage goes out the window, indeed, we get the exact opposite outcome - on day one of the fork, we immediately create reorgs visible to un-upgraded nodes, putting their ability to accept payment at risk.


What constitutes a project to be a Bitcoin Sidechain? From my understanding sidechains require the parent blockchain (bitcoin) to be able to lock a certain amount of coins on the sidechain. My question is how is it different from just sending your btc coins to a 3rd party and they just hold it while they give u their own tokens to play with. How is coinbase different from rootstock which is supposedly a sidechain right? I know coinbase is a company that holds your btc, but doesnt rootstock also hold your btc? The thing is how do they hold it?

A sidechain requires one or more blockchains, aside from the parent chain. This is different from off-chain, which is what would be the case in some types of Coinbase transactions. Since you didn't mention the presence of an additional blockchain in your other reference to a 3rd party which provides tokens in exchange for a payment, I would assume (albeit subjectively) that it would probably be an off-chain type of transaction in that example, too.

Rootstock, on the other hand, has its own blockchain, to create a 2-way peg with Bitcoin to facilitate smart contracts and other potential features, like near-instant payments.

Here's more information about sidechains in case you'd like to read about them in more detail. There are additional technical components beyond the presence of one or more blockchains:

Enabling Blockchain Innovations with Pegged Sidechains
A Simple Explanation of Bitcoin "Sidechains"


Can two bitcoin-qt share the same blockchain data I have a bitcoin-qt and bitcoin-abc on same computer running, can both share the same beginning of the blockchain data file ? since they both have same history till point in time.

It's not a documented feature, but Bitcoin Core and its derivatives only write to the last blk*.dat file, and only read the others.  So you can create symlinks to have them share older files.  I've done this (for testnet) and it worked fine.


Would a normalized, hashed, protected chainstate reduce miner storage costs? Spending freshly generated coins is prohibited by the protocol until there are at least 100 blocks on top of the block from which they came.  This is because the chances of a 100-block reorg is virtually zero.

The chances of a reorg of 1,000 or 10,000 blocks is even lower.  If the chainstate data is normalized, then its hash can be included in each block so that messing with it is as impossible as messing with the blockchain itself.  Would we then be able to prune off all but the last 10,000 blocks?

I know the transaction history is valuable, but under the assumption that we will never see a reorg larger than a particular number of blocks, I suspect it isn't necessary for mining once the chainstate is protected as well as the entire blockchain has been.

It seems to me that normalizing the chainstate so that it can be hashed and protected (like block headers are) would allow validation and mining without having to save the entire blockchain.  That way, only those who really want the history would need to save it.

Am I missing something?

You don't actually need to commit to the chainstate in blocks - just compute it the normal way, but throw away the block data after validation.

In fact, that's exactly what the pruned mode in Bitcoin Core 0.11 does, and it supports mining.

Storing the hash of the chainstate into blocks does have other advantages, like being able to skip processing historical blocks entirely if you're willing to trust a miner majority to commit to a correct one. However, it comes at a very significant cost for validation, as this hash would have to be recomputed and verified with the entry inside every block.


How do I know if my bitcoin client is mining? I set up my bitcoin client to run on the testnet network, where I can presumably mine test bitcoins in a reasonable amount of time using only a laptop CPU.

./bitcoin-qt -testnet -gen

Using top I can see that bitcoin-qt is using a lot of CPU. This leads me to think that it is mining for bitcoins. However, how can I know for sure that it really is? There does not appear to be any indicator in the GUI to show that mining is in process.

If my client eventually does find some bitcoins, will they appear in my wallet? Will they appear in the transactions log?

How do I know if my bitcoin client is mining?

Help > Debug window > Console > Type "gethashespersec"

  If my client eventually does find some bitcoins, will they appear in my wallet? Will they appear in the transactions log?

Yep.


I cant open my bitcoin wallet After a few days I have inserted my external hard drive where I have installed the wallet with my btc to update it.

Giving the .exe "Bitcoin-qt" would normally directly open my wallet and start loading.

Today, however, when I click on it, the initial message jumps, from where I would like to create my wallet for the first time ...

What I can do ?

As I can see, I also keep all the files:
- blocks
chainstate
- wallets
- .lock
- peers.dat
- mempool.dat

Also inform that I recently updated windows 10, I do not know if it would have influenced

You are using bitcoin CORE with the default folder in appdata?

so the location of the entire data folder (including the complete blockchain, and wallet.dat (where your private keys are) is in:

%userprofile%\AppData\Roaming\Bitcoin

copy and paste all that in a folder inside the USB drive.

specially care with wallet.dat, save it into TWO different drives, not one!, never do CUT and paste, do always copy and paste, and don't drag n drop either it's dangerous specially with touchpads hehe, if you don't have two usb hard drives for the entire blockchain, do a full backup in your USB drive, and then save in a flash drive only the wallet.dat.

it is one thing to have to download the entire blockchain because your USB hard drive died, and another is loosing all your bitcoins so, wallet.dat , TWO copies (remember, copies means that the file is in your computer AND on the devices) the more the better.

RESTORE: (my way, maybe there are other options, this is how i did it, multiple times! when defender screwed my blockchain data folder)

install bitcoin core (ideally the same version!, but it could be older, it works)

RUN IT
once it says sincronizing, close it.
(this is so the wallet will create the data folders)

now go to:
%userprofile%\AppData\Roaming\Bitcoin

and delete everything inside, and replace it with your copy from your USB drive backup


How to check confirmations number programmatically How can I check confirmations number for some bitcoin address programmatically? (I have eCommerce shop where each order has separate address).
I want to use blockchain.info API.

Here is an example of the API call, but I can't figure out what numbers should I check in API response:

https://blockchain.info/rawaddr/1JbBiCzQqzE2dW9TCzA6w7N27jVDXxwreD

Confirmations for an address aren't really a thing.  Addresses are not confirmed; transactions are.  A single address is typically used in multiple transactions: one where the address is used as an output, and one where the first transaction was used as an input.  Although it's not a best practice, addresses can even be re-used multiple times.

It looks like this particular address has been used in two different transactions.  Once as an output in 00c83c7677d414053488d0b51067feee157a5b82d5acec5bfe8e9c540c11c624, and once as in input in 378f829160cb9c99cc7a8fb1152472b80f0e1ea9c9cc24118dbccc2da72dedcf.

Each of these two transactions returned in the API response has a block_height value (489353 and 489355).  That is the block at which the transaction was included.  To find how many confirmations each transaction has, subtract the block_height by the height of the most recently confirmed block, and add 1.  So if the current block is 489355, one transaction has 1 confirmation, and the other has 3.


Double transaction on same hash (transaction ID) - Loosing 0.01 btc each time Each time I send some btc to another bitcoin wallet there is a second transaction on the same transaction ID (hash) and each times i am loosing around 75 USD.

You can see by yourself here;

https://www.blockchain.com/btc/address/1NrZWuS4J8MAqX63NHFuLrdmBYf6FttX29

Another weird fact is that on my bitcoin wallet software balance, it's not showing to balance I lost.

Any help would be very appreciated,

Thanks.

See above link about How change works. Looking at this transaction 5f48a419f861ca157e938492a5a8550a85c4d93749cd7d2bcdb9822be6ee9b3b:

(Assuming) you tried to send .001 BTC to 1PqarrL2NAobkNbExtjBA1KEzXk7rwPfGQ, but there did not exist any unspent transaction outputs (UTXO) to satisfy that exact amount (plus tx fee). So your wallet chose to use the UTXO worth 0.01105895 BTC. It then sent the change (minus tx fee) back to your wallet in a separate output to 147FWjxpW9nYo5Z32qaHSoUZbVCNgsPGuL. The address for the change is different because it is based on a different public key (it is a hash of a public key, thus a different address), but is presumably still spendable by your wallet.


Old blockchain info wallet password lost I have a very very long time not used my blockchain info account (it is from before blockchain info has new version)
and I forgot my password + my second password, but I find this saved data from my wallet on my stick.

The data looks like:

{
    "guid": "8d07f7c2-b947-4b3d-80a7-3138dcf3fa80",
    "sharedKey": "eb8bab6b-f00a-4861-83b3-24d7b2938a74",
    "double_encryption": true,
    "dpasswordhash": "76296efc1718b4b57a4ebe0287a35ad4565bf84d4e4437963bd2d06a5b981b1f",
    "options": {
        "pbkdf2_iterations": 10,
        "fee_policy": 0,
        "html5_notifications": false,
        "logout_time": 600000,
        "tx_display": 0,
        "always_keep_local_backup": false,
        "transactions_per_page": 30,
        "additional_seeds": []
    },
    "keys": [
        {
            "created_device_name": "javascript_web",
            "addr": "132uY8ULMT6efFdqWjQ74BfaMt46MgpW2F",
            "priv": "mFmbijM0I7Vn7lOv3XcaayhjxXu0qkhd3gNapgknJdudpQn8H9zZw/uOZ/zZ2HDFDkgQV4n1ZX8VjX12qCymDw==",
            "created_device_version": "1.0",
            "created_time": 0
        },
        {
            "created_device_name": "merchant_api",
            "addr": "1AdbcgN8jFYqErMLiUfhFwSJ2jAa3qYCpv",
            "priv": "PG8w31iFpUiWdTjybhy3fK8Lb/VGqVChZxD0S7U4PgGsyLJbUKFNkipC8PMeD7oUt4HYHqmPzvWspHMyO/jSHQ==",
            "created_device_version": "1.0"
        }
    ]
};

Its someone used blockchain info in last year was a export option for key - and that I will recompensate all professional help and working idea how to import this data in any type of new wallet to I can have access the coins.

Due to the way the blockchain.info wallet works, without the password (and the second password if enabled), there's no way for you to recover your funds.

As a last resort, if you remember bits of the password, you can try to use services/software that'll try to bruteforce the wallet ; given the low balance of your addresses, I doubt it's worth it.

Sorry for your loss.


Generate address of 'private key' from user input I want to take a private key as input from the user and convert it to a wallet address using C#.
I have seen this in a tutorial to generate a random key:
Key privateKey = new Key();
PubKey publicKey = privateKey.PubKey;
Console.WriteLine(publicKey.GetAddress(ScriptPubKeyType.Legacy, Network.Main));

How do I convert a private key string from the user to a wallet address for main net?

Assuming the private key string in this example is pk
Console.WriteLine("Enter private key:");
string pk = Console.ReadLine();
var bitcoinPrivateKey = new BitcoinSecret(pk, Network.Main);

var legacy_address = bitcoinPrivateKey.GetAddress(ScriptPubKeyType.Legacy);

Console.WriteLine("Legacy Address :" + legacy_address);

And if you want to get p2sh-segwit and bech32 address, add below lines:
var p2shsegwit_address = bitcoinPrivateKey.GetAddress(ScriptPubKeyType.SegwitP2SH);
var nativesegwit_address = bitcoinPrivateKey.GetAddress(ScriptPubKeyType.Segwit);

Console.WriteLine("P2SH-Segwit Address :" + p2shsegwit_address);
Console.WriteLine("Bech32 Address :" + nativesegwit_address);


what must do to sent money from bitcoin to my bank account Where can I find my e-wallet and to must I do to send money from bitcoin to my bank account. am trying to send money from bitcoin to my bank account

Simple answer:
You can not send bitcoins to your bank account.
...except is some special cases when your bank accepts bitcoins. I do not believe your bank do that.
Long answer:
You need to exchange the bitcoins for money, say EUR or USD or your local currency. Lots of bitcoin exchanges can do this, but you need to have trust in the exchange, because they can stole your bitcoins and never send you the money.
I use two exchanges, but I am not sure if it is OK to recommend them here.


How to know when a payment has been received by bitcoind? I want to create a website which involves the creation of a new single-use address that a user would send bitcoins to. I'd like to know programmatically when the user has sent bitcoins to the address so the website can post a "thank you" note (or do whatever else). What is the best way to do this?

The flow would be:

Website creates and shows user a new single-use address and says, "send bitcoins here"
User sends bitcoins to the address
As soon as the address receives bitcoins, the website says "thank you for sending 0.3 BTC!"

I suppose I could poll the address in question every few minutes, but this is problematic because the user may abandon the website after step 1 (i.e., never send any bitcoins), so the website might end up polling forever.

I am using the official bitcoind client now, but I'm open to using something else.

I understand Blockchain.info provides an API to get push notifications on a given address activity, but I'd rather not rely on a third-party service.

Beginning with v0.6.0 of the Bitcoin.org client was -BlockNotify.  Beginning with v0.8.2 of the Bitcoin.org client was -WalletNotify which provides transaction-level notification.


Can I use single address for all my transactions? Can I always use single public key (addr1) for all my transactions and when I spend every time protect it with different scripts / keys (key2, key3, etc.), so that spending requires at least two keys ('key1', and 'key-n') but addr1 remains the same for receiving bitcoins.

example.

(transaction, output script): (input address, amount) --> (output 1); (output 2)
--------------------------------------------------------------------------
(trxn1, script1): (addr1, 10 BTC) --> (addr2,  5 BTC); (addr1,  5 BTC)
(trxn2, script2): (addr1,  5 BTC) --> (addr3,  1 BTC); (addr1,  4 BTC)
(trxn3, script3): (addr1,  4 BTC) --> (addr4,  1 BTC); (addr1,  3 BTC)
(trxn4, script4): (addr5, 12 BTC) --> (addr1, 10 BTC); (addr5,  2 BTC)
(trxn5, script5): (addr1, 13 BTC) --> (addr6,  2 BTC); (addr1, 11 BTC)

Is it possible to make script 1, 2, 3 and 5 would require different keys (at least 2; key1 and key-n) to spend bitcoin from this address?

Is it possible with Script? Is there any other ways in which I can keep single address for all my transactions?

addr1 is my address; transactions 1, 2, 3, 5 are my spends and transaction 4 is receiving transaction.

Motivation: To use same address for all my transactions. Reason is, I own firstbits address '1vijay', and I don't want to loose in case of my private key compromised. I am looking for any solution that would solve my problem, particularly scripts.

pseudo-script would be something like,

scriptPubKey: <pubKey1> OP_DROP <pubKey2> OP_CHECKSIG
scriptSig: <sig>

I would like to use 'pubKey1' as my receiving address always, but my spending would depend on private key corresponding to 'pubKey2'.

If you are to receive a transaction with address A, you need A's private key in order to spend it and nothing more.

If you want to require two or more addresses to be used to spend money you receive, you would need to use a multisig address. After that, you would need to use m-of-n private keys to spend the coins, with m and n being predefined when you create the multisig address.

There are other ways one could restrict coins from being spent - say requiring a password or allowing anyone to spend them, but they are a lot more obscure and generally not used by anyone.


How to store arbitrary data in the bitcoin blockchain and how can I differentiate between a transaction an those data? According to this post, I can store arbitrary data in the blockchain (as the news about "child pornography in the blockchain" tell).
Now I want to store "Hello World" in the blockchain.

Is there a newer website/service that supports me putting data into the blockchain?
And what's the difference between a transaction in the blockchain and such a "message"?
Is the structure different? Why could those researchers even find out that it's inappropriate content instead of a default transaction?

Have a look to these data sources:

https://bitcointalk.org/index.php?topic=1023190
https://github.com/petertodd/python-bitcoinlib/blob/master/examples/publish-text.py

And of course the "modern" (and cheapest) way is storing arbitrary data in segwit part of transactions. I do not know is there ready tool for it, but it is not very difficult to write it.

  Is there a newer website/service that supports me putting data into the blockchain?

https://cryptograffiti.info/ (based on bitcoin cash blockchain)


Converting Litecoin M-addresses to a more commonly accepted format Is there any way to convert an (LTC) M prefix address to an L prefix address?

Many services an apps that accept and transfer LTC reject M-addresses as invalid, even though they are given out by Coinbase.

I called Coinbase support but was unable to find a solution.

You cannot convert an M prefix to an L prefix as they are different types of addresses, the first being a P2SH address and the latter a P2PKH address.

You can, however, convert it to a 3 prefix address using https://litecoin-project.github.io/p2sh-convert/, a convertor built by the Litecoin Foundation for this exact purpose.

Originally, Litecoin used the 3 prefix for their P2SH addresses. However, this caused an overlap with Bitcoin, which also uses a 3 prefix, and led to many people sending funds to incorrect addreses. Litecoin then changed their prefix, but since it is simply an encoding change, you can convert it back to the original prefix for wallets that have not yet update their integration to respect the new prefix.


C++ code for traverse though all the blocks in blockchain? In my project for one particular functionality, I want to traverse through all the Transactions. For that purpose I want to traverse through all the blocks in blockchain.

If you are intent on doing it with c++, there is a blockchain parsing library that may help you here https://code.google.com/p/blockchain/.

Depending on your application, though, I might recommend just writing a terminal script to use the daemon. It probably won't be as fast, but I bet it would be easier to get up quickly. These commands can be called to get you the info you need:

// Gets the block at index index
./bitcoin-cli getblockhash {index}

// Gets the block using the result of the first statement
./bitcoind-cli getblock {hash}

// The block has an array of transactions in it
for (Tx tx : block.tx) {
    ./bitcoind-cli getrawtransaction {tx} 1
}


Do any actual bitcoin credit / debit cards exist yet? With the rumors of the Bitinstant credit card failing to deliver, and the only other one out there being a fake scam site, does anyone out there offer a solution to this?

Just the ability to pay with Bitcoin wherever credit cards are accepted in USD is all I need.

Bitcurex offers prepaid cards for Euro, Dollar, Pounds and PLNs.


Will I have the same amount of bitcoin on "bitcoin core" and "bitcoin unlimited" Do you have to buy bitcoin unlimited coins with my bitcoin?
What will happen in the outcome of a bitcoin unlimited hard-fork?

If a hard fork activation of Bitcoin Unlimited were to occur, both the resulting chains share a common blockchain-history:

                     BTC : ← 6 ← 7
1 ← 2 ← 3 ← 4 ← 5 <split>
                     BTU : ← 6 ← 7

All the coins that were in your possession before the split now exist on both chains. Once you have moved them to separate addresses on the two chains in order to prevent replay attacks, you'll be able to move them independently by using two different Bitcoin wallets that each interpret one of the chains.

As to other results of the fork, I don't feel like it's appropriate to make predictions at this point, but I would expect significant volatility as some users would move to dump coins from the side that they don't wish to support.


Does Merkle Tree root hash changed when miner node not found POW nonce? In bitcoin PoW process,if miner does not found the nonce, I understand that he must
to increase nonce and rehash the entire block header again
to mine the new block.
so if nonce defined 4byte[between 0 and 2^31],
goes from 0 to 2^31 finally and even not found the target hash, does the miner rehash the Merkle Tree including coinbase transaction?
And what algorithm for miner to change coinbase transaction?

Not necessarily. If a miner runs out of nonces, there are still other things in the block header he can change. The version number and timestamp can both be changed to effectively increase the number of nonces that can be tried. However there are not as many possible version numbers of timestamps that can be used as they have to fit within certain constraints.

If the miner does not change those, then he will change the merkle root. This is most commonly done by incrementing a value in the coinbase transaction known as the extranonce. This value is stored in the coinbase script where miners are free to place up to 96 bytes of arbitrary data. By incrementing the extranonce, the merkle root will change and the miner can continue with searching through nonces again.

If the miner runs out of nonces and extranonces, he can reselect transactions to be included or reorder transactions, both of which will also change the merkle root.


How much data does it take to prove a given transaction exists on the blockchain? As I understand the SVP protocol, a client can be reasonably certain that a transaction has been accepted on the blockchain if they know it is a member of a certain block, via the Merkle path, and a reasonable number of blocks have been mined on top of that block.

How much total data would that be, roughly?  I guess if you were beginning with 0 knowledge, you would need all of the block headers, beginning from the genesis block?  But once you are convinced you are looking at the head of the right chain, you could discard all of the ancient block headers, and just save a recent one as a trusted starting point to evaluate subsequent transactions?

I guess the premise of my question is faulty, as a fake transaction could always be embedded in a fake chain, if enough computing resources were available.  So, there is no amount of data that insures a transaction is valid, without access to other information, e.g., what is the longest chain currently in existence.

A better question for my purposes would be how much would the electricity cost to create one fake block header at today's difficulty level?  Figuring that blockchain currently pays around $60K to mine one block, I would guess it must be in that order of magnitude, though smaller since we are removing the race condition.

In theory, you would only need the data from the block of the transaction, and the ability to prove it the transaction still exists after at least 6 confirmations.

The more confirmations (blocks mined beyond a transaction) the lower probability it becomes possible to reverse. Generally speaking, 6 confirmations is enough to identify a transaction is irreversible.

Here's a quote from Mastering Bitcoin by Andreas Antonopoulos:

  By convention, any block with more than six confirmations is considered irrevocable, because it would require an immense amount of computation to invalidate and recalculate six blocks.

Block vary in size, but in SegWit transactions, the entire block can be a maximum  ~2 MB.

These days there are many online tools that can verify this without needing the entire blockchain.
The bitcoind JSON RPC API also works fairly well in providing transaction data. (Cannot be manipulated like with an online API)


How do I use Blockchain.info's Receive Payments API with node JS / Express? Blockchain has great documentation for PHP, but nothing really for node!

Does anyone here have any projects,where they used the blockchain.info Receive Payments API, in their node apps, to receive money / check for confirmations?

I learn a lot better by viewing / recreating example code so any you have would help me out tons!

I'm working on something like this now. I do not have a complete implementation built yet, so please bear with me for any errors or troubles that might arise. However, this might help get you on your feet...

I started by installing bitcoind and setting it up as a client which Node.js can interact with the Blockchain through. I did this by setting up bitcoin.conf with my Blockchain information and starting bitcoind in a screen. Take a look at this page for information on connecting bitcoind with your Blockchain account: https://blockchain.info/api/json_rpc_api

You'll also need middleware for Nodejs to interact with Blockchain through bitcoind. Here's the one Blockchain links to: https://github.com/jb55/node-bitcoin can be simply installed with:

npm install bitcoin

The readme file on this Git provides information and code snippits you can use to connect Nodejs with Blockchain. Node connects to your local bitcoin server:

var bitcoin = require('bitcoin');
var client = new bitcoin.Client('localhost', 8332, 'username', 'password');

Node gets the balance of all your addresses, with at least 6 confirmations:

client.getBalance('*', 6, function(err, balance) {
  if (err) return console.log(err);
  console.log('Balance:', balance);
});

Here's a list of all the possible Blockchain API requests: en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list

You can use these functions to create and destroy wallet addresses, check their balances, as well as send funds from your script if you so desire.

Speaking briefly about security, double encryption is recommended and can be enabled in the Blockchain My Wallet 'Account Details' page. This means each address has it's own access password, on top of the master wallet password. Simple operations such as fetching a balance do not require both passwords to be sent, but sending funds would require Node to send both the master and wallet passwords. If you're using a server with a static IP, you can also use the 'IP Lock' setting in Blockchain to restrict access to outsiders. Gotcha: two-factor authorization must be disabled on your Blockchain wallet to allow access from your script.


Not receving Bitcoins to my testnet wallet I am running the bitcoinj wallettemplate on testnet3. I have this address miAKWcmebJ7TYyZCYUx54djHsatVGdNZA8 , I tried out some websites which sends me testnet coins (Faucet). But I am not receiving any. ? What I am I doing wrong ?

At last I found this one. this was the only one which was working.
I tested on some coins and send them back.


Minimum Tranasction Fees At current exchange rates, it looks like the standard transaction fee is on the order of tens of cents (USD).  Inclusion of the standard transaction fee means getting the transaction picked up within minutes.

Conversely, zero transaction fee transactions may not be picked up for days.  It also seems to be the case, at least for now, that transactions in limbo like this may be double spent by reissuing with a higher transaction fee.  See earlier discussion here:  Could any standard fee transaction be double spent by using a higher fee?

One can imagine that in the longer term there might be a market equilibrium in which a certain floating minimum transaction fee is required by miners to guarantee processing, and that sellers might not deliver/perform unless that fee were included in a payment.

Are there ways to estimate what the minimum fee might be?

Bitcoin Core, as of 0.10, has a fee estimation RPC call, which you can read more about here: http://jonathanpatrick.me/blog/floating-fees .

If you don't want to run Bitcoin Core, there are other third party services that provide simple API calls to estimate fees as well, like the Chain Endpoint on BlockCypher's API: http://dev.blockcypher.com/#chain-endpoint (Full disclosure, I work there/am biased)


What provably fair Bitcoin gambling sites work well on a mobile? Are there an Bitcoin-based gambling sites or apps that work on a mobile?

Most of the sites seem to be assuming the player is on a full size display.

If the service isn't considered "provably fair" then I'm not interested.  An example of a provably fair game is one where the host gives the hash of the secret, then a client seed is generated, then after play at some point the secret that was used is revealed.

Provably fair means the player can prove the operator didn't cheat.  With website-based provably fair systems, the generation of a random number and/or client seed is easily to see and monitor.  Unless a mobile app is open source, this same capability is not available.

So a provably fair website that provides an app doesn't mean the app provides provably fair online gaming as well.   An open source app could be provably fair.

You won't find any of (or at least not many of) these apps on the Google Play store since they are online gambling that is a prohibited app on their service.  But the apps can still be installed from external sources:

Seals With Club poker has a mobile app.
Bitcoin Video Casino has an Android app.


how to place a bitforex api buy order I have read the documentation for BitForex on placing a buy order here:
https://github.com/bitforexapi/API_Doc_en/wiki/Order

Then after understanding that, I read the API Call Description documentation:
https://github.com/bitforexapi/API_Doc_en/wiki/API-Call-Description

Here is what I have in my code:

var crypto = require('crypto')
var axios = require('axios');
var accessKey = 'xxx';
var secretKey = 'xxx';

var nonce = Date.now().toString();

var amount = "1"
var price = "0.00015393"
var symbol = "coin-eth-bf"

// tradeType 1 is buy , tradeType 2 is sell
var tradeType = "1"
var message = `/api/v1/trade/placeOrder?accessKey=${accessKey}&amount=${amount}&nonce=${nonce}price=${price}&symbol=${symbol}&tradeType=${tradeType}`;

var hash = crypto.createHmac('sha256', secretKey).update(message);
var signData = hash.digest('hex');
axios.post(`https://api.bitforex.com/api/v1/trade/placeOrder?accessKey=${accessKey}&amount=${amount}&nonce=${nonce}price=${price}&symbol=${symbol}&tradeType=${tradeType}`)
    .then(function (response) {
    console.log(response.data);
    })
    .catch(function (error) {
    console.log(error);
    });

I keep getting an error:

{ code: '1011',
  success: false,
  time: xxx,
  message: 'NeedParam accessKey and signData' }

I am currently at a loss to why I keep receive this error.
I am passing both the accessKey and signData in.
The part that is fuzzy to me is the signData.

Am I creating the signData properly based on the documentation?
Also, am does order matter for the parameters that are being passed
in? Anything else I may potentially be doing wrong?

I don't believe you can"t use the $() syntax to concatanate strings in node.

var message = `https://api.bitforex.com/api/v1/trade/placeOrder?accessKey=   ${accessKey} <--  &amount=  ${amount} <-- &nonce=${nonce} and beyond[...]`

you can simply do
message = "/api/blahblah" + accessKey

You obviously did this multiple times.  If the issue is something different I will return to the question but this seems simple.


How is scalability of walletnotify of the full node wallet I'm thinking about how large exchanges handles customer deposits, it appears there are two available solutions, one is to use external notification apis, like blockchain.info 's notification api, another is run a full node and use the walletnotify feature. Since the first approach brings dependency to an third party service, also, it does not support testnet notification, which we use during development, so I'm trying to run a full node. My question is how scalable is it? Suppose there are 10,000 users, and platform must support add more addresses for a user, say in average each user generate 10 addresses, that's 100,000 address to watch. If I add those 100,000 address as watch only to the full node and enables walletnotify, is that a good way to handle it? Will there be any technical issues?

Using walletnotify has proven to work and is used by a lot of scalable apps today. I would not rely on it completely though. walletnotify's job is to execute a shell command every time it receives a wallet transaction. This means data is flowing between processes, which does not make me entirely comfortable as a developer. After all, it only takes one error for someone to be missing their funds.
I would recommend not only using walletnotify, but to also check X blocks after Y minutes. You can keep track of blocks passed and if any transactions were not processed by walletnotify, your cronjob of checking transactions will recover the transaction. You can use listsinceblock RPC command and keep track of the block height each time you check transactions. You could store transactions processed in a DB somewhere.
After all, this is a financial application so I think a backup check is vital.


BTC deposit old address exchange i had BTC deposit to old address in coinsbit.io exchange after 20 days they told me we dont have access to old addresses to bring back your money and i know the only one can have this access is coinsbit to transfer it. i tracked my old address in coinsbit they transfer my money after 5 days to another addreses . i sent ticket many times but they are saying we dont have access . is there anyway to bring this money by report or something? my old address is : 3ETDfiumVEBTZP1HEKDv58Uoiv2jbnomTF
my two hash link: https://blockchain.coinmarketcap.com/address/bitcoin/3BFZmH5ZYJxkqtVLNzi3YEeWQ8nNrxq7zC

https://blockchain.coinmarketcap.com/address/bitcoin/3BYeChb5aeXmWBP33318nnHyZhNYpmTqBu

You are right, the only ones who should have access to that address is CoinsBit.io.

If they claim they are unable to recover the coins, there are only three possible scenarios:

They have lost all copies of the private keys, or the root key used to derive them - this would be extremely irresponsible of any exchange, but does not appear to be the case here since the coins have been spent, which requires access to the keys.
They have been hacked and the old address' keys are compromised - this would imply that the coins were spent by an attacker, and the exchange no longer has access to them.
They are simply exit scamming and taking funds from users.

In all three cases, no one here can help you. Bitcoin transactions are irreversible, and without the private keys the funds are immovable. You should consider engaging a lawyer and going after them via the legal system.


Google Sheets Cryptofinance Add-on - is the company still operating? I sent in some support emails since May 14 and have not heard back. Anyone aware if the developer is still operating this add-on for Google Sheets?

      Update, they replied today (May 23) and resolved my inquiry.

I believe so, I've had a reply to my emails and telegram messages just few days ago. Maybe they are too busy with this (mini) bull market?


Deposit flow, user balances I am a working on website where people should be able to deposit BTC to thier account balances and then do something with these balances. I figured out that I need deterministic wallet and generate different address for each user (based on user id) and perhaps for different deposit (based on total user deposit count - I've read that is best practicle to use 1 address for 1 transaction). I would like to be able to notify users when we see unconfirmed transaction and when it gets confirmed (add deposited amount to users balance).

Deposit flow:

1.1 on rawtx check if one of output addresses is in DB as some users deposit address

1.2 if it's some users address create new deposit in DB with 0 confirmations and mark is as pending

1.3 notify user that we can see his deposit but it's not confirmed yet and he will get BTC onto his balance once this transaction reaches 6 confirmations

1.4 on rawblock get all deposits with less than 6 confirmations and query blockchain.info to get confirmations count (see problem c).

1.5 update confirmationCount and if it's >= 6 assign coins to balance + notify user about balance change - from now on his deposit will be marked as confirmed

Now problems:

a) If server goes offline for any reason (app error/network issues/maintenance) potencially user can still deposit coins to previously copied address and we won't catch that transaction - so it will never go past 1.1. In ZMQ I can detect network issue by checking sequenceNumber (and query RPC for missing information?). I can't query all addresses on application startup to check if there were any deposits while application was down so meaby I should persist last block id (known to my app - updated after 1.4) in DB and on startup just check all newer blocks for already confirmed transactions (and perform 1.1, 1.5) and check mempool for all unconfirmed transactions and perform steps from 1.1 - 1.5.

b) My other idea of solving a) problem was to keep track of synced addresses/users in apps memory/redis. After user connects(registers/logins) check if such user was already synced in this application lifetime (this application start - node index.js, kill, node inde.js would be 2 lifetimes - I hope you know what I mean) if user is synced do nothing and if not scan all user addresses for all transactions and check if they are already added to DB. And mark user as synced. From now on 1.4, 1.5 should take care of the rest (?).

c) I would rather not use external service such as blockchain.info and just get information via RPC but whole confirmation checking flow seems complicated becuase of edge cases like double spends/block reorganization. Also I had hard time using bitcoin-core RPC (it meaby was because I first synced bitcoind and then added indexes and it's still syncing them).

d) Meaby there is some other more safe/easier/scalable way of doing such this?

These are indeed hard problems, but luckily already served by BTCPay Server, with extra features like lightning payments: https://github.com/btcpayserver/btcpayserver.

You can just run it via the included docker recipe (https://github.com/btcpayserver/btcpayserver-docker) and communicate with it via its API.

Or if you really want to reimplement the nitty gritty stuff yourself, look at its code or architecture documentation.


Altcoins: Determine how many confirmations to require to deposit For Bitcoin it is common knowledge that 6 confirmations suffices. For the hundred of Alt Coins however, I'm not sure what the best practise to be protected enough from double-spents and the likes is.

I saw Bter.com requires different confirmations varying on which Altcoin you want to deposit.

For example COMM-coin requires 10 confirmations, but BBQ coin 6, and Infinitecoin only 4.

Is there a mathematical method behind this? How do they know how many confirmations to require?

Yes, there is a mathematical grounding behind this, namely Poisson distribution. See Satoshi's original paper (last pages) for some details about calculating the odds of a successful double spend attack given a certain portion of the networks computation capacity. This also means of course that networks with a larger hashing power are more susceptible to an attack than networks with lower hashing power.


Does a transaction in Bitcoin Mempool reach many miners during mining or only a single miner? I'm trying to understand the logic around the Mempool. What I understand is a miner will pick transactions based on an incentive given by the sender, i.e. a fee, so that the higher fee, the faster transaction will get confirmed.

But, What if the transaction get picked by a single miner regardless of fee and that miner is very unlucky miner that somehow it never win the block hashing lottery. Is that possible?

My question is:

Is only a single transaction picked by a single miner and the miner hashes the transaction with other transaction, then guessing the nonce, if it wins, then it includes in the block, else return to the Mempool?

Or,

Is only a single transaction picked by multiple miners and all those miners hash the transaction with other transactions, the guessing the nonce and the miner who wins the lottery included it in the block?

How it actually works:

You send your transaction to one or more nodes (your wallet does this job for you). Each of the nodes (some of them are miners) sends it immediately to all the nodes it knows (and again and again).

All the miners store the transaction (if it's valid) in their own mempool.

When a new block was created, all miners look in their mempool and try to find the best not-mined transactions, pick those with the highest fee per byte and include it in their block-mining-attemp.

If one of the miner's mempool-transactions is mined, they simply delete it out of your mempool.


Are there counterparty nodes that one can run to support the counterparty network? Does counterparty have its own set of nodes to keep its service up?
Is it pow or pos system? Or is this just a centralized service?
What was the purpose of it burning bitcoins to generate their own counter party tokens when its somewhat centralized?

Yes it does, the project runs a reference node.

The PoW comes from Bitcoin, but anyone can run a Counterparty node. I don't know if there's a name for it, but maybe it could be described as a community consensus approach. All Counterparty nodes can validate transactions embedded in the blockchain.

The purpose of burning BTC was to make it a non-scam token. Those who burned BTC committed to the project. Another way to put it is it's a project without "investors". Proof of Burn was rare then and in the flood of ICO scams, it's never applied these days.


how to use bitcoind "walletnotify" for unique transactions only while using bitcoind "walletnotify" my curl command is getting 3 hits generating 3 unique transaction hashes  but requirement is to execute only once for unique transactions.

I heard about walletnotifynew from :-"https://www.multichain.com/qa/9566/how-can-i-use-walletnotify-command-to-get-notification"
but its not working .

My bitcon.config file

rpcuser=root
rpcpassword=root
testnet=1
test.rpcport=8332
rpcallowip=127.0.0.1
server=1
rpcbind=127.0.0.1
walletnotifynew=/home/scripts/transaction.sh %s
#walletnotify=curl -d "txid=$1" http://127.0.0.1:8888/api/v1/listen-transaction %s

Database entry i was transferring the withing same wallet still three incoming but there should be only one entry of outgoing

select * from transaction;
+-------+--------------+------------+-------------------------------------+-------------------------------------+---------+------------------------------------------------------------------+----------+--------+
| tx_id | amount       | made_on    | sent_from_address                   | sent_to_address                     | success | transaction_hash                                                 | tx_type  | userid |
+-------+--------------+------------+-------------------------------------+-------------------------------------+---------+------------------------------------------------------------------+----------+--------+
|    53 | 0.0000000000 | 2020-02-17 | NULL                                | 2NFgnEMcE4kvvCLXK6uiEgb3dZuVLGUK75v |       1 | 11acce71f3d10330e10d70f5ee974abe5d216ec188309b61d1f751a1615d439d | INCOMING |   NULL |
|    52 | 0.0000000000 | 2020-02-17 | NULL                                | 2NFgnEMcE4kvvCLXK6uiEgb3dZuVLGUK75v |       1 | bc3267ffcc44b8d526cbb1de19f653bc90aedda4dc4fc2fc9ab18a954e7347c1 | INCOMING |   NULL |
|    50 | 0.0001000000 | 2020-02-17 | 2N6MqukeqDftwXsVDBSBkDrnbvzaXoNwNhi | 2NFgnEMcE4kvvCLXK6uiEgb3dZuVLGUK75v |       1 | 9bb2ab339930a68f33ce3521bee46363cbd29a87c68b718c4ae415a3ba53b7b8 | OUTGOING |      1 |
|    51 | 0.0000000000 | 2020-02-17 | NULL                                | 2NFgnEMcE4kvvCLXK6uiEgb3dZuVLGUK75v |       1 | 2e0976cd310fe1d740227cec0ae615dae668d4efeea740e51b81cb1b89dd2a47 | INCOMING |   NULL |
+-------+--------------+------------+-------------------------------------+-------------------------------------+---------+------------------------------------------------------------------+----------+--------+

There is no walletnotifynew option in Bitcoin, you will have to do deduplication on the application side.


Can Litecoin mining be bottle-necked by motherboard/cpu? So I brought 2x Sapphire Vapore-X R9 280X video card.  I am only doing 550kh/s each while on my other more powerful setup with the same card get about 750kh/s.  I am wondering if the motherboard/cpu matters?  Here is what I got on my new rig:

Asus P5K

Intel Core 2 Duo @ 2.66Ghz

2GB DDR2 Memory

As far as my research goes, this should all be fine, but at the end, the hash rate does not lie, what am I doing wrong?

I highly doubt it. Even the PCI-e connectors do not really matter. I've got less CPU power and RAM than you and my rig is controlling 4x 7950s at full potential. The CPU/Motherboard is essentially calling functions. The functions themselves are what cost so much, and those are computed by the GPUs.


Why did Bitcoin lose value so fast in early January 2015? What on earth is driving the price of Bitcoin and other alternative currencies down lately? It's one thing for it to go down a bit but losing practically 80% of its value in less than a year? I feel like bitcoin is coming to a complete collapse. A list of the most important factors and a detailed explanation would be great guys.

Adding to my answer on What are some of the proposed ideas to why the Bitcoin dropped to sub $400 in the end of summer 2014?, which I think is still mostly accurate:

Bitstamp loot

There are about 19k bitcoins held by the hacker that raided Bitstamp. While, as far as I know, they haven't found their way back into the market, it is an amount that would impact the markets if it were dumped. It is possible that some speculators were expecting a dump, and tried to position themselves to buy low. Such a dump in itself could have scared the already skittish market into further dumps.

Bitstamp has no trading fee until 19th

While Bitstamp seems to have weathered the hack well-enough, they are not taking any trading fee until the 19th. The fee usually being 0.2% – 0.5%, trades on much smaller movements are currently profitable. As Bitstamp is still the most important Western Exchange, this might have spiked a new dynamic.

The loss in value

Markets amplify the current trend. The loss in value is causing fear, leading to further dumps, creating a catch-22.

Russia banning Bitcoin websites

Bitcoin supposedly was a hip way to withdraw money out of Russia for a while. Although Russia had been rattling with their saber a while towards Bitcoin, they are finally starting to take action by blocking Bitcoin services there now. This might induce a trend of Russians moving out of Bitcoin.

Butterfly Labs has to sell their stash to confirm with financial obligations

Apparently, Butterfly labs has been ordered by court to refund their customers. According to rumors on reddit, they have been selling thousands of Bitcoins and are still sitting on more than 90k.

Mining operations sliding into unprofitable ranges

A bunch of mining operations, as for example CEX.IO, have cited that the current price makes their mining unprofitable. To cover financial obligations, they have to liquidate a larger percentage of their bitcoins than before, perhaps even their saved holding they were hoping to carry over to the next bubble. With the dropping price covering their obligations by liquidating bitcoins only gets more bitcoin-expensive.

Bringing oneself in position to buy takes a few days

When the price quickly lost value, few of those that were interested in catching up the cheap coins were already in position to buy. As it takes a few days for money to be transferred to exchanges, the buy reaction is a bit delayed in comparison to a price drop.

Especially on Bitstamp where deposits were closed for a few days during the slump in the aftermath of the hack, people were probably waiting for the dust to settle. In fact, a lot of the deposits from Bitstamp were immediately withdrawn on reopening.

Once the dust settled, and people started to realize that Bitstamp actually appeared to be in good shape, it still took a few days for potential buyers to transfer money to Bitstamp, which would explain why the price was somewhat shifted lower on Bitstamp in comparison to other exchanges for a while.

As usual: I'm a computer scientist, not knowledgeable in economy beyond what I read here and there. Please do not consider this investment advice; I have been wrong before. Please trade responsibly.


When a block is "discovered" how is the nonce determined? I know that a block is based on a random number called a nonce, but if that number is random  and unknown to the miner, how is that number actually verified as the correct nonce and not some arbitrary number?

Basically, there is no such thing as a "correct" nonce, only a set of possible "correct" blocks which can use any nonce they wish to obtain an acceptable hash.  So the nonce is just "some arbitrary number".  But in order to understand how nonces work, you first have to understand the hashing process by which blocks are produced.

Cryptographic hashes are a mathematical way of turning any set of data into a random number, called a hash.  The hashing process is designed so that it's easy to calculate the hash of some data but nearly impossible to find data which will fit a specific hash, having even a slightly different set of data will produce a totally different hash, and so that the only way to find a hash with a particular property (say, being below a certain number) is to calculate lots of them until you get lucky.

In the Bitcoin network, only blocks with certain hashes get accepted and included in the official list.  The criteria for which blocks "count" is that their hash has to be below a certain number called the target.  The network adjusts this number up and down according to how frequently blocks are passing the test--this is how it's able to keep the rate of block production at an average of 10 minutes per block.  So if the target is

00000692856290566183958127638592383846392938562929689273923968

then a block with a hash of

00000739485762992939239823472938472569106923385616929838472389

won't be accepted, but blocks with hashes of

00000683060299472046094517810601040976920106812102601296720934

00000000000000000000000000000000000000000000000000000000453737

or

00000692856290566183958127638592383846392938562929689273923967

will all pass with flying colours.  These aren't real hashes--they're just examples.

A miner is taking a list of checked and valid transactions, putting them together in the right format, and then calculating their cryptographic hash.  But let's say that the hash they get doesn't meet the criteria (as most of them don't).  What are they supposed to do?  The only way to get a different hash is to use at least slightly different data.  So instead of messing up their list of valid transactions or anything like that, blocks have something called a nonce in them.  The nonce is just a meaningless number that can be changed as many times as you like so that you can check a bunch of different hashes and see whether they pass the network's difficulty check.  So when a miner is checking billions of hashes per second (as many of them are) they are just changing the nonce to something else, checking the hash of the whole block; changing the nonce to something else, checking the hash of the (now slightly different) block; changing the nonce again, etc.

In this sense a "correct" nonce is simply the one that allows the block to hash to an acceptable number.  Just like there are many acceptable hashes, there are many different nonces which will work for the same block.  But a miner only has to find one of them.  Whichever one they find first is just fine.

You may also be interested in how the target is calculated.


how to set the conf file ,if my wallet is encrypted I'm working with bitcoin-qt to send payments, the config file is set to work with JSON-RPC.
it's include the rpcuser and rpcpassword, all calls I make to the wallet works fine, on the UI of the bitcoin-qt.exe I wanted to encrypt the wallet so every send payment I do from the UI will ask me for user password, I did it from setting->encrypt wallet.
After that all calls from JSON RPC I get an error "The remote server returned an error: (500) Internal Server Error." . should I add something in the conf file ?

You need to issue the walletpassphrase RPC command to unlock the wallet for some time, before you can perform send operations.