Would it be possible to make a functional Bitcoin fork that confirmed a block of transactions every millisecond?

You couldn't make functional Bitcoin-like fork with that fast of block mining. There is a tradeoff between speed of block creation and consistency of the network. In Bitcoin the blocks are created infrequently enough that the entire network can agree on the canonical blocks quickly and transactions can propogate quickly enough of that they tend to get included in blocks fairly quickly (assuming that miners aren't ignoring them due to low/no fees).

If a fork aimed for a block generated a millisecond that would imply that network latency would result in thousands of blocks happening before you could even see the first one. In Bitcoin there are occasional forks of the blockchain due to propagation delays, but they are very quickly resolved by the network. A fork with millisecond blocks (and a large user base) would certainly have thousands of competing forks at any given time, and it would take tens of thousands, maybe even millions of confirmations before it became clear that a fork was dominant. (By which time, there would be thousands of forks of that fork.)

Plus, even without any transactions, each block has a minimum size of overhead, so the size of the blockchain would be growing at an outrageous rate. The same would apply to network bandwidth: the amount of chatter between the nodes would be outrageous: none of the nodes could keep up with the volume. Especially given that the volume would have so much duplication between all of the competing forks of the blockchain.

As Colin Dean points out, Litecoin has established a 2.5 minute target. So changing the target block generation speed is possible. But every time you go lower, the overhead and consistency gets harder.

What's the theoretical maximum? It's hard to say since so much depends on how globally distributed and large the network is. My wild guess, given current technology: anything much less than a minute would have a lot of forks and a lot of overhead. Anything less than a few seconds would almost certainly fail to achieve any kind of stable consensus about the blockchain.


How to get bitcoin bip32 public key from private key?

I need to know how to get the corresponding public key of a private key in hd-wallets, I don't need the derived ones but the public key who is related to the private I got.

A private key derived using the BIP32 hierarchical derivation is similar to any other one and the corresponding public key is obtained by "multiplying" your private by G, as for any other private key.
You want to use a specific crypto library for this operation, and I believe coincurve to be a good maintained Python binding to libsecp.
You can also use python-bip32 to simplify your use of BIP32 derived keys (relies on coincurve under the hood).


Cryptocurrency with less deflationary properties

It's technically possible to have a blockchain with any generation schedule, such as X% inflation per year or constant reward per block.

The main reasons for a schedule with an upper bound is:

The Austrian economics school, to which apparently Satoshi and a large part of Bitcoin's early adopters subscribe, says that the optimal situation is that the monetary supply is bounded.
If you want to have some long-term inflation you will need to choose what it is, and any choice will be arbitrary. "0% inflation" is a bit less arbitrary option to anchor on.
One of Bitcoin's key properties is that the monetary is supply is not manipulable, and it's perceptually easier to sell it on this point by saying "The protocol guarantees there will never be more than 21M bitcoins" than "The protocol guarantees that in the long term, there will not be more than 3% monetary inflation per year".


To add a new RPC, you need to write the function the implements it's action, add the function to the dispatch table, and update bitcoin-cli's type conversion table.

