Positive or negative private key of a bitcoin wallet?

There really isn't a "positive" or "negative" for private keys. Private keys are unsigned integers, so they're basically all "positive". Your "negative" numbers are not actually negative, they're the modular additive inverse of the "positive" private key.

Since private keys are really unsigned integers, you can't glean any information about signed-ness from the public key because there are no signs to even look at. Every private key is the "negative" of another private key, so a private key is both "positive" and "negative". Every private key has an additive inverse.

However, given two public keys, you can determine whether their private keys are additive inverses of each other by checking whether the X coordinates are the same. If so, one should have a Y coordinate that is odd, and the other have a Y coordinate that is even. This only tells you that their private keys are additive inverses of each other. But you won't know which is the lower number or what one of them is (unless you have the private key for one of them).


Someone made a small, apparently fraudulent, transaction to my public address. What is the purpose behind it?

She might be expecting you to make a transaction consolidation all of those coins you received. Since the inputs of a transaction are almost always the coins (in jargon "unspent outputs") of the same person, she could then find the transaction which spent those 0.2 cents, add up all the inputs, which would be the amount you earned in the last N days.


Can I cancel an offline transaction with this approach? (opposite of nLocktime)

The approach is correct. You don't have to use different private keys, you can use the same private key and same address for each of the control outputs.


How is the wallet balance split across keys?

It is foreseeable that the number of private keys that you must maintain may grow  to an unmaintainable level.

The most common sense way to consolidate is to send your balance to a single address. This, however, effectively announces that all of those previously created addresses are linked to the same wallet.

If you really must maintain anonymity, then you could send the balance to a tumbler, and have that tumbler output different amounts to several different addresses you control. This, however, does have a cost, because tumblers are not free. Another alternative to a tumbler service is to send your balance to a web wallet that pools all bitcoin together (ledgering internally) and manually send different amounts to separate, new address. However, any time a balance exceeds one of those addresses' balances, it's likely that more than one will be used for the transaction, thereby linking them.


How do I find the transaction ID of what I just transacted?

With bitcoin-qt you can look in your transaction history and right click your transaction to find more info, including the txid.

When using bitcoind, the client gives you the txid as the response for a successful send.


Is the first input in a transaction always the sender's?

Can it safely be said that the first input in the inputs of the transaction is the sender's?

No, no such ordering exists.
Transactions consume UTXOs as inputs, and create new UTXOs as outputs. A transaction can have multiple inputs from one person, or inputs from multiple people. In some cases, more than one person can own an input. So there isn't really any useful way to point to a particular input in a random transaction, and say "this is from the sender".
In cases where there are two or more inputs, there is also the potential that the transaction is a 'payjoin' style transaction, which is specifically built to break common heuristics that attempt to determine UTXO ownership/transaction participation.
More generally, it is prudent to craft transactions in ways which do not surrender information needlessly, so that you can maintain privacy while still engaging with the Bitcoin network.


What miner can I use to mine litecoin with the scrypt hash function?

You can look at this table of software scrypt miners.

You don't mention whether you intend to try to use a CPU or GPU to mine. Towards the top of the list is sgminer (for GPU mining) and Pooler's cpuminer (for CPU mining). There are other choices listed there, but a number of them are just graphical frontends or are listed as no longer maintained.


How can one extract an address balance at a specific height?

This is relatively hard to achieve, because if you wish to allow querying any address at any height you deal with a LOT of data. You probably would need serve database server (cluster).

I'm pretty sure, getting a balance at a specific height from a specific address is not possible over a existing app or API.

You could try built it yourself with bitcoin-core as basis.
Maybe have a look at the >1year old address index patch from Johnathan Corgan. But it would required additional to allow a API where you could define the height.

But caching every address at every possible height (Juli 29 2015: 367456, amount of addresses ~250k) is nearly impossible.


You won't be able to sync without having any connections. The problem is that you have 0 connections; make sure that you don't have any firewalls (either in your docker container, the host, your router, or your ISP) that is blocking Bitcoin traffic.


No, that is not possible. The opening and closing of channels by confirming funding and closing transactions represents the act of securing and delivering of the channel capacity and balance respectively.

The 2-of-2 multi-sig from the funding channel represents the total channel capacity. During the lifetime of the channel, this multi-sig must remain unspent, so that the spending transaction which is eventually confirmed during channel close can be updated during the channel lifetime.

Since no coins can be created, the (funding) input cannot be more than the total of closing transactions outputs, whose amounts represent the last channel balance.

There are proposals to "spend" this funding output together with additional inputs/outputs to an updated funding output to update channel capacities.
See channel "splicing" on this topic.


Fetch Balance of wallet without Core wallets of all coin?

You can check the balance of an address even if it is not a core wallet by using block explorers. Here are two useful ones for checking the balance of a Bitcoin address:

https://blockchain.info/api/blockchain_api

and an Ethereum account:

https://etherscan.io/apis#accounts

You may wonder how it is possible to check the balance of an 'offline' paper wallet. It comes down to how Bitcoin (and other Bitcoin-like blockchains) work. At the most basic level, you have a private key. You can generate a public key from the private key and then an address from the public key. Bitcoins are sent to this address.

Blockchain explorers can check the balance of any address, even addresses that have not been generated yet! This is because an address is simply a string of letters and numbers that conform to a particular format.

You can read more about addresses here:

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


Why can't we make the Bitcoin software start the blockchain from the beginning?

And how exactly would the network agree on the last included block in order to spawn your new blockchain? That would be kind of complicated.

In my opinion Merkle tree is already fixing the problem. Downloading the headers of each block is enough to verify payments.

Remember that only miners actually need all of the blockchain data. Clients don't.


You're looking for CBlockIndexWorkComparator, which operates by three rules. The rules are applied one at a time, and if a rule leads to a tie, then the next rule is applied.

Which blockchain has the most work?
Which one was received first? (This can be different for different clients, which is why the previous rule is applied first.)
Which one has a larger pointer address? (This is largely random, and different for different clients.)


How do you create a planet-specific cryptocurrency that will ignore longer block chains from other planets?

Simply limit the block target (i.e. 10 minutes) to the speed of light (300,000 km/s).

Unless there is some wormhole or other unknown to reduce this limit, Bitcoin is safe from honest mining from any planet outside of 180,000,000 kilometers away (300000km/s * 60 sec * 10 minutes) since any miner can't keep up with the blockchain and would get any block at about the time the next block comes out.

Someone with more advanced technology / more hashing power could create a 51% attack and submit it to disrupt the Bitcoin economy even outside of this radius.


Can someone explain this [outdated] BIP12 OP_EVAL exploit?

Each transaction has a certain number of "sigops", the number of signature validation script ops like OP_CHECKSIG in its scripts. These script ops are very expensive to compute. Transactions with too many sigops are considered non-standard and will not be relayed by most clients. Blocks with too many sigops in their transactions are illegal and will be rejected entirely.

That exploit allows you to include sigops in transactions without increasing the sigop count. It could be used to create a very slow-to-compute transaction that isn't very big size-wise. Not a huge exploit, and it could be worked around, but it demonstrates an important weakness in BIP 12: OP_EVAL scripts can't be analyzed accurately without running them first.


How does a full node benefit from receiving a block with a version number in its header?

The block version number has traditionally been the way for miners to signal their readiness to enforce a soft fork. The version number was likely used because of its historical use for soft fork signalling. Also, the version number does not indicate that a particular set of rules are active for a block. In fact, the version bit used by Segwit is no longer set by miners (besides those using ASICBOOST) since Segwit has activated.

Additionally, the version number helps SPV wallets know when segwit is active so that they can use it. Otherwise SPV wallets would have to download entire blocks in order to examine the Coinbase transaction in order to do so, which would largely defeat their primary benefit.

Full nodes don't really benefit from the version number being used as the signal. However when deploying any kind of fork, consideration must be made for everyone in the ecosystem. Using the version number does not hurt full nodes, has some extra benefits of not taking up block space for transactions themselves, and lest SPV wallets know when the fork activates.

  I thought Segwit was about transaction ordering in the actual block

No. Segwit does not effect transaction ordering at all. It changes the format of transactions and how certain output scripts are validated.

  Other than protecting those values for future forks, does Segwit require any special consideration by SPV wallets / miners?

Yes. SPV wallets need to know when Segwit activated so that they know when they can make and accept transactions containing Segwit inputs and outputs.


What is the ideal public nxt.properties config file for a public facing node for NXT / Ardor?

Are the following entries still necessary:

nxt.uiServerHost=0.0.0.0
nxt.uiServerCORS=true
nxt.uiSSL=true


How to create a P2SH address with bitcore-lib

Here is the reference for creating a P2SH multisig address https://github.com/bitcoinjs/bitcoinjs-lib/blob/master/test/integration/addresses.js#L44

However your question states "custom" P2SH so I think you might be asking about something more advanced, in which case I would suggest reviewing bitcoin.script.compile, the CLTV address for example:

let bitcoin = require("bitcoinjs-lib");
let bip65 = require('bip65');

function cltvCheckSigOutput (aQ, bQ, lockTime) {
    return bitcoin.script.compile([
      bitcoin.opcodes.OP_IF,
      bitcoin.script.number.encode(lockTime),
      bitcoin.opcodes.OP_CHECKLOCKTIMEVERIFY,
      bitcoin.opcodes.OP_DROP,

      bitcoin.opcodes.OP_ELSE,
      bQ.publicKey,
      bitcoin.opcodes.OP_CHECKSIGVERIFY,
      bitcoin.opcodes.OP_ENDIF,

      aQ.publicKey,
      bitcoin.opcodes.OP_CHECKSIG
    ])
  }

  function utcNow () {
    return Math.floor(Date.now() / 1000)
  }

