how are lightning network payments instant and secure at the same time?

This is a very good question and I will give a quick summary of what is happening here. The longer version can be seen on my educational video on how to create payment channels starting at 33:41 (though I would recommend to watch from the beginning to review bitcoin and notation.)

  My understanding being the multi sig wallet is a temporary address which will remain active until the LN channel is closed.

yes this is true! The key is a multi sig address which already prevents the attack setting to the shop which you discribed in the onchain bitcon setting without confirmations. If only you need a key for a double spend you can double spend. In the setting of the multisig you would need collaboration from the victim (shop) which would not do help you

  When it's closed a new transaction would be created distributing the funds to my wallet and the shop's wallet depending on where the funds were in the LN channel when the channel was closed

I think this is where you might not have the concept fully right. While it is true that the funds from the multisig wallet will be moved according to the distribution of funds to the two channel partners the initial transaction that spends those funds will be created even before the channel is opened by sending funds to the multisig from which this commitment transactions spends.

All that being said. the funding transaction is not in the mempool as you guessed but in fact confirmed within the blockchain for the channel to be open and operational. So for an initial channel opening (unless using the somewhat special setting which allows turbochannels) one also has to wait for a couple of confirmations to use the channel safely. The setting with the shop also would not require you to have a direct channel with the shop. As soon as both you and the shop have channels connected to the network you should be able to pay the shop over a path of channels without the necessity to open another channel with the shop.


How is it possible to say that a bitcoin was fully spent?

An output ("coin") is by definition either fully unspent or completely spent. There is nothing in between. A transaction has one or more inputs (which refer to the unspent outputs of earlier transaction) and it fully consumes them.

A transaction can also have 1 or more outputs. For each output a value is specified (number of Satoshis), so by being a little creative you can easily split or merge "coins".

This way Bitcoin "simply" needs to remember only the last outputs of a chain of transactions, there is no point in remembering (indexing) anything older. That's what the UTXO set is: Unspent Transaction Outputs database.


Is equihash/scrypt suitable for pooled mining?

I found https://minezcash.com/zcash-mining-pool/ so apparently there are quite a few zcash mining pools already.

Regarding the difficulty question I am currently looking at https://github.com/str4d/zcash-pow/blob/master/pow.py What is irritating me is that there still is a SHA256 calculation apparently.


How was a pay to ip transaction created?

Pay-to-IP transactions were removed in 0.8.0.

Such transactions worked by essentially contacting the IP address you were sending to, seeing if it was running Bitcoin, and receiving a public key from the Bitcoin node there to pay to.

However, this wasn't very secure. There was no way to prove that the response was coming from the IP address you tried to contact - It was trivial for a man-in-the-middle attack to simply hijack your request and reply with their own bitcoin public key, effectively stealing the payment.

Here is the BitcoinTalk discussion discussing the PR linked above and the removal, with the thought process at play.


bitcoin-cli "getbalance" always returns 0

getbalance only applies to addresses you own (and are in your wallet.dat).


How to find the private key of blockchain wallet?

I am hoping you are talking about blockchain.info

If yes, then I am again hoping that the above address you have posted is a wallet address in your blockchain.info

If again, the answer is yes, please follow the below steps:

Go to settings, then click addresses as shown below:

Click on more options aside your address whose private key you require as shown below:

In 'More Options' you will find "Private Key", please click it:

They will show you a warning as below, please click continue:

You can see your private key for the corresponding wallet address:

Hope this helps you!


Are generated public/private keypair the most random possible?

The source code is open take a look for yourself. I am no expert on cryptography though so I will leave the explanation of this to someone who is. This is the file that you would want to look over https://github.com/bitcoin/bitcoin/blob/master/src/key.h


Does desktop wallet need to be online for the coins to mature?

No, your wallet does not have to be online. Maturity depends on the block number in which a transaction was included into the blockchain.


What's a good site to see bid/ask walls?

btccharts.com is a better version of mtgoxlive.com - it lets you zoom out to see more price range, and has a bunch of other features.

See its forum thread for discussion of it.

Note: the site is currently down for maintenance but should be back soon.

Also, clarkmoody will show you a live updating view of the market, but the depth is shown numerically, not on a graph.


How do non-deterministic wallets violate the principle of address reuse?

The text indeed doesn't make it's case clear, but the idea is that random key generation makes for inconvenient backups.  The more keys you generate, the more frequently you will have to back up the wallet.

To avoid this, some users of non deterministic wallets have resorted to reusing keys\addresses, as a sort of easy way out of having to follow the demanding practice of frequent wallet backups that are needed when new keys are generated.


Analysis on the Block Chain for Dead Bitcoins

No Bitcoin is dead by definition - it may just be impossible to spend them, because e.g. you lost the private key. So you will never be able to distinguish between dead addresses and just untouched paper wallets.