At the bottom of the RPC file you added your function to (in this case, src/rpc/blockchain.cpp, you will see a table that has all of the RPCs in that file as well as some extra information about them like category, name, and argument names. Add your new RPC to that table.

Next, if your command has any arguments which are not strings, open src/rpc/client.cpp and add those arguments to the vRPCConvertParams list there. In that list, you give it the RPC name, the index of the argument that needs to be converted, and the name of that argument.


reproduce CVE-2018-17144 (inflation bug) on regtest for learning

No, that's incorrect, there is two types of double spend:

single transaction spending the same utxo
multiple transaction spending the same utxo

CheckTransaction() which is called by CheckBlock() only validate the first case, not the second, the second is done by both Consensus::CheckTxInputs and CheckInputs(),

if you look at the code in CheckTransaction, it only check whether there are duplicated vins exists in the same transaction, it doesn't know whether the vins has been spent in another transaction.


You can just remove the current version and install the newer version since they are storing your details on your pc, not in the application itself.

What you can do as an extra action, is storing your backup phrase somewhere.


Looking For Bitcoin Communities in New York

You might want to look on meetup.com for these kinds of groups.


Bitcoin Core 0.18.0 in Docker container: Could not connect to the server

This was a very simple fix. Instead of regtest.rpcbind=127.0.0.1, I used regtest.rpcbind=0.0.0.0. The logs complain with a warning:
WARNING: the RPC server is not safe to expose to untrusted networks such as the public internet

but since I'm using regtest mode for development, it's not a problem.


A question about full nodes, lightweight nodes and merkle trees

I suspect you are confusing merkle roots and merkle trees.

A merkle tree is the binary tree of hashes. The leaves are individual transactions, which are hashed, and then the hashes hashed together until only one hash remains. That remaining hash is the merkle root. A merkle branch is a particular path down the merkle tree from the merkle root to a transaction.

Full nodes store the merkle root because it is part of the block header. The block header contains the merkle root so that the block hash itself will also commit to the transactions contained within the block. While the merkle root itself isn't generally used elsewhere, as part of the block header, it frequently needs to be sent out to other nodes which are downloading blocks. It is expensive to have to recompute the merkle root every time, so instead we just keep it so that blocks can be sent out quickly.

Furthermore, by storing the complete block header, when the transactions themselves are discarded in pruning, the block headers are kept and so that the header chain is still tracked. Without the transactions, it would not be possible to verify this header chain again if the merkle root were not being stored.

Full nodes do not store the entire merkle tree or any merkle branches. These are unnecessary for normal operation. When a SPV client asks for a merkle branch, it is computed on the fly.


Can I write my own pool software by using bitcoin API?

You can, of course! But you may start from some existing programs that do what you say, most are open source and well documented. And ask someone, it's very hard to do it on your own!


In Bitcoin, it is recommended that big amount of transactions wait for 6 confirmations and smaller amounts wait for 3 confirmations.
When a seller uses bitcoins to sell he must never deliver the product with an unconfirmed tx, because since it is in the mempool it can be modified. Once a new confirmation arrives the safer it will be to deliver the product.

If you want to improve it and for example accept unconfirmed txs without fear of the double spent, you should do like what Bitpay does, have your own application to generate wallets and a transaction link only understandable by your wallet software so you can use memopool transactions.

I do not recommend you to do that, I would wait those 3 confs at least to make sure.


Is it posible to create a transaction output that can either be reddemed by privK of Addr A or by privK of Addr B AFTER certain blockheight?

Certainly. You can do this with OP_CHECKSEQUENCEVERIFY which allows for relative timelocks.

The basic structure would look something like this:

IF
    <pubkey A>
ELSE
    "30d" CHECKSEQUENCEVERIFY DROP
    <pubkey B>
ENDIF
CHECKSIG

Read BIP 112 for more information.


How do Bitcoin devs make sure that their modifications do not affect the consensus rules or the running network protocol?

"Best-effort". Formal proofs don't help. All one can do is to write tests, like any other well-written piece of software.
They also maintain forks of some dependencies such as LevelDB and don't update some of them such as BerkeleyDB.
See What Went Wrong. Especially the 2013 hardfork wouldn't have happened if they could ensure an unchanged consensus protocol.


The process is not formalized precisely because only really non-controversial changes are supposed to make it in at all.

This hasn't always been the case, but is becoming more true in the last year.
Right now the process goes like this:

Start by thinking of some feature/improvement.
Convince the dev team(s) of the relevant parts (core consensus, wallets, other layers) that this is a good idea in the abstract, and it needs to be standardized.
Write a draft.
Get gmaxwell to assign a BIP number for reference.
Make everyone happy with the detailled draft.
At some point, the status of the draft changes to Accepted (based on actual agreement of all/most devs).

You can follow https://github.com/bitcoin/bips to see when changes are made.


When creating a transaction, how can you prove that you own your address without exposing your private key?

In Public-Private Key Cryptography, you can use your Private Key, (without sharing it with anyone), in a way to create a message that is completely tied to your Public key.

Anyone can look at that message, and your Public key, and deduce that the only way that message could be generated is by someone who knows the Private key, even though they don't know what the Private key is.

The fact that the message can be confirmed with your Public key proves that you must know the Private key, and must be the owner of the Public Key and the Wallet Address.

Think of it as a lock that is left closed all the time.
You can unlock the lock anytime with your secret key, without showing anyone your key.

Anyone can look at that lock, and come to the conclusion: "This lock must have been opened by the owner who has the key; no one else could have opened it", but you still never shared the key with anyone.


This is on the to-do list for the developers.  One proposal is to remove transactions that have been completely spent if they are fairly deep in the block chain (that is, there is minimal chance that a block chain reorganization could occur which would affect the transaction)


If an offline, never connected, Electrum wallet is lost, it can still be recovered?

Yes, the private key(s) can be derived from the seed. That's the point of deterministic wallets. The wallet that generated the seed does not need to be connected to the Internet in order for the seed to work.

The BIP32 wiki page explains the actual algorithm used to generate a very large number of private keys from a smallish seed.


The downsides outweigh the upsides: as you mentioned this would require a hard fork, and would leave everyone (not just mining farms) who owns a Bitcoin miner with a very expensive paperweight, and as such it's unlikely a large enough portion of the community is willing to make the change for it to be successful. It would require throwing away a significant amount of infrastructure.
I suppose one day if it were to become a problem where Bitcoin miners are colluding to try and rewrite the blockchain or censor transactions, then we could reevaluate this. However, mining already comes with such razor-thin margins that it is extremely unlikely miners will be throwing away their profits to do this: they would all have to agree to work against their own best interests.


Is there a point to vanity addresses if a new destination address should be created per sender?

Vanity address' purpose is generally in its name - vanity. You mainly use it to show off, like say in forum's signatures or general donation address, not for business in most cases. Usually you won't want to use a vanity address when you want to remain anonymous, which is what you try to accomplish by using a new address for each transaction. You can use the vanity address to mark your brand as well. For example, SatoshiDice's addresses all start with "1Dice".

Generally, you would use a vanity address if you can spare the computational power where people could see it quite clearly, and use the other addresses when you don't want to make an effort.


Why guiminer is using different amount of GPU each time I restart my copmuter?

Other applications can alter your GPU settings not just guiminer.

If you take a read over this question here it may reflect a similar circumstance which is causing a variable hash rate on your hardware. Without knowing your exact usage of your computer though I cant say for sure.


Does Bitcoin have a built-in life expectancy?

but never actually get there

Except at some point there will be a rounding error (as numbers are integers in the code) to zero new coins being mined.

  does this imply that the incentives for miners will also be reduced?

Not really. First of all the miners also collect all the fees from all transactions. That should compensate for the reduction in new coins being mined. Another factor is the price of Bitcoin, either in USD or by the time USD doesn't exist anymore, the number of aircraft carriers you can buy for 1 Bitcoin.

Rolling out a new chain will actually probably become harder and harder over time as the network effect causes people to use the chain that is most useful. The number of other people that use it is a big part of its usefulness.


Am I scamed? FA exchange trading company is fraud? They are requesting taxes

It is certainly not 'normal' for an exchange to demand 'taxes' in order to withdraw. If you have a positive balance on your account, and they are requesting that you send additional, new money to them, then I would say without a doubt this is a scam. Think about it: why would they not just deduct any 'taxes' as a fee from your total balance when you withdraw?

My advice would be to not send them any more money ($$, BTC, etc). I am sorry to say, but you may have to cut your losses, and just move on. If the amount lost was substantial you could try reporting the scam/theft to your local law enforcement, but there may be little they can do to help.

You can try making a wallet of your own to withdraw the BTC balance to, but I would guess they will not allow this withdrawal either.

As an individual, you may be liable to pay taxes on your cryptocurrency trading, but this liability would be to your local tax authority.

Sorry for your losses :(


Security bridge on bitcoin-qt walletpassphrase

The wallet passphrase protects against an attacker who has access to your disk but not the rest of your system.

If someone has access to your bitcoind through RPC, you need to protect by setting an RPC password, not a wallet encryption password.


Easiest way to buy Bitcoin from Montreal/Canada

Deposit cash at a bank is a deposit method for CAVirtex.   TD or CIBC banks.  You don't need to have an account to deposit.

https://en.bitcoin.it/wiki/VirtEx

Update:

CaVirtEx no longer allows cash deposits at any bank. You now make a Bill Payment to an established Payee, and CaVirtEx credits your account about 2-3 days later.

https://www.cavirtex.com/news

There is a new service called harborly which allows you to buy and sell bitcoins in Canada directly with your bank account.

https://harbor.ly


There are various ways to extract and dump the private/public keys from a wallet.dat depending on how it became corrupted.
First, try to run -salvagewallet command to repair it.
If you have a tool to dump the mongo db, yes its possible to find possible keypairs (pub/priv) and dump them out using python tools. Of course you would need the passphrase for this.
What system are you using, mac, Linux, Windows, and what version was the wallet created with?


Will Bitcoin switch to a faster block rhythm?

No, the Blockchain will not change the number of blocks produced. That would require the difficulty retargeting rules to be changed, but the difficulty setting is part of the Consensus Rules, i.e. changing them would require a successful Hard Fork. There are currently no such plans.

Price

There is lots of speculation about price effects, but before we get to that, let's review the facts first.

Facts

Daily production is about 3600 bitcoins (~144*25)
The Halving will reduce this to about 1800 bitcoins per day
The timing of the halving can be predicted fairly accurately: 16th of July (± a few days)
We have data from the first Halving (2012-11-28), and numerous altcoin halvings
Price has been "fairly stable" between $152 and $502 (source Bitstamp) in the past year
Previous research showed that most bitcoins were not circulating, I assume this still is the case

Thoughts

From [1.] daily production, [5.] price stability, and [6.] dormant bitcoins we can conclude that the market is soaking up more bitcoins worth more than 1,000,000 USD per day.
Reduced supply from [2.] would suggest an upward shift of market equilibrium.
Yet, the predictability of the supply event [3.] would suggest that such movements spread out due to anticipation, which aligns with the day of the [4.] first Halving only showing small price movements (+1.7%).
Reduced supply will also cause a steep decline in Mining profitability, may cause inefficient hardware to be sunsetted, or pointed at more profitable coins. E.g. the May'14 Dogecoin Halving [4.] caused difficulty to drop by ca. 25%. This effect should be less pronounced in Bitcoin, as more than half of the Bitcoin network's hash power came online over the last 6 months since the hash rate more than doubled.

Conclusions

It is unreasonable to expect a sharp price increase around the Halving as the event is anticipated. The Halving effects would manifest ±6 months (guess!) around the Halving.
The price remains unpredictable: The longterm effects may have been mis-estimated by the market, leading to a subsequent correction (as with Litecoin's Halving in Aug'15), or a subsequent rally, as reduced supply takes effect.
Remember: There is a large number of other unknown events that will also affect the market.

So my final answer is: We don't know yet whether the price will double. It seems plausible for the exchange rate to rise above current levels.


How can I use messengers for crypto transactions?

You can communicate transaction details to your counterparty using the app, but afaik neither of the messenger apps you mentioned have a cryptocurrency transfer system built into them.

So you'll need a wallet app, but otherwise you can communicate with your counterparty through the messenger app (agree on the amount to be transacted, send a payment address, etc)


your work is "wasted" caused by the mining-algorithm.

you have found a new block if sha2(sha2(blockheaderOfnewBlock) starts with a certain amount of zeros. the blockheader contains a nonce, the hash of the previous block and some other information. since the previous-block-hash is another hash if a new block was found you have another information-base for your mining-software.


What is the Ripple equivalent of the "51% attack?"

Ripple solves the double spend problem by consensus. Everyone who wants to run a server on the Ripple network picks a set of validators and tries to reach a consensus with them on which transactions are valid.

The Ripple equivalent of Bitcoin's 51% attack would be if some group obtained control over enough validators that the consensus process failed. Because people specifically select validators that they believe are unlikely to collude, this would be an exceptionally difficult thing to do.

If validators refuse to come to a consensus with each other, this is detectable to other validators. They then pronounce the network broken (because they don't know which side is right).

In this case, servers would declare the Ripple network unusable automatically. Until the problem was resolved, no transaction results could be relied upon.

The solution would consist of analyzing the signed validations and proposals to see which validators were being unreasonable and for all honest people to remove those validators from the UNLs (lists of validators they try to come to a consensus with).

So you would have to gain people's trust and then in the process of making the attack you would lose that trust and have to start over again.

By contrast, if someone acquired ASICs to attack Bitcoin, they could attack Bitcoin repeatedly. It's not clear how Bitcoin could respond to such an attack, but changing the mining algorithm (to make the attacker's ASICs worthless) is probably a non-starter as it would also make all the Bitcoin miners' investments in ASICs worthless as well.


Why are AntMiners' firmware closed-source / non-GPL?

The ASIC "arms-race" is all about having cutting edge technology. In a recent Motherboard article about a mining farm, the hardware was not even allowed to be specified.

Consider also that both SHA256/Scrypt ASIC manufacturers were clamoring to bring smaller nanometer sized chips - and the associated R&D costs - and it's probably more a question of why a company would make their hardware open source.


Non-bidirection payment channels for lightning network

There's no fundamental reason why you couldn't use a non-bidirectional link. The onion routing protocol of lightning is ignorant of the channel between two nodes. Hypothetically, if two lightning nodes were right next to one another, you could have robotic arms pass pennies back and forth in lieu of a lightning channel.

That said, would a non-two-party lightning channel work, or would it let one channel participant defraud another?

Normal lightning works like this: before Alice and Bob create a channel, Alice signs Bob's refund transaction, and Bob signs Alice's refund transaction. Alice's refund transaction says:

Output 0: 1 BTC can be claimed by Alice, only after 48 hours, OR
                can be claimed by Bob, if Bob knows P, where hash(P) = x
Output 1: 1 BTC can be claimed by Bob

If Alice decides that she wants out of the channel, she publishes the above transaction, waits 48 hours, and claims her money. Now that we have a way to end the channel, Alice and Bob jointly pay into a transaction that can be spent by the refund transactions, or any transaction that Alice and Bob jointly sign.

That's great, but how do you move money? First, Alice and Bob create new refund transactions to reflect the new state of the channel. Then, Alice tells Bob P, the value above that hashes to x. If Alice tried to submit that transaction to the Bitcoin network now, Bob would reply by taking all of the money in the channel.

This is where we hit our first roadblock. If there are three parties with money in the channel, and Alice cheats, it's obviously unfair to Charlie for Bob to take all of the remaining money. How do we fix this?

If Alice uses her refund transaction, we drop into a two party version of the lightning protocol. We do this whether or not Alice cheats by using an old refund transaction. Alice's refund now looks like this:

Output 0: 0.33 BTC can be claimed by Alice, only after 48 hours, OR
                   can be claimed by Bob and Charlie, if they know P, where hash(P) = x
Output 1: 0.67 BTC can be claimed by Bob and Charlie

We're not done, though. When Alice uses her refund transaction, Charlie might be offline. (In fact, that might be why Alice is leaving the lightning channel.) Therefore, Bob and Charlie each need to create a sub-refund transaction before they fund the channel. Bob signs Charlie's transaction, and vice versa. Bob's transaction looks like this:

Output 0: 0.33 BTC can be claimed by Bob, only after 48 hours, OR
                   can be claimed by Charlie, if they know P, where hash(P) = x
Output 1: 0.34 BTC can be claimed by Charlie

The result is that if you have n people participating, you need n refund transactions, and n-1 sub-refund transactions, and n-2 sub-sub-refund transactions. This grows factorially, so if you have 10 participants, I estimate that you must sign and revoke about 3.6 million transactions for every channel update. This will cover every possible ordering of nodes leaving the channel.

If you're willing to trade off some security, you could have 5 lightning nodes create a 3-of-5 multisignature account, and only allow withdrawals from that account if 3 nodes agreed that the withdrawal was done by a node with enough balance. If you're interested in this, I suggest looking at federated peg.


Link my bitcoin address with multiple wallets

I created a CoinBase bitcoin wallet address, can I share this address with Electrum desktop software instead of having different addresses and paying the transfer fees.

No, because afaik Coinbase does not provide access to the private keys for this address, and so you will not be able to control this address from any other wallet software. In order to send a transaction from your Coinbase wallet, you will have to submit a request to Coinbase to initiate a transaction, and then their service will (hopefully) craft and publish the transaction for you. The point here is that you can contrast this custodial wallet model with a self-sovereign wallet model, in which the user is fully responsible for maintaining their own private keys (funds). (disclaimer: I have never used Coinbase, but it is my understanding they are a custodial service, and in that case the above is true).

In order to spend some bitcoin, you need the private key for the bitcoin address in question. If you use some wallet software that is non-custodial, the software will create and manage these private keys for you in the background (a bitcoin address will be presented to you). If you so desire, you can import the keys to another wallet, so that you can spend your funds from one of several wallet instances. Many wallets these days are 'hierarchical deterministic' (HD) wallets, which will provide you with a 12 or 24 word 'seed phrase', this seed phrase can similarly be used to recreate an entire wallet on a separate device.

However, in general, having multiple instances of the same wallet is not the most secure method of using Bitcoin, as you would now have a larger possible attack surface. If any one of your wallet instances is compromised, then your funds could be stolen. Additionally, entering private keys into software is a moment of vulnerability, as a keylogger could be present on your machine, waiting to grab any bitcoin private keys, etc.

Many users will instead create several wallets, using various software and with varying levels of security between them. Maybe one wallet holds the majority of your funds in a super-secure manner, while another wallet is easily accessible through your mobiles phone, with a small amount of BTC on it for day-to-day spending, etc.

If you use good wallet software and are cognizant of the mempool backlog, you can send non-time-sensitive bitcoin transactions for extremely cheap. If Coinbase is offering cheaper fees than what you would actually pay to miners otherwise, then that probably just means they are making money off your use of their service otherwise. Generally I would not recommend using them as your wallet, it is a better idea to educate yourself on how to use bitcoin to regain monetary sovereignty, not sacrifice it to some corporation.


Does an SPV bloom filter get applied to full blockchain or just new transactions

This question has the answer.

For the first question when an SPV client starts up and sets a bloom filter it will not receive any special messages from connected bitcoin nodes. The bloom filter will result in transaction broadcasts to the SPV being filtered.

In answer to the second question an SPV client must still request ALL block headers and send a getdata request for every block in order to determine whether it contains any relevant transactions. The purpose of the bloom filter is to restrict the number of transactions returned by the merkleblock response to the getdata request.

An SPV client that's relying on bitcoin peer nodes for transaction information will have a slow initial start up as it needs to request all the block headers.


Most difficult (highest) chain wins. Side chains are stored forever just in case they become valid again.


What are the keys used in the blockchain levelDB (ie what are the key:value pairs)?

Bitcoind since 0.8 maintains two databases, the block index (in $DATADIR/blocks/index) and the chainstate (in $DATADIR/chainstate). The block index maintains information for every block, and where it is stored on disk. The chain state maintains information about the resulting state of validation as a result of the currently best known chain.
Inside the block index, the used key/value pairs are:

'b' + 32-byte block hash -> block index record. Each record stores:

The block header.
The height.
The number of transactions.
To what extent this block is validated.
In which file, and where in that file, the block data is stored.
In which file, and where in that file, the undo data is stored.

'f' + 4-byte file number -> file information record. Each record stores:

The number of blocks stored in the block file with that number.
The size of the block file with that number ($DATADIR/blocks/blkNNNNN.dat).
The size of the undo file with that number ($DATADIR/blocks/revNNNNN.dat).
The lowest and highest height of blocks stored in the block file with that number.
The lowest and highest timestamp of blocks stored in the block file with that number.

'l' -> 4-byte file number: the last block file number used.
'R' -> 1-byte boolean ('1' if true): whether we're in the process of reindexing.
'F' + 1-byte flag name length + flag name string -> 1 byte boolean ('1' if true, '0' if false): various flags that can be on or off. Currently defined flags include:

'txindex': Whether the transaction index is enabled.

't' + 32-byte transaction hash -> transaction index record. These are optional and only exist if 'txindex' is enabled (see above). Each record stores:

Which block file number the transaction is stored in.
Which offset into that file the block the transaction is part of is stored at.
The offset from the start of that block to the position where that transaction itself is stored.

Inside the chain state database, the following key/value pairs are stored:

'c' + 32-byte transaction hash -> unspent transaction output record for that transaction. These records are only present for transactions that have at least one unspent output left. Each record stores:

The version of the transaction.
Whether the transaction was a coinbase or not.
Which height block contains the transaction.
Which outputs of that transaction are unspent.
The scriptPubKey and amount for those unspent outputs.

'B' -> 32-byte block hash: the block hash up to which the database represents the unspent transaction outputs.

Latest version of bitcoind(please add version compatibility) uses obfuscation of the value in key/value pair . So you need to XOR with the obfuscation key to get the real value.
I won't go into the specific serialization details of the particular records. They're often specially designed to be compact on disk, and not really intended to be easily usable by other applications (LevelDB doesn't support concurrent access from multiple applications anyway). There are several RPC methods for querying data from the databases (getblock, gettxoutsetinfo, gettxout) without needing direct access.
As you can see, only headers are stored inside this database. The actual blocks and transactions are stored in the block files, which are not databases, but just raw append-only files that contain the blocks in network format.
As to your second question: what is n? If you just want to access some records, sure, iterate over the keys and stop when you've read enough.


bitcoin public key vs public key hash vs. pub key

I provide my thoughts more on privacy than risk:

  If i had a database that had a bunch of public keys... would all of
  the utxos at the original wallet be at risk?

AFAIK no, for P2PKH transactions. The bitcoin system has a locking and unlocking mechanism. The locking is done with the pubkey script: the author of a tx defines the target (to whom the tx shall go), and the spending condition(s). This is were in P2PKH tx the hash of the public key goes. The spending condition is then s.th. like this "you need to provide a value, that when hashed, equals the provided public key hash in this transaction". Usually this can only be provided by the original author of a transaction. With a lost database, anyone could now create such a transaction, but not sign it! When then the tx shall fulfill the spending condition, the tx needs to be signed (and the pubkey is provided in hex format).

So if your database is disclosed, the locking mechanism for P2PKH tx can be understood. However, the unlocking is in the sigscript of the transaction, and just with the stolen database you may not provide a valid signature, cause you need the corresponding private key for the signature.

More to the locking/unlocking e.g. in Andreas' book "Mastering Bitcoin" in section 6 "Transactions".

  If this is the case... why do we even go through the process of
  creating p2pkh addresses in the first place?
  Is it just for aesthetics, less bytes in the transaction, just for
  privacy, or is there an actual security reason?

Next to the answer in the link from Pieter Wuille, I'd see P2PKH addresses help to keep the privacy up to the point, when the tx is finally spent, cause hashes are not reversible (as per today's knowledge).


check your wallet: wallet like jaxx and other have some fees


From my experience the process of syncing the blockchain is CPU bound, not IO bound (You can check this on Linux by running the top command). bitcoinj has two ways of verifying signatures, either using native code based on the secp256k1 library, or using java code based on the spongycastle library. Your last error message indicates your are not using secp256k1 which is most likely a source of performance degradation and a cause of slow syncing process.

In order for java to use the secp256k1 library, you need to set the environment variable LD_LIBRARY_PATH to a path where the file libsecp256k1.so is located (I am on Debian, this file may have different names on various systems). For example, you could use the command:

$ env LD_LIBRARY_PATH=<path-to-directory> java -cp <classpath> MyJavaClass

However, even if you happen to already have the library libsecp256k1.so on your system (because you installed some other piece of software which relies on it), the above command will not work unless the library was built with the --enable-jni option so as to enable java to interface with it.

In order to build a java-enabled libsecp256k1.so, you can do as follows:

$ git clone https://github.com/bitcoin-core/secp256k1
$ cd secp256k1
$ ./autogen.sh
$ ./configure --enable-jni \
              --enable-module-ecdh \
              --enable-experimental
$ make
$ make check

The library file will then be located in the .libs directory. You can decide to overwrite your existing system file with this new version (but you take the risk of messing up something), or you can simply put this file anywhere you want (or a symbolic link to it) and make sure the LD_LIBRARY_PATH environment variable is properly set to the directory in which it (or a symbolic link) is present.


How do I check if a particular address is 'owned' by a loaded wallet in Bitcoin Core?

You want the getaddressinfo wallet RPC. It will tell you whether an address is considers "yours", along with various other information like whether you have the keys, whether it's a payment address or change, what its label is, and how it was derived.


The bitcoin-qt synchronization just stopped

You can try downloading bootstrap.dat from the torrent at sourceforge as suggested in the answer to Is there a newer Bitcoin blockchain download available?

Because of its format, the client will verify the integrity and the bottleneck will switch from your download speed to your CPU speed.

This is the link to the torrent file


Transactions seen by peers, but not confirming

Okay, some observations:

MultiBit Classic 5.16 is more than two years old.
The transaction you mentioned doesn't appear on either blockexplorer.com, blocktrail.com or blockchain.info. It seems that they didn't get propagated in the network.

The Bitcoin transaction market has evolved in the past two years and due to a higher demand, the transaction fees have become more competitive. I would guess that your old version of MultiBit wouldn't have a good estimation for fees. Therefore, it seems likely that your transactions didn't fulfill the 'minimum relay fee' criterion and didn't get relayed by the peers that did see them.

I found this FAQ that addresses specifically your issue: I sent bitcoin from MultiBit Classic but they are stuck., which provides a similar explanation as one of the most likely reasons.

You should:

Update your software to a more current version to mitigate this issue in the future.
As suggested in the above FAQ: "You can remove the transaction that never propagated by doing a Tools | Reset Block chain and Transactions."

As always, if you don't have a backup of your wallet, you should create one, especially before changing things about your Bitcoin software, but also in general.


How does Blockviewer work? (tool to discover identities of "anonymous" bitcoin transactions)

The technique was first described in form of formal study by researchers with the Clique Research Cluster at University College Dublin, blog post: An Analysis of Anonymity in the Bitcoin System, the research paper is here.

Imagine transaction of 1 BTC from address:Alice to address:Bob, blockchain shows that there was transfer of 1 BTC

1 BTC source:Alice, destination:Bob

Now, if a person controlling address:Bob wants to spend the 1 BTC he or she has to construct transaction that shows in blockchain as

1 BTC source:Bob, destination:Charlie

Lets say you see next three transactions in the blockchain:

1 BTC source:Jessica, destination:Alan
1 BTC source:Bill,   destination:Erik
2 BTC source:Alan,Erik   destination:Manhattan

To construct the 2 BTC transaction he or she has to have control over both Alan and Eric addresses in another words the person knows the private keys of it, therefore it's the same person, this is not true for a Bitcoin exchange or web based wallet were many people have limited access to the same private key.

Now if you know for sure, e.g. from forum signature, that address:Erik belongs to Gavin Anderson then you also know that address:Alan belongs to Gavin Anderson.

So far this technique didn't uncover any BTC theft and remains to be a toy. Also, there is many ways to block it, e.g. by using Bitcoin Anonymizer.


Is there a limit to how much extra data can be put into blocks via scripts?

The maximum size of a block is 1MB. A block can be filled entirely with arbitrary data.

Namecoin actually puts its extra data into the "coinbase" parameter, which is specifically designed to hold arbitrary data. Data put here is limited to 100 bytes, and this data will in the future be safely forgotten by most clients.


Merkle Root for Block 100000: calculation in Excel


Someone said they would send me bitcoin, they sent me a exe file, called bitcoin.exe, and it is not running

This sounds like a scam, or at least, an attempt to compromise your computer with malware.

Sending someone a Bitcoin transaction does NOT involve sending someone an executable file. It involves using the bitcoin network to send a bitcoin transaction that moves some amount of bitcoin to addresses owned by the transaction's participants.

You can generate receiving addresses, or send transactions of your own by utilizing bitcoin wallet software. You should download this software only after learning about how to use it, and finding a reputable place to download it from. In pretty much every case, you should not download and run a .exe file sent to you by an unknown person. If you have already done so, you should consider your computer compromised, and never use it as a bitcoin wallet otherwise, you will need to find a clean device for that purpose.

For more information on getting started with Bitcoin, see: I am new to Bitcoin, how can I get started?


Technically a block with just one transaction in it would be valid. However miners have an incentive to add more transactions to the block they are currently mining because they receive the transaction fees attached to those transactions.


The GetWork request includes only the block header, containing exactly the fields shown here and no others.  This is all the miner ever sees.  Notice that the transactions are not in the block header -- just their (Merkle) hash.  The miner doesn't actually know what transactions it is mining.

The pool checks that the block header of the submitted work exactly matches the header of some GetWork previously issued by the pool.  Some pools (Eligius) give the miner permission to alter the timestamp field only, and only according to very strict rules.

The pool always checks that the block's hash ends with 32 zeroes (note that this is "below" difficulty zero!  Every block in the chain has more than 32 trailing zeroes in its hash).

Some pools check other things (for example, that you didn't request work using one account and submit it using a different one), but the checks above are the only ones that are both mandatory and universal.


Will a new block be found immediately, when there are enough transactions to fill a block?

We don't have to wait until a block is full, instead blocks are created in a random process. Whenever one is found, the miners directly try finding the next one. This takes roughly ten minutes, regardless of how many transactions are waiting to be confirmed.

So, we'll all be waiting for the new block.


Recovering funds after I lost my wallet.dat

If you have your private key, you can add it to your wallet with the command
bitcoin-cli importprivkey "<YOUR_PRIVATE_KEY>" "" false

(The false at the end is to cancel rescan at the moment of adding. It could take some time.)

If you do not have the private key associated with the address the coins were sent to back then, they are lost.


What kind of fee doesn't change the amount?

The short version is that the sender pays the fees, not the receiver. If you ask a wallet to send 33 millibits, you pay more than 33 millibits, and the receiver receives 33 millibits.

But it sounds like you're using a wallet that shows it to you differently. For instance, Coinbase (which is an exchange and web wallet, of sorts) doesn't charge you transaction fees at the time the actual Bitcoin transaction happens. They probably do this to reduce confusion in how their services work, what your balances are, and when fees are charged.

E.g. if I want to buy .033, it will charge me for (.033 btc at the current buy rate + a bank fee + a coinbase fee), and it will show a balance of .033. I can send .033 to an address, and it adds the transaction fee for me. Your service probably did the same thing.

Other clients (including Bitcoin-QT and Multibit) show your total balance and require that you pay fees out of that balance; so if I have a balance in Multibit of 1 BTC, I can only send about 0.998 BTC, because I need to pay a transaction fee for most clients to relay my transaction.

You asked wallet A (hosted by somesite.com) to send 33 millibits to address C (address "17BK..."). Your transaction actually looked like this:

input: address A ("1PAR..." in wallet A) - 33 millibits
input: address B ("1Mjf..." somesite.com) - 0.64443 millibits
output: address C ("17BK..." in wallet B) - 33 millibits
output: address D ("14ov..." somesite.com) - 0.44443 millibits
transaction fee: 0.2 millibits (calculated from input - outputs)

The second output, to address D, is the change (if you had sent less than your total transaction amount, some of the change would belong to you; as it is, it sounds like it belongs to somesite.com). This exists because a transaction output must be used in its entirety. somesite.com decided to use the money in addressees A and B in order to have enough money for the transaction. Since your inputs came to 33.64443 millibits, and your desired output+fee only comes to 33.2 millibits, the extra money is sent to an address that somesite.com owns (address D).

172 confirmations in three minutes is practically impossible, as one confirmation takes, on average, 10 minutes (not one second). As you noticed, it was instead saying that the first confirmation took 3 minutes, and that 172 total confirmations had been done.

It's expected that the balance of wallet B went up by the full 33 millibits - what you might not've realized is that it cost somesite.com a total of 33.2 millibits, because of the transaction fee. That is, the sender pays the transaction fee. somesite.com showed you a balance of 33 millibits, even though they had to pony up more than 33 to actually use it.

Even though the balance of address A was exactly 33 millibits, somesite.com also had the balance of address B to pull from.


The system is protected by an incentive mechanism. As Satoshi said in the paper itself:

  He ought to find it more profitable to play by the rules, such rules
  that favour him with more new coins than everyone else combined, than
  to undermine the system and the validity of his own wealth.

This means that if someone has access to a supercomputer, more powerful than the entire network combined, it would make more sense for them to use such computer to mine in a honest way and earn more reward than any other miner. Rather than actually use the power to do dishonest things, like to double-spend or to invalidate transactions, which would diminish the network's validity and therefore the value of the attacker's mining reward.

Also, if such computers are ever built, many people would want them, which would eventually redistribute the power. In that sense, ASICs could be considered tiny supercomputers.


Some of the earlier transactions on the bitcoin network use a raw public key in a p2pk script, instead of the now-common p2pkh format.

Only the p2pkh format is representable as an address. The raw p2pk script has no corresponding address, and must be worked with as a script directly. Some explorers and other tools will attempt to show it as either a p2sh address for the hash of that script, or as its p2pkh version, but that is not accurate to the actual on-chain data.


Option # 2) A node running full-block chain will compute Merkle tree and will send me only the transaction path. Pitfall: the sender will be computing Merkle trees of lots of people.

This is what happens. You connect to a full node, tell it to send you transactions which match a filter, and then you will receive those transactions along with the merkle tree path.

This is specified in BIP 37 which is used by many SPV wallets. Note that not all wallets use BIP 37 such as Electrum which uses its own protocol and connects to special Electrum servers.

  What reward he is getting for his services?

None. Full nodes are not rewarded for anything unless they are a miner.


What are the chances of getting duplicate wallet using bitcoinlib in python3?

When you create a private key, this process is (or at least should be) completely random - meaning that in theory, the probability of creating some specific private key is 1/N where N is the number of possible private keys. There's nothing stopping someone from creating an already created private key, except chance.

A private key is made up of 256 completely random bits. Thus, the number of possible private keys is 2^256 (approximately 10^77) and the chance of getting a certain exact private key is 10^-77. It's hard to overstate how tiny this probability is - for example, it's roughly equal to the number of hydrogen atoms in the observable universe. We can treat this probability as essentially 0.

  is there a possibility of having same public key of two or more private key?

Yes, absolutely. There is nothing preventing two private keys from being associated with the same public key - however, the only way of finding such a case would be through brute force (generating keys until you find a pair that match, and as we learnt above bruteforcing 256 bits is essentially impossible. Even doing a birthday attack - where you generate keys until ANY two of the generated match, you will still have to create 10^38 keys before a 50% chance of collision.

Also, if by public key you are referring to bitcoin addresses, then this can very easily be mathematically proven to be true by the pigeonhole principle. There are 2^256 possible private keys but only 2^160 possible addresses - so it's impossible to have each private key generate a unique address.


What does the sequence in a transaction input mean?

Original meaning of nSequence in transactions

nSequence is a 4 byte input level feature. The original meaning of nSequence was to allow modification of transactions in the mempool. So, if the nSequence value of the input was less than 0xFFFFFFFF (4294967295 in decimal), it indicated a transaction that was not yet finalized. Such a transaction would be held in the mempool until it was replaced by another transaction spending the same inputs with a higher nSequence value. Once a transaction was received whose inputs had an nSequence value of 0xFFFFFFFF it would be considered finalized and mined. In that implementation, replacement transactions did not have to pay additional fees, so there was no direct incentive for miners to include the replacement. Also, no built-in rate limiting prevented overuse of relay node bandwidth. Hence, this feature was disabled later as it was possible for an attacker to use up all the bandwidth among full nodes at only a small cost to himself, creating a denial-of-service vulnerability. This made it difficult for spenders to adjust their previously sent transactions to deal with unexpected confirmation delays or to perform other useful replacements.

  Opt-in Full Replace-by-Fee Signaling

Then came the proposal for Opt-in Full Replace-by-Fee Signaling. It considered a transaction to have opted in to allow replacement of itself, if any of its inputs have an nSequence number less than 0xFFFFFFFE. It also required higher fee than the previous relayed transaction

  Absolute and Relative Locktime

Transaction with nLockTime is used to prevent the mining of a transaction until a certain date (specified in block no. or time). BIP 68 activation defined the meaning of sequence numbers for transactions with an nVersion >=2. nSequence was repurposed as a relative locktime. That means it prevents mining of a transaction until the input that the transaction is spending has reached a certain age in blocks or timespan.  If nSequence > 0xEFFFFFFF then there us no consensus meaning to the sequence number and it can be included in any block under all currently possible circumstances. If nSequence <= 0xEFFFFFFF, it implies relative locktime.

If nSequence <=0xEFFFFFFF, then the sequence's 22nd bit determines if the relative lock-time is time-based or block based. If the bit is 1, the relative lock-time specifies a timespan in units of 512 seconds granularity. If the bit is not set (i.e. it is 0), the relative lock-time specifies a number of blocks. The value of the relative locktime, is then interpreted from the first 16 bits of the nSequence. The below figure shows how nSequence is evaluated.

  Use of nSequence with CHECKSEQUENCEVERIFY (CSV) opcode

CSV is a script level opcode that is used to lock the spending of a particular output of a transaction until certain blocks/time from when the transaction containing the output was mined. When the user is spending this UTXO in a transaction input, he must set the nSequence value in that input greater than or equal to the CSV parameter. The value in CSV must match the format in the corresponding nSequence value. If CSV is specified in terms of blocks, then so must nSequence.

  Other miscellaneous points

Currently, if nSequence = 0xFFFFFFFF, the sequence number has no effect on the transaction.
If nSequence = 0xFFFFFFFE, then it implies that the transaction uses locktime but does not opt-in replace-by-fee.
Plain vanilla transactions created from Bitcoin Core uses nSequence=0xFFFFFFFE, because they want to use nLocktime to prevent miners from pulling the transactions forward. The nLocktime used in such transaction is set to the last mined block.

For more information on Locktime refer here.

  Future potential for nSequence

As can be seen from the description above, a number of bits remain undefined. This allows the possibility to increase granularity by soft-fork, or for increasing the maximum possible relative lock-time in the future. For example,

If nSequence > 0xEFFFFFFF then the remaining 31 bits have no meaning as this condition can be satisfied by just setting bit (1<<31).
If nSequence <= 0xEFFFFFFF then the bits 23 to 30 have no meaning.
Also, only first 16 bits are used to actually encode relative lock-time meaning a further 6 are unused (1 << 16 through 1 << 21 inclusive).


if the hardware wallet company ledger goes out of business, what will happen to my crypto asset / private keys in ledger?

Your keys are stored securely on the hardware device itself.
If Ledger (or Trezor) goes out of business then their wallet client will also most likely not be supported anymore.
This isn’t that much of an issue. Other wallets have support for interacting with your hardware wallet, like Electrum for BTC, Electron Cash for BCH, and MyEtherWallet’s website for ETH.
If you also have your seed written down, you can import that seed into Electrum. This is more of a last resort move though.


Transaction creation process is not non-interactive(Mimblewimble)?

It is possible to create MW transactions interactively, and if you're creating multisignature outputs I think this is actually necessary. But ordinary transactions can be created non-interactively (well, with half a round of interaction, as in Bitcoin where one party sends an address to another party who builds a transaction) in two ways:

Suppose the sender is trying to send 5BTC to the receiver.

The sender can create a transaction that doesn't balance unless a 5BTC output is added. Aside from this discrepancy the transaction is valid; she sends this to the recipient.
The recipient then adds a 5BTC output, adds another kernel to the transaction so that the blinding factors still add up, and the transaction is complete.
The sender acts as above, but sends the opening of the kernel. This is a bit dangerous because it gives the sender the ability to reverse the transaction long after the fact, but I'm unsure what sort of attack this would enable.

Note that both cases require a secure channel from the sender to the receiver because anyone who gets the incomplete transaction could add their own 5BTC output to it.

It's also possible to do this in reverse: the recipient sends the sender an incomplete transaction that needs a 5 BTC input to balance, and the same considerations apply.


Can I, and how do I query the Bitcoin Core wallet to give me a list of all transactions for any specified address?

You question deserves a very long explanation :-) Instead of repeating what was already discussed, I put some links here which will help you to begin.

  Given any address, what would be the json command and or how would I
  import into python...

first it is important to understand, that the wallet that you talk to (via RPC) is not the blockchain. You can only fetch information for the known addresses in the wallet.

  ... for an array of all the tx id's for all tx's associated with any
  given address (whether part of my wallet or not)?

This is a repeating pattern here in the forum, a quick search revealed this.

And how to send python commands to RPC is described here. A quick search for "RPC python" reveals many more sources of information.
The RPC commands themselves are well described here and here.

For sure we can't write the code for you, so maybe show us a bit how far you got, and then we can easily follow where you got stuck, and maybe even provide the help you are looking for.


Difference between Hashcash proof of work algorithm and Ethash proof of work algorithm?

Hashcash and Ethash are two different things and not directly comparable. Hashcash is the idea of using hashes for a proof of work system. it can be used with any hash function.

Ethash is a specific hash function. It is used in a hashcash proof of work system, specifically the one used in Ethereum.

Hashcash is not comparable to Ethash because it is not a hash function at all.


If you made the second transaction to same Bitcoin address so yes you will not miss that second transaction even if you made the transaction after the backup.

if you made the transaction after the backup and you made the transaction to a different address you will also get any future transactions for two reasons:

1- Bitcoin Core using HD wallet so you have one master private key and they derive all your future addresses from that one seed.

2- if you are using old bitcoin wallet or HD wallet set to 'OFF' you will still have future transactions but not forever and that because of the limit of keypool future.

  Keypool New public and private keys are pre-generated and stored in a queue
  before use.

  This pooling feature was added so backups of the wallet would have a
  certain number of keys that would be used in the future. By default,
  the number of entries in the queue is 100[1].


Will SegWit allow for m of n multisig with very large n and m?

By reading this answer, I understand that in m-of-n multisig addresses, m and n are limited by the maximum size allowed by the P2SH redeemScript (i.e. 520 bytes).

That's correct. Even though the OP_CHECKMULTISIG script opcode supports more keys, more than 15 public keys simply don't fit in a P2SH redeemscript, so that becomes the limiting factor.

  However, in this section of BIP141, it is stated that the witnessScript can be as long as 10,000 bytes. As far as I understand, this implies that with SegWit adoption it should be possible to create and use m-of-n multisig addresses with very large m and n that will be considered valid.

BIP141 only describes the consensus rules - i.e. what transactions are valid inside blocks. There are a number of standardness rules that apply for transactions to be relayed and accepted into memory pools, to avoid potential avenues of abuse before they're understood. Bitcoin Core 0.13.1 and up limit witness scripts to 3600 bytes for that purpose.

  For instance, would the following witnessScript, which should represent a 50 out of 100 multisig address, be considered valid and spendable under SegWit?

  0x01 0x32 <100 signatures> 0x01 0x64 OP_CHECKMULTISIG

I assume you mean public keys there instead of signatures?

No. OP_CHECKMULTISIG itself only supports up to 20-of-20, so if you want to use that opcode, you can't go above 20. However, you can construct others scripts that go above those limits.

In particular:

<pubkey1> OP_CHECKSIG
OP_SWAP <pubkey2> OP_CHECKSIG OP_ADD
OP_SWAP <pubkey3> OP_CHECKSIG OP_ADD
...
OP_SWAP <pubkey67> OP_CHECKSIG OP_ADD
<m> OP_NUMEQUALVERIFY

would implement an m-of-67 policy, with less than 3600 bytes.


Signrawtransaction is not working on bitcoin core V0.17.1

As the error message says, signrawtransaction is deprecated. Stop using it. Instead use signrawtransactionwithwallet (if the transaction you are signing uses keys from your wallet) or signrawtransactionwithkey (if you are specifying keys on the command line).


As you have found out correctly, the length field describes the following script length. Then the SigScript follows:

004730440220762CE7BCA626942975BFD5B130ED3470B9F538EB2AC120C2043B445709369628022051D73C80328B543F744AA64B7E9EBEFA7ADE3E5C716EAB4A09B408D2C307CCD701483045022100ABF740B58D79CAB000F8B0D328C2FFF7EB88933971D1B63F8B99E89CA3F2DAE602203354770DB3CC2623349C87DEA7A50CEE1F78753141A5052B2D58AEB592BCF50F014CC9524104A882D414E478039CD5B52A92FFB13DD5E6BD4515497439DFFD691A0F12AF9575FA349B5694ED3155B136F09E63975A1700C9F4D4DF849323DAC06CF3BD6458CD41046CE31DB9BDD543E72FE3039A1F1C047DAB87037C36A669FF90E28DA1848F640DE68C2FE913D363A51154A0C62D7ADEA1B822D05035077418267B1A1379790187410411FFD36C70776538D079FBAE117DC38EFFAFB33304AF83CE4894589747AEE1EF992F63280567F52F5BA870678B4AB4FF6C8EA600BD217870A8B4F1F09F3A8E8353AE

The script starts with a hex "0", which compensates for a very early "off by one error" in the execution routines of the checksig routines. An element too much was popped off the stack. This "bug" is so long in the system, that everyone got accustomed to it, and removing it requires an enormous effort. So it became a feature :-) Even more, if there are tx, which have an execution time in the future, they wouldn't work anymore...

  how did the explorer find out that it is 2-3 multisig. In the
  first place how to identify a multisig?

The explorer finds this in the script sig. There is the two signatures, and the part for the multisig:

<sig1> <sig2> <length> OP2 <pubkey1> <pubkey2> <pubkey3> OP3 AE

to be better able to view, I have decoded the script a bit. The sigs start with hex 0x47 or 0x48, and end with 0x01. They are ASN1-DER encoded, providing a view into the R and S fields, and have surrounding length information. After the second 0x01, follows the length field, and then the multisig OPcode (0x02) and the 3 pubkeys.

00: OP_0, OP_FALSE:      an empty array is pushed onto the stack.
<sig1>
47: OP_DATA_0x47:        push hex 47 (decimal 71) bytes on stack
30: OP_SEQUENCE_0x30:    type tag indicating SEQUENCE, begin sigscript
44: OP_LENGTH_0x44:      length of R + S
02: OP_INT_0x02:         type tag INTEGER indicating length
20: OP_LENGTH_0x20:      this is SIG R (32 Bytes)
02: OP_INT_0x02:         type tag INTEGER indicating length
20: OP_LENGTH_0x20:      this is SIG S (32 Bytes)
01: OP_SIGHASHALL:       this terminates the ECDSA signature (ASN1-DER structure)
<sig2>
48: OP_DATA_0x48:        push hex 48 (decimal 72) bytes on stack
30: OP_SEQUENCE_0x30:    type tag indicating SEQUENCE, begin sigscript
45: OP_LENGTH_0x45:      length of R + S
02: OP_INT_0x02:         type tag INTEGER indicating length
21: OP_LENGTH_0x21:      this is SIG R (33 Bytes)
02: OP_INT_0x02:         type tag INTEGER indicating length
20: OP_LENGTH_0x20:      this is SIG S (32 Bytes)
01: OP_SIGHASHALL:       this terminates the ECDSA signature (ASN1-DER structure)

4C: OP_PUSHDATA1:        next byte is # of bytes that go onto stack
C9: OP_Int(0x01-0xff):   201 bytes onto the stack
52: OP_2:                the number 2 is pushed onto stack
    ################### we go multisig ####################################
41: OP_DATA_0x41:        uncompressed pub key (65 Bytes)
41: OP_DATA_0x41:        uncompressed pub key (65 Bytes)
41: OP_DATA_0x41:        uncompressed pub key (65 Bytes)
53: OP_3:                the number 3 is pushed onto stack
    ################### 2-of-3 Multisig ###################################
AE: OP_CHECKMULTISIG:    terminating multisig

You find a very good explanation in chapter 6 "Transactions" and 7 "Advanced Transactions and Scripting" of Andreas' wonderful book "Mastering Bitcoin", which is also online available.


I suggest you go and read about just what cgminer is presented with, in most cases it is just the header which has absolutely no bearing on the content of the block. It does not, and can not in most situations know what the work it has been provided with actually is.

The node providing work must be modified slightly by changing the isStandard checks, which you can find in main.cpp of the Bitcoin core client. There's not really that much interesting you can do at present without making your block invalid, but it's easier just to submit them directly to eligius.st which is a pool that already accepts certain nonstandard transactions. The chance of a user solo mining a block is vanishingly tiny at this point.


Why doesn't Core know where the transaction is coming from

The 'From' field was intended for online transactions, a feature that was removed many years ago. For more information, see IP Transactions.


How many numbers to try to solve the proof-of-work problem

There's no maximum. Instead you can find the formula linking the target and the required number of initial zeroes. Then the average number of hashes you need to calculate is 2^(target number of initial bits). Then you could input the current target to find the average number of hashes.
I don't know the formula for that but for example the block 661657, a recent one, had the target bits as many as about 76, which means it took about 2^76 hashes.


Block messages with transactions hashes instead of full transactions

There are probably several reasons, but it's mostly historic. There is no inherent problem with just sending transaction id's. There is a disadvantage too, though, namely increased latency, which is not necessarily a problem when doing an initial sync, but it is not wanted when a fresh new block is propagating.

In fact, this idea is part of BIP 37, which specifies a protocol extension for requesting filtered blocks. To avoid the increased latency, matching transactions that are not known to the server to be already known to the receiver, are sent immediately after the filtered block itself.

Edit: BIP152 compact blocks also use this idea, though they use shortened 48-bit transaction ids instead to save space.


even after 0.0005BTC Fee, My transaction is unconfirmed

Don't use fixed fees! Fees are not per transaction, they are per byte (size of the transaction matters).

The size of the transaction is based on how many inputs you use. Mostly, that's not under your control.

You transaction above is 815bytes.
You fee: 0.0005 0BTC.
~= 0.000613 BTC/bytes

The current feerate to get confirmed within the next 10 blocks is 0.00136386/1000bytes (March 8th 2017).

Your fee is way to low to compete with other transactions.


Automated Testing using bitcoind in regtest mode, problems due to race condition

I would separate out the unit tests and the integration tests.

If the function needs to go out to the internet or wait for the blockchain, I make them integration tests which I can run less frequently like every five minutes. The functions that are fast I like to run every 10 seconds.

Linking the errors to sensible time stamped logs like pm2 and key-metrics allows you to see what has been going on while you were sleeping.


What are the transaction fees with Ripple.com?

The default fee for a transaction is 0.00001 XRP.

But the fee is not fixed. Quoting the wiki:

  Transaction fees are adjusted based on two factors: base fee and load
  fee

  base fee: long term fee adjustments
  Since transaction fees are
  paid in XRP and the price of XRP may change overtime, to keep the
  price of transactions affordable, Ripple uses an adjustable "base fee"
  to specify the cost of transactions.

  load fee: short term fee adjustments
  The "load fee" can rise quickly to protect the network
  from attacks and keep the network functional under heavy load.

The fee schedule is changed using consensus, quoting. D.Schwartz:

  A node can introduce a transaction to change the base fee. If a
  trust-weighted majority of nodes vote "yes" on the transaction, it
  will be incorporated into the ledger and the fee will be changed.


Java: way to convert a 256-bit private key to WIF?

You should convert hex representation of bytes to byte array (not String to byte array). Then make hash. Then convert the byte array back to hex representation of bytes in String.

The whole solution will look like:

import java.security.*;

class HashExample {
    public static void main(String[] args) throws NoSuchAlgorithmException {
        String string = "0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D";
        string = "80" + string;
        byte[] data = hexStringToByteArray(string);
        byte[] digest = MessageDigest.getInstance("SHA-256").digest(hexStringToByteArray(string));
        String result = bytesToHex(digest);
        System.out.println(result);
        //prints: 8147786c4d15106333bf278d71dadaf1079ef2d2440a4dde37d747ded5403592
    }

    public static byte[] hexStringToByteArray(String s) {
        int len = s.length();
        byte[] data = new byte[len / 2];
        for (int i = 0; i < len; i += 2) {
            data[i / 2] = (byte) ((Character.digit(s.charAt(i), 16) << 4)
                    + Character.digit(s.charAt(i+1), 16));
        }
        return data;
    }

    private static String bytesToHex(byte[] bytes) {
        StringBuffer result = new StringBuffer();
        for (byte b : bytes) result.append(Integer.toString((b & 0xff) + 0x100, 16).substring(1));
        return result.toString();
    }
}

Of course this is just example. In production code I recommend to use one of the available libraries which can perform this task.


Method not found when I use bitcoin-cli to generate blocks under regtest mode

For the upcoming Bitcoin Core 0.18 release, the generate command has been deprecated and its functionality disabled. For the following major release, 0.19.0, the generate command has been removed entirely. This removal is already in the master branch of Bitcoin Core's source code. If you have built that branch from source, then the generate command does not exist.

Use generatetoaddress instead.


Cannot read property 'toWIF' of undefined

First, note that HDNode was removed in 4.0.0, so you should use the BIP32 module you included. Second, you don't need the extra keyPair property, so your code becomes:

var bip32 = require('bip32')

var privKey = process.env.BIP32_PRIV;
var hdNode = bip32.fromBase58(privKey);

var count = process.env.GENERATE_ADDRESSES ? parseInt(process.env.GENERATE_ADDRESSES) : 1000; // how many addresses to watch

var rescan = 'false';

for (var i = 1; i <= count; ++i) {
  console.log('bitcoin-cli importprivkey ' +  hdNode.derive(i).toWIF() + " '' " + rescan)
}


Understanding a Mysterious Bitcoin Transaction

if you have 50 BTC in one address and you are about sending 10 BTC to another address, Programmatically left bitcoins(40 BTC) in this address are the transaction fee. so some wallets sent remaining bitcoins minus the fee to a new address for privacy purposes.

Almost all wallets don't show this transaction because its a transaction that you didn't make and it contains bitcoin change.


How do i get my Bitcoin Cash from Mycelium wallet?

I just finished following the instructions at this link
https://steemit.com/btc/@libert/step-by-step-guide-on-claiming-bitcoincash-from-mycellium-wallet-201783t112141477z
and it worked quite easily. Much easier than the previous comment.

On a side note Coinomi has very clear instructions that did not work for me on how to sweep your mycelium wallet into your coinomi wallet by obtaining the private keys from your mycelium addresses butt only the first private key had a tiny bit of funds in it I checked through over 1000 more private keys and could not find any other funds so that's when I went back to Google searching and searching and found the link above.

I think how it works when you're sweeping the funds I think you're actually moving them. As opposed to when you restore your mycelium wallet with the coinomi app using the 12 words You're simply gaining access to funds without actually moving them.


What is the meaning of the field for "Profitability decline per year" in bitcoinx' profitability calculator?

I agree that it isn't worded very well. It seems to be a number r such that the revenue n years from now will be r^n times the revenue today, so basically what you said.

To empirically verify this, set electricity and hardware cost to 0 (so that profits equal revenue), time frame in months to 12 (for a full year), and profitability decline to 1. You should get $1,366 or so. If you change it to 24 months, you get $2,732 - exactly double the previous. On the other hand, with a profitability decline of 0.2, you get $679 in 12 months and $814 in 24 months, which is $135 (or 20%) more.


The miner uses JSON-RPC 1.0, for which only the HTTP transport was defined.


The public key format that OpenSSL and Bitcoin use is described in SEP 1, published by the Standards for Efficent Cryptography Group on page 10.

  Convert the field element xP to an octet string X of length ceil([log2 q]/8) octets using the conversion routine specified in Section
  2.3.5.
  Derive from yP a single bit ȳP as follows (this allows the y-coordinate to be represented compactly using a single bit):
  If q = p is an odd prime, set ȳP = yP mod 2.
  If q = 2m, set ȳP = 0 if xP = 0, otherwise compute z = zm-1xm-1 + · · · + z1x + z0 such that z = yPxP and set ȳP = z0.
  Assign the value 0216 to the single octet Y if ȳP = 0, or the value 0316 if ȳP = 1.
  Output M = Y || X.

... and page 53 ...

  If C is an octet string and the leftmost octet of C is 0216 or 0316, parse the leftmost ceil([log2 q]/8)+1 octets of C as an octet string R, the rightmost maclen octets of C as an octet string D, and the remaining octets of C as an octet string EM.
  If the leftmost octet of C is 0416, parse the leftmost 2 * ceil([log2 q]/8) + 1 octets of C as an octet string R, the rightmost maclen octets of C as an octet string D, and the remaining octets of C as an octet string EM.
  If the leftmost octet of C is not 0216, 0316, or 0416, output “invalid” and stop.

So, in plain English:

It can be 0x04 too. That's is the 'uncompressed' key. If you generate a key today, it won't create one of these. However, if you have an old wallet, you might have some. They are equivalent in security to compressed keys.
Whether it's 0x02 or 0x03 depends on on the value of ȳP. We can generate ȳP instead of including the full y coordinate, which saves us a nice bit of space. That's what compressed keys are.

I'm not sure what q is in this context, if somebody wants to tell me in comments, it'd be appreciated.


How do I send Bitcoin in paper wallet to other person?

Spending money from a paper wallet is the hardest part. Making the wallets themselves is easy but spending the coins is harder than it should be. Here's a guide on how to do it safely:

Create a NEW wallet on blockchain.info. Keep in mind that you will only use this wallet for the express purpose of emptying your paper wallet. You will not reuse the paper wallet and you will not reuse the blockchain.info wallet.
Log into your blockchain.info wallet and go to Import/Export. You will get a warning about advanced usage. Agree to that to make it go away.
Use the import private key option or the scan with webcam option to import your paper wallet private key.
Once you've done the import you must spend the entire balance. Send what you need to an address owned by the other person and the rest to an address on your desktop client. Don't keep any balance in your blockchain.info wallet.

You might ask why go through the trouble to do all this. That is because sometimes if you import a private key it might be reused by the wallet app/web service and change is sent back to it. You want to avoid that because if you assume you've spent all the coins in the private key and then you make the private key public and change is sent to it somebody could steal your coins. So to avoid all that you import into a temporary blockchain.info wallet and spend all the coins in one go.


What cryptocurrency systems predate Bitcoin, and how do they differ from it?

The closest predecessor to Bitcoin is generally agreed to be Wei Dei's b-money proposal.

The proposal had a lot of holes. For example, it assumed that money could be created simply by solving hard computational problems. But it contained no mechanism to control currency inflation, so currency would inflate as computing power increased.

He actually offered a way around this, auctioning off the currency. But this still creates huge problems without a centralized authority -- who confirms the bids were paid and issues the currency? On what authority?

It also hand-waves over major issues. It requires servers to be partially trusted and argued that to be a server, you could be required to deposit some money in a fund that would be debited in the event misconduct was discovered. But who would debit the account? And who would get credited? And by what authority would they do this?

But this got the ball rolling on the idea of a completely decentralized crypto-currency. The amazing thing about Bitcoin is that it solved all the remaining problems at once.


Is possible specify who can send bitcoins to me?

Not possible.  Anyone who can spend a utxo can create a transaction sending those coins to any address, or any script, that they wish.  There is no way to forbid people from sending coins to your address.

Your software will need to filter the transactions and determine which of them were authorized by you.


What are the contents of the wallet.dat file? What is Key pool, default key and reserve keys?

The page you are referring to on the Bitcoin wiki is pretty dated and doesn't really relate to current behavior in Bitcoin Core. Be aware that a lot of the wiki is like this. "Default key" isn't a phrase in common use, I can't fathom what that page could have been talking about in the context of Bitcoin Core.

Reserve keys and the keypool are essentially one and the same. The concept is born out of the problem that people would make a wallet backup, create a few new addresses and receive coins there, restore from a day old backup and find that all their money had disappeared.

The basic solution is to pre-generate a number of addresses and store them in the wallet file, when the client needs a new address it uses the oldest fresh key it has available. The resulting wallet file backup can be safe for as many future transactions as there are keys in the keypool (100 has been the default for a long time), after which point the backup will again become stale and money lost if the user has to recover from it. It's important to keep in mind that making outgoing transactions also consumes a reserved key as one needs to be used for a change address as well, this property makes it difficult for users to know when they need to make a new backup.

The keypool design prevents some very simple mistakes, but it's still easy to lose money to poor backup practices. Hierarchical Deterministic (BIP32) wallets are significantly safer as the backups never become stake, and this is instead used in more modern wallets. The Bitcoin Core wallet tends to be the most conservative and so is slow to move away from the keypool, but it will eventually happen.


How can I get the bitcoin amount of an bitcoin address which doesn't belong to my wallet?

You can use the new scantxoutset method to check for UTXOs matching a given script, address, or key descriptor.

For example, to scan an address, you can use:

bitcoin-cli scantxoutset start "[\"addr(1....)\"]"


How do you apply "-zapwallettxes" on Windows?

-zapwallettxes removes all wallet transactions that are not in the blockchain. It can remove "stuck" transactions, although you don't need this feature in normal operations mode.

Solution A)

On Windows, you need to start the command line prompt (cmd.exe), go to your window search and enter "cmd" and start cmd.exe.
Start bitcoin-qt with --zapwallettxes=1

C:\Program Files (x86)\Bitcoin\bitcoin-qt.exe --zapwallettxes=1

(maybe adapt the program files path)

Solution B)

Create a bitcoin.conf file (normal textfile) here:

C:\Documents and Settings\YourUserName\Application data\Bitcoin (XP)
C:\Users\YourUserName\Appdata\Roaming\Bitcoin (Vista and 7)

Place....

zapwallettxes=1

... in the bitcoin.conf file, start Bitcoin-Qt, remove the zapwallettxes=1, restart Bitcoin-Qt.


Suppose that the light client wants to retrieve the complete block number 1234. I've seen on the documentation the getdata message, which other nodes can reply with a block message.
Do you have any hints on how to evaluate how many bytes the light client must send for the getdata message and how many bytes must be received?

It depends on how big the block is. The block is 0-1 MB prior to segregated witness activating, and 0-4 MB afterward. In general, the earlier the block is from, the less data it contains.
There's some overhead for the message header, but it's 24 bytes, so it doesn't really matter.


Bitcoin paper wallet and Bitcoincash withdrawal?

You will receive an equal amount of Bitcoin Gold as you have in your Bitcoin paper wallet at the time of the fork.  Your paper wallet that contains the Bitcoin will automatically contain the Bitcoin Gold.  In other words, your private key controls both.  We will have to wait to see which online wallets and exchanges support Bitcoin Gold in order to "split" Bitcoin Gold from Bitcoin to be able to withdraw or exchange them.  This is the same scenario as the BTC/BCH hardfork that occurred on Aug 1.


What happen if the Bitcoin network is down, or all miners stop keeping records?

Nothing happens. The longest chain of blocks in existence, so long as it builds off the latest checkpoint) is always the valid chain, no matter what. So long as at least one node brings it back eventually, there's no problem. (And you can keep it yourself if you're particularly worried about it. If you're running the standard client, you already are.)