let NETWORK = bitcoin.networks.testnet;
let alice = bitcoin.ECPair.fromWIF('cScfkGjbzzoeewVWmU2hYPUHeVGJRDdFt7WhmrVVGkxpmPP8BHWe', NETWORK);
let bob = bitcoin.ECPair.fromWIF('cMkopUXKWsEzAjfa1zApksGRwjVpJRB3831qM9W4gKZsLwjHXA9x', NETWORK)

//set lock time for 3 hours from now
let lockTime = bip65.encode({ utc: utcNow() + (3600 * 3) });

let redeemScript = cltvCheckSigOutput(alice, bob, lockTime);
let scriptPubKey = bitcoin.script.scriptHash.output.encode(bitcoin.crypto.hash160(redeemScript));
let address = bitcoin.address.fromOutputScript(scriptPubKey, NETWORK);

console.log(address);


what would it take for the Bitcoin price to drop less than a dollar?

This is all speculation in a very new technology. I'm not an expert in economics, but there are irrefutable facts that's some of the "cultists" will not entertain. There are, simply put, 2 types of Bitcoin advocates:

Those who see in binary; black and white, moon and doom - more often than not Bitcoin's "success" is solely judged in fiat conversion
Those who are more pragmatic; the people who understand that MySpace gave way to Facebook

The most dangerous attitude is the former, because there is no acknowledgement that Bitcoin, in its infancy, still has a long way to go. The Blockchain is the key technological advance here. It is already being adopted by companies like Blocktech Group for commodoties and smart contracts. That may involve building on top of the Bitcoin blockchain, or it may mean an entirely new Blockchain purpose built for a corporate interest.

  As a thought experiment, imagine there was a base metal as scarce as gold but with the following properties:

  boring grey in colour
  not a good conductor of electricity
  not particularly strong, but not ductile or easily malleable either
  not useful for any practical or ornamental purpose

  And one special, magical property:

  can be transported over a communications channel

  If you redact "over a communications channel" you end up with depleted
  uranium...

-Satoshi Nakamoto

So with that in mind, realise that there is no certainty of a $10,000 BTC price in the future. Perhaps $400 is what BTC is worth? Perhaps $1100 was well and truly over its true? These questions can only be answered with time and with development. There's a very small team looking after the code while speculators search for answers about why they're not rich yet. Perhaps we need to add value to Bitcoin instead of expecting, like it's everyone's destiny, that BTC will go to the moon in price. Will it drop to $1; only if the Bitcoin P2P network dies. I think the best think anyone can take away from this is it is possible to separate a Blockchain from Bitcoin. A long term outlook would serve everyone better than daily stresses over price volatility.


What are the obstacles to pegging the value of bitcoin to an established stable currency?

The only way to fix an exchange rate is to constantly trade at this rate. This requires unlimited funds.

So assume you want to peg BTC against CHF as in your example. For simplicity, we aim at 1 BTC == 1 CHF. Here's a simple recipe.

Have unlimited Bitcoin and unlimited CHF.
Find a Bitcoin exchange.
Offer to buy an unlimited amount of Bitcoin for 1 CHF/BTC.
Offer to sell an unlimited amount of Bitcoin for 1 CHF/BTC.
Observe how everyone will accept 1 BTC/CHF as the official rate.
If you run out of Bitcoin or CHFs, give up.


Accidentally send BCH to my CashApp wallet!

The only one that can help you is CashApp, since you locked your funds to a key they control. AFAIK, CashApp uses segwit addresses, and BCH does not support segwit, so recovery would require a bunch of additional (likely manual) intervention. You'll have to negotiate with them.


Ripple is actually not really new but still an interesting coin.