I was also thinking about it and came up with a proposal for a protocol change: If it is well known and communicated through every news, and everybody would agree in that change of course, it would allow miners to 'take' money from transactions which are unspent more than (let's say) 2 years. This means they can transfer the coins to another address without providing the signature and the network accepts this. This sounds scary, but it wouldn't mean you steal somebody when everybody knows. You just have to move coins every two years. Unfortunately long-term paper wallets would be less convenient.

Of course details are missing, e.g. you shouldn't get all the money of a big transaction in one block just because you are lucky. Anyway, I think this "using of dead coins" idea wont make it, as everybody is interested in a rising bitcoin value, and this happens when some are lost!


That's exactly right. People who want to sell bitcoins typically set a minimum price and people who want to buy bitcoins typically set a maximum price. When they meet, a sale takes place.


Bitwasp-PHP can do it. with much more features.


Recovering Bitcoin / Litcoin wallet with partial PyWallet recovery

The file recovered_wallet_NNN.dat should be a standard Litecoin wallet file containing those (possible) private keys that pywallet found.  Install litecoin-qt if you haven't already, back up your existing wallet.dat if any, and copy recovered_wallet_NNN.dat in its place.  Then run litecoin-qt -rescan (this may take a long time to start up as it rescans the entire block chain).

If the data found by pywallet included your old private keys, litecoin-qt will have access to them and will show you your balance.  You can then send your coins to a new address or whatever you like.

It's also entirely possible that the data found by pywallet looks like private keys but is actually something else.  They will still work as private keys (since a private key can be any 256-bit integer) but they will correspond to addresses that don't contain any coins.  In that case, litecoin-qt will show you a zero balance, and you are out of luck.

The file pywallet_partial_recovery_NNN.dat appears to be used by pywallet to save its progress in case you abort the recovery process.  Since in your case it finished correctly, you don't need this file for anything.


You questions are legit, however they might need a bit of reorg.

  where is the link to a new block then?

Every block header has the hash of previous block's header. So there's the link

  Do they create blocks while searching for a new block with btc inside?

a miner "creates" a block by selecting tx from the pool and "solving the math problem" as you said. Other miners are doing the same thing. When someone else solves a block before you do, she broadcasts it and you'll receive the block through the p2p network. If that's a legit block, it usually makes sense to stop your work on the current block and work on the next one on top of the one you just received.

  if a new block is found also has this block'a Tx inside?

it's totally possible, depending on what tx you select and what tx the other miner selects

  Does somebody has a sample on the blockchain?

If you mine, then every scenario would be like this

  Do they then use those blocks, add Tx and match it to the blockchain?

if "those" means the new blocks you receive while mining, then no, you just accept it after validating it, and then solve for new blocks on top of that.

  How many Tx can go in a block?

as little as one (that pays to the miner), and as many as the number of tx that fills the block (such that the total size of tx data is less than 1 MiB)

  Are there also empty blocks?

yes if empty in the sense that no other tx except for the one that pays the miner. It happens more often in the early stage, but it still happens nowadays.


How to build a web site on which clients can send and receive bitcoins without an account?

A payment gateway may have restrictions on the type of business category, and online gambling may be a category they don't support.

The process is pretty simply.

Supply a new address for each deposit.  When a payment arrives to that deposit address the customer account is credited.

A payment is considered final, generally, once it has six confirmations.  That may be a long time for a customer (an hour, or longer even) -- some sites use one, or three confirmations but then have withdrawal restrictions so that newly deposited funds are not withdrawn until the original deposited funds have six confirmations.

But this business deals with money. Any business that deals with money, whether dollars, euro, gold, or bitcoin, should not be operated without giving appropriate attention to the factors that require attention.  With Bitcoin being a non-reversable payments system, IT Security becomes among the most important areas of the business.

Learning how to construct a payment transaction (sendtoaddress using bitconid) or receiving a payment (poll bitcoind using listtransactions, or -walletnotify) should be your last concern at this point.  Figuring out how to manage a wallet, using a cold wallet and hot wallet, for example, and making sure you have backups, etc., are a higher priority.

This experience might be something you hire out for rather than solicit from a Q&A site.


Why are there such huge differences between commissions on different exchanges?

It varies from exchange to exchange because people running exchange are different with different thinking. Me and my brother runs a website where we sell coins in exchange of USD(we are not a exchange anyway just small dealer) we do charge some fees but the difference here is my brother will charge a customer upto 20% higher than actual rate on the other hand(u have different fingers) I charge only that amount which is reasonable.


How do I know how much each address own in a wallet?

Technically, bitcoins aren't sent to a wallet.

The Bitcoin blockchain works as a ledger.  A "wallet" simply holds the keys that allow you to spend funds.

If you are simply asking how to monitor balances for certain addresses, there are third party services such as BTCBalance.net which make this possible.


How the Recipient's public key is used in bitcoin transaction

It says a coin is a set of digital signature. For what I understand the whole process is the following:

Hash together the previous transaction hash plus the recipient public key;

digitally sign the hashing string with the private key of the sender;

The thing that is signed is not related to the previous transaction. It is actually the current transaction that is being created (or parts of it), but without the signatures.

The digitally signed result represents the transaction.

No. The result is never transmitted as it can be calculated from the transaction itself. The signature is placed inside of the transaction.

First of all, when the transaction is trasmitted to majority of the nodes, they have to decrypt the signed transactions by applying the public key of the sender to verify his identity.

No. There is no encryption or decryption happening. A digital signature does not produce any encrypted data. Nodes should be verifying that the transaction is signed with the public key.

Well, where the nodes take the public key of the sender?

The public key is either provided in the transaction output that is being spent (so nodes refer back to the previous transaction) or it is provided within the spending transaction itself. In the latter case, typically the previous transaction output will contain the hash of the public key so nodes will check that the public key provided hashes to that hash.
Note that I say typically because there are cases where none of this is true. Since Bitcoin uses a script system, anyone can create a script which does whatever they want, including signing the transaction or not. Transactions are only signed because the commonly used scripts say that the transaction must be signed in order to be spendable, but not all scripts require that.

but we cannot do so because the transaction is again encrypted and we need the public key of the last-last owner.

No. Again, nothing is encrypted. Furthermore, in an encryption scheme, the public key is absolutely useless for attempting to decrypt something. Things can only be decrypted with the private key. All blocks and transactions in Bitcoin are not encrypted and all of their details can be plainly read.

The other question is about the Receiver public key inside the data in the hash function. Does this really matter as a proof that the coin associated to that transaction are held by the new owner? Or they play a role in the user validation? I mean, the arrow with the name "verify" what stands for?

Yes, it does matter. Otherwise anyone could provide a public key which has a valid signature. The point of having the hash of the public key is to prove that the public key provided is the correct one and that the previous transaction committed to that public key (i.e. the previous transaction actually specified that public key).


How is the real world value of bitcoins generated?

BTC works as any currency. As long as people see value in it, it has value.

The momentum was just the curiosity the users had... Also the whole "Make free money with your computer"- thing which was started.

A big influence was the famous "How does bitcoins work" video I saw on vimeo. That got ME started at least. (Link to updated version)

The algorithms your computer solves when "mining" isn't used for anything no.
There are also other kinds of crypto currencies on the rise. The most notable is Litecoin. It uses a different algorithm. (Scrypt, instead of BTC's double sha256). The point of Litecoin was to make users able to "mine" more efficiently on their CPU's.

I hope this somewhat answered your question.


don't know if this help
but I had the same problem
COINBASE FIX IT
sent btc to my coinbase receive address but I did not cover the fee>> fee amount to low .
2 1/2 week went by it showed pending on coinbase
blockchain showed no transaction completed.

it first show back in my personal wallet
then a week later coinbase shows I received btc 0.000685 btc

    I sent 0.3555000
    but 1 week later it pulls from my wallet and goes to coinbase in full.
    so coinbase did something on there end to push it through.
    I was out nothing .
    but it takes 3 to 4 weeks for them to fix it .
    hope it help you


Is it possible for some one with huge computing power to disrupt Block Chain?

I don't think the premise of the attack (rebuilding the entire blockchain within the time of one block) is necessary. If someone wanted to rebuild the entire blockchain, they could take, say, a year to do it, which would considerably reduce the computational requirements. Of course more blocks would be created during that time, so they would need to catch up at the end, but that would be much easier than re-creating the whole blockchain in 10 minutes.

The other thing they could do is start in the middle of the blockchain (unless you have a good reason for redoing the entire thing), which would also reduce the computational requirements. Or is the idea of rebuilding the entire chain that they would control all the bitcoins?

I think it would be reasonable for a three letter agency to build enough ASICs to have well over 51% and take over mining. (They could have enough capacity right now hidden in pools, waiting until they need to take control and nobody would know. And the hardware would pay for itself.) But rebuilding the entire blockchain would require an implausible amount of hardware for little benefit.


How can the output of an unconfirmed transaction be spent?

It works just fine.  "Spent" here just means that a second transaction has been broadcast whose input is an output of the first transaction.  You don't have to wait for confirmation in order to do that, and you can continue the process with arbitrarily long chains.

However, the second transaction can't be confirmed until after the first one is confirmed.  (Or, they can both be confirmed in the same block.)


The Bitfinex:BTC/USD pair seems to be traded with one decimal figure precision.

There is no way to get more accurate data, as this is the most accurate data.

In my opinion one decimal figure is enough. Since BTCs price is so high, the first decimal figure is actualy the 5th significant figure. Most forex exchanges only go to 6 significant figures.


can cryptocoins be put to good use? now or in the future?

Primecoin is an example of a well-known cryptocurrency that is doing something useful. As its name implies, its utility relates to prime number discovery:

  The innovative prime proof-of-work in Primecoin not only provides security and minting to the network, but also generates a special form of prime number chains of interest to mathematical research. Thus primecoin network is energy-multiuse, compared to bitcoin network.


What is protecting the mempool from being DDOSd?

First of all, there is no "The mempool". Every full node has an individual mempool, and as these contain no transactions that are already in blocks (confirmed transactions), by definition nodes cannot be guaranteed to have agreement about it. So, what you're looking at it blockchain.info's mempool, which may or may not be similar to that of other nodes.

What can cause differences between mempools? One obvious example is in the case of a double spend: no conflicting transactions are allowed in it, so if two distinct transactions which spend the same inputs are broadcast into different places of the network, some will accept one, others will accept the other, based on which they hear first. That's not the only difference, though. Nodes can also have different mempool acceptance policies.

A node's mempool is ultimately its expectation for what transactions may reasonably confirm in the short to medium term. Good mempool acceptance policies are trying to model that expectation. If a transaction's fee is very low, it may not be worth keeping around if there are plenty of higher fee transactions to mine first.

And that is the basis for the mempool DoS protection that was added in Bitcoin Core 0.12. Roughly, whenever the mempool's memory usage goes over a certain preconfigured size (the -maxmempool setting), we kick out the transactions with the lowest feerate, and (temporarily) increase the minimum feerate to get in in the future to that of the evicted ones. That solves the issue of unbounded memory usage.

But what about bandwidth? Things like BIP125 and this eviction described above essentially result in the ability to keep broadcasting transactions, and have them be accepted and replace other transactions, without really paying anything. I say paying here, because the fundamental rule we base mempool policy decisions on is that since we expect transactions in the mempool to confirm, and thus pay their fee. Thus, we'd want a rule that whenever something is evicted from the mempool (for whatever other reason than it confirming), something else pays "something" for that relay. In practice this is accomplished by having a separately configured relay feerate (which does not change when the mempool is full), that specifies the "price" for relay. In the case of mempool eviction, the new transaction(s) must pay at least that relay fee more than the fee of the replaced ones.


Why is the difficulty adjustment restricted to a factor of 4?

You need restrict how much difficulty can change. Imagine if someone managed to forge the timestamps on the block that they were creating, and make it so that it appeared that it only took one second to generate 2016 blocks. Should difficulty then go up by 1209600? Clearly, that would be ridiculous.

On the other hand, you need to make the adjustment flexible enough to adapt to unforeseen advances. 4 is an arbitrary value picked as a compromise between these two requirements.


Does an increase in hash/s decrease the time it takes to obtain a block or does it increase the possibilities of solving one?

Since solving a block is a probabilistic math problem, having more hash power will increase the probability that you will find the right hash and solve the block. You cannot be 100% sure of the estimation given by the profitability calculators.


Bitcoin fork resolution - Fork losers download previous blocks 'til common block?

As soon as miners find a solution to the block header, they relay the block to the full nodes in their network. These full nodes will validate the block and will add the block that reaches to them first on top of the existing blockchain. Later, when they receive the other block at the same height, they will not discard it but maintain a copy of it. However, the nodes do not relay the block that was received later. Although the nodes assume that the block they received later must have lost the 'race', it keeps the “losing” block so that it has the information needed to reconverge if the “losing” chain ends up “winning.” So here you have a blockchain fork, where around half the nodes have a different version of the blockchain at the best height. When the fork is ultimately resolved when the next block is mined, the nodes can converge back because of the copy or the other block that they keep.

Chain reorganization with more than two blocks is rare unless there is a bug in the software like the one that caused one of the major fork back in March, 2013 that lasted 31 blocks.


addnode in bitcoin.conf doesn't work (Regtest mode)

well im late but i can tell.

it works, use following string

addnode IP:8333 add   but the Port you dont need to show, because everyone uses the same port, because thats the one he set as open on his router. the rpc port must only defined once at startupt. in addnode dont use it, because you could be bound on an IP too via the bind= command, then the server dont know what to do.


P2Pool Missing BTC Reward in Block History

Well there is a message being displayed on the P2Pool site that reads, "January 25, 2018: Our historical block data became corrupted (only relating to it's display on this website), data for all blocks after April 1st, 2017 were lost. They will be restored to the data set ASAP." so this is the reason for the missing information.


getbalance says 0 for incoming TX even though 0-conf is allowed

getbalance returns the balance that your node currently considers spendable. According to your console output, the transaction that sent you the output was flagged as "bip125-replaceable"=>"yes". Since a transaction flagged as replaceable can be amended or retracted by the sender until it gets confirmed, an output from such a transaction will not be considered reliable and not used as an input until confirmed.


Take a look at Peter Todd's python-bitcoinlib.

From the github repo:

  This Python2/3 library provides an easy interface to the bitcoin data structures and protocol. The approach is low-level and "ground up", with a focus on providing tools to manipulate the internals of how Bitcoin works.


How fast is BitcoinJ for getting UTXOs(/UnspentTXOuts)?

The question is how quickly can BitcoinJ do this?

It's not fast enough for that particular use-case.

  Will it synch up the whole chain using bloom filters or can it directly poll BitcoinD nodes for UTXO data for a specific address?

It always uses bloom filters, and if you search for one additional transaction, it needs to search through those blocks again.

  I worry that if it synchs the whole chain then even with bloom filters it will take maybe 10 seconds.

10 seconds is very optimistic. The remote node needs to go through all ~50GB of blockchain data, and compare each transaction against your bloom filter.

It sounds like your needs would be better served by something that allows you to query by address, like the Electrum network or Blocktrail's API.


The first byte, 1D, is the length. The next three bytes are the high bytes of the hash. So we have 00ffff, then we add ff bytes onto the end to get to 29 bytes. Then we're done.

We wind up with 3 bytes of leading zeroes because 32-29 is 3. And we get one byte of zeroes from the second byte of the compact bits. So the final result is 00,00,00,00,ff,ff,ff...


My Blockchain Payment Has Been Unconfirmed For 3 Days Now Please Help

You can use replace by fee to encourage miners to pick up your transaction.  This should be your next step.  See here for more info:

What is replace-by-fee?

Also, here is a how to:
https://freedomnode.com/blog/75/how-to-fix-slow-bitcoin-transactions-with-replace-by-fee

This site can help recommend what you should use for your fee so that you can set your expectations of when a transaction will be confirmed:
https://bitcoinfees.earn.com/
Basically, the more you pay with a fee, the faster it will be confirmed.  The less you pay, the slower it will be confirmed.


Why do I need a private key to send some my bitcoins?

A private key is the only way to assure everybody else you and only signed a specific transaction saying 'give X of my coins to Y'.

If you publish your private key, anybody can sign transactions like that and your money can be stolen. You should keep your private key private.


Cash reward for help retrieving my 0.5 bitcoin

First off: DO NOT send those exact passwords to anyone offering help. Having those passwords may allow them to access and steal your coins.

If you open your wallet and see a zero balance, that is probably not a good sign if you haven't moved the coins yourself. Look at the history of transactions, and see if there are any that moved the coins to a new address. You need to figure out if the bitcoin has been moved to an address that you no longer control.


Scaling fee solution for Bitcoin lightning?

Currently it cost $0.000116736 USD (1 satoshi) fee to make a transaction on lightning.

This is incorrect; there is no set price for sending a LN transaction. Each node can define its own policy for forwarding a payment through the network (base fee rate, plus a small percentage of the amount forwarded), so the fee paid will depend on the payment route taken.

In some cases (eg you have a channel open directly with your counterparty) there will be no fee for the LN payment itself.

Anecdotally, I think the most fees I have paid for a LN transaction is still in the range of single digit satoshis.

  Can we just increase the decimals and have sub-satoshi fees for lightning?

LN nodes already track sub-satoshi amounts, with a resolution of 1/1000th of a satoshi. Note that these sub-satoshi amounts cannot be reconciled onto the base chain in the event of a channel closing, but they are still tracked by LN nodes, and in aggregate many sub-satoshi amounts can add up to whole satoshi values (which could then be settled on-chain).

  What are some other scaling solutions to lower the fees?

The current LN fees are entirely defined by the network’s nodes. So it is a free market, wherein nodes can charge a small amount for the use of their liquidity in forwarding payments. If you want, you can run a node with zero fees, but many users will likely want some compensation for their liquidity availability.


What happens if a miner publishes a block which contains an invalid transaction?

A block with an invalid transaction is an invalid block, regardless of the proof of work.

When it is broadcast, other full nodes will ignore it as spam, and typically disconnect from the node that sent it.  A bad block is unlikely to propagate very far on the network.

When other miners see it, they will also ignore it.  If they mine on top of it, they will be wasting their hashing power.  This also means that the miner who did the proof of work on the invalid block has wasted their own hashing power.  This is why it's important that miners validate the transactions they include in blocks.


Used salvagewalllet, now it shows zero balance

-salvagewallet will extract only the private keys from your wallet. When it does that, it may also end up corrupting your wallet if it was not already corrupted. -salvagewallet should only be used as a last resort.

Because only the private keys are pulled out, all transaction and comment information is lost. That means that you will lose all of your labels and your wallet balance. You will need to rescan the blockchain be starting Bitcoin Core with -rescan.


How to get balance of a bitcoin p2sh address?

Do a search for it in blockchain.info or similar service.

Eg for an example address 3P14159f73E4gFr7JterCCQh9QjiTjiZrG you can see the result of such a query here.


Empirical analysis of blockchain branches: once every 380 blocks?

Blockchain forks are an artifact from the network propagation and appear at random intervals (and far more often than what you observed). It is important to note that since nodes do not forward information that contradicts their view of the network, i.e., they have accepted one of the forks, you will not be able to observe all forks in the network, but only those that are propagated to you through the network.

For details on what causes blockchain forks and their impact on the security/performance of the network see Information Propagation in the Bitcoin Network (disclaimer: I am one of the authors).


Are electrum's private keys 512 bits or 256 bits long?

Is this the final function to be called for priv key generation or are there steps or functions that I missed?

You are missing a lot of steps.

The seed value is 512 bits because more bits is more secure, and BIP 32 specifies that a seed value between 128 and 512 bits should be used. It does not matter what the length of the seed value is because it will get hashed anyways and the result is 512 bits.

BIP 32 uses 512 bits because the value is split in half for two 256 bit values. One of those is the private key, the other is the chaincode.


What does the main_chain value returned by blockchain.info mean?

If a block is part of the main chain, that means that the tip of the blockchain is a descendant of that block.

If a block is not part of the main chain, that means there is a longer chain of blocks that does not include this one. These are called orphaned blocks or invalid chains.

If a block is in the main chain, its parent is automatically in the main chain too.

In the above figure, the black boxes are the main chain. The grey blocks are invalid chains. The green box is the genesis block.


Create a non-SegWit address in electrum wallet

I don't see any arguments in https://github.com/spesmilo/electrum/blob/b2be29b508deb310631cacfb51bb1561bce75ff9/electrum/commands.py#L795 to specify the address type similar to address_type used in Bitcoin Core's getnewaddress

As sipa also mentioned in the comments, "bc1" prefix is used for segwit addresses

I think Electrum uses the default address type of wallet for creating new address which is decided while creating new wallet. So you can resolve this issue by creating a new wallet and select appropriate address type.


Prices are set by the market, meaning that every individual decides what they will buy/sell their own bitcoin for, and the generally accepted price is an aggregate of all the individual prices.

If a bitcoin owner prices their coin it too high, no one will buy it. They will either have to reduce their price to a more reasonable level, or just go without a sale.

If they price it too low, the coin will sell immediately, and be taken off the market.  The buyer will likely price the coin higher, closer to the market value.

The sites that are buying/selling (such as CoinBase) are quoting the price they are actually willing to pay.   Other sites that provide information (Blockchain.info) are posting the results of their survey of multiple buyers/sellers.   It is possible that their data may be skewed or differ from the data on another site.  But a liquid market with lots of activity should keep those differences small.


Two bitcoin addresses - Can you link them together?

You will not be anonymous unless you take special measures to make it so.

If you simply not use the old address to receive new payments, in all likelihood there will be a point where the client will combine outputs from this address and your new addresses, and this will indicate that the addresses belong to the same person.

It will be somewhat better if you send all the coins from the old address to a new one (with change, so the amount you should send is lower than the total). Then everyone will know that coins moved from the old address to the new one, but they can't tell if they both belong to you or if this was a payment to another party.


RIPEMD160 was designed in the open academic community and not like SHA2 by a NSA competition... one may see this as security advantage.

160bit hashes do also have less space requirements (then sha256) on the blockchain as well as in indexes, etc.


Do Bitcoins mined in a pool automatically transfer to your wallet?

Generally, no.  Usually you have to specify the address in your wallet and the threshold minimum so the pool sends your funds.

Most pools require some kind of registration; Eligius.St only requires your wallet's payment address.


Blockchain and Bitcoin client difference of amount

You've probably sent TO an address in your wallet. The amount is shown as a net figure. I.e.it is a bit like you have transfered money from your left pocket to your right pocket. MultiBit just shows the fee that you have sent to the miner.


Following SegWit implementation, is BIP-146 signalling and implementation still on the docket?

Bitcoin-core already enforces low S-values as a standardness rule for transaction relay, but making a transaction non-standard does not cause a softfork.

BIP-146 does call for a softfork by making high S-values in tx signatures invalid, not just nonstandard.

The BIP also states that the majority of txs on the network already adhere to the low S rule, as of Aug 2016. To quote from it:

  The reference client has produced LOW_S compatible signatures since v0.9.0, and the LOW_S rule has been enforced as relay policy by the reference client since v0.11.1. As of August 2016, very few transactions violating the requirement are being added to the chain. For all scriptPubKey types in actual use, non-compliant signatures can trivially be converted into compliant ones, so there is no loss of functionality by these requirements.


If you are in London, you could go to the local meetup group and sell them directly http://www.meetup.com/London-bitcoin-meetup/ and there is also https://localbitcoins.com/ Both ways people can pay you in cash, with no fees.


Smaller transactions are easier to validate; larger transactions take more work in Bitcoin

Smaller transactions are easier to validate; larger transactions take
  more work, and take up more space in the block. For this reason,
  miners prefer to include smaller transactions.

This is not necessarily true. Miners do not validate transactions, nodes do. Miners generally are only aware of the current block template they are trying to mine. That's why it's important for a miner to connect to a node they trust, in order to get the block template. Miners will get block templates that prioritize transactions with the highest fee/kB. This maximizes the tx fees for the miner for mining the the block.

While it is true that larger transactions are harder to validate, a larger transaction is not harder for the miner to validate because it does not do validation. See Node Operation under Bitcoin Mining. It is also not harder for the miner to hash because it is only hashing the merkle root of all the transactions (along with the other header data) selected for the block. See Block Hashing Algorithm. The merkle root is the same size regardless of how many transactions it represents.

Users must compete for the higher fee/kB if they want a better chance that their tx will be included in the next block.

Edit: As an aside, extremely large transactions with lots of inputs can cost the network almost as much to process as they cost the sender in fees, because computing signature hashes is O(ninputs*txsize). For this reason, nodes limit transactions to MAX_STANDARD_TX_WEIGHT to mitigate CPU exhaustion attacks.


Can High CPU Droplets from Digital Ocean be used for Bitcoin Mining?

No, neither CPUs nor GPUs of any kind are of the slightest use in Bitcoin mining.  This has been the case for several years, since the introduction of ASIC miners which are now many orders of magnitude more efficient.

See In the ASIC-age, is it worth starting mining Bitcoin at home?


Error initializing block database. Do you want to rebuild the block database now?

As the question is already answered in the comments and there anothere question arouse about how to send API commands independently to the server from each node.

As Nick ODell gave a correct hint, in fact you need to prefix each API command like "getbalance" with "bitcoin-cli -conf="!

Thanks to Nick ODell!


CheckBlock() --> Checks the info inside a block
AcceptBlock() --> Additional checks + write to disk
ProcessNewBlock() --> Calls both of the above and also a function called ActivateBestChain(), which decides whether propagation to the network is warranted, among other things.
ConnectBlock() and DisconnectBlock() Append the block in question to the end of the blockchain (or take it off from there), linking it with the previous block's hash.

Bitcoin needs to be industrial-strength code, so expect to see checks everywhere, for anything that could possibly happen (i.e., >1 coinbase transactions in a block, etc.). Moreover, some database operations are atomic, there are decisions when to propagate new blocks to the network, and to further complicate matters, the source code itself is the best documentation out there (slowly changing though, Andreas' Book is just a start).

Let's start with CheckBlock(), which is called by other functions:

Its sequence of operations/function calls are:

CheckBlockHeader() --> checks mostly that the PoW is there;
fCheckMerkleRoot --> checks correctness of Merkle Root & that there are no duplicate transactions
Checks size of the block, whether 1st transaction is coinbase, whether there are other (obviously invalid) coinbase transactions, and only then it checks the transactions and whether the maximum number of sig_ops has been surpassed (which prevents 'a "rogue miner" from creating an incredibly-expensive-to-validate block."');

AcceptBlock() will make its own checks and write to disk;

So, in sum, CheckBlock() makes sure that there are no shenanigans within a particular block, AcceptBlock() will write to disk. ProcessNewBlock() calls both CheckBlock() and AcceptBlock(), here's its outline:

Call to CheckBlock(); verifying it's ok;
Call to AcceptBlock(); as you can see from the comment prior to the call, AcceptBlock() will write it to disk;
Calls and Checks whether ActivateBestChain() is successful

This leaves out ConnectBlock() and DisconnectBlock()...

ConnectBlock() and DisconnectBlock() Append the block in question to the end of the blockchain (or take it off from there).  These are complex functions, in my opinion they are ripe for a slow refactoring, but see the final note:

Final note:  I am not a bitcoin-core developer; if one could edit and help out here, I am sure this answer could be considerably improved.   I know one thing, though: the more you study the code, the better your understanding and appreciation of the industrial strength of this magic internet money.


Practical application of Electrum's Encrypt/Decrypt message feature?

Presumably, using a bitcoin public key you could encrypt a message, and only the person who controlled a private key associated with that bitcoin address would be able to read the message.

It's really a question whether you have confidential/private/secret information that you wish to share.

If you're looking for an hypothetical use case, imagine you paid your doctor in cryptocurrency for an embarrassing medical test, the result could be sent back encrypted such that only the person who paid can read it.

Or, Lets say you paid for software license online with cryptocurrency, the software key can be sent back encrypted such that only the person who paid could read the key.


libbtc: Where are the binaries generated?

How the console tells, maybe this is not the correct place, also because you receive a segmentation fault (core dumped) during the make check.

See ./test-suite.log
Please report to https://github.com/jonasschnelli/libbtc/issues

However, may you have installed the library in your system with the command sudo make install, this command puts the binaries of the library is a place where are all the libraries of the system?
Maybe you have only a failure in the check
But the last commit of this library is on Nov 4, 2018, and maybe this can be a signal of the motivation of your error.
I hope I clarify your idea


Difference between blockchain.info and cold storage

Does it mean that it's somehow a cold storage?

No. Cold storage means that the private keys for your Bitcoin are held in an offline machine and are never online. Using blockchain.info means that you are online, and the private keys are held in your browser. Furthermore, cold storage means that you have sole control of your private keys; with blockchain.info, you don't. Blockchain.info (or a malicious man-in-the-middle) can control your private keys by giving you bad javascript on the web page which steals your private keys.

  So what is the difference between having my coins at Blockchain.info compared to having the stored on my own computer?

When you store your private keys on your own devices, that means that you have full control of the private keys. That means that if you need the private keys for something like cashing out your BCH, then you are able to do so. It also means that your coins are less likely to be stolen by someone.


If the computer "disappeared", there is no way to get your Bitcoins other than finding the computer again.

You had a "wallet.dat" file on the there which stores the information necessary to access your Bitcoins. Without it you cannot access your Bitcoins.


Why does the Bitcoin client require at least one confirmation before I can spend?

There is no technical reason you can't spend it immediately. A transaction that is dependent on an unconfirmed transaction should be accepted by the network and should eventually make it into a block.

You will almost certainly have to include a transaction fee with the second transaction in order to get it accepted into a block immediately. Otherwise, you will be waiting some time before the second transaction gets committed into a block.


Well, are the transactions in the mined block verified also by the other nodes in the network, after checking the correctness of the nonce by the network?

Yes.

  If so, how many confirmation nodes are needed to say "yes, this correct mined block contains correct transactions! let add it to the blockchain"?

It doesn't work that way. If a node thinks a block is invalid, it doesn't relay the block. If all nodes who got the block in first place, thinks that the block is invalid, other nodes don't receive that block and it gets forgotten. If they think the block is valid, the clients add the block to their blockchain and relay it to other nodes.

  Can a well mined block be rejected by the network? Maybe by some malicious host ?

Yes, ISPs can do that (although big pools run their own ISP). But that's pretty hard (impossible) without the help of the miner's ISP.


According to https://github.com/bitpay/copay

Copay wallet is now Bitpay Wallet. Repo at https://github.com/bitpay/wallet

So you shouldn't be using the Copay app.
it also says

WE HAVE DETECTED SOME FAKE COPAY WALLETS ON THE GOOGLE PLAY STORE FOR ANDROID THAT WILL STEAL YOUR COINS

So you need to be certain you have a genuine non-malicious app.

If you have an old Copay non-custodial wallet app, and have forgotten it's password, and did not make unencrypted backups, and did not write down a recovery phrase or equivalent,  it is probable that the only hope is to use a brute-force guessing tool like BTCrecover (not an endorsement) along with anything you can recall about the length, composition and structure of the "PIN".
Remember that the most important job of the app is to keep out people who don't know the "PIN".


Is there a fallback plan if bitcoin's underlying cryptography is cracked?

No, there is no explicit, publicly-disclosed plan for this situation.

However, there is an implicit plan: when it becomes know that practical quantum computers are on the near-term horizion, the programmers responsible for maintaining Bitcoin at that point will create a hard fork or soft fork to introduce a new signature type, likely something based on Lamport signatures or Merkle signatures.

Users will upgrade their wallets to wallets which support the new signature type and spend their bitcoins from their old private keys to their new private keys.  This is pretty much identical to what Android users had to do for the SecureRandom bug.

This is all very easy if done in non-rushed manner, and fast quantum computing is still a ways off, which is one reason nobody is working on this now.  The other reason is that the proposed new signature types are all much larger than the secp256k1 ECDSA signatures we use now, so using them would increase block chain bloat.

Note: the question mentions the cracking of private keys from public keys, which could be done on a fast quantum computer using Shor's algorithm.  However, in the comments, the OP (B.T.) focuses on cracking SHA256 (which would likely be done using a different algorithm; I don't know which).

The answer above focuses on the private key problem, but the solution for the proof of work problem is the same: a hard fork or soft fork to change the hashing algorithm to make its most difficult value even more difficult.  Again, as long as we have months or years to make the change, this is an easy upgrade, so there's no sense in performing it prematurely.


Blockchain.com is not a blockchain node, it is an explorer. They have no constraint on following the same rules as a Bitcoin Core node, and can keep orphaned and forked blocks available if they wish to, and return all blocks they know of for a block height if they wish to.

In the main Bitcoin chain, things are as you say - Only a single block may survive at a given block height. If multiple blocks are mined for a given block height, the chain with the most amount of work done (essentially the block with the longest chain of descendant blocks) will be kept, and the other will be orphaned.


Simplest way of obtaining MtGox exchange rate via an API?

JSON can be a little hard to read because it's generally meant to be served without characters such as spaces and newlines that would make it human-readable.

Here's output from the fast ticker:

{
  "result":"success",
  "data":{
    "last_local":{
      "value":"136.87303",
      "value_int":"13687303",
      "display":"$136.87",
      "display_short":"$136.87",
      "currency":"USD"
    },
    "last":{
      "value":"136.87303",
      "value_int":"13687303",
      "display":"$136.87",
      "display_short":"$136.87",
      "currency":"USD"
    },
    "last_orig":{
      "value":"136.87303",
      "value_int":"13687303",
      "display":"$136.87",
      "display_short":"$136.87",
      "currency":"USD"
    },
    "last_all":{
      "value":"136.87303",
      "value_int":"13687303",
      "display":"$136.87",
      "display_short":"$136.87",
      "currency":"USD"
    },
    "buy":{
      "value":"136.10500",
      "value_int":"13610500",
      "display":"$136.11",
      "display_short":"$136.11",
      "currency":"USD"
    },
    "sell":{
      "value":"136.87250",
      "value_int":"13687250",
      "display":"$136.87",
      "display_short":"$136.87",
      "currency":"USD"
    },
    "now":"1381085718504609"
  }
}

The "result" item is always guaranteed to be there, but has of course varying content based on whether or not the call was successful. The "data" element contains a series of prices, with each name indicating its price.

Most JSON parsers in interpreted languages such as Ruby, PHP, and Python parse JSON into a hash or dictionary. You'd want the value of the "value" key of the "last" key of the "data" key.

Here's a one-liner version in Ruby for the v2 ticker:

ruby -e '%w(open-uri json).each{|b| require b}; open("http://data.mtgox.com/api/2/BTCUSD/money/ticker_fast") {|d| puts JSON.parse(d.read)["data"]["last"]["value"]}'

Or something a little more readable:

require "open-uri"
require "json"

open("http://data.mtgox.com/api/2/BTCUSD/money/ticker_fast") do |d|
  json = JSON.parse(d.read)
  puts json["data"]["last"]["value"]
end

Here's a one-liner version in Ruby for the old ticker:

ruby -e '%w(open-uri json).each{|b| require b}; open("https://mtgox.com/api/1/BTCUSD/ticker") {|d| puts JSON.parse(d.read)["return"]["last"]["value"]}'

Or something a little more readable:

require "open-uri"
require "json"

open("https://mtgox.com/api/1/BTCUSD/ticker") do |d|
  json = JSON.parse(d.read)
  puts json["return"]["last"]["value"]
end


Why does bitcoin create several "empty" wallet addresses?

Bitcoin doesn't "register" addresses on the blockchain. The reason I was having trouble looking up arbitrarily-generated public addresses on the testnet Block Explorer website is because I was searching for mainnet addresses, not testnet addresses. For example, addresses generated using the above https://bitaddress.org website are by default meant for mainnet, and are invalid on the testnet blockchain. If you use add ?testnet=true to the URL you will generate valid testnet addresses.

The exact differences between testnet and mainnet addresses are documented in numerous places online. Among them, the Testnet page on the Bitcoin wiki, which states:

  A different value of ADDRESSVERSION field ensures no testnet Bitcoin addresses will work on the production network. (0x6F rather than 0x00)


In Ethereum smart contracts is it cheaper to keep all the data, or delete old data?

You get a gas refund of 15000 for resetting a storage slot to zero, but you have to use this gas during the current transaction (more specifically, you get at most one half of the total spent gas as a refund). This means you can trade some cleanup with other operations, but you will never be returned such refunded gas in ether.

So the general idea is that if you e.g. have a crowdfunding contract, the function that checks whether its goal has been reached is cheap to execute even if it clears all the data and sends funds around.

But if all you do is to delete the data, you are probably better off just leaving it there, as the transaction that deletes the data will never be free.


How to convert scriptPubKey bytes to Bitcoin address?

You are not considering the op codes in the pub_key string.
For example, a script_pub_key could be OP_DUP OP_HASH160 [pub_key] ...
and you have to pull out the pub_key.
This sample code shows the addresses, you can check them against a block explorer for the same transaction id.  Note that the byte after OP_HASH160 gives the length of the pub_key in bytes after it, so it needs to be skipped as well to generate the address.

import sys
import base58
import hashlib
import binascii
from blockchain.reader import BlockchainFileReader
block_reader=BlockchainFileReader('/var/data/bitcoin-data/blocks/blk00325.dat')
satochi_convert=1e8
def sha256(x):
    h=hashlib.new('sha256')
    h.update(x)
    return h.digest()

def hashStr(buffer):
    return binascii.hexlify(buffer)

for block in block_reader:
    #block has .header, .transactions
    for iter,tx in enumerate(block.transactions):
        print('  Transaction (txn_hash):{} {}'.format(type(tx.txn_hash),tx.txn_hash))
        for x in tx.outputs:
            script_pub_key_str=hashStr(x.script_pub_key)
            if script_pub_key_str[0:4]==b'76a9':
                #This is a pubkeyhash
                bytes=x.script_pub_key[2]  #number of bytes in the pub_key
                assert bytes==20
                public_key = x.script_pub_key[3:3+bytes] #20 bytes
                z=b'\00'+public_key
                #checksum=sha256(sha256(z))[:4]
                #address1=base58.b58encode(z + checksum)
                address2=base58.b58encode_check(z)   # adds checksum for you
                print('  output value {:<20} address {}'.format(float(x.value)/satochi_convert,address2))
            elif script_pub_key_str[0:2]==b'a9':
                #this is a scripthash (pay-to-script address)
                bytes=x.script_pub_key[1]  #number of bytes in the pub_key
                assert bytes==20
                public_key = x.script_pub_key[2:2+bytes] #20 bytes
                z=b'\05'+public_key  #used for mainnet
                address2=base58.b58encode_check(z)
                print('  output value {:<20} address {}'.format(float(x.value)/satochi_convert,address2))
            else:
                print('  output value {:<20} other {}'.format(float(x.value)/satochi_convert,script_pub_key_str))
        print()

Sample output for first transaction in your block file is:

 Transaction (txn_hash): cc728403552d5e1fddf06e6a7e8552353f315be6c1a43a8e64e4d11b081d4ca3
  output value 25.17686501          address 1N6LrEDiHuFwSyJYj2GedZM2FGk7kkLjn
  output value 0.22864963           address 1Hr9uwzwXWpjQDNUWdZ1i9qnoSpnniJe4U
....

OP codes here: https://en.bitcoin.it/wiki/Script,
scriptpubkey info: https://en.bitcoin.it/wiki/Transaction
NOTE: this is just an example of how to calculate addresses, it is not very robust as it does not check other OP codes afterwards, other possible payment scripts, etc.


Is one lightning network channel equal to one transaction?

No you don't need to open a channel with everyone whom you want to pay.
The lightning network is a network of payment channels. This means that you can use the first channel to send money to other participants in the network as long as there are sufficiently liquid paths of channels from your node to the recipient.


If the transaction is confirmed, the process is done.  "Unspent" just means you haven't spent the coins yet.  But you can do so whenever you wish.


What is the number of transactions in a block?

The absolute limit is the size of the block, which is currently hard-coded at 1,000,000 bytes.  Each transaction takes up a variable amount of space, but ~250 bytes is about right for a simple (one-input one-output) transaction.

However as soon as a block is solved it is not possible to extend the block by adding in more transactions, as the proof of work has to be redone, so broadcasting it immediately is the only sensible thing to do. So the number of transactions in a block is actually a function of the number of transactions being generated over a time period and the time taken to solve a given block.

Blocks used to contain fewer than 200 transactions and the largest number of transactions in a block was 1,976 at the time this answer was originally written (May 2013). In meanwhile (November 2017) the average number of transaction per block is well above 1500 with peaks above 2200.


Is there any useful documentation on using the MtGox API with node.js?

The Bitcoin wiki has a nice example program:

var querystring = require('querystring'),
        https = require('https'),
        crypto = require('crypto');

function MtGoxClient(key, secret) {
        this.key = key;
        this.secret = secret;
}

MtGoxClient.prototype.query = function(path, args, callback) {
        var client = this;

        // if no args or invalid args provided, just reset the arg object
        if (typeof args != "object") args = {};

        // generate a nonce
        args['nonce'] = (new Date()).getTime() * 1000;
        // compute the post data
        var post = querystring.stringify(args);
        // compute the sha512 signature of the post data
        var hmac = crypto.createHmac('sha512', new Buffer(client.secret, 'base64'));
        hmac.update(post);

        // this is our query
        var options = {
                host: 'mtgox.com',
                port: 443,
                path: '/api/' + path,
                method: 'POST',
                agent: false,
                headers: {
                        'Rest-Key': client.key,
                        'Rest-Sign': hmac.digest('base64'),
                        'User-Agent': 'Mozilla/4.0 (compatible; MtGox node.js client)',
                        'Content-type': 'application/x-www-form-urlencoded',
                        'Content-Length': post.length
                }
        };

        // run the query, buffer the data and call the callback
        var req = https.request(options, function(res) {
                res.setEncoding('utf8');
                var buffer = '';
                res.on('data', function(data) { buffer += data; });
                res.on('end', function() { if (typeof callback == "function") { callback(JSON.parse(buffer)); } });
        });

        // basic error management
        req.on('error', function(e) {
                console.log('warning: problem with request: ' + e.message);
        });

        // post the data
        req.write(post);
        req.end();
};

var client = new MtGoxClient('mykey', 'mysecret');
client.query('1/BTCUSD/public/ticker', {}, function(json) {
        // do something
        console.log(json);
});

Here's documentation for the v1 API


NXTcoin Startup - Error: Could not find or load main class nxt . Nxt

You have to first compile by doing:

./compile

then:

./run.sh


Clarification on the script P2SH, how is executed to Bitcoin core?

Let's go over this step by step. Suppose say you want to lock some bitcoins in a 2-of-3 multi-sig.

Locking steps

Create a multi-sig script: OP_2 <pub_key 1> <pub_key2> <pub_key3> OP_3 OP_CHECKMULTISIG.
Hash the multi-sig script with HASH160 which gives you multi-sig_scripthash.
Base58Check the multi-sig_scripthash with version 0x05 giving you an address starting with 3....
The scriptPubKey will be OP_HASH160 <multi-sig_scripthash> OP_EQUAL.

Unlocking Steps

Your stack will start at <signatures><redeemScript>. The signature is OP_0 <sig_A> <sig_B> and redeemScript is OP_2 <pub_key 1> <pub_key2> <pub_key3> OP_3 OP_CHECKMULTISIG.
Since v0.3.7, Bitcoin Core executes the unlocking script first and looks at the resulting stack. So your <signatures> and <redeemScript> are evaluated together first. This would result in a multi-signature evaluation.
In normal cases the above step should just return 1 as signatures satisfy the redeemScript. But with P2SH there is a caveat added by BIP-16. Whenever you have a OP_HASH160 <hash> OP_EQUAL locking script, it serves as a P2SH identifier. So before the evaluation of <signatures> with <redeemScript> the redeemScript is copied from the stack to another one. Then the evaluation is done with what is on stack (<signatures><redeemScript> in our case). If successful, replace the current stack with the just redeemScript. Hence, instead of 1 you have <redeemScript> at the top of the stack.
You run OP_HASH160 on the redeemScript. Stack is now <hash160_of_redeemScript>
You push <expectedredeemScripthash>. Stack is now <hash160_of_redeemScript><expectedredeemScripthash>
You run OP_EQUAL resulting in evaluation and returning 1 to the top of the stack.


Bitcoin Core no longer contains any mining code, so it's definitely not mining.  (If it were, you'd see 100% CPU usage.)  Mining has nothing to do with the behavior you are seeing.

You're downloading the entire block chain (150+ GB) and checking it for validity, which explains the CPU usage.   The UpdateTip message simply records that you've received a new block, and you've checked it and determined that it is a valid addition to the blockchain.  This is normal behavior for Bitcoin Core or any other full node, and is inherent to its operation.

I see you have enabled pruning, so that will save disk space.  It won't save bandwidth or CPU though.  If you don't want to use that much bandwidth, don't use Bitcoin Core.  There are other "thin" wallet clients that don't need to download the entire blockchain - the tradeoff is that you have to trust other nodes to tell you that transactions are valid, instead of being able to check it for yourself.


How to avoid conflicts in a peer-to-peer topology (Bitcoin)?

The mempool is just a temporary store of unconfirmed transactions. Each node's mempool is not synchronized, and in fact a node could choose to not keep a mempool at all. So no node needs to verify whether anyone else has a transaction, before deleting it from their memory. Miners will choose transactions from their mempool, to build new block templates that they will mine on.

What matters is the blockchain. Each new valid block will (likely) include some transactions, so when a node hears about that block, it will update its mempool accordingly (removing transactions that have been confirmed in the block).

Thus, miners can all be attempting to mine a block that includes the same (or different) transactions, and it is simply the first miner to find a valid block that will 'win', with their block being appended to the blockchain. All other miners will see this new block, and start to mine on top of it, adjusting their mempool (and thus the transactions they include in their new attempts to find a block) accordingly.


if I have 1 BTC on my address, suppose I run a mining node, what prevents me from trying to mine a block in which I spend 1.2 BTC ?

This is the specific set of code in Bitcoin Core that rejects anyone's transaction who's is putting less money into the transaction (inputs) than the recipients are receiving (outputs), e.g. spending more money than they have added to the transaction:

const CAmount value_out = tx.GetValueOut();
if (nValueIn < value_out) {
    return state.DoS(100, false, REJECT_INVALID, "bad-txns-in-belowout", false,
        strprintf("value in (%s) < value out (%s)", FormatMoney(nValueIn), FormatMoney(value_out)));
}

Technically, this isn't checking the "balance" of an address, since in Bitcoin system itself, addresses don't have balances.  When you receive bitcoins, you receive them to an individually-identifiable output (payment).  When you spend bitcoins, you identify exactly which output (or outputs) you want to spend and spend all of that value at once.

If you want to pay someone less than the full value of one of your outputs, you add an extra output on to your payment that returns the remainder to yourself.  This is like paying for a $2 snack with a $5 bill and receiving $3 change back to yourself (and it Bitcoin, we call that extra output paying yourself the "change output" by analogy).

So in the code above, by checking every single spend in the system to prevent anyone from receivng more bitcoins than were initially spent (except for newly-minted bitcoins), we prevent negative balances.

  At what point in the process is the balance of my adress checked to make sure I do have the bitcoin that I want to spend ?

As explained above, inputs and outputs (rather than address balances) are what's checked.  They're ultimately checked when a block is received; however, the software may check them for unconfirmed transactions and cache the result so that it can process newly-received blocks faster.

Somewhat related, you also can't pay someone a negative output:

    if (txout.nValue < 0)
        return state.DoS(100, false, REJECT_INVALID, "bad-txns-vout-negative");


Where is the configuration file of Bitcoin-Qt kept?

The location of bitcoin.conf depends on your operating system:

Windows XP             C:\Documents and Settings\<username>\Application Data\Bitcoin\bitcoin.conf
Windows Vista, 7, 10C:\Users\<username>\AppData\Roaming\Bitcoin
Linux                         /home/<username>/.bitcoin/bitcoin.conf
Mac OSX                  /Users/<username>/Library/Application Support/Bitcoin/bitcoin.conf

Source


How can Node B certify that block x is an invalid block

At a very basic level: a blockchain is a hash-linked list. Each block references the hash of the block preceding it, so any modification to a past block will be obvious, because that block's hash will no longer be a part of the longest chain.

The situation is trickier for a new node that is hearing the history for the first time though, or during a time when there are two valid competing chain-tips. Which chain-tip should be considered valid?

Bitcoin uses proof-of-work to decide which chain is valid: the one that has the most work accumulated (often termed 'the longest chain'). You cannot fake work being done, and so the competition amongst miners is what secures the network's history from tampering.

Without an objective measure (ie, energy spent creating a PoW), it can become very difficult to determine the valid chain in the event of a chain-split. You could create a system of voting, but such a system relies on subjective measures, and as such may be more game-able by network participants.


This is a normal transaction for an exchange paying out their users. The inputs are from user deposits and the outputs are for user payouts. It's very hard to know without a look at their database who owns which address, but this type of transaction is very common for large services like exchanges.

The reason there are so many inputs and outputs is that it's a lot cheaper for the exchange to send out 1 big transaction instead of many little ones.


What is the Lightning Network proposal? What problem is it trying to solve?

Two issues with Bitcoin's design
Scalability of "everyone checks everything"
Bitcoin is a gossip network:
P2P nodes connect mostly randomly to each other and pass-on new information to each other as they receive it. That way, information floods through the network quickly: each step further increases the nodes that were informed exponentially (until most are).
In Bitcoin every node receives and checks every piece of blockchain data, currently some are relayed even more than once. While this is a manageable problem at 1 MB blocks, this setup has a real cost: bandwidth usage, CPU load for verification, and storage-footprint on the hard drive.
At 1 MB, the Bitcoin network can support about 3 transactions per second (tps). To scale up to Visa-levels we'd likely need around 3,000 tps. To serve all internet commerce, a multiple of that. While there are some gains possible with more efficient use of the space we have (CoinJoin, Schnorr Signatures, …), it is obviously a much harder challenge to manage ~1 GB blocks every ten minutes. At that point, relay bandwidth would be a multiple of that, verification of 144 GB blockchain data per day would take a significant portion of an average home computer's computing power, and hard drives would tend to fill up fairly quickly.
It follows that there is a limit to what can be done with pure on-chain scaling.
Instant payments
Early Bitcoin merchants were comfortable to take the risk of accepting zero-confirmation transactions. The "first-seen" principle was firmly established as a node policy and even transactions without fees would confirm eventually.
Since then, blockspace demand has increased, some miners changed their policy to mine the transaction with the most fees instead of the "first-seen", and zero-fee transactions have become infeasible.
Meanwhile, payment processors and some merchants still take the calculated risk of accepting transactions before confirmation, but generally, a transaction is only reliable after it is confirmed.
Lightning Network
The Lightning Network (LN) proposal describes a structure to provide secure, instant transactions negotiated only among the involved users.
LN leverages payment channels, a type of multi-signature construct, to create jointly managed balances between pairs of users. By re-negotiating the balance's payout shares, the users can instantly transfer balance to each other. Each re-negotiation is recorded as an update to the smart-contract securing the funds of both parties.
By having multiple connections in the network at once, users can receive balances from one partner and forward them to another. Leveraging this network, Lightning Network is promising instant payments to every other LN participant and increased transaction capacity at a low-cost.
Should a user wish to close a payment channel, the smart-contract's current state can be executed on the Blockchain as a regular transaction.
Interested to read more? See → How does the Lightning network work in simple terms?


How can I get logging information on incoming transactions with bitcoind?

If you run the daemon or the GUI (bitcoin-qt) using the debug=1 argument, then bitcoin will write a variety of events to the debug.log file, including info about transactions received by your node.

I just ran a test to confirm this. You could follow these steps if you want:

(1) From the terminal window, start bitcoin-qt like this: $bitcoin-qt -debug=1

(2) Navigate to the /.bitcoin folder: $cd .bitcoin

(3) View the last few recent entries into the debug.log file: $tail debug.log

When I did this, I saw the following entry:

2017-11-21 12:58:54 AcceptToMemoryPool: peer=3: accepted 4e1a7429f28c7410e177bf3278aca76b6e32e097ed8d87dbd18980de9c23f343 (poolsz 18765 txn, 94644 kB)

I then copied the transaction ID and cross-referenced it at blockchain.info:

https://blockchain.info/tx/4e1a7429f28c7410e177bf3278aca76b6e32e097ed8d87dbd18980de9c23f343

And as expected, it was there as an Unconfirmed Transaction (which makes sense because the log entry mentions "AcceptToMemoryPool", so it sound like my node received a transaction from a peer, and has decided to put it in the mempool - that's just my guess, maybe I'm wrong)


How is the PRIVATE KEY actually created in the first place?

Speaking of bitcoin (other cryptocurrencies may do things a bit differently but the principles will likely be similar) and simplifying slightly (i.e. not discussing stuff like segwit).

For ECDSA a private key is simply a large (psuedo)-random number. Depending on the particular wallet implementation the private key may be generated and stored, or it may be generated deterministically from a master secret.

The public key is then derived from the private key and the bitcoin address is derived from a hash of the public key.

Bitcoin transactions have "inputs" and "outputs", normally the total value of the outputs must be less than or equal to the total value of the inputs, but there is a special transaction called a "coinbase transaction" that can introduce a limited number of new bitcoins per block and also collect any transaction fees from other transactions in the block. An input of one transaction must satisfy the conditions set in the output from another transaction to spend the value represented by that output.

There are several types of output, but the normal one is/was "pay to pubkey hash". The output contains a hash of a public key (aka a bitcoin address) and the corresponding input must contain the corresponding public key and a digital signature made with the corresponding private key.


AFAIK there is no way to incrementally make. You either make or you don't.

But, you could try >make bitcoin-qt and see if it just makes that module? Nope:

>make bitcoin-qt
make: *** No rule to make target 'bitcoin-qt'.  Stop.


Your bitcoins belong to an 'account' that can only be accessed by using a private key, which is in your wallet. You can have copies of that private key/wallet in many places. They all access the same account.

I like to think of it this way... The bitcoin network is like a massive bank full of billions, trillions, and so on of vaults. You can put coins into any vault without needing a key to that vault. You can only take coins out of a vault IF you have a key to that vault (your wallet). Your coins are never stored on your actually computer. Only the KEY to the vault is stored on your computer. That key is used to access your coins. Downloading the blockchain is simply a way of letting your bitcoin client know how many coins you have, who you sent coins to, and who sent coins to you. Its like a virtual copy of those billions of vaults, which mostly all you don't have access to. Only that vault whose key you possess. Good luck!


Because a "segwit address" starting with a 3 is actually a specific type of P2SH, the scriptPubKey will just be a normal P2SH scriptPubKey, which doesn't reveal anything about the script itself (only a hash of the script). You need the redeem script, which will be a null byte followed by a push of the public key hash. From what I can recall, the script is output in the hex field of the validateaddress result.

Again, the public key hash doesn't actually reveal the public key, so once you have that there will probably be an extra step required, perhaps conversion of the public key hash into an address starting with a 1 and then validateaddress on that.

It is unfortunate that the support for segwit addresses is not great in version 0.15.x, it'll be much better in 0.16 when Peter Wuille's segwit wallet PR is merged


is it possible to launder bitcoin by exchanging it for litecoin and then back to bitcoin?

Because all transactions in both Litecoin and Bitcoin are stored in the block chain, you run into the same issue you do here if you were just to try and withdraw USD for bitcoins, i.e., does your intermediary store logs of the off chain transactions? When you buy LTC using BTC on Kraken, if Kraken decides to log this transaction then there is now a link between the BTC and the LTC. This link could be used by law enforcement if they are trying to trace some dirty BTC. From an LEO point of view, this is how they would follow the money:

Use the BTC blockchain to trace the money to a Kraken account.
Ask Kraken for information about where that money went. Kraken gives them an LTC address.
Use the LTC blockchain to trace the money to another Kraken account.
Ask Kraken for information on where the LTC went. Kraken gives them a new BTC address.
Use the BTC blockchain to follow the "laundered" money.

The blockchain stores all transactions. The only way to clean money is to do some sort of transaction off of the block chain. To do that you need an intermediary who is willing to do that for you, and take the risk of LEO or some other regulatory firm calling them on it. Shady mixing pools might be willing to do this for you, but Kraken or other legitimate commercial exchanges will not.


The answer is yes, but not anytime soon.  Also, it's a function of how frequently channels are opened and closed, which can be estimated, but is not "really" predictable.

If you read the LN whitepaper [link], it mentions in the conclusion that "to enable 7 billion people to make two channels per year with unlimited transactions inside the channel, it would require 133 MB blocks"


Incentive for miners to keep mining once reward get very low

it will be less and less rewarding to keep adding hashing power for the miners to protect the network and more and more tempting to try a 51% attack even if it just for breaking the confidence in the network.

This is a pretty weak assumption. We don't make any calls for necessity in the Bitcoin hashrate growing, there's no security assumption around that, it's just an observed property that presently it happens to be growing.

Bitcoin miners are assumed to be operating with a single goal: profit. If somehow causing the thing which is giving you profit to fail is adventurous to you, then we can just rest easily on the knowledge that the underlying basis for Bitcoin to exist is incorrect.

  The incentive to play the game fair and keep mining is pretty high, but what will happen once that reward get very low like 1 bitcoin or even less, even if the price get big like > 100 000 dollar it will be less and less rewarding

If the cost for operating the hashrate exceeds the revenue generated, miners don't mine. The whole system ends up with an equilibrium of having barely profitable mining hardware- regardless of how much profit there is to be made doing it. If the fee volumes don't ultimately cover for this, there will be less mining.

  forever keep a sufficient amount of machines ready to be powered ON at any sign of a 51% attack attempt

You assume incorrectly. There is not large farms of idle hardware simply laying around. Large facilities require a significant amount of upkeep, large amounts of power are not available instantaneously, and if there was large amounts of ready-to-go obsolete hardware, it would doubtlessly be so inefficient as to be worthless towards any cause.

  so what could be the solution to keep the network protected

Failure of the incentives means complete failure of Bitcoin as a whole, to pretend otherwise, or to pretend that there's some secret bullet which hasn't already been deployed, is disingenuous.


Deciphering cgminer interface in terminal

Bitcoin Forum > Bitcoin > Mining > Mining software (miners) (Moderators: gmaxwell, MiningBuddy) > CGMINER ASIC FPGA miner monitoring fanspeed RPC linux/win/osx/mip/arm/r-pi 3.9.0

Cite:

A:   The number of Accepted shares
R:   The number of Rejected shares
HW:  The number of HardWare errors
WU:   The Work Utility defined as the number of diff1 equivalent shares / minute

 AVA 0: 23C/ 47C 2280R | 77.10G/83.20Gh/s | A:120029 R:0 HW:2295 WU:1162.5/m

Each column is as follows:
Temperature (if supported)
Fanspeed (if supported)
A 5 second exponentially decaying average hash rate
An all time average hash rate
The number of accepted shares
The number of rejected shares
The number of hardware erorrs
The Work Utility defined as the number of diff1 equivalent shares / minute

The cgminer status line shows:
 TQ: 1  ST: 1  SS: 0  DW: 0  NB: 1  LW: 8  GF: 1  RF: 1

TQ is Total Queued work items.
ST is STaged work items (ready to use).
SS is Stale Shares discarded (detected and not submitted so don't count as rejects)
DW is Discarded Work items (work from block no longer valid to work on)
NB is New Blocks detected on the network
LW is Locally generated Work items
GF is Getwork Fail Occasions (server slow to provide work)
RF is Remote Fail occasions (server slow to accept work)


What is the impact of purposely sending a signed message with zero fee?

The underlying motivation behind transaction fees is to compensate for resource utilisation as there is always an inherent cost when validating transactions (Electricity - CPU usage) and relaying transactions (Internet Bandwidth). Another reason why there's transaction fees is also to deter spam.

By purposefully sending a signed message (with no fees) to the Bitcoin network, what you're effectively trying to do is use these scarce resources for free and therefore it is perfectly possible for participating nodes to refuse to relay/process your transaction.

However, you may use a signed message with zero fees to prove that you're in control of a unspent transaction output for example. Instead of broadcasting this directly to the Bitcoin network, what you might do instead is send this to one party who requires this "proof" privately and so as long as the UTXO is valid (i.e. committed in the Blockchain already), then your signed message with zero fee is as convincing as it gets to sufficiently prove that you have the funds to do whatever it is you want to do.


Let's say I found a tarball with blockchain data files which I load to my datadir and start my Bitcoin Core client, what sort of attacks am I vulnerable to? Could the files contain fake balances?

It depends. If you're just importing blocks (so no chainstate/ subdirectory with UTXO set), there should not be any possible attack. The client will validate those blocks at startup time, just as if they were being received from the network, to rebuild the chainstate. If one of the blocks was modified, it would be rejected as an invalid block at this time, and the correct blocks would be requested from the network instead.

However, if you accept a chainstate from someone, anything is possible. They can convince you they have unlimited amounts of money, or convince you they have paid you in the past. For any future transactions relying on such faked funds, getting to confirm them would require cooperation from a miner that is willing to build an invalid chain to defraud you (or others, in case many people used that chainstate "backup").

  If yes, what will happen if another peer requests a block which has altered data in it, how will that other peer handle this situation?

Blocks can't be altered without invalidating them, so other peers downloading blocks from you can't be affected. Similarly, a -reindex would fix any problems for yourself as well.


How to install a Bitcoin client on Ubuntu Server

Once you've installed bitcoind, you should create a configuration file (stored in ~/.bitcoin/bitcoin.conf) containing at least an RPC username and password, and then you just run bitcoind to start the server.


What is the purpose of Merkle Tree in blocks?

Btc wiki: Merkle Trees

A Merkle tree is a hash function value which can be used to validate that every piece of information in a block can be authenticated, in this case, it validates that for each Tx and its hash value, it has not been tampered with in any way, shape or form.

Let's use an analogy: assume we have a file cabinet of files, each file in numerical order. Now, assume each file is sealed with a wax stamp, and each wax stamp has the date spelt in words. If we changed the date at all, the words make it so there's no longer a match (1==>7 is easily done, but not one==>seven!). So we're sure each file (Tx) is legit. Now assume the filing cabinet has the sum of the number of letters used in those words on the Txs' stamps. Any change that was made, say one==>seven has changed the sum of the letter, since seven is two letters longer than one. This is a simplistic analogy of how hashes can easily authenticate a piece of data.

Furthering the analogy, each block (filing cabinet) has a combination lock which references the block (filing cabinet )before that. So minor changes in even one single letter of a single Tx in a single filing cabinet (block) will invalidate whole system.

I recommend looking into the Wikipedia cryptographic hash entry to get a deeper understanding, or books like Mastering Bitcoin


Would migrating my coins to a segwit (bc1) address reduce my fees as I send them out?

I'm thinking of migrating all my coins to electrum 3 as a segwit (bc1) address. Then, would my fees be smaller?

When you send your coins to bech32 addresses, the fees will not be smaller. However the fees will be smaller when you spend from those bech32 addresses.

  And if I exclusively use electrum 3, would I be able to send my coins to legacy addresses (1...) without any issues?

Yes.


How do I set up IRC bouncer to receive messages and follow the discussion while I am offline?

On some IRC channels such as #bitcoin-core-dev there are third party managed conversation logs so you can follow the conversation from when you were offline without setting up a bouncer. However, I don't think (at the time of writing, September 2020) that there are conversation logs for the #bitcoin-core-pr-reviews channel except for the weekly meeting which is logged on the Bitcoin Core PR review club site. You definitely can't receive messages whilst you are offline.
There are various options to set up a bouncer but in the interests of simplicity I will just outline one assuming you followed the instructions here to install Textual on MacOS.
You will need a virtual private server (VPS) to be running 24/7 to log the discussion and receive messages on your behalf and then you can connect to that server whenever you come back online. This will require a monthly subscription.
So your first step is to choose a VPS provider. One easy to use option is Digital Ocean but there are others that perform the same function and are equivalently priced. (We generally avoid product recommendations on this site so please excuse this counterexample.) You can connect directly to your VPS/Digital Ocean Droplet with SSH using the instructions here. There is a tutorial for setting up SSH keys here.
Once you have set up your VPS you will need to install ZNC on that server. Instructions for doing that are here (deprecated but easier to follow and should still work) or here. The latest ZNC release is available here. You can ssh into your VPS using:
ssh -i /path/to/private/key root@IP_address_of_VPS

Instructions for connecting your Textual client to the ZNC bouncer are here.


when are old blocks verified by each full node?

never unless rescan=1 command-line option passed to

  From what I've seen, the possible answers include: when it's downloaded and when you do a -rescan.

yes, on downloading also of course

one of my .dat files is broken (some garbage in contents) but bitcoin-qt works well because it uses UTXO, not blocks themselves

  if I change the contents of an old block (and thus break the hash chain)

this depends what do you mean.


Mining operations: what's allowed and what's not?

I think you miss general understanding about the Bitcoin mining problem. Try reading "Bitcoin mining in plain English", a good article trying to explain mining the easy way.

I'll answer your different questions, but some of them are quite irrelevant.

What are these competitions/races called? Block bids? Block challenges?

I assume you mean proposals here. A block try must satisfy certain conditions to be valid. Once a miner finds a valid block, it broadcasts it through the Bitcoin network so that other miners and clients can verify it and, if it is valid, add it to their block chain.

What software announces to all the miners that a new "block bid" is ready? In other words, how do miners know to start competing with each other?

Miners don't compete. When a miner finds a block, it announces this via a Bitcoin client. All other miners will stop their current search for a block and start to find a new block that is valid to follow the last block found by another miner.

It is important to understand that the mining problem does not get's easier to find when you try longer. Every try for a solution has an equal chance of success. It's just about making many tries. So when another miner finds a valid block, it is no problem for you to slightly change the problem you are working on because every try still has an equal chance.

What software do miners use to compete with? bitcoind? Something else?

Miners can announce their new blocks with any client that implements the protocol. bitcoind is an obvious choice. However, many people do pooled mining, by which a mining pool gives them parts of the problem and the pool will announce new blocks when one miner finds the solution. This means that pooled miners don't need a Bitcoin client like bitcoind to mine, but only a miner program that supports pooled mining.

Can miners write custom software the interfaces with #3 above (bitcoind or other), or is that "not allowed"?

If I understand this right, you ask if miners can write their own Bitcoin clients to announce their blocks? Of course they can. Bitcoin has an open protocol and every client that correctly implements this protocol will be accepted by the network.

Can miners divide a "block bid" problem over multiple computers, or again, is that "not allowed"?

Of course. This is what mining pools do essentially. They distribute the problem over all miners that are registered with it. When one of them finds a block, the reward is shares among all connected miners, proportionally with their relative contribution to the problem solving.

What's allowed and what not?

To answer your question heading: everything is allowed.

You can use whatever techniques to do Bitcoin mining. It is an essential part of Bitcoins security that you cannot cheat, because everything is allowed.

However, when you don't follow the Bitcoin protocol, none of you actions will be accepted by the network. So basically, you can do everything, but there are things that you should not do, because the other people in the Bitcoin network will just ignore you when you do.


Which coins can butterfly-labs miners mine

Look at http://dustcoin.com/mining.  The currencies designated as having SHA-256 algorithms (e.g., Bitcoins, PPCoins, Namecoins, and Devcoins) stand a good chance of being mined with BFL-like ASIC mining hardware. Remember, some currencies support merged mining - mine once and get paid in multiple currencies. Either your centralized pool supports merged mining or you have to do it on your own.


Filter transactions by time on a given address

Not exactly what you were looking for but there's a site that does exactly this, check it out.

https://goochain.net/

Filter on dates/ find adresses with partial numbers etc.


Are the capabilities of Namecoin a strict superset of Bitcoin?

The amount of NMC required in order to register a domain name is fixed by the protocol.

Having NMC and BTC be separate currencies ensures that the number of BTC needed to register a domain name is set by market pricing mechanisms, not by the hardwired protocol.

If we used NMC for buying and selling things other than BTC, it would be like denominating all of our economic activities in terms of domain name registrations ("this pizza will cost you 0.012 domain name registrations").  This is a bad idea because the demand for domain names would indirectly influence the price of everything else in the economy.  It's the same reason why the precious metal with the fewest industrial uses is the best one to use as money.

This is why I think that any non-Nakamoto-blockchain currency with a significant use other than currency doesn't detract from the value or usefulness of the Nakamoto chain.  The fact that they can be used as something other than a currency makes them really poor currencies.  The fact that it's easier to exchange them for BTC than for fiat actually slightly increases the usefulness of the Nakamoto chain.  But of course all of this applies only if the alternate chain has a credible non-currency use.  So far I don't know of any other than NMC.


A Bitcoin block can contain only 1 mb of data. A transactiom averages around 255 bytes. A block is built about every 10 minutes and the blockchain forces the difficulty to do so. So per hour, only around 6mb worth of transactions can pass, however there's a much higher demand due to Bitcoin's popularity. If only X transaction can fit in a block but five times X would like to do a transaction, only the highest bidding  X number of transaction will proceed. At this point it's basic supply and demand understanding.


Format of comment parameters on bitcoind sendfrom command unclear. Attempts result in 'error: type mismatch'

It appears that you are missing the field "minconf", probably setting that to any value would allow you to call the function properly.


Is it better to compile bitcoin node or rather for some reason just use the official binaries?

if you can compile your node, do it. well done! for most of the users it is technically nearly impossible to compile a bitcoin node because most of people have not enough technical knowledge. bitcoin.org provides binaries so that all people (who have not the time and knowledge to compile it) can also run a node.

hint: if you want to be 100% sure that you have a legit node, you must compile the libraries which a bitcoin node uses too, because the websites/binaries of every library which will be used by a bitcoin node can also be hacked theoretically.


Short answer: Yes, this is probably a bug in the block explorer.  blockexplorer.com shows a positive balance.

Some of the transactions shown there are "strange" (they presumably have non-standard scripts which someone was experimenting with), and this probably is tripping up the biteasy explorer.

Note that the notion of "balance" of an address only really makes sense when using "standard" transactions, where the output script says: to spend these coins, provide a public key whose hash is the address X, and a signature made by the corresponding private key.  For fancier transactions, "balance" gets more fuzzy.  For instance, I could make a transaction that requires signatures by two private keys, corresponding to addresses X and Y.  Should those coins be "credited" to both addresses, or neither?  Either way the books will not balance.


How doest the bitcoind command "move" work?

I think it refers to the accounts having a shared pool of money. When account A gets a deposit, the account gets a tally and it goes into the pool. When account B gets a deposit, the account gets a tally and it goes into the same pool. Moving money from A to B doesn't actually move the money address-wise, just changes the tallies. So if account A withdraws MORE than account A had deposited, part of that money will come from account B's deposit.


How can Segwit increase transaction throughput if the same amount of data is stored in the blockchain?

The answer to the question "Are the segwit witnesses part of the blockchain" depends on what you define as the blockchain:

According to old pre-segwit nodes, the answer is no, as they don't care or receive the witnesses.
According to new segwit nodes, the answer is yes; the witnesses are as much part of the chain as everything else, and subject to just as many validation rules.

So segwit increases throughput slightly, at the cost of increasing the size of the blockchain. There is no magic bullet here, and this aspect of segwit is simply a block size increase. It is not a scalability improvement.

Segwit was primarily a solution for the transaction malleability problem, opening the door for various higher-level protocols that were handicapped by being unable to reason about future on-chain transactions that weren't published yet. In addition it also improved he incentive structure a bit (making spending relatively cheaper w.r.t. creating outputs). As a final side effect of that, it also increased the block size a bit in a backward compatible way.

As for your question about another fork that goes even further: what your software does has no effect on those who don't adopt it. Even if it has all the hashrate in the world on board, old nodes won't care or see your additional data.


getnewaddress and watch-only addresses (importaddress)

I don't thing your approach makes sense. Why would you importaddress as watch only and give them out over getnewaddress? Do you try to missuse bitcoind as a address database (importaddress = store  |   getnewaddress = retrieve)?

If you need endless amounts of addresses, you probably like to switch to Bip32 (a.k.a HDWallets). There is a experimental patch for bitcoin-core (https://github.com/bitcoin/bitcoin/pull/6265) which would allow you to call hdgetaddress without having the master seed (private key) in the wallet.


Just registered in bitcoin core...Gave my address for receiving, how long it takes for 1st transaction?

First of all, your Bitcoin Core client should be fully synchronized with the network, as @PieterWuille stated. This means your client should download and validate the entire blockchain. This may take a while to do because of the current size of the blockchain that is at roughly 124 Gb (Go have a look here). This is why this process might take a long while to complete, and your wallet will only reflect your transaction after it has synchronized.

However there are other possibilities that you can use if you aren't looking into heavy bitcoin mining and usage, or for starting purposes. You can have a look at bitcoin wallets (eg. Multibit, Bitcoin Wallet, and Breadwallet just naming a few) rather than looking at bitcoin core, just for starting out. There are also some nice online wallets and mobile wallets you can use, however, all wallets have some pros and cons to them, and maybe the best thing will be is to first read up about all the different wallets available, the main bitcoin site is a nice starting place together with the bitcoin wiki.

However, there is a small catch. Because your bitcoin has already been sent to your bitcoin core receiving address and is currently in the blockchain, you will have to wait for it to completely download to receive that bitcoin, or you can maybe read up on transferring your private keys but I am not very familiar with this and thus not sure if it will work.