Unlike a bank account, your Bitcoin balance doesn't have to exist in any particular place to be valid. The miners create the mathematical relationships that prove it's valid such that anyone at any time can tell that it's valid just by looking at the mined data.

If you connected to any Bitcoin node right now and presented a longer chain of blocks (so long as it included the last checkpoint) than they already had, they would switch over to your chain of blocks and it would become the official chain. It wouldn't matter that prior to introducing it, you had the only copy. It's mathematically valid, so the network would accept it.


Won't ASIC miners eventually break SHA-256 encryption?

Another way to look at it is to take a look at a recent block that was mined, for example, block 388368.  Looking at this block on blockchain.info, you can see that the hash for this block is:

0000000000000000021ff110a589e44f56979254a204557311204f803910fdfa

It took roughly 10 minutes for all of the miners (doing a combined 700,000,000 giga-hashes per second) to find the above hash which has enough leading zeroes (17) to meet the difficulty requirement of the network at that time.  Since the remaining digits after the first 17 leading zeroes could have been anything, there are 16^47 (i.e.16^(64-17)) possible hashes that could have been found which would have satisfied the difficulty requirement (which is 3.92 * 10^56), yet it took all of the mining power of the entire bitcoin network ~10 minutes to find just one hash that met the requirement.

To crack a hash, you need not just the first 17 digits to match the given hash, but all 64 of the digits to match.  So, extrapolating from the above, it would take 10 * 3.92 * 10^56 minutes to crack a SHA256 hash using all of the mining power of the entire bitcoin network.  That's a long time.


