How to connect to bitcoind from ruby rpc client?

you will communicate over RPC/JSON

There is an example in the official doc :

require 'net/http'
require 'uri'
require 'json'

class BitcoinRPC
  def initialize(service_url)
    @uri = URI.parse(service_url)
  end

  def method_missing(name, *args)
    post_body = { 'method' => name, 'params' => args, 'id' => 'jsonrpc' }.to_json
    resp = JSON.parse( http_post_request(post_body) )
    raise JSONRPCError, resp['error'] if resp['error']
    resp['result']
  end

  def http_post_request(post_body)
    http    = Net::HTTP.new(@uri.host, @uri.port)
    request = Net::HTTP::Post.new(@uri.request_uri)
    request.basic_auth @uri.user, @uri.password
    request.content_type = 'application/json'
    request.body = post_body
    http.request(request).body
  end

  class JSONRPCError < RuntimeError; end
end

if $0 == __FILE__
  h = BitcoinRPC.new('http://user:password@127.0.0.1:8332')
  p h.getbalance
  p h.getinfo
  p h.getnewaddress
  p h.dumpprivkey( h.getnewaddress )
  # also see: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list
end


Where is the safest place to trade? Open account? Wallet?

Depending on the country you are in there are various ways to buy bitcoin. My default recommendation for US buyers is to use Coinbase.com or check out localbitcoins.com for a face to face trade.


How many nonces on average do I need to try in order to get n leading zeros?

If you want n zeroes when written in binary, 2n.

If you want n zeroes when written in decimal, 10n

If you want n zeroes when written in hexadecimal, 16n.

If you want n zero bytes, 256n.

However, none of these things are relevant in terms of Bitcoin. The difficulty is not the number of zeroes required; the difficulty is the minimum ratio between a well-defined maximum value, and the hash you got (when interpreted as a 256-bit unsigned integer).

In practice, the formula is that you need difficulty * 248 / 65535 attempts.


Auto formatting data into sendmany command

You can export the spreadsheet as a CSV file, then parse it using your favorite programming language into a dictionary. Convert the dictionary to JSON, and that will give you the second argument to the sendmany command.

I'd do this in Python using the built-in csv and json packages.

I'm not aware of any solutions that will do this if you don't know how to program, though.


MultiBit developer here. You should be able to simply spend from your Classic wallet into your new HD wallet. Don't try moving private keys around - that's really easy to get wrong and is one of the reasons we wrote HD in the first place.

There are full instructions on upgrading on the MultiBit website: https://multibit.org/en/help/hd0.1/how-to-upgrade-from-classic.html


Yes, what you need is BitWage; it does exactly what you ask: get paid fully or partially in bitcoin without involving your employer. There might be other services like that.


Are hashes of Merkle tree roots unique throughout whole blockchain?

The merkle root is a 32 byte hash.
As the hashing operation is sha256, it is exceedingly unlikely that you will find duplicates, but it is not, strictly speaking, impossible.


Can you add more Dash to a masternode that already has 1000 Dash allocated for a masternode?

You would have to create 2 masternodes and you would earn double the amount of Dash, and run separate nodes, probably on different computers as Dash requirements are sort of high.

Also you would need a server running 24/7 with 2 different IPs for the nodes.


OK, so I had several backed up .dat files on google which I put in opentimestamps

Bitcoin core stores wallet data ina file named wallet.dat so that was one of your .dat files.
Opentimestamps is just a service that provides proof that a document existed on a specific date. It doesn't store the contents of the documents.
You therefore have proof that your wallet.dat existed but that is of no use to you.

I just want the bitcoins that I know I have. I had a wallet.dat

You need to find either

that wallet.dat and any password you used to protect it
or a written copy of the "private key" that the wallet contained.

Otherwise all the money that was in that wallet is forever lost and unusable.


How to salvage bitcoins from corrupted hard drive?

You can also try running pywallet on the old wallet file to get at the private keys. Not sure it'll work with such an old file but it's worth trying:

https://bitcointalk.org/index.php?topic=34028.0

Once you have the private keys you can import them into any client like electrum, bitcoin-qt, multibit etc. to see if you have any coins.


Do we put all the transactions in the memory pool?

Bitcoin Core maintains a separate orphan pool, with transactions whose parents are missing. Its main purposes is dealing with peers that send us groups of independent transactions in the wrong order, so this pool does not need to be large.

Since Bitcoin Core v0.13.0, all transactions sent to peers are sent in batches, and within those batches in dependency order. This massively reduced the average size of orphan pools on the network (from hundreds to typically just a few).


From the perspective of the Bitcoin network, Coinbase owns both the Bitcoins you transferred in, and the Bitcoins they sold to you.

This is useful from a technical perspective, because Coinbase can have as many transactions within their system as they want, and no-one outside of Coinbase needs to keep track of them.

This is problematic because Bitcoin can't give you any guarantee that Coinbase won't take your Bitcoins, and Bitcoin can't give you any guarantee that Coinbase has enough assets to pay all of their account holders.

Coinbase could publish an audit showing how much Bitcoin all of their account holders are supposed to have, and signed statements showing control of enough Bitcoins to cover those obligations, though.


Can I create a Blockchain copy (up and running) in order to make my own bitcoins transfers without Fee?

Anyone can create their own blockchain, but you will not be able to reconcile your chain with the bitcoin blockchain at a later date (even if you start your chain by forking off from a certain btc blockchain block height).

I don't know what your use case is, but if you're not going to use an already existing blockchain, I would expect that creating a private database (SQL?) would be a better choice than trying to create a private blockchain.

You could, for example, create a database that is designed to mimic the balances of bitcoin addresses you control. Users of your database could freely transfer these 'bitcoins' to eachother on your server, and then only when the user wants to move value to someone outside of your internal system, would you need to initiate an actual bitcoin network transaction.

So the actual bitcoin you control would function as a 'reserve' that your database's value is backed by. This is basically how centralized exchange services work. The users of your system will need to trust you in using it.


Ended up answering my own question! If anyone else runs into a situation like this, the problem is that the code is deriving a non-hardened child key but checking for the hash associated with a hardened child key. According to the BIP32 docs, to derive a child key you hash the private key prepended with a single zeroed out byte and appended with a hardened index (greater than or equal to 2^31). So in this case, I only needed to swap out the public key for the private key, prepend it with a single 0x00 byte, and use the first child hardened integer 0x80000000 instead of 0x00000000.


Why is HMAC-SHA512 used on root the root seed to create master private key and chain code in HD wallets?

I'm willing to bet the 2048 rounds of hashing required by the BIP 39 Standard takes considerably more energy than 1 round of hashing.

Put another way, substantial computing cycles are required to create brute forced Rainbow Tables when lower entropy human readable seeds are functionally mapped to private keys. This is somewhat analogous to the leading hash zeroes values miners satisfy to add blocks to a PoW-based blockchain, except the computing cylces are fixed by mnemonics-to-seed portion of the BIP39 Standard.

The Python stretch can effectively implement the mnemonics-to-seed functionality written into BIP 39.

stretch->passlib.pbkdf2(secret, “mnemonic”+salt, rounds=2048, keylength=64, sha512)

The two two Bitcoin-related examples of piped commands using stretch and bx yield the same result.

% stretch -f sha512 -r 2048 "bunker wreck real edge inflict aerobic buddy mercy divorce wolf bright immune fat foot poet section sustain reveal unique reflect have latin problem chapter" mnemonic123 | bx base64-decode | bx base16-encode | bx hd-new | bx hd-private
xprv9veSXAfA7GoYvaMAXgm3uYGS4VLH1Foc9qmTBRCb4c3F2Vqd261k2vo646nLU54MRVseFx2BbhZYQS9HDUy4dvTV3fygVGxedqYSR82B3he

% echo "bunker wreck real edge inflict aerobic buddy mercy divorce wolf bright immune fat foot poet section sustain reveal unique reflect have latin problem chapter" | bx mnemonic-to-seed -p 123 | bx hd-new -v 76066276 | bx hd-private
xprv9veSXAfA7GoYvaMAXgm3uYGS4VLH1Foc9qmTBRCb4c3F2Vqd261k2vo646nLU54MRVseFx2BbhZYQS9HDUy4dvTV3fygVGxedqYSR82B3he


Does anyone have insight into how Coinbase calculates the number of confirmations for a transaction?

Coinbase allows BTC to become spendable after zero confirmations as long as they are in sync with the BTC blockchain, which they usually lag behind a bit.

The reason Coinbase lags behind the bitcoin blockchain is because their internal node is generally lagging behind the blockchain about 2-4 blocks; sometimes less, sometimes much more. I don't know why, but I imagine it helps reduce fraud with instant buys and maybe the system they use to sync their services with the blockchain gets bogged down under heavy loads..