Their website lists several possible exchanges (https://ripple.com/xrp-portal/how-to-buy-xrp/). I have no strong opinion about which of these is most reliable. There are others (https://poloniex.com for example) where you can trade XRP/BTC, too, so if you already have an account at an exchange that you trust that might be the easiest way.


In NXT, how long do you have to wait for 1440 blocks to be mined?

1440 blocks in nxt is about 24 hours. Since nxt blocks are generated every minute, thats 1440 minutes.

1440 minutes / 60 minutes = 24 hours

NXT block generation isnt exactly 1 minute as some blocks are solved once every few minutes, but on average its about 1 minute. Hence the 1440 block mentions you see everywhere.


How can I run Bitcoin-QT client behind a restrictive firewall using a putty tunnel?

The easiest way to make this work would be to install cygwin on your windows machine, specifically ssh client package.

Then from a cygwin shell, run ssh -D 8080 user@linuxHost.

Now you can point the qt client to localhost:8080 as the socks proxy.


Bitcoin-QT client shows coins, but cannot find wallet.dat

I guess you already looked there, but when I open a terminal and enter
ls -la ~/Library/Application\ Support/Bitcoin/
I see all the files there, including wallet.dat. Please note the backslash before the folder name space.


Is there a working, functional, maintained way to accept bitcoins through a Wordpress site to an Electrum wallet?

I've searched quite a lot for something like this and to my knowledge, the answer is no.

the bitcoinway plugin you reference was the closest thing to a working plugin that required no middleman.  It used to work with the older woocommerce and the 1.9.8 mpk but it doesn't work at all now with the latest woocommerce version.  It has not been updated in a long time and id say its a dead plugin now.
the closest thing I've found to replace it was the coin simple woocommerce plugin but as of the latest woocommerce update, it no longer works due to a JSON parse error that I can't workaround.  It does require signup on coin simple but from what I can tell, the API key and biz ID are input to allow you to validate transactions.  Your MPK is plugged in on woocommerce and coin simple never controls the wallet.
gourl.io is probably the next best thing but they do have interaction with your wallet and forwarding of the funds.
there is a plugin that works with an MPK that generates addresses with the click of a button.  But its not automated as far as commerce sales go.  The plugin name is "Bitcoin Payments".  https://wordpress.org/plugins/bitcoin-address/

if anybody finds a working plugin without a middleman, please share.


do the trezor wallets support all crypto currencies for strorage?

See "Which coins are currently supported?" on Trezor FAQ

  At this moment it is Bitcoin, Ethereum (+ all ERC-20 tokens), Ethereum Classic, ZCash, Litecoin, Namecoin, Dogecoin, Dash and Bitcoin Testnet

So the conclusion is, Trezor supports most of the altcoins, but the computer software doesn't. If you can't code a software that allows Trezor to hold more altcoins, you can only use the altcoins in the list, with the name of the wallet next to it.


How does Ripple solve the sock-puppet problem during consensus?

A key point in Ripple is that the consensus doesn't take everyone's opinions into account. Each user has a list of trusted nodes. It will not do much good for an attacker to create multiple anonymous, untrusted sockpuppet accounts.


How blockchain.info calculate the value transacted

You do not have to calculate the in/out values to see how many bitcoins have been "sent" to an address.

You see, outputs from a transaction can be "locked" to a specific address. However, the address page on blockchain.info shows all the transactions that have resulted in an output being locked to that address.

In the most recent transaction on that page, you can see that one of the outputs has been locked to that specific address:

Out:
----
1BTvKHzbfm3RjPMxDZSsG2YYuaEHgfdJNP - (Spent) 0.00045884 BTC
1NCLWFw6F2nJ2pgBWy96K37rbx7VSLZs66 - (Unspent) 0.00239111 BTC
1D7BNbWBPuL22TW6WuoSq5sRrbPAxeJw8g - (Spent) 0.0156 BTC
19tqZYnP9youKtbene2FZiZtZyJYaLeBDw - (Unspent) 0.0236 BTC <- this one
1wLbaePtYhh2t5Cgd5NF59LX6Pooe1yLH - (Spent) 0.00920259 BTC
3HXAkXTYvtLzYuudDfNZBMSoueUtvdwXAz - (Unspent) 0.03036754 BTC

So that's where they are showing that 0.0236 has been received by 19tqZYnP9youKtbene2FZiZtZyJYaLeBDw.

I suppose showing entire transactions on an address page can be a little confusing, when it's only the outputs that are locked to an address (not entire transactions).

Here is an alternative way of viewing the balance of an address in a blockchain explorer: http://learnmeabitcoin.com/browser/address/19tqZYnP9youKtbene2FZiZtZyJYaLeBDw


In Ripple, when an IOU is defaulted upon, who gets hurt?

There are two very important concepts here:

You can only be hurt by someone you chose to trust.
A chain only exists instantaneously while a payment is made.

The answer to your question depends on whether David pays Charlie or not. If David pays Charlie, then David gets hurt because he trusted Eve and she betrayed him. If David doesn't pay Charlie, then Charlie gets hurt because he trusted David and David betrayed him.

David learns a valuable lesson here. If you trust someone, you may wind up on the hook for the full amount you were willing to trust them for. Your choice will be to make good on them or betray the trust that people have extended to you.

Alice still holds an IOU from Bob and she agreed to trust Bob. Unless Bob betrays her, she's safe.

Now, this may not be exactly what happens. For example, if David can find someone else who will take Eve's IOUs that leads to a payment path to Charlie, he can meet his obligations and stick someone else who chose to trust Eve with her worthless IOUs. So you may get a game of "hot potato" with someone getting stuck with it last.

It is important to understand that when you extend trust to someone in Ripple, you are trusting them to hold your money -- money you may owe to other people. It should not be done lightly, except perhaps in small amounts.


Yes your wallet file will be sufficient to recover your Bitcoin if you did not encrypt it with a password.

In the future please encrypt your wallet and store backups offline


In Bitcoin v0.1.5 to v0.3.24, the coinbase scriptSig contained:

txNew.vin[0].scriptSig << nBits << ++bnExtraNonce;

In Bitcoin v0.4.0 to v0.5.3, it changed to:

pblock->vtx[0].vin[0].scriptSig = CScript() << pblock->nTime << CBigNum(nExtraNonce);

Bitcoin v0.6.0 to v0.6.3:

pblock->vtx[0].vin[0].scriptSig = (CScript() << pblock->nTime << CBigNum(nExtraNonce)) + COINBASE_FLAGS;

Bitcoin v0.7.0 to current:

txCoinbase.vin[0].scriptSig = (CScript() << nHeight << CScriptNum(nExtraNonce)) + COINBASE_FLAGS;

So the coinbase scriptSig field has changed over time, but it has always placed the extranonce as the second item.

In Bitcoin v0.1.5, the size was unlimited, and in more current versions, it's 4 bytes or less. (This is caused by the switch from bnExtraNonce to nExtraNonce.)

There are some other odd details - in v0.1.5, it only resets when the client resets, but in later versions it resets on every new block.

Of course, this is just what the core client does. Other miners or pools might do something else.


Can one safely buy vanity addresses from a third party without risking one's coins from being stolen?

From what it appears, yes, it is possible, and quite simple really to outsource vanity address creation to a third party without risking anything.

Bitcoin addresses are created from ECDSA keypairs. Their property is that if you take two private keys and add them together (with appropriate modulo operations), the sum will map to a public key that is the same one as one would obtain by adding the two public keys corresponding to the private keys.

This means that in order to outsource vanity key generation, one can create an ECDSA keypair, store the private key safely, and give out the public key to other people. They would then proceed to generate ECDSA keypairs, summing the generated public keys to the one provided by you, and checking whether they map to the appropriate vanity address. If it does, they need only to give you the appropriate private key, which you then need to add to your secret private key in order to obtain the private key that maps itself to the vanity address.

JoelKatz explained it in his post, and I went ahead and implemented a "vanity pool" that enables such outsourcing. Moreover, I also created a simple testing suite for playing with combining the ECDSA keypairs. Currently there are no "split key vanity miners" available, nor any offline solutions for this problem, but they can follow shortly.


how to config p2pool so that it can connect to bitcoind wiht HTTPS?

For using SSL with Bitcoin follow these instructions: https://en.bitcoin.it/wiki/Enabling_SSL_on_original_client_daemon

Maybe your RPC Connection String have connection type "HTTP"

connection-type = "http"

Change http to https


How does intial block download work at P2P layer?

Bitcoin Core does headers first sync so it downloads the headers first and partially validates them before downloading the blocks. So if a malicious node sends headers with invalid PoW's, the syncing node will disconnect from it and sync headers off of another node. If the it receives multiple headers for the same block height, that node will be considered to be misbehaving and stop syncing headers from it.


Not all addresses beginning with a 3 are multisig, and Bitcoin Core does not make you multisig addresses. Addresses beginning with a 3 are P2SH addresses. The segwit addresses Bitcoin Core generates by default are segwit scripts nested in a P2SH address in order to allow for backwards compatibility. If you want to use the native segwit addresses (bech32 addresses that begin with bc1), you can start Bitcoin Core with -addresstype=bech32 or go to the receive tab to get a new address and check the "Use bech32" checkbox.


Bitcoin core wallet backup corrupted by an external tool

According to a random website coughed up by Google:

A file with the AXX file extension is an AxCrypt Encrypted file. AxCrypt is a file encryption program that scrambles (encrypts) a file to the point that it's unusable without first being decrypted with a specific password/passphrase.
When an AXX file is created, it's automatically assigned the exact same name as the unencrypted file but with the .AXX file extension appended to the end. For example, encrypting vacation.jpg results in a file called vacation.jpg.axx.
You can double-click an AXX file to open it with the AxCrypt software. However, note that if you're signed in to your AxCrypt account, double-clicking the AXX file will open the true file and not actually decrypt the AXX file.
Use the program's File > Open Secured menu to open the AXX file but not actually decrypt it. To decrypt the AXX file requires that you either right-click it and choose AxCrypt > Decrypt or use the File > Stop Securing option


Can rainbow tables be used to find private keys from public keys?

No.

A rainbow table is simply a memory-cpu tradeoff that allows you to find preimages of a function faster by having a precomputed table with some of the entries.

In order to construct a rainbow table for bitcoin private/public keys, you still have to first iterate through all the keys at least once. It doesn't matter that only part of the keypairs will end up in your rainbow table - you still have to go through all them.

That is an impossible task. There are 115,792,089,237,316,195,423,570,985,008,687,907,852,837,564,279,074,904,382,605,163,141,518,161,494,336 valid private keys to go through. To put that in perspective: if you would put a computer on every square micrometer of earth (1/1600th of the cross section of a human hair) that can compute as many public keys per second as the entire Bitcoin mining network does hashes per second at the time of writing (4 exahash/s), it would take you 120000 times the age of the universe to go through all keys.

And, even if somehow you had an oracle that could give you the rainbow table, it would need to be impossibly large to make cracking private keys practical. If your table had a trillion entries, it would only make cracking a trillion times faster. That's still utterly impossible.


Can Bitcoin blocks be organized into shards?

If you mean whether block verification can be distributed so that one entity can participate without storing the entire blockchain, this isn't compatible with the current design, but maybe a new design can do that. Also, suggestions such as this aim to improve the ability of lightweight (SPV) clients, who do not store the entire blockchain, to verify transactions concerning them specifically, without changing the core protocol.

If you mean whether a single entity can distribute the blockchain among several machines on the same LAN, then this is possible. The basic operation needed for block verification is to look up the details of a previous output, so the natural sharding key would be output hashes. One could also cache the newest outputs which are the most likely to be used in the following transactions.


How to transfer BTC from desktop wallet to mobile wallet (without fees), say using Electrum or Bitcoin Core

To accomplish this you will not 'transfer the bitcoin', you will just import the keys that can spend your bitcoin, into a new wallet.
Not all wallet software will support importing/exporting keys in every format, so you'll need to ensure that your current wallet software is capable of exporting keys in a format the the new wallet will accept. There are several formats for private keys, as well as other standards for backing up/recreating wallets, such as BIP32/39/44/84, etc. Be sure to familiarize yourself with these formats, and know which ones you'll need to use in order to accomplish your goal. Any wallet software worth using will allow you to export keys in some way or another, and hopefully provide some sort of documentation to help with this.
Very importantly, you need to understand that the private keys (or mnemonic seed phrase) that you'll be handling is the literal key to your bitcoin. If you store it on, or enter it into a compromised device, your bitcoin could be stolen.
Once you have the keys that control your bitcoins exported, you can import them to the new wallet, and (potentially after a rescan of the blockchain to locate your funds), your funds should appear in the new wallet.


I keep hearing about MAST, what is it and what does it do?

From what I've read and heard about MAST, it's an alternate version of pay-to-script-hash that uses a Merkle root instead of a regular hash digest.  It combines this idea with that of an abstract syntax tree, which is a data structure that compilers use to parse source code.  By "Merkelizing" a syntax tree, it allows redeemers to only expose the parts of the script being used for redemption.

This means that you can have more complicated scripts than are currently allowed by the 10,000 byte or 201 OP code limit.  Let's say there's a redemption script whose conditions look something like this:

A OR (B AND (C OR D)) OR ((E OR F OR (G AND H)) AND NOT I)

Right now, this script would be too complicated to fit inside the limit.  By forming it into a syntax tree and Merkelizing it, a redeeming transaction would only have to expose the conditions that were met.  For example, just A would redeem it, and so would just B and C.  This fits inside the size limit, while also never revealing the unused conditions that could have been used to redeem the UTXO.  There's a complexity gain without introducing the risk of DOS attacks, as well as a privacy gain.

I'm unsure how this will directly help with scaling, but since it allows for more complex scripts without a transaction size increase, it certainly won't hurt.  It's just another building block at the disposal of a developer, which they can then hopefully use to solve some future problem.


Bitcoin economic nodes, concensus, and historical nodes

the recent dos + inflation bug

That would be CVE-2018-17144

  Can you someone elaborate on the economic majority?

A definition from Concensus as a service, Swanson, 2015

  A consensus mechanism is the process in which a majority (or in some cases all) of
  network validators come to agreement on the state of a ledger.  It is a set of rules and procedures that allows maintaining coherent set of facts between multiple participating nodes.   In the case of Bitcoin, the “longest chain” – the  chain with the most
  proof-of-work – is  considered to be the valid ledger.

Active nodes reject transactions or blocks that don't meet the rules. If some nodes have a different set of rules, there can be effectively a fork in the blockchain.

Ultimately it is the longest version of the blockchain that prevails. This has the most proof-of-work embodied in it.

In the  case of the bug mentioned, as more nodes get upgraded, they will reject any blocks that contain transactions that attempt to exploit the bug. There will be invalidated blocks.

Only active nodes play any part in enforcing concensus rules. Nodes which are not currently propagating transactions or blocks play no part in this.


Why I obtain this error trying to compile this wallet?

Like it says, you are missing the header file miniupnpc/miniwget.h.  Usually this means there is a required library that is not installed.

Ubuntu has the convenient tool apt-file for finding which package provides a particular file.  Install the apt-file package (apt-get install apt-file) and run apt-file update to install the file list.  Then you can do

$ apt-file search miniwget.h
libminiupnpc-dev: /usr/include/miniupnpc/miniwget.h

So you need to install the libminiupnpc-dev package.

Since the documentation doesn't seem to mention this dependency, you may want to report this as a documentation bug to the MJcoin developers.


Is the scriptPubKey of a previously unseen transaction in an incoming block checked? If so, where?

The behaviour of the mempool or orphan tx pool should not influence the validity of blocks at all.

When a block comes in:

main.cpp:ProcessMessage deals with processing messages, and dispatches to:
main.cpp:ProcessNewBlock deals with specifically processing block messages, which stores it on disk using AcceptBlock and then calls:
main.cpp:ActivateBestChain tries to verify the potentially new best chain and switch to it. For every atomic "reorganization" step, it calls:
main.cpp:ActivatebestChainStep which will try to verify new blocks to be added to the tip of the chain using:
main.cpp:ConnectTip which does the actual processing using:
main.cpp:ConnectBlock, which will iterate through the block's transactions and verify their inputs using:
main.cpp:CheckInputs which builds up a list of CScriptCheck objects for each script execution to be performed, which are verified from another thread. ConnectBlock waits for these threads to finish and deal with the result. In those threads, we call:
main.cpp:CScriptCheck::operator() which performs a single encapsulated script execution, using:
script/interpreter.cpp:VerifyScript to do a verification of script, which consists of executing a scriptPubKey + its spending scriptSig using:
script/interpreter.cpp:EvalScript.

So, EvalScript() should be executed for all scriptPubKeys which are spent by a block, before that blocks ends up being accepted as a tip.


How to compute double sha256 shown in examples of bip 143?

Do this:

echo -n $PREV_OUT | xxd -r -p | openssl dgst -sha256 -binary | openssl dgst -sha256

Explanation

You want to do this:

  prevout (raw bytes) -> sha256 -> sha256 -> convert to hex

You're doing this:

  prevout (raw bytes) -> convert to hex -> sha256 -> sha256 -> convert to hex

xxd -r -p reverses the hex conversion.


Why can't we fight Bitcoin thieves by not accepting payments from hacked accounts?

Fungibility. Money needs to be fungible, otherwise it's not money at all.

Blacklists allow censorship and confiscation of wealth by centralized/powerful players (like governments) which will be abused to screw over innocent people Or (hopefully) scare those people away from Bitcoin in the first place: why would you invest in Bitcoin if you know you could end up on a blacklist someday?

It weakens the lesson the victims needed to learn the hard way: if you don't hold the private keys securely yourself, you don't hold the bitcoins.


Is it possible to run a pruned node while being able to verify any TXID?

You're asking two different things, so it's not clear which answer is correct.

Yes, a pruned full node verifies all transactions. That's why it's still called a full node.

No, pruning is not compatible with txindex.

But, are you sure you need txindex? If you're only receiving payments to yourself you don't need txindex.


Altcoin Wallet Warning: Virus Alert Coinstealer in it! Why?

its sounds like a false positive,the same was happened on Bitcoin core https://bitcointalk.org/index.php?topic=1694796.0 to be sure you have to options 1 check their source for backdor etc,2 or raise an issue on GitHub


Do any altcoins use a DHT for connecting to peers?

As far as I know, Both Eth(https://github.com/ethereum/wiki/wiki/Kademlia-Peer-Selection) and Ada(https://cardanodocs.com/technical/protocols/p2p/) use Kademlia DHT.


with what number do multisig addresses (non-P2SH) start?

There is no address type defined for raw multisig. If you want to send money to them, you'll need to construct the scriptPubKeys manually, or use the payment protocol (BIP 70-72).

In general, raw multisig is discouraged as it stores more data than necessary in the UTXO set (the database that all full nodes must maintain to be able to validate transactions).


Mapping the Bitcoin Lightning Network: Why not use the Blockchain?

wouldn't it be possible to parse the blockchain for all live payment channels to create a complete, up-to-date map of the Network so that you do not have to use flooding or beacons on the Network itself?

No because it is not possible to know which transactions are related to a payment channel opening, and channel closing transactions can be ambiguous. The funding transaction sends money to a 2-of-2 multisig, but these are in outputs as a P2WSH or P2SH-P2WSH script which means that the redeemScript that specifies the 2-of-2 are not known. You cannot assume that any P2WSH or P2SH (because a P2SH-P2WSH looks just like a P2SH) is for funding a payment channel.

For closing transactions, if there is a cooperative close, then the spend of the funding transaction's outputs will look just like a normal 2-of-2 multisig, which is not indicative of a payment channel. In a unliateral close, you would be able to identify the unilateral close only after the person closing the channel spends their output.


How does the Bitcoin Network verify whether the wallet has enough bitcoins for the transaction?

It doesn't. The network doesn't care about wallets or accounts at all. Those are constructs used by other programs to manage bitcoins.

The network just checks to make sure that the inputs a transaction uses are valid.

  However isn't it feasible if the size of the blockchain becomes really large? Is there any practical way that the current nodes verify whether the transaction is valid?

Nodes keep an efficient index of unspent outputs. They can then check the inputs of a new transaction to make sure they're in the index of unspent outputs. You have to scan the whole blockchain to build this index, but once it's built, accessing and maintaining it is cheap and efficient.

You can think of an account as a key and unspent outputs as locks. The nodes just have to check that the key fits the lock. It doesn't matter what other locks the key might or might not open. The person who holds a key wants to know what locks it will open, but to know if access is allowed, we just have to check if the key fits the lock it's being put in.


Hashcash is one of the many anti-spam techniques used today, which is essentially a proof-of-work system designed to limit not only email spam but also denial-of-service attacks. A similar proof-of-work methodology is being used in bitcoin for block generation.

With an average of 150 billion e-mails sent out on a daily basis I cannot see how this could be deployed in the blockchain, which would then have to be adjusted to facilitate 1,7 million TPS while now it only serves 7 TPS (artificial limit).

Also, bitcoin is not really made for such small payments which would result in tons of useless and unspendable dust outputs.


Sure there was, when mining-difficulty was very low. And the miners did not have yet implemented mining on GPUs.


It's different for each wallet but here are the top ways.

Coinbase Method
You put a fee on USD->BTC and vice versa. Downside of this is that you can exploit the user using the delay created by using fiat and banks, Coinbase purportedly buys bitcoins when user buys, then a few days later takes bitcoin and refunds (by marking transaction as "suspicious") user if price goes up and holding is profitable.

Blockchain.info Method
You gain revenue from allowing services to put links on your website. Downside to this is that you can't just advertise more if you aren't making the hosting costs.

Patron Method
You gain revenue from often your own services, basically your just a free wallet that the owner supports himself. No real downside. Inputs.io used this, revenue gained from CoinLenders, ultimately "hacked" which makes you wonder the motivation of a non-profit wallet service.


Now that bitcoin difficulty is too high to see much output even on a properly configured gpu with the right drivers, running cgminer at > 100 Mhash/s of sha256d, your learning excercise might be better making an sha256d "altcoin" of < 100,000 difficulty.

In terms of strategy, I think that you want to download a "stratum proxy" which preprocesses blocks from "somewhere" to compute a "midstate" which anything runnning cgminer on your LAN can try hashing with lots of nonce values.  I think that "somewhere" could conceivably be some sort of local testcoin full node which you've poked the source code of.  Whilst "somewhere" could also be a usual BTC mining pool, you won't see enough shares to get bitcoin for your gpu programming.

Next I think that you want to set up your gpu pc with correctly installed drivers and cgminer, so that you can see the text in a terminal showing a reasonable hashrate when you run cgminer with your stratum proxy specified.  You might need to open a port number and do some messing like that the first time it is used, and it took me a few days to get that far on linux.

Once you have seen your gpu working with "ordinary" cgminer, you might want to go into the source code of cgminer, but unfortunately that hides most of the inherant parrallelism of the gpu behind the proprietary binary hardware drivers to which it makes some calls.  It may be that those won't let you use more than 1 gpu core for reasons unknown to me.  You can also call cgminer as a multithreaded cpu miner but that is sooo 2010 that it won't do much with bitcoin nowadays.  Hence my hint that an altcoin or home testnetcoin on sha256d might be interesting.


Why can I only see the balance of my wallet and not the one of each of my receiving addresses? (Multibit)

There are multiple reasons why you do not see individual address balances or get to choose the sender address:

For privacy reasons your client will generate a new address for every change output in your transactions. Soon, you'd have many more addresses; and choosing from a long list of addresses is not user-friendly.
"Addresses are not wallets nor accounts, and do not carry balances. They only receive funds, and you do not send "from" an address at any time." (see Address Misconceptions)
There is no "from" address (see From address)


How to use BitCoin private keys (a primer)

But what I don't understand in particular is how they relate to transactions and wallets.

This requires a long answer. Here's a nice intro which should answer this.

  I am actually not sure what the point is for adding the key to the wallet. Does it somehow relate to transactions? Why do I need to add a private key to my wallet?

If you read the above intro to cryptography in Bitcoin, this question is almost fully answered. You need a private key because that's the secret half you use to sign transactions. Otherwise  people could spend your Bitcoins.

  Can/should I add more than one to a wallet? Or, oh! I think I remember, the wallet key is just for storing your private keys. But why don't I just store it myself in a different way? What advantage does having it stored in a wallet offer?

Yes you should create many. In fact, one private key for each transaction is ideal. You can store these keys anywhere you want, but a wallet program will do many nice things for you. The wallet keeps track of how much Bitcoin you have, it gives you an easy way to sign TX's and send them to the network, it groups all your received transactions and allows you to combine their amounts to form new transactions and so on. A profesionally developed wallet will also normally employ good security practices. But nothing's stopping you from rolling your own key store.

  Then the second part of the question is, what key I should be signing my transactions with, and how. Can I say "wallet, give me a key by name" or something?

Bitcoin Core and other wallets offer a database management system to manage your keys for you. Yes you can usually give them mnemonic names or start typing a prefix and the wallet software suggests the rest. You should sign your TX's with a key you've never used before. That's the general rule.

  Final part of the question is, how many keys I should have.

One key per transaction. Never reuse keys.


Method of spending LTC Litecoin from a paper cold wallet?

You can import the private key, spend part of it, send the change back to the same address, and delete the key. This would leave a lesser amount in the same paper wallet, but is generally not a good practice (address reuse).

Also, if the address has multiple inputs, you can just spend X if Y distinct inputs with exact change and that will work too.

litecoin-cli importprivkey 1LYourPrivateKeyThatIsWrittenOnThePaperThatYouWantToKeepForSomeReason


Where can I find people willing to pay me in bitcoin for services?

CoinWorker pays Bitcoins for repetitive jobs such as identifying images that contain adult content, or rating search engine results.  It acts as a Bitcoin interface to the CrowdFlower network.


Script To Limit Transactions To Specific Wallets

How to use OP_BOOLOR and OP_EQUAL?

You can see the actual implementation for script opcodes in Bitcoin's script.cpp.

OP_BOOLOR does this:

[...]
CBigNum bn1 = CastToBigNum(stacktop(-2));
CBigNum bn2 = CastToBigNum(stacktop(-1));
CBigNum bn;
[...]
case OP_BOOLOR:              bn = (bn1 != bnZero || bn2 != bnZero); break;
[...]
popstack(stack);
popstack(stack);
stack.push_back(bn.getvch());
[...]

So it's effectively reading from the stack, popping the values and pushing the result.

OP_EQUAL is pretty much the same:

[...]
popstack(stack);
popstack(stack);
stack.push_back(fEqual ? vchTrue : vchFalse);
[...]

It's popping two values from the top and pushing the result of the comparison.

Is the script correct?

Let's run the scripts and see what happens! scriptSig is executed first:

scriptSig: [Wallet] [Wallet] [sig] [pubKey]

This code is just pushing into the stack, so after the scriptSig runs the stack looks like this:

[pubKey] <- TOP OF THE STACK
[sig]
[Wallet]
[Wallet]

Notice the elements are reversed. The first thing pushed goes to the bottom of the stack.

Now scriptPubKey is run keeping the contents of the stack resulting from running scriptSig. If we do that with your script...

scriptPubKey: OP_EQUAL Wallet1_Value [Wallet]
              OP_EQUAL Wallet2_Value [Wallet]
              OP_BOOLOR
              OP_VERIFY OP_DUP OP_HASH160 [pubKeyHash] OP_EQUALVERIFY OP_CHECKSIG

...the first thing that gets executed is OP_EQUAL, which compares the top two elements of the stack [pubKey]  [sig] which are obviously not equal so 0 (false) is pushed. I'll just stop here since it won't make sense at all to continue.

Building the correct script

I guessed what you actually meant to do, and this are my proposed scripts.

First, I guess the spending user supplies [sig], [pubKey] and [Wallet] where [Wallet] is either Wallet1_Value or Wallet2_Value to be able to spend the funds:

scriptSig: [sig] [pubKey] [Wallet]

Final stack after running:
    [Wallet] <- TOP OF THE STACK
    [pubKey]
    [sig]

That's scriptSig, and it's what a user supplies when he wants to spend the funds. We're done! Let's build the next step, i.e. the scriptPubKey that checks if the supplied values are fine.

The first thing you want to do is to check whether [Wallet] is one of Wallet1_Value or Wallet2_Value. First let's duplicate [Wallet] so we can check it twice. The first step in scriptPubKey is OP_DUP. Let's run both scriptSig first and the the new scriptPubKey:

scriptSig: [sig] [pubKey] [Wallet]
scriptPubKey: OP_DUP

Final stack:
    [Wallet] <- TOP OF THE STACK
    [Wallet]
    [pubKey]
    [sig]

Of course we want to check it against Wallet1_Value first:

scriptSig: [sig] [pubKey] [Wallet]
scriptPubKey: OP_DUP [Wallet1_value]

Final stack:
    Wallet1_Value <- TOP OF THE STACK
    [Wallet]
    [Wallet]
    [pubKey]
    [sig]

And now check the top two items for equality:

scriptSig: [sig] [pubKey] [Wallet]
scriptPubKey: OP_DUP [Wallet1_value] OP_EQUAL

Final stack:
    (== Wallet1, either TRUE or FALSE) <- TOP OF THE STACK
    [Wallet]
    [pubKey]
    [sig]

Now we want to check the duplicate [Wallet] against Wallet2_value but the previous result is at the top of the stack. We must swap it first using OP_SWAP:

scriptSig: [sig] [pubKey] [Wallet]
scriptPubKey: OP_DUP [Wallet1_value] OP_EQUAL OP_SWAP

Final stack:
    [Wallet] <- TOP OF THE STACK
    (== Wallet1)
    [pubKey]
    [sig]

Again, we push the value we want to check, and OP_EQUAL it:

scriptSig: [sig] [pubKey] [Wallet]
scriptPubKey: OP_DUP [Wallet1_value] OP_EQUAL OP_SWAP [Wallet2_value] OP_EQUAL

Final stack:
    (== Wallet2) <- TOP OF THE STACK
    (== Wallet1)
    [pubKey]
    [sig]

The script is pretty much done. Now just OP_BOOLOR OP_VERIFY:

scriptSig: [sig] [pubKey] [Wallet]
scriptPubKey: OP_DUP [Wallet1_value] OP_EQUAL OP_SWAP [Wallet2_value] OP_EQUAL OP_BOOLOR OP_VERIFY

If OP_VERIFY finds FALSE at the top of the stack it will reject the transaction. If it finds TRUE the script continues and the stack looks like this:

Final stack if correct [Wallet] was provided:
    [pubKey]
    [sig]

Which is what the stack looks like after a regular scriptSig! So the rest of the scriptPubKey is just a regular pay-to-pubkey-hash script. The final scriptPubKey is:

OP_DUP [Wallet1_value] OP_EQUAL OP_SWAP [Wallet2_value] OP_EQUAL OP_BOOLOR OP_VERIFY
OP_DUP OP_HASH160 [pubKeyHash] OP_EQUALVERIFY OP_CHECKSIG

Actual security

Now, regardless of the order, the script is not very secure. I get this might just be an exercise in understanding scripts or is not meant to be secure (it might be only a check to avoid spending from unwanted wallets) but I think it's important to show how this is actually not secure at all.

Whenever you publish a transaction using this scheme, the output scriptPubKey is publicly available and looks like this:

OP_DUP [Wallet1_value] OP_EQUAL OP_SWAP [Wallet2_value] OP_EQUAL OP_BOOLOR OP_VERIFY
OP_DUP OP_HASH160 [pubKeyHash] OP_EQUALVERIFY OP_CHECKSIG

Both Wallet1_value and Wallet2_value are public for anyone to see in the blockchain! The security still depends ONLY on [sig] [pubKey] since I know exactly what's required to spend the transaction, i.e. the script security is equivalent to a regular pay-to-pubkey-hash transaction!

EDIT: A little bit safer (response to comment)

  Could you require Wallet1_value and Wallet2_value be hashes instead? Then the scriptsig would have to supply a hash of one of the two wallets.

Yes. Actually it's very easy (changes shown in bold face):

OP_HASH256 OP_DUP [Wallet1_hash] OP_EQUAL OP_SWAP [Wallet2_hash] OP_EQUAL OP_BOOLOR OP_VERIFY OP_DUP OP_HASH160 [pubKeyHash] OP_EQUALVERIFY OP_CHECKSIG

As you can see the top of the stack is hashed (OP_HASH160 or OP_HASH256, whichever you prefer) before duplication, so now you can compare the provided data to match with one of two hashes instead of values.

This is a bit better since the data is not there in plain sight. You would have to brute-force to find one of WalletN_hash. The problem is as soon as you spend it, the WalletN_value becomes public in the spending transaction, so WalletN_hash can't be used in a transaction again! It would be one-use only. If you published several transactions with the same WalletN_hash, you'd have to spend all outputs at the same time or else the unspent ones might be hijacked.

Bear in mind the scheme is still secure because there are signatures involved. If the scriptPubKey lacked the standard signatue verification it would just be:

OP_HASH256 OP_DUP Wallet1_hash OP_EQUAL OP_SWAP Wallet2_hash OP_EQUAL OP_BOOLOR OP_VERIFY

Any miner could listen for this type of transactions and, as soon as anyone tried to spend one with scriptSig = [WalletN_value], the transaction could be modified (even the outputs!) instead of relaying it since the transaction is not signed at all, so the miner could redeem the outputs himself.


In the bitcoin scripting language, how can I access other outputs of the transaction? Or how else can I limit how the coins may be spent?

There is no way to enforce a rule regarding the nature of an output when an input is spent. You will have to enforce this off chain in some manner, perhaps through multisig schemes where one key is held by a rule engine that will only sign the tx if your requirements are met.


You should've used another blockexplorer instead of blockchain.info. The transaction didn't get confirmed due to low fees. I suggest trying to send it to ViaBTC transaction accelerator and see how things goes from there.


The Bitcoin client requires a transaction fee to be paid for low-priority transactions. Transactions of the kind you describe are low-priority, thus the cost of such an attack will be prohibitive.


You can use this libs for your purposes:

https://github.com/bitpay/bitcore-lib

https://github.com/bitpay/bitcore-explorers

And you dont need a node =)


bitcoin node: what is the difference between simnet and regtest?

Simnet is only available for btcd (bitcoin node) and lnd (lightning node) afaik, while regtest is also available for bitcoind (bitcoin node), lnd and eclair (lightning nodes). The two modes are similar, according to documenation of LND:

  Simnet is similar to regtest in that you'll be able to instantly mine blocks as needed to test lnd locally

Both also are similar in the fact that the payment addresses are unique, to prevent confusion with the main network.

Where they differ, I think, is that simnet goes a bit further and also applies some network changes to disable things like peer discovery.

But I couldn't find conclusive evidence for this. Since I do a lot of tests with multiple Lightning clients, I tend to use regtest, since that's more broadly supported.


Is money that has gone into bitcoin already spent?

As @RedGrittyBrick says, change the word "bitcoin" to "euros" and see if that helps you. All currencies work this way, not just cryptos:

Is money that has gone into euros already spent? When I buy a euro from someone and they get USD I get euro. They go buy lambos or real estate for their gains. So the underlying currency is spent, but euro market cap is increased. This would mean that euros don't actually have any real money in them and they could collapse without bottom basically. Is this logic correct or is real really currency as value behind euros?

And someone in Europe probably has the exact same question about USD.
All currencies are fundamentally worthless. Except for things like gold, which you can use to plate the contacts of electrical switches, coins, which can used as paperweights, and paper notes/bills, which can be used as toilet paper.


Mnemonic Phrase (BIP39) with Existing Seed Generating Library

You probably know that HMAC-SHA256/HMAC-SHA512 and thus PBKDF2 are one-way functions. There would be no way how to reconstruct the seed from the generated sentence in your setup, which is the only purpose of such sentence.


Why hasn't my bitcoin transaction gone through?

You've sent Bitcoins like so:

WALLET1 ==> mixer ==> WALLET2

The problem here is that you can't be certain the middle part will work, be it for technical reasons, or more likely, they've been lost or "lost". By nature, mixers are run for clientele operating in the "very dark grey area". So it's extremely unlikely you've got any recourse, other than contacting their tech support. I'm sure you know all this.

Fundamentally, mixers in charge of your funds cannot be trusted. Theoretically, the only way I can see around this would be for a service to pre-mix the required amount, and then for you to withdraw it after you know it's safe, which would likely need to use BIP65 and/or BIP16, or perhaps a combination therein with message signing, to prove address ownership. I don't know there's any mixers like this, because quite frankly, I believe their profits come moreso from scamming or selectively scamming.

Because mixers are out, your options are either CoinJoin or DarkWallet, but I have not got experience with either of them.

This probably isn't the answer you're looking for, but unfortunately this is where it stands. Good luck.


Who controls the features added to the bitcoin network?

To change Bitcoin, you must change the behavior of Bitcoin Core (or some other full Bitcoin client) and then convince people to use your modified version. Different levels of network adoption are required for different types of changes:

If the change only disallows certain transactions or blocks that were previously allowed, then the change can be applied by the majority of mining power. Only miners need to use the updated version of Bitcoin. This is called a soft fork. For example, P2SH was a soft fork change. Miners updated over the course of several months. This went very smoothly and most people didn't even notice it happening.

Adding sidechains would be a soft fork change, as would most other feature enhancements. (It might not be obvious how disallowing certain transactions could be used to add new features, but it's usually possible if you're careful about it.)

If the change allows things that were previously disallowed, then each user individually decides whether to use the change or not. This is called a hard fork. Even if every other Bitcoin user and miner decided to increase the total BTC supply from 21 million to 50 million, you could continue using the old version of Bitcoin and you would be unaffected by this change. However, you would be unable to transact with people who use the modified version. As a result, this sort of change is likely to be widely accepted only if an "economic supermajority" accepts it. This means that the decisions of larger economic actors (exchanges, merchants, etc.) are more important than the decisions of regular Bitcoin users because more people will care about whether or not they can trade with them. In a hardfork, miners are not especially important.

There have been a few hardforks in the past, but most of them were in response to critical bugs that needed to be fixed immediately (such as the BDB lock limit bug). There's never been a hardfork that was controversial.

(Note that if a softfork is enforced by miners but not most users, then undoing it is not a hardfork change.)

Lightweight nodes like MultiBit or Electrum can't enforce the rules of Bitcoin properly, so they're at the mercy of some full nodes elsewhere. Exactly how this works depends on the client. This is why you really should use a full node if you can: it protects you and strengthens the economic power of the good network. Bitcoin Core is by far the most commonly-used full node client, so the Bitcoin Core developers will have a lot of influence over any proposal to do a hard/soft fork change. However, they still can't unilaterally change the network. Their changes need to be accepted by miners and/or users for the network to actually change. The network can also be changed by others if they can get people to use their modified Bitcoin client.

To clarify some common misconceptions:

Bitcoin is not a democracy of either miners or users. For the most important things, your Bitcoin client does what's right no matter what.
The Bitcoin Core developers do not have absolute power over Bitcoin.
The Bitcoin Core developers are separate from the Bitcoin Foundation, and the Bitcoin Foundation does not own bitcoin.org.


P2SH (pay to script hash) within a script?

No, P2SH can only be invoked using the exact magic pattern described in BIP16 in the scriptPubKey and not using any variant of it, nor recursively inside the P2SH redeemScript itself.

Earlier proposals (see OP_EVAL) existed that did allow much more flexibility, but it was hard to give strong guarantees about execution time and memory in such a model.


That's correct.
UTXOs are just entries with the following fields:

txid of the transaction that created it
output position in that transaction that created this output
the output itself (consisting of scriptPubKey and amount)
the height of the block that created this output (needed for relative locktime checking, see BIP112)


Transaction taking a long time to confirm, now it doesn't even show up on Bitcoin Explorer

I can see the transaction here: https://blockchair.com/bitcoin/transaction/c4bea179e5e772b131c475f9030088b67dea5054a545713dc32458829fa61598
This is how you can visualize your transaction in a pool of other unconfirmed transactions with different fee rates:

Miners prioritize transactions with higher fee rates from this pool to add in the blocks and thats how transactions are confirmed. Your transaction will stay lower in the pool and less likely to get confirmed until others keep using higher fee rate.
Also there is a limit of 300 MB used by most of the full nodes which might result in lot of low fee rate transactions being dropped from their mempool. Not sure if this will affect your transaction with fee rate: 30 sat/vByte.

RBF was not enabled for this transaction. Ensure that you are using a wallet that supports RBF and enable it for most of the transactions. It allows you to add more fees later.

CPFP cannot be done in this case as it has only one output which I am assuming owned by the website.

Be patient and wait for couple of days. Email the website support about this issue.


understanding how exchanges "store" bitcoins

You access the bitcoins in your account at an  exchange through their web interface only. They keep the private keys to those those bitcoin addresses hosted at their exchange. So, even though its your account, they control the private keys.
If you want to move those funds outside the exchange, pay them to yourself on a wallet hosted on a device you control. An exchange is unlikely to give you access to the private keys, because then the private key would be out of their control and they could not guarantee that the funds were safe nor be held responsible if they were spent.


Why is the Bitcoin Core wallet database moving from Berkeley DB to SQLite?

The introduction of descriptor wallets presents an opportunity to introduce a new database backend as descriptor wallets are backwards incompatible. The following is taken from Andrew Chow's blog post on what's coming to the Bitcoin Core wallet in 0.21. (There was also discussion on this GitHub Issue.)
Why move from Berkeley DB?

Not designed to be used as an application data file. The Legacy Wallet has several hacks to get round this as a result and Berkeley DB wallet files can easily be corrupted.
Berkeley DB produces extra files which need to be moved with the database file. This means that Berkeley DB is less portable and requires a directory for each wallet.
Changes were introduced to Berkeley DB database environment files breaking backwards compatibility.

Why choose SQLite?

Can be used as an application data file.

New SQLite versions maintains backwards compatibility with versions as far back as 2013.

Does not require database environment. A completed write guarantees that the data was written to the database file.

Can now move to single wallet files instead of wallet directories.

Here is the proposed timeline for legacy wallet and Berkeley DB removal from Bitcoin Core.


Is there a real threat of so called ">50% attack"?

Well, the answer is two-fold: what's the chance of a 51%-attack to happen and what are the consequences if it does.

What's the chance of it happening?

You mention correctly that the major parties via which such an attack can be achieved, are miners. The chance that a 51%-attack is performed by a 3th party is neglectable, since the cost to achieve a mining output to achieve such as enormous. Only maybe if a large government would decide to assign a large budget to it, it may happen, but still ASIC hardware is scarce and difficult to manufacture.

So basically the real threat is in the miners. However, the chance that a miner would obtain >50% hashrate share is minimal. The miners themselves would not benefit from their pool having such power, on the contrary. So what would happen is miners leaving for another pool, pulling the pool's share back under 50%.

The only real threat that remains is the possibility that multiple pools are compromised simultaneously. In such a case, however, I believe the pool owners will notify users as soon as possible, resulting in miners leaving. Also, from the moment the party in power of the compromised miners starts manipulating the block chain, the community will notice. I believe it won't take long before people will be warning each other and miners will stop operating at the compromised pools.

So let's conclude that in the worst case, an attacker will can perform an attack and hold it for a few hours max until it will lose its position.

What are the consequences in such a case?

A party that is in control of the network can't really manipulate the blockchain very drastically. Here are the main actions one would be able to perform:

Decide what transactions are included in the chain. Essentially it can halt all payments, but than they would be noticed very quickly. Probably the attacker will only manipulate transactions of his own concern.
Receive all block rewards. But that is no more than an extrapolation of a miner's situation with a <50% hashrate.
As a result of nr 1, an attacker can easily perform double-spend attacks. This will be the main threat. Since the attacker decides what transactions make it to the blockchain, he can very easily make a transaction, perhaps even give it one confirmation, and then revert it with another. When he receives fiat or goods for his first transaction, he can make profit by reverting the transaction.

It is clear that the consequences are quite minimal. It is difficult to maintain such a situation, it will require extensive planning in order to make real profit from the attack since the only way to actually make profit is through exchanging things for bitcoins and double-spending the transaction you made.

EDIT: There might actually be a scenario in which an attacker may be able to make good profit from the attack, like David Schwartz mentions in the comments. Even with the fore-mentioned assumption that the network will react after the first time the attacker messes with the block chain, a well-prepared attack can do damage with one backfork*. The attack would look as follows:

The attacker deposits bitcoins in an account on an exchange. (Probably he will have multiple accounts on multiple exchanges to make as much profit as possible at once.)
As soon as the exchange recognises the transaction as being confirmed, the user withdraws the bitcoins again. Most exchanges use different wallets for sending and receiving, so the withdrawn coins will most probably come from a different address. (Making the withdrawal independent from the deposit.)
As soon as the attacker receives the transactions that represent his withdrawals through the bitcoin network, he will hardfork* the chain to undo his deposit transaction and doublespending it in his new chain, as well as including the withdrawal transactions in the new chain.
This way the attacker will have both the deposit amount as the withdrawal amount in his wallet.

Although this scenario is possible, it would require extensive planning. Also, most exchanges require more than one confirmations and the more confirmations are required, the harder the attack becomes. To successfully hardfork* multiple blocks in a feasible time, the attacker will need more than just 51% of the network hashrate.

* I'm not sure if this is an established term, but I think of a backfork as a fork of the chain a few blocks before the latest to revert the history of those blocks.

(Wrote this from my mobile phone, typos may occur.)


Why is a chain code needed for entropy in HD wallets?

For reference, the original spec is located here.

A few minor adjustment to your basic equations of how HD wallet child key derivation works. (And also note that these equations only apply for non-hardened indices)

MyHash = HMAC-SHA512(Parent_PublicKey + Parent_ChainCode + Index)
Special_Integer = Leftmost256Bits(MyHash)
Child_ChainCode = Rightmost256Bits(MyHash)
Child_PublicKey = Parent_PublicKey + Special_Integer * G
Child_PrivateKey = Parent_PrivateKey + Special_Integer

I added the * G, and changed Child_PrivateKey to Parent_PrivateKey in the last equation. The * G is because you need to use Elliptic Curve multiplication before you can add to the Parent_PublicKey, which is an Elliptic Curve point.

Now let's look at how these equations would look if the chain code wasn't used.

MyHash = HMAC-SHA512(Parent_PublicKey + Index)
Special_Integer = Leftmost256Bits(MyHash)
Child_PublicKey = Parent_PublicKey + Special_Integer * G
Child_PrivateKey = Parent_PrivateKey + Special_Integer

Now, if you know the Parent_PublicKey (which is public knowledge and may be found on the blockchain for instance), you can try many values for Index and derive all of the child keys

Now assume someone got ahold (somehow) of one of your private keys for somewhere in the tree. Without the presence of a chain code, they can derive all of the private keys down the tree from the node where they have the private key. What's worse, if they can get access to the public keys higher up in the tree, they can derive the private keys as well with a little backwards-engineering of the equations (basically, Parent_PrivateKey = Child_PrivateKey - Special_Integer). This is undesirable, as it would be better if losing a single private key doesn't compromise much/any of the rest of the HD key tree.

All of this is not possible with the chain code present. So there are very good privacy and security reasons for using the chain code.

  Is the chain code as "public" as the public key, or is it desirable to keep it private to the extent possible?

It's definitely desirable to keep it private, because leaking it exposes you to the issues mentioned above.


Where can I find resources for programmers to understand Bitcoin?

The book Mastering Bitcoin would be a good solid start (although it might not answer all your questions). It is also available for free.


Use Bitcoin RPC to send from many addresses to single address

Yes that possible:

you need to know the txid and Vout index for those particular addresses when they were funded

for example here i have used 3 addressees to send some BTC  to single addresses 2N6V6Ko17CPWaZZf6YrGKeq8R1fzbqrTKLF and if  know the txid and vout of those addresses when they were funded i will do:

1)create raw tranaction