How to determine if a public key point y is negative or positive, odd or even?

There is no concrete determination that makes one 'y' value negative or not in an EC point. Feel free to make your own convention, like y-values <= than half of p are negative, and > half of p are positive. That's just a convention, though.
Related:

What does the curve used in Bitcoin, secp256k1, look like?

Also, how can you identify which pub key is odd and which is even?
ex: private key 1 x,y is odd , private key 2 x,y is even

You can't! Not without knowing the private key itself. If you could, you would be part of the way towards solving the discrete log problem.


As it is already being discussed on the forum, the standard is currently not in use by anyone, so its implementation details can change over time.


How could I know what of external wallets (private keys) I should use to send btc using libraries assuming it usually changes?

You can't without scanning the entire blockchain to find out what addresses have been used before.

  How could I basically send BTC to some wallet having only seed hex or 12 words?

You can't without scanning the entire blockchain to find the UTXOs that you can spend.

In general, a mnemonic phrase or a seed is not enough to be able to send Bitcoin to someone else. You need to generate keys and scan the entire blockchain to find UTXOs that you can spend. This is why many wallets store more than just the seed phrase in their wallet files.


How to make ImportMulti function like ImportAddress for watch-only addresses placed into Accounts?

After doing some RPC function call tests with ImportMulti and ImportAddress, I feel confident answering my own question.