Coinbase does have a network page (https://coinbase.com/network) that allows one to check the status of the last block seen on their side. Therefore, if it shows "Last block created 57 minutes ago," one can safely assume they are about 5-6 blocks behind the btc blockchain and will take some time to catch up.

It can be quite annoying and cause a purchase to be delayed or cancelled, but by watching the network page, one can make more informed decisions about when to send.


How to verify signature in java using message and public key?

The code you are using to verify the signature is correct according to the bitcoinj-core 0.15.7 library. What may be wrong is the data you are verifying.

When spending a Transaction Output in a new transaction, the entire new transaction (with a few modifications) is signed to prevent malleability. For a simple transaction the "signing type", or SIGHASH, is typically SIGHASH_ALL and is represented by the number 0x01000000 (little-endian). This means that, for every transaction input you sign, the output's scriptSig is placed where the signature would go for that input, all other input signature fields are set to empty, and the SIGHASH is appended to the end of the transaction.

Details for verifying a standard transaction has already been answered, and includes step-by-step instructions: How to redeem a basic Tx?


Transfer Bitcoins From Bitcoin Core To Blockchain Wallet?

Yes. It is possible. To transfer the bitcoins out without synchronising the blockchain, you'll have to create a signed raw transaction and broadcast it with a third-party provider (such as blockchain.info). You can lookup the input from a blockchain hosted on a third party provider.

bitcoin-cli help createrawtransaction


They will either reuse the address in coinbase transaction subsidy output every time they mine a block, and then publicly claim that address, or they will "tag" their name (ascii-encoded) and some metadata in an OPRETURN or the scriptSig of the coinbase transaction.

Here's the coinbase TX from block 603526:

https://blockstream.info/tx/0eb39c3f1a6813dfe5bb9d86dd71de2593aa76f25d4f25b149c9f564eb33cd54

The script sig is

03863509fabe6d6d0f3e894118566fd52beccf2a405c060fb701171dd16d83f1fb4aa0219fa8656601000000000000002469020000535e15a74a1b00000000e6892f736c7573682f

which is ASCII for:

5  z>mm>   AVoU+lO*@\7Qmq{J !(ef$iS^'J /slush/

There's slushpool!


How to decrypt MultiBit private key with 128 bytes line and 52 bytes line?

I found an answer here: Decrypting keys from Multibit
The way Export and limited import of private keys  explained is almost right, but it's missing a parameter, -md md5. I added that and it worked.


Is there a short-form for addresses with seven characters length?

I think what you are mentionning is firstbits. But this practice is now obsolete as it encourages address reuse, which reduces privacy.


Checksum vs. Hash: Differences and Similarities ?

Sometimes these terms are used more or less interchangeably.  Traditionally, a checksum is used to detect corruption and a hash is used to map large elements into slots randomly.  In Bitcoin-land we're often concerned with "cryptographic hashes"  which are hashes that have special security properties.

Things called checksums are usually designed to have certain uniformity properties that make them maximally likely to detect errors.  Things called hashes are usually designed to be very fast to compute and not be too non-uniform.  Things called cryptographic hashes are designed to make it difficult to compute a collision.

The security properties of cryptographic hashes often make them slower and less uniform than functions you would use for cases where the security isn't required.

Generally any function from any of the three groups could be used in any of the applications, the result would just not achieve the security, performance, or reliability that you'd get for using the right tool for the job.


You aren't doing anything wrong. You just need to be able to handle those duplicate transaction ids. It actually happens a few times before BIP 30 went into effect making such duplicate txids invalid.

These duplicates happen because the coinbase transaction in two different blocks can be exactly the same, so they have exactly the same txid. This is because prior to BIP 34, there was not anything that makes each coinbase transaction unique; you could have a transaction which pays out to exactly the same address with exactly the same amount (the block subsidy) and if you don't set a coinbase string or use an extranonce in the coinbase, you will have two identical coinbase transactions.

To handle the two cases where transaction duplication happens, you should allow an exception to the BIP 30 rule for those blocks. The transaction that those duplicate txids reference when being spent can only be the most recent duplicate transaction. Any prior ones are completely unspendable.


This happens usually when your server isn't yet fully loaded, i.e. the executable/binary is started, but is still busy processing (I think loading the wallet and a vital part of the block chain necessary for most basic RPC commands, although I'm not sure). This could take, depending on your wallet size and processing speed, from a few seconds to several minutes in general.

If that doesn't work please comment!


In Bitcoin, any transaction that confines to the consensus protocol is valid. This is unlike other ledger based system like Ripple, where the validators vote on whether the transaction is valid and if it should be included in the ledger. In those ledger systems, the validators gets reward for helping maintain the ledger.
When your Bitcoin full node receives a transaction, your node will check through all the protocol requirements. This includes verifying that the inputs consumed in the transaction have not been spent in the past (i.e. no double spend), there is a valid signature that unlocks the bitcoins, inputs are greater than outputs as so forth. You can find a detailed list of the transaction verification rules here.

Does the Engine verify everything what is coming thru and i just have to pay for Power, Online Time, Memory and so?

That is correct. As mentioned above, when Bitcoin Core will receives a broadcasted transaction, it automatically verifies it against the consensus rules to determine that they are valid. Incorrect transactions are discarded and not relayed to other nodes. You only need to have your machine running with the software and it would take care of it.

Why my Budget didn't move a Single Satoshi up or down

In Bitcoin, only the miners get the block reward and the transaction fees associated with it. A full node's job is to ensure that the block which the miners have mined conforms to the protocol requirement. If say a miner turns malicious and mines a 'fraud' block, the full nodes connected to the network will reject that block and will not relay it further. Other miners also assume that the nodes on the network are honest and do not build further on the 'fraud' block mined. Thus the malicious miner not only loses the block reward and transaction fees, but also has spent his electricity and mining power to waste. Thus full nodes play a very significant role in the Bitcoin network to ensure everybody is acting in an honest manner.


Is it possible to create batches of transactions in bitcoin blockchain?

If you have no trouble with Alice, Bob and Claudia know about each other, you could create a single transaction with 3 outputs, one for each of them. In such case they will all three get bitcoins, or all three would not get bitcoins (because actually it would be 1 transaction, which will get into blockchain, or would not).
sendmany
I can show you the way to make it with bitcoin-cli. For this you'll need full node running on your machine (bitcoind). This node must own your funds (privkeys for accounts with your funds must be in its wallet.dat). If this is the case, then you need sendmany method.
Run:
# Unlock the wallet (If your wallet is unencrypted, skip this step)
bitcoin-cli walletpassphrase "passphrase" 10
# Send all funds to everybody you need
bitcoin-cli sendmany "" '{"2N8hwP1WmJrFF5QWABn38y63uYLhnJYJYTF": 0.05, "2N5zxMH53RX3JLWbV5csmZrAhWY1R7Fr1SA": 0.05}'
# Lock the wallet
bitcoin-cli walletlock

You'll get transaction id as the result of sendmany call:
3a2addb48252889711a74f7e131816c8becfb112910342faefd17a8913ac2de7

(it is real transaction in bitcoin testnet)
To get more info about sendmany method, you can run bitcoin-cli help sendmany, you'll see the list of available params and examples of using it with curl. Or you can go to the official documentation
createrawtransaction
If you have access to bitcoin node, but this node does not have your funds, you can create new unsigned transaction using createrawtransaction  method on the node, then sign this transaction in your wallet and send it, using sendrawtransaction.


getnewaddress on non-descriptor wallets does not work for non-single key things. Ad descriptor wallets have not yet been released, you are not using a descriptor wallet. When you use importmulti to import a descriptor, it does not actually import the descriptor. Rather it uses the descriptor to construct a bunch of keys and scripts and imports them into the wallet. However this does not mean that those scripts will be accessible with getnewaddress. They are just in the wallet as being watched.
You aren't doing anything wrong, getnewaddress just doesn't work like that for non-descriptor wallets.
If you make a descriptor wallet (using one of the 0.21.0 release candidates, or a build of the master branch), then getnewaddress will work as you expect it to.


Ethereum nodes are geth and parity.

Unlike Litecoin and Dogecoin, Ethereum is not a derivative of Bitcoin. Thus, the RPC interface is completely different, and you will not be able to simply point an existing  Bitcoin based system at the ethereum node. You will likely need to rewrite whatever you require to work with Ethereum APIs.


As Bucko commented in August 2017:

  Unfortunately right now there's no way to remove a wallet via the API in bcoin. There is a zap endpoint but I don't think it does anything yet. If you don't care about losing other wallets, you can just delete the wallet db directory from your bcoin directory.


I got a coinbase transaction and I don't know where it comes from

Interestingly, it was a withdrawal from earn.com I made a few months ago which I forgot about. Wondering if they mine on their own.


Does BIP39 mnemonic construction avoid repeating words?

There is nothing stopping a word to be repeated more than once. In a 24 word mnemonic, with 2048 possible words in the dictionary (BIP 39), there is a probability of at least one duplicate around 12.7% of the time (variation of the birthday paradox).


How bitcoin network appends new block in its Block-chain

The math makes it rare for boxes to be solved at the same time. However, Yes it's true. If more than one miner solves the cryptographic hash at the same time can add a block (a group of transactions) which as a result, leads to multiple branches. In this case, you simply build on the top of the first one you received.
Solution The tie gets broken when someone solved the next block. Because The general rule is that you always immediately switch to the longest branch available. The end result is that the blockchain quickly stabilizes.
So, the transactions of an ignored block of a small chain, go back to the unconfirmed transaction pool and be included in a later block.


I'm doing something similar but using segwit addresses (BIP49). If you are using BIP32 with a standard derivation of m/0'/0/0 you could do something like this - See: https://github.com/bitcoinjs/bitcoinjs-lib/blob/master/test/integration/bip32.js#L35

//get a mnemonic, then seed, then root.
var mnemonic = bip39.generateMnemonic();
var seed = bip39.mnemonicToSeed(mnemonic);
var root = bitcoin.HDNode.fromSeedBuffer(seed);

//root can be transformed to your xpub and xprv
var xprv = root.toBase58();
var xpub = root.neutered().toBase58();

//You can then create the address with a derivation of m/0'/0/0
var change = 0; //0 for external (receive), 1 for internal (change)
var index = 0; //the index of the address you want to generate
var keypair = root.deriveHardened(0).derive(change).derive(index);
//or keypair = root.derivePath("m/0'/" + change + "/" + index);
var address = keypair.getAddress();

If your derivation for your addresses is m/0' (then external, then the index) Then you have the xpub for the parent m and can store xpub of m/0'/0 on the server. On the server when a user clicks the button it generates the address n/0, where n = your xpub of m/0'/0.


How did they generate these vanity addresses with 27 predetermined characters?

Your observation is correct and indeed those addresses cannot be generated by vanity address generator in a reasonable amount of time.
Most likely, there is no secret key corresponding to that address and the person chose the p2pkh(and thereby the address) directly. Indeed, by looking at the explorer, there seem to be no outgoing transactions from that address.


how to avoid deposit fees / transaction fees when buying bitcoin

Coinbase has a much larger limit if you verify yourself.  For instance, on Coinbase I have $5000/week limit.  And I belive you can get up to $1M limit with enough paperwork.

Bitfinex offers a .1% fee or $20 (whichever is higher) so for $3300 that would be .6% fee with the $20 minimum.  For $300 though, that's 6.6%

I'm not sure where you get $11.51 for $300 at CB.  I just attempted to buy $300 and it was only going to charge me $304.47, which is a 1.49% fee.  There's the same 1.49% on a $5000 purchase.  They do have a minimum, which appears to be $0.99 < $50, $1.99 < $100, $2.99 < $202, and after that it's 1.49%

EDIT: Oh, I see.. You're talking AUD, not USD.  Not sure what the rate is there.  FYI, in the future it's best to specify currency symbol if you're talking about Dollars and not USD.

According to this page:

https://support.coinbase.com/customer/portal/articles/2109597-buy-sell-bank-transfer-fees

3.99% is the base, but in the US they wave some fees depending on the payment type.  It appears that in AU they only allow Credit Card purchases, and not wire or EFT.  That kind of sucks for you.


Using the bitcoin wallet PKI for message encryption

The cryptography Bitcoin uses for wallet private keys is ECDSA, using curve secp256k1:

http://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm

It is for signing messages, and does not useful for any method of encryption.

There are other methods of encrypting and communicating a message, ... Gli.ph, BitMessage, GPG/OpenPGP, and more.

If you trusted the party you are sending funds to, that party could use the message signing capability in the client to sign a message that tells you what GPG key to use in encrypting a message to that party, for instance.  That would give you the assurance that you are encrypting a message truly only readable by the party that has control of that Bitcoin address and signed the message.


How to backup seed in lightning and give your channel to watchtower

For clightning I have created a video that explains how to restore your node with seed and state you can watch it here: https://youtu.be/-S7pQOw36vI

The general idea is that hsm_secret sites your seed in binary and the sqlite3 datebase sites your channel states.

I believe in lnd the process would be similar only that they give you the seed words explicitly instead of hsm_secret. They should also have some database or file in which they site channel state.

As for watchtowers. Currently to the best of my knowledge there are no such services available.


How Bitcoin nodes validate a new wallet

They don't
Bitcoin nodes validate blocks and they validate the transactions within those blocks
Other nodes don't have access to your wallet and can't validate it or anything in it.

I mean, what if this wallet already exist?

No one knows or cares if the private-key initially generated by your wallet already exists. Nodes don't check for this type of "collision".
If someone else's wallet has the same private key, either of you could spend each-other's money as well as your own.

if I create an address offline, how Bitcoin nodes would accept my address as valid (or this isn't needed?)

Any address is accepted so long as it looks like an address. A well-formed address has an acceptable length, initial bytes and checksum.

I mean, in which moment, Bitcoin nodes accept my offline-created address.

each node accepts it at different moments. In whatever moment they happen to come across the address and see that it is a well-formed address.

how this address appear in this web?

A correctly generated well-formed address that has never been used and consequently never appeared in the blockchain is nevertheless a valid address. I expect most blockchain explorers would simply display it and show that there are no transactions associated with it.

In summary, no one keeps track of wallets, private-keys and addresses that have been created and never used. All of these are just as valid as a wallet, private-key or address that gets used a thousand times a day every day of the year.
There's a vast ocean of numbers,  they are all valid. Some have been used, some not yet, almost all  will never be used.

See also

Can Large Bitcoin Collider break into the wallet which is created by new version of Electrum?


What do you think about "squashing" the blockchain?

Running a full node allows a user to independently verify the state of the bitcoin network. In order to verify the state of the network, the full node will run through every transaction in every block, and this is only possible if the full node has access to all of the data that comprises the network's history.
If you 'squash' (compress) this information, then the necessary verification cannot take place. Given a compressed piece of data, it does not seem possible to verify the validity of the uncompressed data (according to whatever rules), without having the uncompressed data itself. So instead you would need to trust that someone else had verified this data before it was compressed, and doing so would be counter to the goals of the bitcoin network (ie allowing every user to independently verify the network state).
Further, the blockchain record is not well-suited for compression.

Throw away adresses with a balance of 0
Create a new genesis block containing all adresses that have a positive balance

The bitcoin network does not keep track of address balances, it keeps track of UTXOs.
Note that you can run a full node with pruning enabled, so that old blocks will be discarded from your local storage after verification has been completed.


What reasons are there to mine and support Litecoin?

This is simply my opinion on why I get into altcoins. I like to diversify my portfolio. In my eyes any one currency could overthrow another currency.

What I usually do is mine a decent currency, then use that currency to invest in certain things. For example and this is simply an example and I'm not using it to spam. I would mine litecoin then spend my litecoins on hashing on CEX or BleuShares or something else. This starts to make me stronger and gives me more.

I also sometimes buy metals such as gold and silver with my crypto currencies. But I'm a firm believer of diversification.

There was a twilight zone episode where theives steal gold and sleep for 100 years to find out gold can be manufactured in the future and the gold was worthless. I don't see such things happenning anytime soon, but it is nice to not put all your golden nuggets in the same basket.


how to get one address from two public keys?

I answer my question for the benefit of future generations of readers.

If you have only one 33-byte-long public key, you obtain an address by applying a standard technique that consists of 5-7 steps, depending on how you view the technique.

If you have more than one 33-byte-long public keys, you have to construct a so-called redemption script or, in bitcoin parlance, redeemscript. After you’ve constructed the redemption script, you apply the standard technique to the entire redemption script.

Technically, a redemption script is a byte array. Suppose you have two public keys. Conceptually, your byte array should look like this:

[OP_1][length of public key 1][public key 1][length of public key 2][public key 2][OP_2][OP_CHECKMULTISIG]

In my question, I said that I had parsed the input script of a transaction. Therefore, I didn’t have to construct the array. The redemption-script array was already in the input script. I made a “mistake” of extracting the public keys from the redemption script, believing I should massage only the public keys. I should have taken all the bytes of the redemption-script array.


What would happen if two miners were mining two blocks with two different set of transactions?

No, each block must reference it's predecessor block in the header, and the blockchain has only a single block at each height. The second miner must therefore modify the block template that they are mining with to build on top of the just discovered block. They need to update the hash of the predecessor block and the blockchain height in the Coinbase transaction. Otherwise the block they would be finding would be competing with the just published for inclusion instead of writing forth the blockchain.

The rest of the block template could stay the same, if none of the transactions got included in the blockchain already.

However, your question sounds to me like you're thinking that searching for a block has progress. Mining is a progress-less process, each attempt may or may not succeed independently. Thus, it would be a more profitable strategy for each miner to try including the juiciest transactions (by highest fee rate) and to switch to a new block template whenever a block is published with the new juiciest transactions.


Where are the blocks in the blockchain stored?

Since it's unclear what context you are asking in:

The blockchain is stored, distributed, on every machine in the Bitcoin network being used to mine Bitcoin.

This network is self-regulating and peer-to-peer. There is majority rule, meaning that if one node on the network no longer agrees with the other nodes (on, say, what the hash of the last block was), it is kicked out of the network and will have to "resync" its data to be in agreement with the network.


What are the best criticisms of blockchain technology?

Decentralized technology is inherently more inefficient than centralized tech. In Bitcoin this expresses e.g. in the difficulties to implement Scalability and the Proof of Works energy consumption.

The other most prevalent criticism I've read is that there is no central instance in Bitcoin to dampen value swings. The predetermined rate of money creation does not leave any option of steering the money supply. While this is something many Bitcoin advocates like about the project, citing the patchy performance of central banking in the past, the resulting volatility is frequently listed as the most important design flaw of Bitcoin.


Cannot Making Outgoing Payments with blockchain.info API v2

https://github.com/blockchain/service-my-wallet-v3/issues/108
Please update your API version and see the link.


The x field is not the time that of each transaction they received. x is a date is unix epoch time and y is the number of transactions that were received during that day. Since you probably exported the number of transactions for the past year, you got 365 days of data so your count of xs results in 365. But that is not what you want, you want to sum the y values.


Which is the relation between transactions and blocks?

The initial statement is correct. The blockchain is the list of all solved blocks, essentially the ledger of all transactions completed in the Bitcoin network. Each block contains (among a few other things) a list of transactions.

When you do a transaction, it is not destined for a specific block. You merely publish your transaction to the network and it goes onto the list of unconfirmed transactions. (There is actually no one authoritative list, however, everyone on the network keeps their own list and distributes it to others to whom they are connected.) Miners (who solve the hashing puzzles required to "solve" a block and make it official) will typically include all unconfirmed transactions in the blocks they create. But they may not. They may just not have received your transaction in their part of the network yet. Or, if your transaction didn't have a fee included, they may only be willing to process transactions with fees. Technically, they are under no obligation about which transactions to include in the block. But since miners get fees from many transactions, and miners benefit from the strength of the Bitcoin network, transactions are typically quickly included in a block.

To answer your second bullet, yes, an unconfirmed transaction is one that has not yet been included in a block.

And to answer your final bullet, no, new transactions cannot be added to older blocks. The "solution" to a block is a mathematically hard puzzle to solve, and it is based on the transactions that are included. So, if you added a transaction to an older block it wouldn't be the same block any more. And the "solution" wouldn't work either, so it would essentially have to be re-mined.

And to further complicate adding a transaction to an older block, each block also includes a piece of information from the previous block in the block chain. Meaning that if you added a transaction to an older block (or modified it in any way), you would not only have to re-solve the old block, but you would have to re-solve all blocks between that block and the current block. And since no one would recognize your re-solved blocks unless you were able to create an even longer blockchain than what currently exists, it isn't realistic to be able to do so. You would have an extremely large amount of processing to and you would have to solve it considerably faster than the rest of the world was working on the old block chain. (The exception is if you have more mining computing power than everyone else in the world combined. This is sometimes called the 51% problem.)

This is all by design. The point of the block chain is that the history of transactions is unalterable and mutually agreed upon as the truth. If it were possible to add transactions into the past, you could change that history. And, for example, spend the same bitcoins twice. But because of this chaining of bitcoins that isn't possible. (It is also why most people don't consider a transaction final until it has "6 confirmations". What "6 confirmations" really means is that the block that it is included in is 6 deep in the block chain. At that point the block chain is deep that it is considered completely unalterable.


Calculate fees with Blocktrail/btc.com SDK

I am not sure as have not used their api system but it could be down to the format of your bitcoin address you are passing in.

66f4dec6ab29cd056ce1814c6fdfee05e1524b36 is read as a valid bitcoin address using this service

However when I search that address under a block explorer I get the following address which starts with the more common 1 1APPGSyMsPaBUAHtjEm6tPqV9U54JRzmd6

66f is not a start of a bitcoin address i recognise, though there are many out but no mention on the wiki

Thus I would suggest trying your code with the more common bitcoin address format

$FEES = $wallet->coinSelection(\Blocktrail\SDK\Wallet::normalizeOutputsStruct(['1APPGSyMsPaBUAHtjEm6tPqV9U54JRzmd6' =>'100000']),false,false,\Blocktrail\SDK\Wallet::FEE_STRATEGY_LOW_PRIORITY['fee'];
echo "$FEES";

And see if that works


How to send zero fee bitcoin transaction

Bitcoin Core and a number of libraries that facilitate building transactions will allow you to create a zero fee transaction. The problem is that most nodes on the network will not relay transactions with a fee rate below the minRelayTxFee (1 satoshi/virtualbyte). Additionally, most miners don't include transactions below the minRelayTxFee in their blocks.


How would one "Encrypt" a message using a Bitcoin *public key* and use its private key to decrypt it?

Yes, this is possible.

However, I want to upfront state that this is not advisable for multiple reasons:

Bitcoin keys are intended to be single use for privacy reasons, and leveraging them for encryption unnecessarily encourages treating them as a long-lived identity.
There may be ugly and dangerous interactions when keys are used for multiple protocols independently.
You're much better off using systems that were actually designed for encryption than trying to piggy-back off Bitcoin's cryptography.
Implementing your own cryptography is very dangerous (in general, unless you know what you're doing, and get plenty of review from experts).

A scheme called ECIES exists that lets you leverage elliptic curve keys to create an encryption system.

In short, it works by:

The sender:

generates an ephemeral private key k using a strong cryptographic random number generator, with associated public key k = kG (multiplication refers to Elliptic Curve multiplication here).
computes an ECDH shared secret s = H(kP), where P is the public key of the recipient.
computes two symmetric keys x1 and x2 using a KDF seeded by s: (x1, x2) = KDF(s).
encrypts the message m using AES, with x1 as the key, to obtain c = AECEncx1(m).
compute a MAC on K and c with x2 as key: h = MACx2(K || c).
sends (K, c, h) to the recipient.

The recipient:

computes the ECDH shared secret, using s = H(pK), where p is his private key.
computes the same two symmetric keys x1 and x2: (x1, x2) = KDF(s).
computes the same MAC h' = MACx2(K || c)
verifies that h' = h, and fails if not.
decrypts the message using s, m' = AESDecx1(c).


No inputs found when using Electrum to sweep private key from Bitcoin Core

Your coins are likely in a change address. You could do a dumpwallet in bitcoin core and then sweep all the private keys. But this is going to be slow going in electrum and you're going to have to do it in batches. Instead I suggest extracting the addresses which have unspent outputs in them by using the listunspent command in bitcoin core and then sweeping only those addresses' private keys. You can also do this via the cli and then use standard text processing commands to extract the addresses (jq, grep). To get it via the cli run bitcoind -daemon and then use bitcoin-cli listunspent


sendrawtransaction RPC format across core versions

sendrawtransaction takes transactions in the network serialization format. There is a new network serialization format for segwit transactions, so such transactions would be broadcast in one format for 0.12 and a different one in 0.15. If you are not making segwit transactions, then sendrawtransaction has not changed and you can use it in 0.15 as you did with 0.12.


Good informational material on BTC trading? Market vs limit?

Investopedia.org is good, in general.

To answer the other part of your question (Market vs. Limit):

A market order is an order that will execute at whatever the current price is (no matter what - so be careful).  A limit order is an order that will execute only at the price you specify (or better, so it's much safer).


Can you give me an example of a wallet address

Yes.

Bitcoin:1GVY5eZvtc5bA6EFEGnpqJeHUC5YaV5dsb

Some Bitcoin addresses start with a 3. It is pretty much a 3 or a 1.

Before making transactions, always ensure that you are sending to and from a correct Bitcoin BTC address. There are other similarly named altcoins which have different symbols (not BTC) and those transactions do not work and Bitcoins will be lost. Sometimes the altcoin addresses even appear to be the same as a Bitcoin address. You really have to make sure both parties are dealing in proper Bitcoin BTC.


Definetly! Dogecoin uses the Scrypt algorithm so that means any Litecoin tutorial can be used as a drop-in replacement tutorial. Just be sure to use the proper pool address and port.

A google search brings me this nice looking guide:

Debian 6.0.7 - GPU Miner install guide


Is there a difference between "In" and "Out" peer connections?

No, connection directionality doesn't affect peer behavior in Bitcoin P2P at all. The same rules for relaying inventory, and punishments for misbehavior apply to both. The software will avoid making outgoing connections to peers in close proximity in the IP address space to one another, but this does not apply to incoming connections where many connections from even the same IP address are allowed.


To get the master private key of HD wallet

go to help-> debug window -> console

Enter:

walletpassphrase "your walletpassphrase here" 60, to unlock the wallet if its encrypted.

dumpwallet  "filename", will crate a plain text file in same directory where your wallet .dat file is form which you can get your xprv.

walletlock, to lock your wallet

Don't forger to erase the file after you get the info. Also if u change your wallet password the xpri will change.


I'd like to partially answer your question on the tx structure: in general you are right, here some more detail, and yes, you can have several TX_INs and TX_OUTs:

VERSION
TX_IN COUNT
  TX_IN[0] OutPoint hash
  TX_IN[0] OutPoint index
  TX_IN[0] Script Length
  TX_IN[0] Script Sig
  TX_IN[0] Sequence

TX_OUT COUNT
  TX_OUT[0] Value/Amount in Satoshi
  TX_OUT[0] PK_Script Length
  TX_OUT[0] pk_script
 LOCK_TIME

So in general the VERSION field at the very beginning and the LOCKTIME at the end is an additional piece. For sure you find further details in the developper section of bitcoin.org, and in Andreas' book "Mastering Bitcoin" (also online available). Avery good overview of the details was also provided here: http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
I am not experienced enough to answer the part on the blocks, but it is also mentioned in the links.


http://www.highcharts.com is pretty good (Blockchain.info uses it). Charts can be rendered both client and server side which is useful for png previews.


What is the difference between bitcoinj and BitsOfProof?

There are lots of differences in features supported, but the crucial difference is the architecture: Embedded vs. Client-Server Bitcoin Protocol Node and Wallet.

BitcoinJ is a Java library to embed a Simplified or Full Verifying Bitcoin Node and a Wallet into your application.

The Bits of Proof Enterprise Bitcoin Server is a configurable Full Verifying Bitcoin Node written in Java. The server process is accessible through a message bus for client applications and extensions. Several layers and flavors of client libraries are available, such as: STOMP, Java, REST. The Wallet is implemented in the client library, therefore a server process can serve several unrelated applications and distinct Wallets. Several server instances might run in a load balanced configuration serving clients through a common bus. The company Bits of Proof offers commercial support and hosts server instances.


what is the mathematical problem in each block which is difficult to solve?

That difficult mathematical puzzle is finding a block that can legally follow the previous block. To follow the previous block, a block must meet a set of requirements. First, it must contain the hash of the previous block. That means you can't even start solving the problem until the previous block is found.

The key one is that the hash of the block must meet a target. For example, the hash of a recently-found block is:

000000000000000049f4701e8ac6dc62abd4a951363535697f1553963429a28e

Notice all those zeroes at the beginning? You would have to try quadrillions of candidate blocks before you find one with a hash with so many leading zero bits.


See here for an example of a #define configuration. You may then search for those macros in the repo to see their alternatives and define the relevant ones before you #include "src/secp256k1.c"

I can't seem to find any documentation or walkthrough guide on simple usage of the library

This library is not meant for use as a single header, as explained in the README.md:

Expose only higher level interfaces to minimize the API surface and improve application security. ("Be difficult to use insecurely.")

The conventional way of using this library is compiling it and calling the linker when you compile your code with libsecp256k1.a for static linking (You may do gcc your-code.c libsecp256k1.a)
However, I used the library once with an #include only a long time ago, without any problems. That works, and as I described at the top, you just need a few #defines.
secp256k1.h is self-explanatory. You might want to read it all similarly to reading a story. Then you should be able to find the relevant functions.


Are the bitcoin miners decreasing in quantity and increasing in size?

The difficulty is not rising exponentially, but it does keep going up.

Bitcoin miners have definitely gone from a large group of small miners to a small group of big miners.

In 2010 GPU (graphics card) mining made it hard to mine on CPUs. Sometime 2011 CPU mining became pointless. This meant office PCs could no longer take part in mining. Intel graphics (built into Intel CPUs) and Nvidia were both pretty bad at it. So it really meant mining was now only for gaming PCs with AMD graphics.

In 2013 Bitcoin ASIC (application-specific integrated circuit) miners appeared. Sure, some mined on FPGAs before this, but FPGAs didn't make that great an impact before ASICs arrived and killed off both GPU and FPGA mining. Now bitcoin mining was only for people who bought specialized bitcoin mining hardware.

In 2009 anyone could mine 50-100 bitcoins per day on an old laptop. After the transition to ASICs in 2013 you couldn't mine without specialized hardware.

This has greatly reduced the number of people who are able to mine.

Competition is also getting very fierce and margins are slim.

Some miners design their own ASIC chips and build their own miners with these chips. If you buy your miners from them, how can you compete on acquisition cost of miners?

Some miners have special deals with their power company. Can you get electricity cheap enough to compete?

Some say Bitmain uses Asicboost, which gives them a huge advantage. The only way to compete with Asicboost is to use Asicboost. Do you have a setup capable of using it? Will you risk a lawsuit? Yes, strangely someone has a patent pending on this simple software optimization.

Some mining operations are in very cold places like Iceland. Cooling is probably more expensive for you than for them.

The fiercer the competition, the fewer are able to stay in the game.

I wouldn't call this a bottleneck. But it is a security risk. With the majority of hashrate in China, the Chinese government can 51% attack bitcoin. Bitcoin scalability may also have been achieved more easily without huge mining entities that can veto every proposal to improve bitcoin.


If you don't possess and control the according private keys, you don't "own" Bitcoins. Maybe you have a right to access and transfer your Bitcoins and maybe legally "you own them", but not technically.

If you have sent BCH to a BTC address, then, only the according private key of that BTC address could help you sending your BCH out of the accidentally used BTC address.

Either you import that private key into a BCH wallet that supports importing private keys or you directly create and sign a raw transaction (experts only).

Blockchain.info could easily do that for you, but I don't expect that highly centralised services will have the man-power to follow such support inquiries.

Also, they could collect the accidentally sent BCH (don't I don't think they do).


RPC server with bitcoin-qt and bitcoind has a different set of commands?

Just discovered the problem. It has to do with the "wallet" being disabled in the code via the default configuration with my package management.

I investigated the source initially and saw that there is a bunch of commands that are only enabled if the wallet #define is enabled: https://github.com/bitcoin/bitcoin/blob/e18bc583d41d97cdab93b7ffd111402628cfba19/src/rpcserver.cpp#L268

From there I was able to work out that the build options has disabled the wallet. I'm on Arch Linux, which the user-contributed package (on the AUR) has been configured to disable the wallet by default.

In other words, PKGBUILD configuration has added --disable-wallet to the  ./configure arguments as you can see here: https://aur.archlinux.org/packages/bi/bitcoin-core/PKGBUILD

As if the time of posting, the ./configure command is:

./configure \
    --prefix=/usr \
    --sbindir=/usr/bin \
    --libexecdir=/usr/lib/bitcoin \
    --sysconfdir=/etc \
    --sharedstatedir=/usr/share/bitcoin \
    --localstatedir=/var/lib/bitcoin \
    --enable-hardening \
    --with-gui=no \
    --disable-wallet

Modifying PKGBUILD by hand to remove the --disable-wallet argument fixes the problem.


Algorithm to recover missing 12th word (of 12) in BIP39 mnemonic

You will have to check up to 128 variants. Try this software: https://kzen-networks.github.io/mnemonic-recovery/src/index.html


Difference (if any) between proof-of-work in mining bitcoin vs verifying transaction

I think I understand why proof of work is needed to verify
  transactions (essentially to prevent spoofing/double spending etc).

This is right.

  the proof of work for verifying a transaction is the same as for
  mining a new bitcoin

This is right too.

  if this is the case, then it becomes harder and harder to verify
  transactions.

It depends it can become harder as it can become easier. But whatever happens there is no issue with that.

Explanations:

The miner generates blocks which header have the lowest possible sha256 hash until he finds one which sha256 is lower than the Target. This block will be valid and can then be included in the blockchain. Inside of the block the first transaction is different from the others because it hasn't a valid input and it has as transaction output an address controlled by the miner. This address will receive the block reward(new bitcoins that are generated with the block) as well as the transaction fees of
the transactions that were included in the block.

Now actually it's true that generating new blocks become more and more difficult because there are more and more miners with more and more sophisticated mining material.
This is why the target becomes more and more lower in order to maintain an average time between each generated block of about 10minutes.
But if miners will start to stop mining bitcoin the target will increase and mining will become easier again.

This post will help you to understand a little bit better what are the different components of a block.
Bitcoin: 285 bytes that changed the world


https://bitcoin.co.th/trading-suspended-due-to-bank-of-thailand-advisement/

The short version of that article direct from Bitcoin is...

Do not send/receive/mine Bitcoin if you are in Thailand.  Do not buy/sell to any one where the receiving/sending wallet is in Thailand and/or the product (virtual or real) is sent via Thailand.  Currency laws have not caught up to virtual currencies and how ( if it can be done ) it can be taxed. Bitcoin, as a group, has decided it is in the best interest of the virtual currency to try and stop trades to/from that country and ask people there to not mine ( it is really hard to stop someone from logging in to a pool and mining if they want to )

Bitcoin Co. Ltd. has currency exchange applications currently pending review with the Bank of Thailand


You need to buy bitcoins on MtGox using another currency. These bitcoins will show up on your MtGox account.

You can then withdraw these bitcoins from your MtGox account to your own wallet. You can find this under Funding options > Withdraw funds > Bitcoin. Enter the address your wallet gives you and MtGox will send your coins to that address so that they show up in your wallet.


What is the maximum number of output addresses I can send to with one bitcoin transaction?

Today the modern Bitcoin-qt client does not relay transactions with more than 200 outputs. But this is not protocol restriction. You can create transactions up to 100k size, which gives you 2500-3000 outputs (try to count the exact number yourself).

For example, tx https://blockchain.info/tx/0313e6552a5337de92c475c0dbbb0e351a1525b0f202beb9d4c75b3a5b114bf3 has 2501 outputs and was successfuly mined 3 days ago


How do I cancel my BTC transaction (Unconfirmed for 5 hours)?

There's not really anything you can do, other than wait. If the transaction isn't confirmed within ~72 hours of sending, it should be dropped from the mempool ie. returned to sender.

The reason your transactions isn't getting confirmed as fast as you're used to, is because the network is a little congested at the moment. It can only handle around 6mb per hour, and currently there's a backlog of around 35mb.


Is Bitcoin mining profitable on a 8 core, 32 GB server with unused capacity?

No.

  I used http://www.coinish.com/calc/ but it does not have anything near to my hardware specs.

Expect 2-4MH per core. 38MH/s for all eight is all but useless. Maybe 80c a month, if that.

  with 1BTC=$1200+ the scenario must have changed a lot ?

No.

  Secondly, can I use multiple servers and computers to work as a farm towards the common goal of mining bitcoins working as a team and will this help achieve the goal of profitability.

No.


It's hosted at github.

Downloads are here.

It's open source, so you can check the code to see how safe it is.

There's an old but still active thread on the bitcointalk forums.

It looks like the program is java code and so doesn't need compiling for OSX, and also that there's a script DiabloMiner-OSX.sh that runs it on OSX.


If they wouldn't validate it, they aren't participating in Bitcoin anymore, i.e. they wouldn't see new payments confirm.


Why would Mt. Gox's Open Transaction method still require six confirmations?

I think it's as simple as MtGox waiting for 6 confirmations before accepting bitcoin deposits to your deposit address, no matter where they've come from.

If you want instant transfers, don't use "open transactions".

We can try to make up reasons to try to make this policy make sense, but ultimately they make the rules and we act accordingly.


Can an unconfirmed transaction that only Blockchain.info shows be manually re-broadcast?

Old question, but answer might be helpful for someone.

To get a raw transaction append:

?format=hex

to the transaction URL.

For example:

https://blockchain.info/tx/1b087a7aebdd06740bd4ffefba076562b582a97f02cedf2cd32f53f7eb0b3c8c?format=hex


Why can addresses be shorter than 34 bytes?

Yes there can be multiple leading '1' characters, and each '1' represents one leading zero byte. This leads to a shorter address because normally each base58 character represents slightly less than 6 bits of information, but a leading zero byte contains exactly 8 bits of information.

For example the shortest address you can have is 1111111111111111111114oLvT2 (representing 160-bit hash of 0000000000000000000000000000000000000000). It has 21 leading "1" characters representing exactly 21 leading zero bytes (the hash prepended by another 00).


This is due to the "version" byte and the way bitcoin addresses are made with base58.

The procedure is pretty straightforward:

the version byte
the RIPEMD160 of the SHA256 (known as HASH160) of the sec format of the public key (don't worry too much about this part, just know it's 20 bytes long)
the checksum (4 bytes long)

Concatenate these and you have a 1 + 20 + 4 = 25 byte string which then gets encoded into a base58 string to form the bitcoin address. Note that parts 2 or 3 can be pretty much anything, but the version byte is specific to the network.

For your case, the version byte of testnet is 0x6f.

The documented procedure for calculating base58 is here.

Here is a simple python program to demonstrate how this is done:

alphabet = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
def b58(x):
    a = ""
    while x > 0:
        x, r = divmod(x,58)
        a += alphabet[r]
    return a[::-1]
print b58(0x6f0000000000000000000000000000000000000000)
print b58(0x6fffffffffffffffffffffffffffffffffffffffff)

The result of this program is this:

mfWxJ45yp2SFn7UciZyNpvDKrzbhuzkU7H
n4rZHAPGXCu8bYchjzJhK3V7VVredELJRc

That is actually the range of possible addresses within testnet. This is because anything before mfWxJ45yp2SFn7UciZyNpvDKrzbhuzkU7H would result in the first byte being 0x6e and anything after n4rZHAPGXCu8bYchjzJhK3V7VVredELJRc would result in the first byte being 0x70. Running vanitygen should confirm:

$ vanitygen -T mfWxJ3
Prefix 'mfWxJ3' not possible
$ vanitygen -T mfWxJ4
[...]

It's important to keep the version number in mind when generating vanity addresses for this reason.


Created genesis block and set up node. How to mine?

If it's predetermined that 80,000 blocks remain, it sounds like you haven't cleared out the checkpoints.

It's been awhile since I looked at anything other than Ripple or Nxt, but you should be able to find the checkpoints by simply searching for "checkpoint" in the code or the assert()s.

Also, to keep yourself from interfering with the original BlackCoin, you might want to use another port.


Mtgox account verification pending, how to withdraw my bitcoins?

all the new accounts created since a few months have to be verified for any withdrawals, including bitcoins, as stated in a big warning on every page of mtgox :

"Attention Users: All withdrawals and deposits require account verification."

so yes you ll have to wait for your verification to be processed before you can withdraw anything.

the delays seem to be around 5-6 weeks, so . ..  if you already waited one month you should soon get an answer, you will  receive an email when your verification is processed.


If miners switched to random pools every hour, would it help the network?

Would this be beneficial for the network as the hash power is now randomly spread out?

The network itself would not really directly benefit, because the total hash rate remains the same, pools are just a secondary construction. Better distribution of who controls the hash rate, though, is good for the long term health of the network in terms of centralization (either in terms of more even distribution between existing pools, or more pools). If a lot of miners were part of a single large pool, the owner of that pool would be able to perform a 51% attack.

So no, randomly switching is pointless, but choosing a smaller pool to join and stick with is a good idea to help distribute the hashrate better.

  Would this also benefit the miner as they now have an increased luck % on finding the next block with the random pool?

No, you have the same probability of finding the next block no matter what pool you are connected to, because the only thing involved in finding a valid block is the number of hashes you can try.


Why is MTGOX's Price/Bitcoin higher than most other exchanges?

It is because it is more expensive and has delays longer and more unpredictable to get $USD out of MtGox, and because they are facing regulatory and lawsuit problems.  US branch of MtGox, known as Mutuum Sigillum, may bankrupt or get more assets seized. Simply put, a dollar at MtGox is not worth as much as a dollar elsewhere.  MtGox is more accessible/less risky in markets outside US where demand is greater.

There is "friction" moving money between bitcoin dealers; delays, charges, fees, etc.  Arbitragers keep price differences for bitcoin fairly close to the sum of fees, but don't move until they are sure of a profit -- and the price is volatile, so they must account for risk due to the delay between selling in one place and buying in the other.  Delays with MtGox are so unpredictable that arbitragers are very cautious.


why is the header for the JSON RPC interface text/plain? vs application/json?


MuSig is interactive because each signer needs to provide a signature nonce (effectively randomness) before signing. This is not specific to MuSig, but applies to any discrete logarithm-based multisignature scheme as far as I know.

Now to understand why multiple communication rounds are necessary let's look at what happens at each of them, starting from the last, the third round:

Round 3 Every participant creates a partial signature with their secret key. The sum of the partial signatures is the final signature. In order to compute the sum the signers must send their partial signatures. That's one communication round.
Round 2 In order to create a partial signature, the signers have to compute the hash of the combined public nonce R. This is the sum of the individual signer's nonces R_i. The nonces are somewhat similar to public keys in that they are random points whose discrete logarithm is unknown to everyone else Broadcasting R_i is another round.
Round 1 The reason for the first round is the most difficult to understand. If the signature hash would just consist of the sum of R_i's then an attacker would have control over the outcome of the hash function. For example, the attacker could first collect every other signers R_i and then choose his R_j such that the hash output is odd. This specific example would not be helpful to the attacker, but what he can also do in a similar way is to mount a Wagner's attack which results in signature forgery. This is why in the first round, the signers send a commitment (for example SHA256(R_i)) of their nonces. Therefore they have to choose their nonce before seeing the other nonces, because they will only be revealed at round 2.

While this is a relatively intricate dance where quite a few things can go wrong, our implementation in libsecp256k1-zkp should be misuse resistant provided that you

Never reuse a session id. The id can be the output of a cryptographic random number generator or an atomic counter.
Never copy a signing session state. Otherwise, nonces will be reused which results in a direct leak of a secret key. Also, it allows active attacks, such as Wagner's attack.

Now it should be easy to see that offline signing is difficult with MuSig. Before shutting down the signing device you need to store active MuSig sessions on a persistent medium. That's effectively a copy of the state and very dangerous. You need to be sure that you load the correct session state when powering up again and not a corrupted or old or wrong session. For that reason, the libsecp256k1-zkp implementation does not support serializing the session state right now. However, there are some ideas for how to design a serialization format that is maximally misuse resistant.

Another aspect is that nonce commitments can be safely "pre-shared" before a message is known. That means that when setting up your offline signing devices, you start multiple sessions in parallel and exchange the nonce commitments. Then, when you want to sign a transaction, you only need to go there twice, first to get the actual nonce and then to get a partial signature. If you have only one device at a remote location you can make it so that you only go there once (by having all other decommitted nonces ready when you go there). It's important to note that as opposed to nonce commitments, nonces can not be pre-shared because that would allow yet another Wagner's attack.

There is research in progress to effectively remove the nonce commitment round and the whole session state with zero knowledge proofs. This is exciting for the offline signing case, but of course also brings increased implementation and computational complexity.


how to free up disk space after running bitcoind for the first time?

Find the data directory: https://bitcoin.stackexchange.com/a/11210

Create a file named "bitcoin.conf"

Add
    prune=550
to that file.

Restart Bitcoin Core.


TXID is the double sha256 hash of the signed transaction, used to uniquely identify a particular transaction.
When you create/sign a transaction that hash will be generated with your transaction.


The Hash256 is essentially a uint256.  However, after reading through much of the wiki and source, it appears that the Hash256 type is meant to be a generic, unsigned integer type that can store any form of hash that is larger than 128 bits.

As an example, all hashes mentioned in the Tree Formats portion of the wiki are stored in Hash256 fields.  Some are 256-bits (I think?) while other mentioned hashes are 160-bit hashes that are padded with 0's.

As an aside, I also noticed that when working with 256-bit hashes, Ripple often uses the first 256-bits of SHA-512 hash.  This is different than the typical SHA-256 hashes that are used with Bitcoin and most other alt-coins.

NOTE: I know that a few of the Ripple devs participate in this site.  I would be greatly interested in their input.  The wiki and the source is quite cryptic in design-- almost obfuscated.  I had to follow quite a few rabbit trails to come up with the answer that I've provided.


Is it smart to just create wallet and then delete it, writing down the address?

If you only generate a limited set of addresses before you delete your wallet, it is likely you will run out of fresh addresses to receive funds on, meaning multiple spendable transactions will be linked together via the receiving address. This is a privacy disadvantage.

Secondly, your mnemonic key phrase back-up follows an off-chain deterministic key derivation standard (BIP32/43/44), and even if all consensus rules do not chain, there is no guarantee that wallets continue to implement the same key generation method that they currently do (depending on your timeframe). If you cannot use a wallet application with the same key derivation standard later, you will have to derive your used keys yourself using the BIP32/43/44 standards.


Links for websites that were used to show miners signaling support for segwit

On Pieter Wuille's website there are graphs about the Bitcoin network.
These feature graphs of the block version (used for version bit signaling) across time.


ETC vs ETH how do I know the difference?

Ethereum is usually ETH, Ethereum Classic is ETC.


There is no way to 'un-import' a private key in the core client. What you could do instead is:

Make a list of all the private keys you do care about.
Close your client.
Move the wallet.dat out of the data directory to some other location.
Start the client.
Re-import all the private keys that you do want in your wallet.

This is sort of a work around, and it may be kind of tedious, sorry there isn't a better solution currently.


Both. A notification will be sent when a transaction is added to the mempool. For newly added blocks, a notification will be sent for every transaction in that block, so when a transaction is confirmed, there will be a notification for it.


The Bitcoin.it wiki says addresses do not carry balances...but all info suggests otherwise

The wiki is correct, it is a technicality. Bitcoin "balances" are actually just unspent transaction outputs (UTXOs, from previous transactions) which you have the ability to spend. In most cases, that means knowing the private key corresponding to an address which the transaction was sent to. But the address itself doesn't have a balance, it just "locks up" the UTXOs corresponding to it, requiring a private key.

The important point is that the blockchain doesn't store a "total balance" of an address anywhere, to find the "balance" of an address requires looking through the chain to find the unspent transaction outputs sent to that address and summing their amounts.

Then to spend bitcoins, you spend specific UTXOs, you do not just subtract the amount from your "balance".


Actually, all you need is just some basic bitcoin wallet client. There are many opensource wallet clients, most of which will satisfy your needs. Your could search for them on Google.


See http://www.youtube.com/watch?v=IavQ-Wc8S1U

Clemens Cap of Uni Rostock explains the Electronic Bitcoin wallet
device he's working on. It's based on adafruit microtouch device.
This
is a small takeout of Clemens' talk at the Bitcoin Conference in
Prague 2011


Evebtually I decide to do it the curl way.

By having my express app to make a simple GET http request to the bitcoin node, I managed to get the job done.
Doing this with the request npm module is súper simple.

It doesn't solve the issue with the JS api, but allows me to properly leverage on the éstimate fee feature of Bcoin.


Where does the entropy of BitcoinJS' makeRandom() come from?

This code calls this code, which calls crypto.getRandomValues, which is a trustworthy cryptographically secure random number generator. It's secure enough to compete with bitaddress.org, as long as one's browser was not hacked.


Where does the money i am receiving come from?

You would need to find someone to buy the bitcoins from you. Simple as that!

You can do this in person (probably with someone you trust if its $100k!), or through an online exchange (a service that matches up buyers and sellers).


Where can I download the Antminer S9i Software

As MCCCS commented:

  Firmwares can be downloaded from Bitmain but Bitmain is smart enough not to upload S9i's firmware. You'll need to dump a friend's S9i's firmware by yourself.

Comment converted to Community Wiki answer in attempt to remove this Q from list of unanswered questions


generate wallets in exchanges like binance?

According to https://bitcoin.org/en/glossary/hd-protocol

Definition

The Hierarchical Deterministic (HD) key creation and transfer protocol (BIP32), which allows creating child keys from parent keys in a hierarchy. Wallets using the HD protocol are called HD wallets

So this allows you to create lots of addresses just from a Master Key

Are they secure?

As far as you don't leak your mnemonic, all your addresses are safe

Do all coins have HD wallets?

HD wallets provides you a way of managing the addresses more efficiently and easily. So coins don't have wallets, addresses managed by those wallet can hold coins

Hope this was helpful!


Bitcoin Core 17.0 - How to calculate balance with zero confirmations included (watch-only)?

No. Bitcoind requires at least 1 confirmation before a utxo amount is added to your watch-only address balance. Which makes sense, as it can still be trivially double-spent whilst it is not yet confirmed.

Related question: bitcoind sendfrom with minconf=0


the real purpose of mod inverse in bitcoin for creating public key

Basically, when creating a public key from a private key, what you're actually doing is multiplying some number by a point on the curve.
In most cases, you will be multiplying some very large number by what's called a Generator point.  It's just some point everybody knows and agrees upon.

Multiplying a number d mod n by a point G, or sometimes dG is defined intuitively as :

G + G + G + G... and so on d times.

If you remember how to do point addition, the process here is very much the same.
To add two points A and B, with coordinates (A_x, A_y), (B_x, B_y), to a make a third point C with coordinates(C_x, C_y),
point addition is defined as :

Find the slope (we'll call it slp) between the two points A and B
C_x = slp^2 - A_x - B_x        mod p
C_y = slp * (A_x - C_x) - A_y  mod p

And when adding the same point to itself, A + A (or 2*A when d == 2), point doubling is defined as:

Find the tangent (we'll call it tgt) to the curve at point A
C_x = tgt^2 - 2*A_x            mod p
C_y = tgt * (A_x - C_x) - A_y  mod p

Now, we only need to define how to find slp and tgt, and we can start creating public keys.
A slope between two points should look familiar :

B_y - A_y
---------   mod p
B_x - A_x

And a tangent to the curve at a point is :

3 * (A_x)^2 + a
---------------   mod p
    2 * A_y

* the number a is a parameter of the curve.  much like n and p.

You might already see the problem here, it's that division does not make a lot of sense in modular arithmetic.  Instead we sort of multiply the numerator by the modular inverse of the denominator, which makes sense.
To divide two numbers, we use the mod inverse function (which in turn might use the extended euclidean algorithm for example),
so what we would end up calculating would be :

(B_y - A_y) * modinv(B_x - A_x)      mod p  for the slope slp and :

(3 * (A_x)^2 + a) * modinv(2 * A_y)  mod p  for the tangent line tgt.

And this is where we use mod inverse when creating public keys, or really when adding points.


Were you supposed to receive a payment from that company prior to have receiving the email? If so, contact their support and ask them. If not, then the email was probably a scam or phishing attempt.


why OP_CHECKMULTISIG signatures must be placed in the signature script using the same order

Performance.

If you have an m of n multisig scheme, ordering the keys and the signatures  ensures that a minimum of m and a maximum of n signatures will be verified.

If we didn't use this approach the number of signatures to be verified could be as high as  n! / (n-m)! ( this is the worst case scenario).

Keep in mind that, in terms of resources, it is trivial for a transacting node to order the signatures, but it is not trivial for a verifying node to validate 500k transactions per day. We need to use the resources of a verifying node as efficiently as possible.


Running poclbm miner in Ubuntu 13.04 without ATI card

Your VGA card has no performance to maximise. Your CPU is more powerful for this kind of computation. I know, I have the same card.


transfer money to mtgox with visa or mastercoard

Basically, you can't easily buy hard money (like Bitcoins) with soft money (like credit card payments). The problem is that customers could reverse or dispute the soft money payment and the trader couldn't get the hard money back. To cover their costs should this happen, they'd have to give lousy exchange rates.

These lousy exchange rates would chase away legitimate customers. But scammers wouldn't mind, they're not going to pay anything anyway. So the scam rate goes up, the fraud losses go up, the legitimate customers get chased away, and so on.

There do exist businesses doing this, but expect extensive credit checks, waiting periods, demands for detailed documents, and so on. Also, expect to pay too much.


No standard client supports NLockTime directly AFAIK.

You can create raw transactions with bitcoind and then use a standard client to transmit them to the network in the method described here


How can I get the Fee involved in a Bitcoin transaction using RPC client (bitcoin-cli)?

Bitcoin transaction fees are implied by sum(vin) - sum(vout). The daemon doesn't display fee information on transactions you did not create because the value of the inputs isn't retained after they have been spent.

Block explorers show information that takes an additional set of indexes, it's not fair to compare the information shown by one and that returned by a very light weight full node. If you need more information like this on a regular basis you can use a middle layer like Bitpays Insight which will maintain a comprehensive index of this sort of information for you externally.


Is Bitcoin Core storage compatible across different machine architecture?

The database format is supposed to be compatible across architectures.


My multibit wallet (Ver. 0.5.15) shows nothing after being sent part of a coin?

First, check on blockchain.info and see what the status of the transaction is.  Make sure that it shows that the address you think it was sent to really received the coins.  Once you have done that, you know that the transaction has been recorded publicly.  Then it is just a matter of opening a wallet that owns that address.

You need to check the "Request" tab in MultiBit and make sure that the address you sent the coin to is listed there.  If it isn't, then you have opened the wrong wallet, and you need to find the wallet that contains the address you sent it to.


Exported wallet.dat from bitcoin-qt. Then uninstalled bitcoin-qt. Now the wallet is empty!

I had the same problem. What I had to do is delete the copy of the blockchain and let the newly installed bitcoin qt download and sync from scratch. All was good after that.


Yes you're talking about an off-chain solution. Exchanges use this solution.

It would be prohibitively expensive and impractical to transfer ownership on-chain for small amounts and/or frequent changes, so you send your coins to a single wallet owned by the exchange.

The exchange has their own system to keep track of who owns what. This system is private and not transparent, but fast and potentially free. Then when you choose to send it from the exchange to your wallet, a network fee is incurred at that point.

The off-chain solution could also be a blockchain solution, though not distributed as no one else would have any interest in maintaining your businesses ledger.

e.g. with coinbase.com

The Deposit:
Your wallet -> "your" coinbase wallet
  occurs on main net blockchain
  network fees incurred
  technically deposited into a single main net wallet
  wallet controlled by coinbase
  you trust them with your coins at this point

Interwallet transfer on coinbase:
"your" coinbase wallet -> another wallet on coinbase of "your"s
  occurs off the chain
    as such it's free
    as such is opaque
  could be implemented however coinbase sees fit:
    vb running in an excelsheet for all I know!

Withdrawal:
"your" coinbase wallet -> Your wallet
  occurs on main net blockchain
  coinbases single wallet is paying you
  network fees incurred
  grouped with other withdrawals for network fee efficiency
  coins in your full control again


70% of nodes accept Bloom filters, despite DoS attack vector?

So I guess the answer is "Yes, nodes accept Bloom filters because filtering does not make existing DoS attacks any worse nor do they introduce any new DoS attacks."


After various attempts to push through, this BTC transaction is taking forever to confirm?

You may pay a higher fee when you make a btc transfer. For instant in blockchain.info you can set it to fast transfer now!


What's the advantages of using the block chain as opposed to L2 solutions

From the point of view of an application developer, it is for now much easier to use layer 1 features.
This is due to being able to externalize your burden on the network.
1. Hey nodes, will you do my job?
Blocks are expensive to produce
You don't need to have much DOS concerns in your application if you are only reacting to onchain payments. But what happens if you do an expensive operation each time your Lightning node accepts an HTLC ?..
Backups are simple
You don't have to think much about backing up the state of your application for your user: your data is public and stored by everyone. Your user only has to back up a very small amount of data.
On Lightning, you are responsible for your own data. That's sometimes surprising to users who have been accustomed to (ab)using the block chain for years :).
In addition, on Lightning in its current form you are in a pretty bad position should you miss a single state backup. But this may be fixed in the future.
The security model is simple(r)
Even if there are some pitfalls and idiosyncrasies in Bitcoin, it's way harder to reason about assumptions you can reasonably make for your software and what you can convey to your user is a reasonable usage of your software.
For instance, "may i allow my user to re-import their HD wallet master account in another wallet?"

Bitcoin onchain: sure, what could go wrong?
Bitcoin offchain: meh. It's not that simple.

The same goes with "may i dig a hole, put my wallet in there, come back in a year, and still be in full possession of my coins ?"

Bitcoin onchain: sure, what could go wrong?
Bitcoin offchain: meh. It's not that simple.

Bootstrapping is simpler
Even if we usually make the analogy to "send coins to", Bitcoin onchain did not require interactivity. Just send the transaction to every single node on the network, make them verify it for you and call it a (lazy) day.
Now with Lightning for someone to start paying they need to find a way to connect to the payee, actually making the above analogy closer from the truth as they are actually transferring data.
For someone to start receiving payments, they also need to "be able" to be paid (have enough inbound liquidity).
Payments get increasingly more secure
Under Lightning's assumptions, a payment will be almost instantly "secure" :tm:
In practice, arguably even more so than a handful of onchain confirmations. However, maybe not more than a hundred. Or not than a thousand, or ten thousands confirmations.
For some applications (such as making very large payments), you may want to use this feature unique to the block chain: don't consider a payment to be made until a reorganization of the block chain that deep would put the entire currency down anyway.
2. Hey nodes, can you be more qualified at my job?
Of course, there are also drawbacks to (ab)using the chain.
Decent payment security is slow to bootstrap
Getting the first confirmation may be infinitely longer than on a layer 2 system. If you ask "if my payment can go through successfully, when is it going to be finalized?":

Bitcoin Lightning: immediately. (this assumes unstuck payments)
Bitcoin onchain: well, lemme explain you the block space market.

UTXO management
This logic is one you can't outsource to the nodes :). It's pretty difficult optimization problem that highly depend on the usage that is going to be made of your software. It takes a deep understanding of the tradeoffs and knowledge of the existing solutions to the developer to make a sensible decision.
On Lightning, you don't have to manage coins. The value is similar to a flux rather than to actual physical, indivisible coins.
Fees orthogonal to payments and fee management
Onchain fees depend on the actual transaction (in the database sense of the term) size, not on the actual payment. They are in addition very unreliable, in theory you really can't know for sure that your transaction is going to make it into a block in advance. You are really hoping for the best.
The counter measures for adapting to this always-moving block space market incur an additional cost in knowledge and understanding (and complexity of implementation) to the application developer, similarly to coin selection (which is tightly related).
"how much is my finalized payment going to cost me?":

Bitcoin Lightning: a proportional fee of x sats per million of sats transferred and a fixed fee of y.
Bitcoin onchain: well, lemme explain you the block space market.

Higher usage cost
As the demand for the finite resource of block space increases, so are average fees premium to be included as soon as possible in the chain. This makes some design of application not possible onchain anymore, re-aligning the incentives of (ab)using the network to incur less burden to the software / user of the software.
Lack of features
Onchain nodes are pretty restricted in what they can verify for you. Some more complex systems can be emulated on a L2 network with different trust assumptions than the base trustless network (eg with sidechains).
The advantage of not doing it onchain here is that it's opt-in: you don't have to make the entire network and economy accept to augment their functionalities in order to bear even more burden than previously.
Some features may be either backward incompatible or present tradeoffs that not everyone would accept. Their addition to the base layer would raise big questions about the censorship resistance of the system and finally the point of using it in the first place.


Test network completely removed from the real network?

There is a section in the Bitcoin Developer Guide on Testing Applications. The section you are interested in is likely to be Regtest.


I have 2 BTC in my Bitstamp wallet. I have over 10,000 XRP (no issue
  with reserve)

If this is in your Bitstamp account then you need to withdraw it to Ripple before you can use it on the Ripple platform (e.g. just as BTC at MtGox can't be used on the BTCE exchange).

  I have trusted Bitstamp up to $300 in my Ripple client.

To get bitcoin from Bitstamp you'll need to trust Bitstamp for >= 2 BTC (if you fail to do this before attempting the Bitstamp withdrawal, Bitstamp will redirect you to the Ripple client page to extend the required trust). No trust is required for USD unless you'll also be dealing in USD with Bitstamp.

  I've tried to enter an order selling 1 BTC for 8400 XRP.

    Transaction failed!
    Error: Insufficient balance to fund created offer.

The balance referred to here is your BTC balance within Ripple, which from the sounds of it is zero.


What exactly were the novel contributions of Bitcoin?

b-money proposes to pay for money minting by means of proof-of-work. The minted money then has the value of the expended computational power.
For value transfers it either relied on a synchronous unjammable channel and arbitration, or on a set of trusted servers that had to be regularly audited by the other network participants.

In other words, b-money used POW to create monetary scarcity with manual supervision.

Bitcoin instead introduced the use of proof-of-work to create scarcity in the truth source: By electing only one network participant to extend the blockchain through the mining lottery, Bitcoin manages to forgo arbitration or trusted servers, yet manages to create convergent synchronization of the network's state in an asynchronous manner.


Create addresses in bulk; and check balance

As you found out already; private and public keys are not necessarily paired 1-to-1. In fact, using the original Bitcoin client you can just run the getnewaddress to generate a new address belonging to your wallet, which is controlled by only one private key.


Does it make sense to use BitCoin to transfer money to yourself internationally?

While in the US last year, I sent money to myself in Europe that way once, because it was significantly cheaper than using the legacy banking system.

I think it mostly comes down to whether you have easy access to a Bitcoin exchange from your bank account in the US and what amounts you are trying to transfer. It also depends on how urgently you need the money in the other country, and which country you currently are residing in.

Alternative 1 (if in UK): Use your US credit card to get Pounds from the bank, deposit those in your UK bank.
Advantage: Fast
Disadvantage: Currency exchange fee, fee for using CC abroad, (Deposit fee, if you have one)
Alternative 2: International Wire Transfer
Advantage: No manual involvement
Disadvantage: Takes several days, expensive (~$50), get lost sometimes
Alternative 3: PayPal
Advantage: Very fast, independent from residence
Disadvantage: ~3% exchange fee, % transfer fee, has to be withdrawn to Bank account
Alternative 4: Money transmitter
Advantage: Fast
Disadvantage: Needs to be picked up and deposited, expensive I think
Bitcoin:
Advantage: Can be cheap
Disadvantage: Takes a few days, manual involvement
Procedure:
• Consider buying Bitcoin locally if in the US, else buy Bitcoin from Exchange or Coinbase (each takes a few days until it is cleared, I think)
• Send Bitcoin to your account at an exchange in Europe
• Trade Bitcoin for national currency
• Withdraw to Bank account (usually a small fee applies).

Personal experience
Back when I did that last year, I was able to buy Bitcoin at a Bitcoin Meetup at Bitstamp spot-price. I transfered those to Bitstamp, traded, and ordered a withdrawal.

I had a confirmation that the money was headed to my bank account within 30 minutes, it arrived two days later. I actually made a few dollars on it, because the price had slightly increased between my local trade and the trade on Bitstamp.


To get the hash in a human readable version, I advice you to use a class that'll do it for you:

System.out.println(javax.xml.bind.DatatypeConverter.printHexBinary(adshas160));


For small amounts, like a cup of coffee, the double-spending risk is going to be negligible. If it's a person I know, I wouldn't mind receiving and accepting as valid a transaction with zero confirmations.

For shops that will start accepting bitcoin, a stronger security measure would be for them to have multiple bitcoin clients installed in multiple geographical locations. Once each of them has "seen" the transaction they can confirm it as valid, even though it hasn't been included in the blockchain yet.

The idea behind having several machines look and validate the transaction is that it becomes much harder for someone to propagate a double-spend against a transaction that has already been seen and propagated by several machines across the world.


Why do wallets of Bitcoin exchanges have tens or hundreds of thousands of addresses?

Is that number fix ?

It isn't. New addresses are generated by exchanges all the time.

  What those addresses represent exactly?

They are simply multiple addresses controlled by them. They can represent addresses the users deposit coins too (often one per currency, so BTC and USDT may have separate addresses), or intermediary addresses used for consolidation, or hot wallets, or cold wallets, or temporary addresses used as change addresses.

  Why do we find so many addresses but only around 20 of them are rich?

In general, exchanges tend to have thousands of user addresses, into which users send crypto. Exchanges will then move all that crypto to a handful of hot and cold wallet addresses, which they will then use to process use withdrawals. The majority of addresses will be empty most of the time, unless you happen to check one between the user depositing coins and the exchange sweeping it to a consolidation wallet.


How can I pass Multiple addresses in Move command

You can't pass multiple addresses to Move commands, also move will be removed in a later version of Bitcoin Core.

Please consider using sendtoaddress instead


Does Bitcoin have a legal expert/team that does their work?

BITCOIN is a software ecosystem, and not owned by "someone". Similiarily you could put some code [echo "hello world"] on github, and it would be publicly available. Then there is also no "they", or an association managing the code. The bitcoin developpers are a group of loosely coupled "geeks/freaks", and anyone with a good skill set could belong to this group, by participating in coding/translating websides/correcting wording ... For sure you know that. So as this developer team provides (a highly sophisticated) software, they are not dealing with regulations from each country, in which the software could be used. But I think your point goes into this direction:

There are companies using this public domain ecosystem (kraken, bitfinex, hitbtc, bitcoin.de, blockchain.info). These companies (and some miners) provide ramp-ups and -downs, to make it easy for you and me to use the bitcoin eco-system. They are for sure under a jurisdiction, within their appropriate countries. And for sure "they" have legal/compliance teams, that deal with country specific regulations (aka "KYC/KYI/...").

Still I am not clear on what you suppose by "their work". I think it would be fair to say, Bitcoin doesn't need any work at the legal level. Countries and governments (or other power structures over individuals) need such things, so it is up to "them" (these power structures), to make sure, bitcoin is used in a way, that it complies with their rules of keeping tidal waves of change away from their protected environment :-)


how to get change address using derived BIP44 publicKey?

I guess I've found the answer as explained in bip43

m / purpose' / *
Apostrophe indicates that BIP32 hardened derivation is used.

We encourage different schemes to apply for assigning a separate BIP number and use the same number for purpose field, so addresses won't be generated from overlapping BIP32 spaces.

Example: Scheme described in BIP44 should use 44' (or 0x8000002C) as purpose.

Note that m / 0' / * is already taken by BIP32 (default account), which preceded this BIP.

Not all wallets may want to support the full range of features and possibilities described in these BIPs. Instead of choosing arbitrary subset of defined features and calling themselves BIPxx compatible, we suggest that software which needs only a limited structure should describe such structure in another BIP and use different "purpose" value.


How does WalletExplorer know which wallets belong to whom?

What walletexplorer does is called address clustering. When you spend bitcoins, your wallet will take input from several txouts belonging to several addresses depending on amount to be spend. So walletexplorer works on a simple heuristic:

If two addresses appear as inputs in any given transaction, they belong to same user

More detail about this method can be seen in this paper by Reid and Harrigan. Of course, this method will fail in case of mixers and coinjoin transactions. There are advanced ways to even detect transaction that go through mixers, but I don't think wallet explorer does that

To find name of wallets it can scrap forums like bitcointalk, some addresses are tagged publicly in blockchain.info, also it can has bots trade on major exchanges to get their addresses.


Clarification of Tx Fees settings in Bitcoincore 0.10

Why the move towards variable Tx fees?

Almost all miners choose what transactions to include in blocks based on fees and priority relative to byte size, so transactions that pay higher fees are more likely to be included in the next block than similar-size transactions that pay lower fees.

Advanced users have always been able to take advantage of this mechanism to set their fee higher for transactions they want to confirm quickly and lower when they don't mind waiting for a while.  But to do this right has always required manually looking at recent blocks to see what were the lowest fee or lowest priority transactions they accepted, which put this kind of "fee market" out of reach of everyday users (or advanced users who don't want to spend much time pinching pennies).

However, Gavin Andresen introduced code into Bitcoin Core 0.10.0 to automatically have each Bitcoin Core node keep its own statistics about block fee and priority thresholds, so now you can run a simple command like this,

$ bitcoin-cli estimatefee 25
0.00001919

to see that if you don't mind waiting up to 25 blocks for confirmation, you can probably set your fee to 0.00001919 per kilobyte.

Thanks the the work of several volunteers, the Bitcoin Core GUI now also uses this information to allow everyday users to easily choose between fast confirmation and low fees.

(source: bitcoinillustrated.org)

This really gives the fee market a chance to develop so that Bitcoin Core can automatically adjust to things like filled (max-size) blocks, new larger blocks, changing use patterns, and significant changes in BTC/fiat exchange rates.  It is also hoped that some safe way will be found to allow SPV clients to also estimate fees and priority so that they can offer their users the same informed choices.

  Is the 0.0001 BTC fee deprecated?

Yes, mostly.  It's still the default if not enough information can be gathered from the network.

There is also still unchanged the default relay fee of 0.00001 BTC per kilobyte.  This isn't related to transactions you create but rather the transactions your node will accept for relay.  The default is widely used, so paying less than it is not a good idea.


Security of ChaChaPoly (IETF rfc7539) in the noise protocol framework of the Lightning Network

The paper you cited proves that ChaChaPoly is IND-CCA secure. This notion of security seems to perfectly cover your attack if I read the definition right  (https://en.wikipedia.org/wiki/Ciphertext_indistinguishability):
"A cryptosystem is considered secure in terms of indistinguishability if no adversary, given an encryption of a message randomly chosen from a two-element message space determined by the adversary, can identify the message choice with probability significantly better than that of random guessing (1⁄2).".

That is, even if just two such lengths existed, the adversary cannot guess which one is encrypted here significantly better than randomly.


Is there a logging system for bitcoind, and if so then where is the log?

The default data location of bitcoind is ~/.Bitcoin on unix and %APPDATA%\Bitcoin on windows. In it, bitcoind will write a debug.log file which is automatically trimmed every once in a while. I'm not sure what is in it, but it should be easy to check. You can also start bitcoind with a commandline parameter to send its debug info to stdout, if you wish.


You can solve this problem by making a request to https://www.okex.com/api/v1/tickers.do (without the symbol parameter). This will give you all the tickers in one request.