syntax: createrawtransaction   [{"txid":txid,"vout":n},...] {address:amount,...}

 bitcoin-cli -regtest createrawtransaction '[{"txid":"582283c5f2293a2cdb27173c3118ff59863d9ff2be5c3b48fa8e66509e9a7d0d","vout":1},{"txid":"3126fc2864fbf780460734dd1512b98e86f72f8e5b8b59047beae9dd859ac33a","vout":0},{"txid":"94a6701b68e38b3f980c9bf2b0e905dd7e479c7ed01590eeee20b1753c29d6af","vout":1}]' '{"2N6V6Ko17CPWaZZf6YrGKeq8R1fzbqrTKLF":"2"}'

2) Sign raw transaction:

syntax: signrawtransaction  <hexstring> [] [<privatekey1>,...]

bitcoin-cli -regtest  Signrawtransaction hexstring_from_createRawtransaction '[]'["pvtkey_add1","pvtkey_add2","pvtkey_add3"]

3) send raw transaction

syntax: sendrawtransaction hexString

bitcoin-cli -regtest hexString_from_signrawTransction


No, it's much less expressive than a PDA, or even a DFA.  There's a stack, but what you don't have is the ability to return to the same program state with different stack contents, or for that matter, to return to the same program state at all.

Execution is linear and there are no loops, so any given instruction in the script is executed at most once.  And each instruction can only inspect a bounded number of stack or input elements.  So a Bitcoin script cannot even recognize the language x* (any number of xs) because a script of length n will only ever be able to look at, say, 4n elements of input, and it cannot distinguish xxxx....xx from xxxx....xy if both strings have length greater than, say, 4n+1.  Even a DFA can recognize that language.