By way of example, suppose I want to import a watch-only address "1CxZZZREDACTEDYYYYREDACTEDxyzabcD1":

Using "ImportAddress":

bitcoin-cli importaddress  1CxZZZREDACTEDYYYYREDACTEDxyzabcD1 "Account XYZ" true

Using "ImportMulti":

bitcoin-cli importmulti '
  [
    {
      "scriptPubKey" : { "address": "1CxZZZREDACTEDYYYYREDACTEDxyzabcD1" },
      "timestamp" : 1510387200,
      "label" : "Account XYZ"
    }
  ]' '{ "rescan": true }'

Lessons Learned:

Label vs Account:
The "account" parameter in ImportAddress has the same effect as the "label" property in ImportMulti.  They both just label the bitcoin address with friendly text (in my case, "Account XYZ").

Rescan and timestamp:
If you set "rescan" to true in ImportAddress, then it will rescan the entire blockchain from the beginning.  However, if you set "rescan" to true using ImportMulti, then it will only rescan as far back as the earliest "timestamp" value in your list of JSON-encoded address objects. Note that I used the following Linux command to generate my timestamp value of 1510387200:

$ date -d "Nov 11 2017" +%s
$ 1510387200

Summary:

You can use ImportMulti to perform the same operation as ImportAddress, knowing that in ImportMulti, the "label" property of each Import object means the same thing as the "account" parameter in ImportAddress. Further, ImportMulti is more powerful because you can specify each address's creation timestamp, which results in a much faster "rescan".

If anything I wrote here is wrong, please correct me.


I have blockchain.info wallet with BTC and BCC. What will happen if I send BTC only to that address?

At the time of the fork, your previous key now gives you access to two independent wallets one BTC, one BCH. They both start with the amount you had before the fork. There are no "pre-fork" nor "post-fork" bitcoin, there are now only one key opening two different wallets.

The two wallets are not compatible anymore, it means that you cannot move some coins from the BCH wallet to BTC wallet, nor BTC to BCH.

If you send BTC to your BTC wallet, then your BTC wallet will get the coins, and the BCH wallet will stay unchanged.
If you want to fill the BCH wallet also, you have to make another transaction, on the BCH network, of the same amount.

Best pratice would be to separate your BCH wallets from BTC wallets. You can do this with Electron Cash software with the "recovery passphrase", as described here: [https://thebot.net/threads/tutorial-how-to-get-your-private-key-from-blockchain-info-redeem-your-bch-from-blockchain-info.396919/][1]. Don't forget that until you move the coins to new wallets, the same key will give access to both BTC and BCH wallets, even if they have different lives, so keep them safe!


BIP 37 automatic filter update not inserting outputs

BLOOM_UPDATE_P2PUBKEY_ONLY means only update the filter with outpoints when the matched transaction is pay-to-pubkey or bare multisig, not p2pkh or others.  I don't know why though, since what you're trying to do is very common.

You may also be interested in this work in Bitcoin XT which allows a filter to be updated with any unconfirmed ancestors of a matching transaction (to better assess its confirmation prospects).


Why is CheckBlock called twice when processing a new block?

I suspect this is an artifact of the way the code used to work. As to why it hasn't been taken out, it's probably just out of caution, or a "Don't fix it if it's not broken" mindset. Bitcoin Core coders are very cautious, and reasonably so since it's a piece of software that is the main interface to the network for many big players in the industry.

In addition, on master right now, CheckBlock contains a check at the beginning to avoid doing the same work twice. (Added in this commit.)

if (block.fChecked)
    return true;


Can a Mining Pool Force Changes Without Agreement from Bitcoin Core Developers?

In contrast, Bitcoin Core Developers are considering limiting to smaller blocks (300KB).

First of all, for these kinds of changes, Bitcoin Core only merges things with very wide consensus. There was a proposal for 300kB blocks by one individual developer, which I think everyone considers to be very controversial.

Furthermore, these kinds of changes are not proposals for changing Bitcoin Core's behaviour and forking off. They're proposals for changing Bitcoin, and that's not something that is to be decided by the authors of one piece of software.

Then, on to answering your question:

The (collection of) economically relevant full nodes on the network determine the network's rules. I say economically relevant, because someone running 1000 nodes in a cluster, and have them do nothing but connect to the network and relay transactions and blocks is not going to affect anyone. I also say collection, because I'm ignoring the issue of how those nodes' operators come to an agreement.

Miners' job is to build blocks that satisfy those rules. They can choose to not do so, but their blocks will be rejected by the network if they do, and they'll lose their income from those.

However, miners can always choose to enforce extra rules on top of those demanded by the network. That's the first step towards a soft fork, but it's not enough. It's just a collusion of miners agreeing among each other to only build on top of other blocks that satisfy some extra criterion. They could even do this without telling anyone.

That is not yet a softfork, because they could just as easily agree to stop doing something like this. To make it a successful softfork, economically relevant full nodes in the network need to start enforcing the same rules at the same time. That is what makes the change lock in. Because if full nodes are in on it, miners can no longer back out - doing so would either invalidate their blocks, or cause an irreconcilable fork in the chain. BIP9 is a mechanism for allowing miners to coordinate the activation of a new feature, and having full nodes activate it simultaneously.

So in short: softforks are subject to a majority of the hashrate plus significant adoption of enforcing code on economically relevant nodes. Developers of particular software do not directly control either, but obviously do have an influence by providing the means to deploy such software.

Disclaimer: I'm a Bitcoin Core developer.


Who does the work in proof of stake (POS)?

In PoS each node is submitting hashes in a similar way to PoW, if a hash is found that is less than the target then the block is created by that node, sent to it's peers, and if they agree, pass it to their peers.
What is different is that in PoW each node iterates through as many hashes as possible, using data from past blocks and a random number called a nonce.  The more nonces and hashes per second a PoW miner makes, the better chance they have of finding a block.
In PoS there is no nonce, the miner (minter) is only allowed to use the data from the past blocks, and use that combined with the number of coins in each UTXO in their wallet.  So if you have 10 UTXOs then you can only produce unique 10 hashes per second.  To prevent people just making more UTXOs, UTXOs with a larger number of coins have a better chance of finding a valid hash, so there is no benefit in having 1 UTXO of 10 coins, or 10 UTXOs of 1 coin each.
A PoS minter could make more than 1 hash per UTXO per second, but the actual hashes would just be duplicates as there is no variance in the inputs.  So there is no reason to do so as its just a waste of energy to create duplicate hashes.

Theoretically the rich get richer in pure PoS, but this is easily avoided by using other mechanisms to assign coins, like work done on scientific computations (Curecoin/Gridcoin).  In PoW those with more money to invest in hardware and energy get richer, which leads to them getting more hardware, it's the same problem.


What is Bitcoin locking and unlocking script?

There are quite a lot of things going on there, so let's break it down bit by bit.

Transaction structure

A transaction can be seen as a collection of inputs and outputs. Inputs refer to previously created UTXOs, while outputs generate new ones. Therefore, when creating a transaction each input spends a UTXO and each outputs creates one.

Outputs structure

Outputs is what contains the so called locking script, or how it is normally referred in a transaction, the scriptPubKey. Such an script contains the condition required to spend such a UTXO.

Inputs structure

Inputs contain references to previously created UTXOs (through the prev_tx_id and prev_out_index fields). Moreover, inputs contain the so called unlocking scripts, or how they are normally referred, scriptSig. Such scripts require the proof of fulfilment of the conditions specified in the UTXO each input is trying to redeem.

Examples

The most commonly used transactions in Bitcoin, and therefore the most common example of this, are Pay-to-PubKey-Hash (P2PKH) transactions, or transactions that pay to a Bitcoin address. A script "paying to a Bitcoin address" will require that you can proof to be the "owner" of such an address. Let's see how this works:

P2PKH transaction

A transaction creating a P2PKH UTXO will have a scriptPubKey looking as follows:

ScriptPubKey = OP_DUP OP_HASH160 <hash160(pubKey)> OP_EQUAL OP_CHECKSIG

Whereas a transaction tying to redeem such an UTXO as an input, will have a scriptSig looking as follows:

ScriptSig = <sig> <pubKey>

If we put both scripts together in a stack, like Bitcoin does, what we get is the following script:

<sig> <pubKey> OP_DUP OP_HASH160 <hash160(pubKey)> OP_EQUAL OP_CHECKSIG

In order to analyze the script you should have two things in mind. There are two types of clauses, opcodes and data (represented between < >). Moreover, scripts are read left to right, and data is used as input to opcodes.

The execution of the script will first duplicate the public key (since is the first operation of the script), and compute the hash160 of it. Then it will check if the computed hash160 matches with the one provided in the UTXO the input is trying to redeem, and finally it will use the remaining public key (recall that we have duplicated it) and the signature to check the correctness of the signature.

You can find more info about the validation of P2PKH in the Bitcoin dev guide. Moreover, there are several other examples of this. You can find the standard types of transactions also in the dev guide. An extensive list of Bitcoin Script opcodes can be found in the Bitcoin wiki.


Will bitcoins be devalued by competing digital currencies?

You could easily create a bitcoin2, bitcoin3, ... you could create an infinite number of bitcoin currencies having different parametric spaces. These would live in separate mathematical spaces however, so you wouldn't for example be able to create bitcoins in bitcoin2 that affect bitcoins in the original bitcoin: it would be a completely separate system.

But we don't need to be so theoretical about this; there are many alternative digital currencies already in existence:

https://en.bitcoin.it/wiki/Category:Digital_currencies

I would also add other forms of popular credit such as paypal credit, and the new Amazon coin that is coming out to that list.

These can co-exist and there is no problem in this.

I think as a challenger of bitcoin however, it would be difficult, as bitcoin is the most established and most popular digital currency so far. People tend to invest in what is already the most popular, so you get a compounding effect due to this. But this isn't to say that something like something like Amazon coin couldn't eclipse bitcoin for popular use.

Note that these currencies also vary in anonymity and liquidity, which will also affect how popular they become.

But I think in summary I have to say that nobody can predict the future for this kind of thing, so we'll just have to wait and see.