Cannot call rpc api from other machine in same local network

The problem is that you apply wrong options values for -rpcallowip and -rpcbind.

-rpcbind=127.0.0.1

This one tells bitcoind to bind RCP server to 127.0.0.1(localhost). That means it will be available from the same host only.

-rpcallowip=0.0.0.0/24

0.0.0.0/24 means Class C network with IP address range 0.0.0.1 - 0.0.0.254

The correct options in your case are:

-rpcallowip=192.168.1.0/24 -rpcbind=0.0.0.0

or even more secure:

-rpcallowip=192.168.1.155 -rpcbind=192.168.1.132


What are mastercoins used for in Mastercoin?

From our FAQ

  The initial value for mastercoins came out of the fundraiser
  "anchoring". People were willing to "sacrifice" 1 BTC in exchange for
  about 100 MSC, so it anchored the initial value of MSC in at least
  0.01 BTC per MSC.

  The more general answer is that Mastercoin provides a set of features
  that only work with MSC or Mastercoin-based currencies, and there is a
  limited number of them. So, in order to enjoy these features, you have
  to own some mastercoins, giving them an independent value. The more
  real world usage Mastercoin sees, the higher the value of each
  mastercoin. In addition, as always, a lot of its value is currently
  driven by speculators executing a price discovery process.

  Specifically, mastercoin tokens are used for:

  Creating derived currencies and smart property are used to create
  and/or promote smart property tokens as an anti-spam measure.
  Mastercoins are used as the liquidity layer for Contracts for
  Difference The distributed exchange between Mastercoins and user
  generated currencies is more efficient than BTC<->MSC or BTC<->Derived
  exchanges - the latter require a 2 step commit process. As the
  protocol evolves, more direct usages for Mastercoins may be created.

I added this last bit about token usages to the FAQ following your questions - thanks ThePiachu for this questions!


Does Bitcoin-Qt require that I create a bitcoin.conf file in order to solo mine on my Mac?

As the name suggests, bitcoin.conf is a configuration file to set various options of the bitcoin client.  Details of the file and available options can be found here.

The most commonly used option is to set the RPC username and password (see your other question).  If you only want to solo mine using setgenerate true (which, as I mentioned in my other answer is not recommended), the defaults should be fine and you don't need to put anything in bitcoin.conf.


Which bitcoin wallets let you export to a universal .wallet format?

Thin Clients (SPV)

MultiBit.org

Tools -> Export Private Keys -> Open the file you exported

grabHive.com (Mac only)

Export not yet implemented

Browser Add-ons

SpareCoins.io (Chrome)

Wrench icon -> Backup Wallet (encrypted)

Full Clients

Bitcoin-Qt

Help -> Debug window -> Console

walletpassphrase {passphrase} {timeout}
dumpwallet {filename} (Recommended method, dumps all wallet keys in a human-readble format, into a file named filename)
dumpprivkey {bitcoinaddress} (Optional method, exports a private key)

Clients with Deterministic Wallets

BitcoinArmory.com

Wallet Properties -> Backup Individual Keys -> Private Key (Plain Base58)

Electrum.org

Export -> Private Keys -> Open the file you exported

Hybrid Web Wallets

StrongCoin.com

Your Accounts -> Select one -> Decode Private Key (with passphrase)

BlockChain.info

Import/Export -> Export Unencrypted -> Look for 5*, L* or K* Private Keys

Android Wallets

Mycelium.com

Keys -> (Options bar |) -> Export
(OUT OF DATE) Key Management -> (Options) -> Export to SD card(jpg to "mycelium-export" folder), QR code or to the clipboard

BitcoinSpinner

(Options) -> Settings -> Advanced -> Export private key -> QR code or clipboard

Bitcoin Wallet (by Andreas Schildbach)

(Options) -> Back up Keys (encrypted)

openssl enc -d -aes-256-cbc -a -in

  .... there will be more in time, hope to keep this answer updated


Was a timejacking attack ever performed?

For those of you who are wondering what TimeJacking is, please consider the following:

In order for computers and machines, separated by vast distances, to work in tandem, they usually have to be synchronized. If the time and date aren't isn't synchronized, this can lead to issues relating to security, usability, and overall response time. According to NTP.org:

http://www.ntp.org/ntpfaq/NTP-s-def.htm

"If you have communicating programs running on different computers, time still should even advance if you switch from one computer to another. Obviously if one system is ahead of the others, the others are behind that particular one. From the perspective of an external observer, switching between these systems would cause time to jump forward and back, a non-desirable effect. As a consequence, isolated networks may run their own wrong time, but as soon as you connect to the Internet, effects will be visible .... Even on a single computer some applications have trouble when the time jumps backwards. For example, database systems using transactions and crash recovery like to know the time of the last good state."

This also applies to online security certificates (in browser). If the time and date is wrong, strange things may happen (invalid certificate error).

While this appears to apply only to the Network Time Protocol, I assure you otherwise - networked systems need to stay synced in order to function. BlockChain and other cryptocurrency handlers have this exact issue because they are handling electronic transactions over vast distances, across time-zones.

Oh wait - in case you don't know what a bitcoin node is:

http://www.coindesk.com/bitcoin-nodes-need/

Now that we know how the system crack can occur, let's delve into the process (good source, BTW - ThePiachu):

(Presented by culubas: Timejacking and BitCoin - Blogspot)

"Each node internally maintains a counter that represents the network time. This is based on the median time of a node's peers which is sent in the version message when peers connect. The network time counter reverts to the system time however if the median time differs by more than 70 minutes from the system time. A very reasonable way to estimate the median network time.

An attacker could potentially slow down or speed up a node's network time counter by connecting as multiple peers and reporting inaccurate time-stamps. (A relatively small number of Tor clients could send enough messages to take over the node's median time.)"

As usual, time is used for security and validation on these monetary hardware servers and nodes. If the time is off, bad things can happen. For more info on how an actual cracking attempt could occur, read the section labeled "Creating a 'Poison Pill' Block" of culubas blogpost cited above.

In short, an attempted hack would create a perceived time gap between the mining machines and node targeted, by lagging part of the system until one of three things occur: either an unaffected node or the target itself creates a block, clocks are reset, or operators intervene. As such, valid blocks could be dropped, and money could be lost or stolen. Please read the original article for more info.

Now, as for the question at hand, I wasn't able to find any confirmed instances of TimeJacking so far. That could be due to a variety of reasons, but I personally think that no one has chosen to target the cryptocurrency yet. In that case, I can't wait to see what a new API update would look like - especially with some new security patches for P2p time-keeping and network certificates. Sadly, it could be just a matter of time.


How often does temporary fork occur and how long does it last?

Blockchain forks occur when two blocks are found at the same height. Only one of the two chaintips can become part of the best chain. Each full node will consider the first block it saw to be the best block for that height, until proven otherwise by another chaintip accumulating a greater total difficulty (i.e. adding another block). When another chaintip pulls ahead, the node will reorganize to the best chain. The node reverts its current chaintip back to the last shared block and then applies the blocks from the best chain. A blockchain fork is generally resolved whenever a block for the next height is found. The "best chain tip" is always a probabilistic determination, but the confidence quickly rises as more blocks get added (hence the recommendation in the white paper to wait for six confirmations). Nothing prevents a miner to continue mining on a stale chaintip. However, a miner cannot spend the block reward if the block does not become part of the best chain, so in most cases, it is unreasonable to mine on a stale chaintip. A miner with a large portion of the hashrate may try to extend a stale chaintip if they authored the stale block in a selfish-mining attack.
Earlier in Bitcoin's history there were some two dozen cases in which blockchain forks consisted of multiple blocks before a best chain emerged. You can read more about that in What is the longest blockchain fork that has been orphaned to date?. As far as I'm aware, we have not had a multi-block chainfork for multiple years.
If you have access to a Bitcoin Core instance that has been running for a long time, you can get all stale blocks it registered by calling the getchaintips rpc. Obviously, your node might not have seen all stale blocks that have occurred. Any node syncing later, will only download the best chain, and not acquire these stale chain tips.
Stale blocks were a fairly common occurrence in 2013-2015. IIRC, there would usually be one or more per day.
Headers-first sync introduced with Bitcoin Core 0.10.0 significantly reduced that. In 2016 the Fast Internet Bitcoin Relay Engine (fibre) replaced a previous effort (the "Bitcoin Relay Network") to provide a supplementary relay network connecting especially mining entities that directly pushed new blocks to other participants.
The rate of stale blocks further dropped around the time that segwit got activated. Some people surmised back then that some miners had been running old versions of Bitcoin Core, and when segwit activation forced them to update to a segwit-compatible client, they leapfrogged a number of block relay improvements that had been added over the years. Another rumor was that some mining outlets (spending millions on mining hardware!) used micro-computers as their mining controllers which would take a while to validate new blocks, delaying their switch to the latest chaintip.
These days, it's common that the network goes weeks without any stale blocks. BitMEX Research runs a forkmonitor which offers an RSS feed to alert users when stale blocks (and other block related events) occur. Unfortunately, it seems to me that the RSS feeds item list was reset and I was unable to find a list of their history of fork alerts. In lieu of that, let me note that BitMEX Research tweeted on 2020-01-26 that they had seen a stale block at height 614,732 and that this was the first stale block they had registered since 2019-10-16. Searching BitMEX Research's tweets for "stale", since 2020-01-26, they also tweeted about stale blocks on 2020-07-10, 2020-06-09, 2020-03-03, 2020-02-27, and 2020-02-22. Assuming BitMEX research tweeted about each, they have recorded seven stale blocks since 2019-10-16.
Note that the "orphan block chart" provided by blockchain.com appears to be broken.


As mentioned in the above comment, these are Blockstack IDs.

https://blockstack.org/blog/browser-public-alpha


How can one know which way mining pools will vote for P2SH?

You should check out this page:

http://blockchain.info/p2sh

If you want to verify if a given pool operator has indeed mined the blocks for the votes, he or she can sign some message with the private keys corresponding to the public addresses that were the recipients of the block reward.


How do light clients connect to the network?

Are they connecting to full nodes directly (using port 8333) or to another kind of server on another port?

Electrum no, Multibit yes.

  In the case of Electrum, it seems to connect to an Electrum server, which runs a full node. What are the advantages of doing so instead of connecting directly to the bitcoin network on port 8333 (assuming that it would be possible)?

It is a different trade-off. Electrum relies on other servers to index the addresses used in the chain, and queries them. Multibit (and other so-called "SPV clients") ask full nodes to scan the chain for them, but as normal full nodes don't have (or need) a full index of all used addresses, this isn't as efficient.

There is also a privacy trade-off. Electrum's privacy relies on the Electrum servers not being compromised (you can run your own, but few users do). Multibit's privacy relies on the BIP37 bloom filter mechanism for letting full nodes scan the chain for them. This method has been shown to be significantly flawed however, and the (randomly selected) nodes it queries transactions from could easily learn a lot about the wallet.


does Bitcoin Core automatically use reindex when you specify txindex=1 with existing sync'd chain?

Changing the txindex setting no longer requires a reindex since version 0.17.0 (see https://bitcoincore.org/en/releases/0.17.0/, under "Transaction index changes). It'll update just the txindex itself whenever it's out of sync automatically.
So:

It doesn't inject a reindex (which would cause throwing away the entire chainstate database, and rebuilding it). It just detects the txindex is out of date, and scans the unindexed part of the chain in the background.

The command is "bitcoin-qt", almost certainly, with nothing more.


Is there a way to force fail the transaction in testnet network

You can set fees to very low (for example 1500 for a small 1 input 1 output transaction), not zero though. That will (most likely) get your transaction to be not mined in a few days and dropped.


How to reference different wallets with curl JSONRPC requests Bitcoin core

This is the command I use - the http address is the address of the docker container that the Bitcoin daemon is running in
curl --user johnsmith --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getbalance", "params": ["*", 6] }' -H 'content-type: text/plain;' http://10.0.0.1:18332/


What is the purpose of the announcement_signatures message as specified by the Lightning Network RFC?

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

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

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

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

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


Two errors when trying to run make command

This issue caused by newer versions of Boost was later solved. You may either checkout v0.15.2 or download the 0.15.2 tagged source code here


How are bitcoins generated during mining?

On a high level, the entire bitcoin network is built on the fact that all of the nodes are following the same rules. The rules state that whoever hashes the next block gets to mint a number of coins, so they can.
From the Bitcoin white paper:

By convention, the first transaction in a block is a special
transaction that starts a new coin owned by the creator of the block.
This adds an incentive for nodes to support the network, and provides
a way to initially distribute coins into circulation, since there is
no central authority to issue them.

From the wiki:

Bitcoins are created each time a user discovers a new block. The rate
of block creation is approximately constant over time: 6 per hour. The
number of Bitcoins generated per block is set to decrease
geometrically, with a 50% reduction every four years. The result is
that the number of Bitcoins in existence will never exceed 21 million.


Does Ripple give an advantage to early adopters?

Advantages to being an early Ripple adopter:

Being able to get a lot of free ripples during their first distribution
Being able to establish oneself as a reliable and reputable Gateway that will be a go-to place for everyone
Establishing oneself as the first business to do something with Ripple - be it selling something or offering some services. Other early adopters would be then inclined to spend their ripples on your service just for the sake of using the system

Generally, there is not that vast of an advantage for being an early Ripple adopter as compared to using Bitcoin. That doesn't mean, however, that the advantages are not there.


Assuming everything else in the block is valid, the block hash simply needs to be smaller than the target. https://en.bitcoin.it/wiki/Difficulty explains how to find the target from the bits representation; and to find it from the human-readable difficulty D, you calculate 2^208*(2^16-1)/D.


How to exchange a cryptocurrency from an address that's not in a wallet

Visit https://www.reddit.com/r/Ripple/
and scroll down to the "Wallets" section on the right side bar.

Download a lightweight wallet of you choice, start the wallet sweep/import the private key, then send to your Binance wallet.


Can I send BTC from other node or wallet with my address?

You can use createrawtransaction to create a raw transaction, in which you can specify your custom inputs and outputs.
In this case you would specify the input to be the address from node2, and output/outputs to be addresses you are sending bitcoins to. Use signrawtransaction to sign raw transaction it using your imported private key and sendrawtransaction to send it to the network.


Why have prices fallen so drastically around October 2011?

One thing a lot of people fail to notice is the decreasing volume at the exchanges. If we look at the USD volume - and not at the bitcoin volume, which is misleading because bitcoins are now worth much less - we can see a spike in June and a decrease afterwards:

The news reports in June attracted lots of people who were curious about bitcoin. A part of these people left and the market size is now coming back to April/May levels. As a consequence, there is much less money being traded. However, we still have 5 new coins being produced every minute and lots of miners who want their invested money back.
The current price is a natural consequence of high supply and low demand.