Bitcoin uses the so called UTXO (Unspent Transaction Output) model.
The first time it is not very intuitive because it is different from the traditional accounting model where you just spend from and send to an account.
Think about full piggy banks that can't be filled more than they are and that you have to break open before being able to spend the content:

1) Bob has 1 piggy bank, he wants to pay Alice with half of the piggy bank's content
2) he breaks his piggy bank
3) he takes half of it and gives it to Alice, who will put it all in a new piggy bank belonging to her
4) you put the remaining half in a new smaller piggy bank belonging to you and which is waiting to be broken open.

Each piggy bank/UTXO is linked to an address.
A Bitcoin user can of course have several UTXOs related to his address. The sum of the UTXOs gives the amount of bitcoins owned by the address (which is one of the function of wallets).
Each transaction input is the output of a previous transaction.
Although wallet software gives the feeling that you "transfer" bitcoins or satoshis, you don't spend from an account you spend UTXO.
You spend from transactions previously made to you.


Remote SSH connection to Raspibolt Lightning Network Node

About your specific setup we would need more information to trouble-shoot but here are some general network debugging steps I take -

Start at the lowest level

RPIs come with SSH enabled by default last I checked so this is just a sanity check step.

First make sure that the Raspberry Pi is allowing SSH connections (you mentioned you already did this so just for brevity) from your local network -

From another machine on the same local network as the RPI -

$ curl -v {{put your rpi local IP address here}}:22

which shows if the port is open because if it is you should see something along the lines of * Recv failure: Connection reset by peer.  If the port is not open the failure from above should be something along the lines of failed: Connection refused.

In the first case your server responded on 22 but did not accept the connection (since it is a curl and not an attempt to SSH in)

If that is successful you can of course follow up with an SSH attempt to verify you have access -

$ ssh {{user}}@{{local ip}}

Move outside the network

Since you were able to SSH in locally (if you were not then getting to this step is irrelevant) the next step is to disconnect from your Wifi or local network and then test your router / firewall settings.

You can do this for example by tethering on to your phones internet connection and issuing the same commands as above, replacing the IP address on the local network above with the your external IP address.  You can get your external IP address by Googling "What is my IP".

Finally, repeat the steps above to first test that the port is responding and second test that the connection is being allowed.

As you mentioned before the main culprit is not forwarding ports on the router.  Additionally you will need to set up your lnd.conf to listen on the externalip as well as instructing the RPC service or REST service to listen on that external IP as well unless you are using something more advanced like a reverse proxy.


What happens when bitcoin drops and i add more money to my wallet

This really is just a math problem more than a bitcoin question, but it’s simple enough so here is your answer:

  If i have $1000 worth of bitcoin with the current price of bitcoin at $7000

($1000)/($7000/BTC) = 0.14285714 BTC

This is the amount of bitcoin you would own. Changes in the dollar value of a bitcoin will not affect how much Bitcoin you own, it will only affect the dollar value of what you own.

  then later on bitcoin drops to $6500, (...)  what will happen if i add more money in my wallet then later bitcoin goes back to $7000, will i have more than $1000?

Yes.

To illustrate: let’s say you buy just $1 worth of bitcoin when the price is $6500/BTC:

($1)/($6500/BTC) = 0.00015384 BTC

Now add that to your original BTC balance:

0.14285714 BTC + 0.00015384 BTC = 0.14301098 BTC

Now, at a price of $7000/BTC:

(0.14301099 BTC)*($7000/BTC) = $1001.08


There is a game that uses Bitcoin as its currency called Dragon's Tale, not to mention numerous online casinos. In general, using Bitcoins in games is quite feasible, just requires a willing developer.

In many cases it can even be preferable, as one could imagine making a simple micropayment in an instant provided they need to purchase something in a game, rather than transfer the money in bulk and later not using all of it without the chance of getting the rest back.

Moreover, similar to upcoming Diablo 3 Auction House Marketplace, or already existing market in Second Life, one can imagine the players earning Bitcoins in such games from other people and later withdrawing their earnings with an ease.


electrum wallet help needed funds missing

You must have downloaded electrum from a fake site which served you a backdoored version of the program. If you still have access to your browser history I suggest going through it to find out the exact URL you used to download electrum. The official site is at electrum.org and downloads are served via download.electrum.org.


Depends on your wallet.

A Bitcoin private key is a 256bit (32bytes) random number (there is a max limit, but lets don't go into the details).
Often, wallets export them as a WIF encoded base58check string which looks like L1esWYsDL8nBeTRmGjUiDru54nXS4wF811n3e7mbvoSjM2zZWJ6w.

Sometimes, wallet use HD (look up BIP32 if you are interested).
Then the root private key starts with "xprv" and look like xprv9s21ZrQH143K4bhMhuUKZnW9DW5Dx9mwGQseMNdoECsaCGdhL9N8jR6KG5c3UTYrKPTkRNEBfeX7LjE2VjScyLZYA3XqRpyYbhnZHnsUepS

Search after "export private key" or "dump wallet", etc.


Generated new cryptocoin but how to get balance in my account?

Coins that are immature mean that you have not mined enough blocks for them to be spendable yet. If you did not change the COINBASE_MATURITY global variable, then you will need to mine 100 blocks before the immature coins become mature and spendable. Of course the process of mining produces new coins, so your immature balance will increase until you have mined 100 blocks.


Is it possible to run two Lightning Network nodes on top of single Bitcoin Core node?

Technically it should be possible. You can find a pretty straight forward description in the lnd docs at: https://dev.lightning.community/tutorial/01-lncli/index.html

I am running several c-lightning nodes on top of the one Bitcoin node that I'm running. In clightning you just have to specify a different data directory and port for each node. Also on this machine I have an lnd node running.

I could give you examples how to do this with c Lightning but you asked for lnd / eclair. As said I don't see any reason why it would not work with the other implementations but I have not checked it yet. This referring you to their documentation.


What algorithm do bitcoin miners use to choose which tx to include in their block?

No. this is not knapsack problem and no one need to find optimal solution.

Sort your transactions in mempool by two rules:

subsequent transactions can not be to the left of parent ones
most profitable transactions (fee/size) gravitate to left

and take leftmost transactions from mempool until 1 mb limit


What is better, pre-existing Bitcoin-core API bindings for python or custom wrapper functions

bitcoin-cli is just a wrapper for the RPC functions so you're essentially doing the same exact thing as an RPC call. Generally, using RPC is preferred since you don't have to rely on the bitcoin-cli executable being on the system and in your current path. This most likely won't work on windows, for example.

In general RPC is preferred because you can access it from other systems. With your program, you'll only be able to run it on the system that has bitcoin core installed whereas with RPC, you can run from other systems.


How does having a large mempool and allowing a greater transaction ancestry set change the interaction with your peers?

How does this change your node's interaction with its peers? Do peers send data that exceeds your node's preferences and your node drops that data upon arrival or does your node inform its peers what to send?

The protocol supports a fee filtering command, simply, only relay transactions which meet a specific feerate and nothing below. This prevents pointless relaying of transactions which would result in immediate eviction from the memool.

  If you allow more data via higher values, does your node forward previously unacceptable data to its peers once their backlog clears enough for the data to be accepted by them?

No. Wallets in Bitcoin are expected to re-send transactions periodically if they have not been confirmed. If they will successfully relay at a later date with less mempool pressure, re-broadcasting it would be required.


How is Transaction malleability affected by SIGHASH flags?

SIGHASH flags allow for the flexible alteration of a transaction.

Yes, but the SIGHASH types mainly allow for incremental progress towards creating a full/final transaction, such as combining multiple transactions signed with SIGHASH_SINGLE. Once the transaction is fully created, there are certain tweaks that can be done to it that don't invalidate the tx but change the TxID, and these tweaks can be done regardless of how it was signed.

  What malleability risks do SIGHASH transactions incur by virtue of their usage?

I think the SIGHASH signing types allow for the alteration of transactions before they are final. Once a transaction is final, the malleability issues persist regardless of how it was signed. In fact, ECDSA signing itself (regardless of which SIGHASH type is used) is non-deterministic, so you could sign the same transaction twice and distribute them, and they would both be valid (but conflicting), but have different TxIDs.

  Given that there are legitimate usages of SIGHASH, and changing a Tx (and presumably the TxID as well), what is the correct way of using Sighash w.r.t. a TxID and tracking its progress?

To track a transactions progress, you will probably need some other way to identify the transaction other than the raw TxID (double hash of tx data). i.e. Some number associated with a transaction that is passed around to all who are editing it, or keeping track of the outputs of the transaction.


As you say, the result of sha256 is a hexadecimal string.  Hexadecimal only uses the digits 0-9 and a-f, which is 16 possibilities, not 36.

If you redo your calculation with 16^18 instead of 36^18, you get an average time of around 3600 seconds, or 1 hour.


Why are ticker messages in the MtGox PubNub API repeated?

PubNub MtGox API Ticker Repeat Messages

The Ticker Events are Updates that are streamed directly to you which may or may not represent a price change.  However the ticker updates are typically tied to a trade event which occur on the trade channel.

You can find the trade stream here:
http://www.pubnub.com/console/?sub=sub-c-50d56e1e-2fd9-11e3-a041-02ee2ddab7fe&pub=demo&channel=dbf1dee9-4f2e-4a08-8cb7-748919a71b21&origin=pubsub.pubnub.com&ssl=true

So in regards to the updates you may receive unchanging value updates.  You may also consider looking at historical values by using the History API: http://www.pubnub.com/how-it-works/storage-and-playback/

Also check out the related Stackoverflow article: https://stackoverflow.com/questions/20547815/convenient-way-to-extract-data-from-the-mtgox-pubnub-json-api/20553315#20553315

or

https://stackoverflow.com/questions/20495713/are-there-ready-made-java-classes-for-the-mtgox-pubnub-json-api/20500700#20500700


If block sizes go up, won't sigop limits have to change too?

Yes, the maximum number of signature operations per block also need to change. It may change dynamically with the block size limit. The code currently assumes a ratio of MAX_BLOCK_SIZE to MAX_BLOCK_SIGOPS:

From https://github.com/bitcoin/bitcoin/blob/v0.10.0rc3/src/main.h#L59-L60:

/** The maximum allowed number of signature check operations in a block (network rule) */
static const unsigned int MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;

If this ratio were kept constant, then when the max block size was increased, the max signature operations would increase to:

16.7 MB / 50 = 335,544 sig ops


You could also try the Blocktrail API: https://www.blocktrail.com/api.
They are new on the scene but their API can be quite useful. They have a node.js API as well as PHP, Python, CURL and jQuery. It doesn't track prices though but hope it can be of help some other way.


getting address from public of ScriptPubKey vs ScriptSig

You can't find the address from the scriptSig or input in general, because you don't know what the output was. Your question makes the assumption that every output contains a (common, but not only) P2PKH script.

If you would know the output being spent was a pay-to-pubkey-hash scriptPubKey, which is spent by revealing the full public key and a signature with it, you can indeed compute the address as the P2PKH address of that public key. But you don't know that without access to the output.

If you would know the output being spent was a P2SH scriptPubKey, which is spent by revealing the full script and its inputs, you can compute the address as the P2SH address of that script. But you don't know that without access to the output.

If you would know the output being spent was a segwit P2WPKH or P2WSH scriptPubKey, which are spent with an input that contains the public key resp. script as the last witness stack element, you can compute the address as the Bech32 address corresponding to that key or script. But you don't know that without access to the output.

If the scriptPubKey of the output being spent is not one of these specific templates (P2PKH, P2SH, segwit), the answer is simply that no address for that output exists. Addresses are a convenient human-readable form for specific types of transaction outputs that are common im payments. But they are by no means the only things supported by the Bitcoin protocol.


Is it possible to create bitcoind regtest network on Ubuntu (which itself is on Virtualbox)?

It appears that Fred Tingey's answer was mostly correct, but contained incorrect port numbers in the samples he provided. If someone were to copy and paste it all it would not have worked correctly.

I've modified his answer, it is awaiting peer review.

The use of Ubuntu, Docker and VirtualBox shouldn't affect your ability to configure regtest.

You may have problems connecting from the host to the guest, if you do I suggest perhaps asking questions on superuser or ubuntu exchanges instead.

Hope that helps!

=== Here's the edited version:

In order to run multiple nodes in regtest mode on a single machine you will need to sandbox each node.

In this example I have three nodes, they are named Alice, Bob and Cory. Since Bitcoin is a Peer/Mesh network, my goal is to connect each nodes so that changes made to Cory are ultimately visible to Bob (without necessarily requiring a direct connection between the two.)

Step 1: Create folders for each node.

These folders will contain our data and configs for each node. The names are not important, they can be renamed later, so you can name them "Alice", "Bob" and "Cory" for now. Remember where you create them, you will need their paths for Step 3 below.

Step 2: In each folder, create a bitcoin.conf file

In the config files Alice will be configured to connect to Cory, and Bob will be configured to connect to Alice. In addition to configuring outbound connections, this is also where we specify regtest=1 and server=1 settings.

bitcoin.conf for Alice

regtest=1
server=1
 # Alice connects to Cory
connect=localhost:18333

bitcoin.con for Bob

regtest=1
server=1
 # Bob connects to Alice
connect=localhost:18444

bitcoin.conf for Cory

regtest=1
server=1
 # Cory connects to nobody

Step 3: Start each node.

Note each node must have a different port number since only one node can bind to a port number at any time.

Alice on port 18444
Bob on port 18555
Cory on port 18333

You can choose your own port numbers of course, just be careful not to use a port number that is already in use by something else.

The command-line options will tell bitcoin what port number to use, where to store data, and where to find its config file:

Cory:

"C:\Program Files\Bitcoin\bitcoin-qt.exe" -conf="C:\Cory\bitcoin.conf" -datadir="C:\Cory" -port=18333 -rpcport=8333

Bob:

"C:\Program Files\Bitcoin\bitcoin-qt.exe" -conf="C:\Bob\bitcoin.conf" -datadir="C:\Bob" -port=18555 -rpcport=8555

Alice:

"C:\Program Files\Bitcoin\bitcoin-qt.exe" -conf="C:\Alice\bitcoin.conf" -datadir="C:\Alice" -port=18444 -rpcport=8444

This will launch three instances of the Bitcoin Client, and the folders for each node will begin to initialize with regtest data.

Step 4: Testing

You can use the Help->Debug Window->Console option to interactively execute commands on any of the nodes. For example, you can mine 101 blocks with the following bitcoin console command:

setgenerate true 101

You should (after a few seconds) then have been awarded coins.

These mining activities result in coinbase transactions - and only the last one of 50 BTC is available to spend. Now you can send some BTC to one of the other nodes.  After a bit more mining such a transaction will be confirmed.

You can also use the console commands getpeerinfo and getinfo to check the network is set up correctly.  One of them (Core wit port=18333) should have 'sync=true' in its peerinfo output, and all nodes should have the same "block height" regardless of which node is used for mining.


How much does the market cap increase when a certain amount of $'s go in the market?

Given that the Bitcoin market is pretty unstable + unregulated I don't think it is possible to predict the outcome of this.

Have a look at the paper Price Manipulation in the Bitcoin Ecosystem by Neil Gandal et al. to get an idea of why this is very hard (if not impossible) to predict.


What would happen to bitcoin in a world with no electricity/internet?

Without computers or electricity, Bitcoin would have no value and could not be used as it is entirely a digital asset. There are no such an object as a coin and thus Bitcoin cannot be put into a physical asset. The blockchain itself is what determines something is Bitcoin, and without it (because there are no computers or electricity), anything physical intended to represent or store Bitcoin (e.g. a paper wallet) has no value besides the value of the material itself.


Make payments Lightning without Invoice?

With the current specification it is not possible to make a spontaneous payment to somebody on the network. However, this will likely change very soon, as it is one of the features on the roadmap and will be discussed in the specification group in November.

There are tricks on how to do a payment by delivering a large fee at the destination and continue routing to someone else (described in this video), but you have to write software to manipulate the route and the destination will not see an incoming payment, since it considers it a fee.


How do I interpret Mt Gox market depth streaming data?

Mt Gox JSON Depth Data

Market depth is a snapshot of the currently open bid(buy offers) and ask(sell offers).
A definition from Investopedia: Depth of Market

Each time a new order enters Mt Gox's order book the real-time depth API broadcasts this to the end user. If you listen long enough to the Mt Gox's depth API you would be able to gain an almost accurate copy of Mt Gox's order book.

Interpreting the Data

volume: this is the amount of item (BTC) that the depth at that price in currency (USD) has changed by. This has been deprecated in favour of volume_int. Basically it is the same thing except the volume_int must be divided by 1E8.

price: the price point in currency to which this depth record relates.

total_volume_int: since volume / volume_int are change records total_volume records how much is available at that price point. A zero value means that no more orders are at this price point. For most purposes total_volume_int is the number you want to use.

How depth data relates to the charts

I'm assuming that the question refers to the live charts. That chart is built by forming points between price and the accumulated depth working outwards from the market price. Then those points get connected. For example:

For bid orders of 10 @ $90, 10 @ $80 and 10 @ $70 the graph would show depth accumulation of: 30 @ $70, 20 @ $80 and 10 @ $90.

Using the data

Depth information is useful to determine just how much "liquidity" there is in the market. This indicates how much a "large" transaction will move the market price.

A steep accumulated depth line indicates potential "support" on the bid side and "resistance" on the ask side. A steep chasm formed by both sides of the accumulated bid/ask depth indicates price stability while a spread out flat bowl indicates price sensitivity.

(bid, ask, liquidity, support, resistance are stock trading terms -> look them up on investopedia, it's a good resource)


Is mining using with cpu(some web sites) fake or not

There are two things mining requires in general:

Processing power (CPU/GPU)
RAM

For Bitcoin, a tiny RAM is OK, but for Ethereum, a few GBs of RAM is needed.

  So how some web sites do mining using client's cpu?

Using Javascript (unfortunately. There are more efficient ways, such as TurboJS or GPUJS or WebAssembly). Basically, they're trying xs with different nonce fields until Hash(x) is smaller than a target value.

Bitcoin mining is possible wherever there's general-purpose processing power. Is it feasible? No. Because of ASIC miners, CPU or even GPU mining have higher electricity costs compared to mining revenue.

On the other hand, it might be different for other coins, such as Monero. You might have heard of CoinHive, which had Proof-Of-Work captchas that required mining Monero for a few seconds. Because Monero is ASIC-resistant, CPU mining used to be efficient. (Until February 2019, when CoinHive miner was discontinued due to the falling value of Monero).

It's likely that they might be scam, otherwise it's unprofitable for you (assuming you pay for electricity).


How is Bitcoin itself represented (either technically or code level)

these questions would justify a whole section of a book. To avoid this, I put a link at the end of the message. In between, I'll try to answer some parts of your question.

  I've gone through dozens of videos and texts, but haven't found
  properly how is the actual bitcoin itself represented technically or
  at code level?

That is a known problem with all these videos. It is not sufficient :-)
The bitcoin is represented as data in the blockchain. Effectivly, a transaction moves bitcoins around, taking transaction from an address, sending it to a new address. When you take a look at some bitcoin explorers, they provide details, e.g. here as an example. To answer your question, you'd need to understand the details presented in this transaction. In short: you'll discover 2 inputs and 4 outputs. This is, what moves the Bitcoins (or Satoshis). Many transactions can then be combined into a block, which then create the blockchain.

  From what I have understood thus-so-far (if correct), is that a single
  bitcoin itself is NOT represented by any class/object at code level
  (or technically NOT represented by a unique ID like fiat money has
  printed on it),

yes, I mean, no serial number on it. But programming wise (there are dozens of implementations), you could think of a class "bitcoin". The default core code has no such thing, code reference is here.

  but rather bitcoin is ONLY a figure that's stored in a distributed
  ledger (blockchain).

yes

  And that the creation of a 'new' bitcoin is out of thin air

well, thin air is often a repeated idea, which sounds like discrediting distinction to the FIAT world. But effectivly you have to do some work ("mining"), which costs a lot. So thin air is probably wrong.

  as a reward for verifying transactions together with proof-of-work
  (i.e. solving a math problem in order to delay the broadcast of
  verificationof transactions) for security purposes (and thus NOT as
  some put it to discover new bitcoins - as no bitcoin has a permanent
  unique ID to be discovered).

somehow - please read chapter 10 of the refenced book :-)

  to please explain how bitcoin itself is represented either technically

Yup: here is Andreas wonderful book "Mastering Bitcoin", which has lots of examples relevant for developers.
My proposal to you: start to evaluate transactions in detail (Chapter 6), and work over into wallets and keys. This gives you the picture within 2-3 hours. And then you probably get the idea. Otherwise you extend your question here, or raise a new question :-)


Does each peer prioritize inv(type=block) over inv(type=tx)?

I don't see any delay here.  Looking at Bitcoin Core 0.9.3's code, I also don't see any code which would cause a delay as long as the node sending the inv responded to a getdata message immediately.

Transactions and blocks are placed into to separate queues in this code:

if (!fAlreadyHave) {
    if (!fImporting && !fReindex) {
        if (inv.type == MSG_BLOCK)
            AddBlockToQueue(pfrom->GetId(), inv.hash);
        else
            pfrom->AskFor(inv);

Transactions and blocks are requested in this long piece of code, which I won't paste here.

I don't see any delays here for transaction requests.  I also tested this locally, and my node always immediately replied to a new inv message (type=tx) with a getdata message requesting that transaction.

There can be a delay in relaying transactions.  For example: node A sends an inv message for a new transaction to node B.  Node B gets the transaction, but then waits before sending an inv message to node C announcing that transaction.  You can see that in this code which includes the comment, "trickle out tx inv to protect privacy".


Bitcoin Wallet

Electrum

BitcoinSpinner

All of the above mentioned store the wallet file locally on your phone


Speed of operations in the Bitcoin network

The alternative currency Geist Geld is experimental and is trying to approach a maximum block rate (that's currently achievable), and has apparently settled upon a target block rate of 1 block per 15 seconds. However, the block rate doesn't necessarily make a substantial difference to how you would use a currency as you could still consider a small transaction accepted even before it's been included in a transaction block, whereas with a faster block rate you may need to wait just as long.

There has been lots of discussion on how a faster block rate would affect things (eg here, here, here, and here) but I think that ribuck summarises it well in that last link: "If you make the blocks too frequent, you get more cases where two blocks are generated at nearly the same time. Due to network propagation delays, this can cause temporary splits in the block chain. On the other hand, if you make blocks too infrequent, it takes too long for a transaction to become essentially irrevocable."

That same link mentions a calculated latency of 2.11 seconds.

With a block rate that's too fast, you may end up with miners consolidating within a part of the network with low latency, creating an unfair distribution of mining returns.


Is it possible (not feasible) to mine bitcoins with Bitcoin Core v0.21.1?

The setgenerate built-in background miner was removed.
There is however still a test-only on-demand miner, which will try to mine N blocks whenever requested by RPC (see generatetoaddress /generatetodescriptor/generateblock RPCs in recent Bitcoin Core versions). It is many times less efficient than even the built-in CPU miner was. Its only purpose is in functional tests (which use the "regtest" network that is permanently at very low difficulty).
The code you see in miner.cpp is additionally used as a backend for the getblocktemplate RPC, which is how pools and external miners communicate with bitcoind. It doesn't actually do any mining (as in hashing) itself, but provides block templates for others to do so, based on transactions in the mempool and the chain's tip block hash.
The -generate option to bitcoin-cli is just a wrapper around the internal generatetoaddress RPC, which is slightly more convenient (it requests an address from the wallet, and then miner to it). It is in theory usable on mainnet, but it obviously won't ever actually find anything (except with extremely small probability).


Why does my c-lightning node pay more than the invoice plus routing fees?

In your c-lightning node you have configured your maximum fee rate which is used by the pay command to do the payment.

The BOLT04 describes how overpaying up to twice the amount to obfuscate payments in order to have better privacy is part of the protocol:

  if the amount paid is more than twice the amount expected:
  SHOULD fail the HTLC.

  SHOULD return an incorrect_or_unknown_payment_details error.

  Note: this allows the origin node to reduce information leakage by altering the amount while not allowing for accidental gross overpayment.

In combination with this merged pull request c-lightning fixed this issue
implementing random overpayments up to the maximum fee rate.

So generally c-lightning will randomly overpay your transaction with an amount that is lower to the maximum feerate you are willing to pay.

Not that in earlier days lnd did not accept overpayments as they seemed to not have implemented this part of the protocol.


How to properly use PreviousTxnID in a Ripple Transaction?

The PreviousTxnID field is deprecated, broken, and should never be used. Instead, use AccountTxnID. It works as follows:

You must use fully-canonical signatures and you should set the fully canonical flag (0x80000000) on all your transactions. Otherwise, the transaction ID could (in theory) be maliciously modified.
You must enable transaction ID tracking on your account. You do this by performing an AccountSet transaction with SetFlag set to 5. This causes your account to begin tracking each account that it executes.
Include a PreviousTxnID field in your transactions that contains the ID of the previous transaction. This will ensure that a transaction only applies if it has the expected predecessor transaction.

Now, replacing a transaction with a nop will invalidate any successor transactions that have a PreviousTxnID field.

If you wish to disable PreviousTxnID tracking for your account, perform an AccountSet transaction with ClearFlag set to 5.


I think you are viewing the metric incorrectly. The notion of Bitcoin Days Destroyed is not relative to any other standard of measure. Rather, it is the standard of measure.

To clarify, there is no "gold standard" for Bitcoin Days Destroyed saying "if all Bitcoins had been spent within X weeks the total would be Y". That just doesn't make any sense. Think about it like this: how would one calculate what the DOW would be at today, had it not fallen 200 points? One wouldn't! It cannot be done; the points are there only to show the relationship of the market from day-to-day, month-to-month, or n-to-n. They have no standard to which they are measured.


What if the execution time for an alt coin script exceeds the block time?

You shouldn't need to worry about this ever happening.

There are no loop opcodes in scripts. Every script opcode can only be executed once, and the slowest opcode is probably ECDSA signature verification (because it involves EC_point_multiply). Even so, it only takes about 50~100μs on a single core of a modern CPU to process.

Let's assume a 1MB block (max size) contains 100% signature verification opcodes, that's 1 million signature verification and takes at most 100 seconds CPU time of a single core, this is still much lower than the block time. In practice each scriptSig is accompanied by at least 100 bytes of data (pubkey + ECDSA signature) so it probably takes less than 1 second of CPU time.


As others have stated, doing

Bitcoin-Qt -rescan

fixed the missing transaction.


How much data is transferred using Andreas Schildbach's Bitcoin Wallet Android app?

Since January 14 on my Galaxy Nexus, Bitcoin Wallet for Android has used 120 bytes of mobile data. It's used approximately 160 MB of data on WiFi in the same period. One month cycle earlier, it used 463 KB of mobile data, and approximately 113 MB on WiFi. I plug it in every night and whenever I'm in my car.

I can't answer for the amount of data necessary for the initial synchronization, other than advise you to do it on WiFi for both speed and data limit reasons.


the maximum possible entries a network can accept in RAFT consensus?

In RAFT
First thing is leader must be elected.
To update a data in log, leader must get majority of voting.

In this case after first 2 rounds leader changes.
in 3rd and 4th round new leader updates data.
But in final round leader doesn't get opportunity to update the "e7" as the leader doesn't get majority.


Took care of this with a combination of changing pchMessageStart values, baking my VPS seed node address into chainparamsseeds.h and adding rules to block outbound traffic to ports 9333 (and the other strange unsolicited connections to other altcoin nodes).


Coins are sent to addresses in a globally distributed ledger, not to wallets. The Bitcoin network does not “know” what wallet-software you are using to manage your addresses, and it cannot prevent people from sending coins to addresses that you own. So, the short answer to your question is “No limits.”

One thing that might delay a transaction would be if the payee set the transaction fee too low. Miners, being economically rational, tend to validate transaction sooner if the fees are higher. If the fee is too low, then the coins may get returned to the sender without ever being credited to the recipient. But this has nothing to do with the recipient's wallet-software, since fees are set by the sender.


Where is the incentive to update the Merkle root

The merkle root ensures that transactions were part of the block that is being found. It links the block header to the set of transactions in the block.

So if you don't update the merkle root you are not actually confirming the transactions, and you won't be able to collect the fee of the transactions. So the incentive to update the merkle root is the same as for including transactions into a block: you get transaction fees for doing so.


Is it possible to build bitcoin source code into a windows .exe file, using Ubuntu?

Yep you sure can instructions can be found at https://github.com/bitcoin/bitcoin/blob/master/doc/build-windows.md.

And the provided build scripts all use static linking so you end up with one big executable that does not require installing any dependencies on your Windows machine.


What's going on with address 1NZ9kxxUykiNSe61ZRNPLqWeVHVRnirGry?

What is happening here is that blockchain.info parser seems not to work well when decoding Pay-to-multisig scripts (P2MS).

All the outputs but last two contain Pay-to-multisig scripts as ScriptPubKey (1-3 Multisig for all but the very last one, that is 1-2 Multisig). The last two are normal Pay-to-PubkeyHash (P2PKH).

If you check the information in blockr.io for example, you will see it correctly displayed.

You can also check the decoded raw transaction to find it out. Here you have an example of one of the outputs:

"asm":"1 8322e509a68669409750b06abef89e48423d21c0089efcc211261c16e8f0a413a693bdee97ca3bd3424eb6247bc235a8d49d77cde681093a4824e462a9ea9610ed b72f5174d4946b456da718db0eb1e852a67544c67e6041f1eb6156bae1b1d788614d89542274f46f0100389a6b40f5158dab5da9870b3447b65e8d003665d0e969 db99614d616506661872851a2786ec296ca73dbab8dbf100c21ef2e80be79eb5d916ab3b3b29ec6e5dcda45a405c155655fe380d979877e53b2f1417a744ebf142 3 OP_CHECKMULTISIG"

Notice how the structure of the script is: OP_1 <Public_Key0><Public_Key1>...<Public_KeyN-1> OP_3 OP_CHECK_MULTISIG


If the parent can't be verified, shouldn't it be discarded immediately?

Then you risk needing to redownload that transaction.

  What are the best practices here? Just wait up until N seconds and then discard?

I think what bitcoin does, adding it to a size-limited cache, works well in practice. You just have to make sure that when you receive the parent you broadcast invs for both the parent and the child (assuming the child is still in the size-limited cache).


You may use a blockexplorer e.g. https://blockchain.info/xpub/${xpub} (replace ${xpub} with that string beginning with "xpub") to look up the balance on the web or use a wallet like e.g. mycelium.

You can look up this key as well as the private one with e.g. https://iancoleman.github.io/bip39/ – use a copy offline for your actual backup phrase

Have a look in BIP32 and 43 to learn about xpub and xprv for HD wallets (and later on BIP 39, 44 and 49).


Is there global database of all wallet addresses and transactions?

Yes, it is called the blockchain.  You can browse it through various websites, called block explorers: e.g. http://blockchain.info, http://blockr.io, http://blockexplorer.com.  If you use full node software such as Bitcoin Core, you will download a complete copy of this database (currently over 120 GB).

  How my public key is paired with my wallet when somebody tries to send me coins?

The paper wallet contains a private key and an address.  From the private key one can compute the corresponding public key, and the address is a hash of the public key.  You can give your address to anyone, and they can send coins to that address; this means that a transaction is recorded in the blockchain showing a credit of coins to your address.  Other than your address, this doesn't need any further information or involvement from you.

You only need the private key when you want to spend those coins.  Importing that private key into wallet software, you can make a new transaction to spend the coins that were sent to you.  The private key is needed in order to sign the transaction and prove that it is authorized by you, the rightful owner of the coins; but this process does not reveal the private key to anyone else.  (As part of this process, the public key will be recomputed from the private key and included in the signature.  That is easier than including the public key on the paper wallet.)


Why is Slush Pool recognizing my worker as offline?

When you mine with less than 1 GH/s (1000 MH/s) most bitcoin mining pools will show your hashrate as zero. This is likely to happen at many pools even with 10 GH/s. This is because the current default/minimum worker difficulty in pools makes you find proofs of work very rarely with a GPU. This again gives the pool very little data to estimate your realtime hashrate. If the pool has a hashrate display that covers more time (like average hashrate over the last hour) then you will probably see something.

Why are pools using such high worker difficulty? To function better with ASIC miners. Today 1000 GH/s is a slow miner and less than 1 GH/s is basically zero. There is a popular miner these days that runs at 13500 GH/s.

There are some pools that offer special mining servers for low hashrate miners. In that case the pool may be able to display a realtime hashrate. But the question is whether they show fractional GH/s or round off to the nearest GH/s.

You can mine without a realtime hashrate display on the pool's website. Mining still "works". Technically. The real problem is that you mine so slowly that you never earn more than some "bit dust".


I can't be "Bittrex specific", but i can provide a general answer to how it would work and have seen it work across a half dozen systems that are crypto specific and dozens of financial systems that are non crypto specific:

When you set up a sell order (or just click sell) it's usually not a "1 and done" situation. You are selling 'x' amount for at least 'y' value. As the system matches up the purchases of your 'x' amount to buy orders, a fee is applied when the match is made and the "trade" occurs. The fee can be taken out of BOTH sides of the trade. You have a .25%.. the buyer may have a .25%. That means if the trade completes, whatever you are "due" they will remove it before handing it over. THEY get BCH. The person buying it get's a fee too.. they paid in BTC. Once the trade completes, they pay their fee in BTC.

Sorry this isn't specifically a Bittrex answer, it's a "how these things normally work". I can't imagine how else it could be accomplished as it would mess up all normal accounting practices.

In sum, to maintain accounting: The trade is completed. Fee's are assessed against the results.


How is the Bitcoin Mined in Genesis Block Brought into Transaction?

is the 50 set by the Bitcoin protocol?

Yes, the block reward started at 50 BTC per block, and halves roughly every 4 years (every 210,000 blocks to be precise).

  And will the "50 BTC" message participates in the mining of the genesis block? (No from my current understanding).

Yes it is, the 50 BTC is in the output of the coinbase transaction from that first block:
https://blockchain.info/tx/4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b

The first transaction in any block is the coinbase transaction and pays the block reward to the miner. And because the hash of the transaction is part of the block header which gets mined, it does directly contribute to the hash of the header.

  If the "50BTC" not part of the message for genesis block generation, we're free to change it to, e.g 500BTC after mining the genesis block, and I think that will not violate the original Bitcoin protocol.

1) it is part of the "message" for the genesis block, so changing it would change the genesis block which would make it rejected by every other node on the network.
2) The block reward of 50 BTC is enforced by all nodes so changing it would also make the block invalid too.

  With this question pending, I am not sure how the first Bitcoin is created (looks out-of-band with the generation of genesis block).

The 50 btc from that genesis block are the first 50 BTC ever produced (although they cannot be spent, see this question for why: Why can’t the genesis block coinbase be spent?)


what does this error mean "Script did not clean its stack" while signing segwit transactions

Simple answer, Bitcoin cash doesn't support segwit.


What is the difference between inbound and outbound connections?

If your node initiated the connection, it's outbound, otherwise it's inbound. Nodes will send and receive data from both types of connections exactly the same way.

maxconnections sets a limit on the total number of connections, so if you set it to eight, your node will probably initiate connections to other eight nodes before any node can initiate a connection to it.

Keep in mind that according to this forum post, each open connection will take only a few kilobytes of RAM, so reducing the number of connections might not save all that much of memory.

EDIT: By running a full node that has no slots for incoming connections, you act as a leecher, and you do more bad than good for the Bitcoin network, as Gavin Andresen said on Reddit. You would help the network if you allowed a few inbound connections. As discussed earlier, that's unlikely to take up any significant amount of RAM.


How to migrate Lightning (LND) from local laptop to external myNodeBTC node

This sounds like the age old proverb of "Good, Cheap or Fast - Pick Two"

I like your original suggestion, but you do have options:

Close all channels, wait an hour, then restore the new lnd node w/ your mnemonic seed and password.
Close all channels, wait an hour, send an on-chain transaction from your original lnd node to the new lnd node.
Dont close anything, save your static-channel-backups file, restore with the static channel backup/mnemonic seed and password and wait patiently for multiple days for the funds to be recovered due to force closes (Please don't do it like this)

There are other creative ways to do this (opening new channels on the new lnd node and transferring the funds through invoices or something), but i've stuck to simple examples here.

To move to a new node, we'll have to take your channels offline (not network friendly). We'll have to take them offline, close them, and then reopen them on the new node, so your best bet is to use the option that you are comfortable with.

Closing your channels, then on-chain transaction to the new node may cost more sats due to transaction fees, but it is an easy and fool-proof way to migrate your node.


One cannot "get" the private key from a watch only address. There is ECDSA logic and several hashing functions, that (as per today's knowledge) prevent this.

The priv key is generated in the wallet, via ECDSA you come to the public key, which is hashed and checksum'd and base58encoded into a bitcoin address. These hashing functions are a one way logic...

The answers here are fairly generic, and deserves probably a whole chapter of a book: Andreas' has it already explained in his book "Mastering Bitcoin". It is an amazing book that'll definitely get you to go. It's freely available online here. Look into chapters 4 and 5, that will explain ECDSA and wallets setup, followed by chapters on keys.


Can you create a bitcoin transaction where you specify the miner?

Not directly. You could do it by transmitting the transaction only to the miner in question, and making sure that his software will transmit the transaction to no one else (note that standard clients don't work this way; they're happy to retransmit transactions quickly across the whole network). This would mean that only this miner is trying to include it in a block, so he's the only one that can get the transaction fee.

Note that this means it might take a prohibitively long time for this "transfer" to go through, since you have to wait for that miner (or pool) to find a block. In the case of a pool, the transaction fee goes to the whole pool, not a certain miner in the pool (unless you have some off-blockchain communication).


Is there a way to index transactions so that filterload commands can be answered without iterating through all transactions in a block?

There is a known but fairly undocumented method of drastically improving SPV filtering that happens to remove this as an issue entirely, but it comes at the cost of requiring a hard fork change to Bitcoin.
Traditional BIP37 SPV
For BIP37, a client sets bloom filters on their peers and sequentially downloads transactions and blocks, relying on the remote peer to sift through all the data for that peer and produce pruned blocks which match their filter.
This is undesirable for a number of reasons:

In Bitcoin BIP37 bloom filtered SPV clients have absolutely zero privacy, even when using unreasonably high false positive rates.

Nodes in the network have to process an extremely large amount of data to return the results for just a single peer, and repeat work for every single peer connected on the receipt of a new block.

BIP37 SPV clients can be lied to by omission.

Peers loading an old wallet or rescanning one for transactions they may have missed must completely download all the filtered blocks, again at the cost of other network peers.

Bloom Filter Commitments

Before mining, a bloom filter would be deterministically constructed of all the pubkey-hash (address) and pay-to-script-hash (P2SH) elements in the candidate block.

The hash of this bloom filter would be required to be placed near the top of the block templates Merkle tree, and the contents of it not otherwise written into the block in any form.

When validating the block, this bloom filter would be deterministically reconstructed and verified to match the hash located in the Merkle tree. If the hash of the filter does not match, the block is invalid.

Fully validating nodes can cache the committed bloom filter to disk, or rebuild it at any time from the block data on disk as required (a time/storage tradeoff).

The new process for SPV clients:

Download block headers, the full committed bloom filter for every block in the chain, and the short Merkle path to the bloom filter commitment hash. Verify the header is valid, verify the Merkle path to the hash, verify the bloom filter matches the hash.

Locally compare the bloom filter for potential matches with the users wallet data (addresses, P2SH scripts). The peer independently gets to decide what blocks are interesting to them and which ones are not without having to actually download the contents. Similarly to the normal operation of bloom filters in BIP37 false positives can occur, but never false negatives.

If a block is found that may be interesting they can download the entire block and process it to find their desired transactions.

This neatly solves a number of issues with the traditional approach:

Random remote peers no longer get copies of the users bloom filter. They may be able to extrapolate that information from the blocks the client downloads, but the client can make many attempts to disguise this by downloading single blocks from various sources, making cover traffic of known uninteresting blocks, or even using non Bitcoin network storage once they know which blocks they are most likely interested in.

Remote peers can no longer lie by omission to an SPV client. If they alter the bloom filter committed in the block, it will no longer match the hash in the block, and the SPV client will know they have been deceived.

SPV clients can do quick rescans without needing to download any new data. By retaining the bloom filters once verifying them, they can do as many rescans against it without having to communicate with the network. For full storage nodes, this means significantly faster rescans without having to load whole blocks.

Nodes in the network no longer have any load serving SPV clients, beyond serving additional data when requested. It is their choice to cache the filters when verifying blocks (this comes at almost little cost as they would have to always create the filter anyway). This scales significantly better than BIP37 as the data remains the same for all peers, rather than having to be individually computed.

It's unclear if this would ever gain traction enough to be implemented in a hard fork, or what the optimal false positive rate for the committed bloom filter would be (it's a decision that needs to be made carefully, it can only be done once). There's a nasty tradeoff for usefulness between the size of the filter and it's false positive rate: too coarse means peers download far too many false positive blocks, too fine means the filters will be absolutely gigantic and impractical for anybody to download on an SPV client.
It's not obvious where that sweet spot is, or even if it exists.


Is there any opencart extension where I can use address generated by my personal bitcoin daemon?

I do not believe an opencart extension exists.

If you set RPC User and RPC Pass in bitcoin.conf you can use Bitcoind's JSON-RPC:

https://en.bitcoin.it/wiki/API_reference_%28JSON-RPC%29

I'll add that doing this opens up a whole slew of security vulnerabilities that would need to be addressed. Having your server communicate with your personal Bitcoin daemon over the public network opens up all kinds of issues and I would strongly discourage it.

Alternatively, you could generate a bunch of addresses using your Bitciond and upload the public keys to a DB or txt file on your server, display each address only once and associate it with an order in opencart.


Where can I find out which BIP (bitcoin improvement proposal) are going to be implemented or not?

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

BIPs aren't too organized, but usually there's a thread in the development section of bitcointalk and a few things on mailing list.


The chain would split and when the networks re-connected the longer chain would take precedence.

All transactions on the orphaned chain from the time of the split would be invalidated. Good if you were a spender, bad if you were a receiver.

Note that one company in particular has already deployed a satellite system that broadcasts bitcoin blocks. If there were nodes on both parts of the network receiving the satellite broadcasts when the "split brain" occurred they would be able to keep it from forking, at least that's the theory.


Are you sure you actually installed 0.20.1 before? It seems that the pull request to add the 0.20.1 release to bitcoin.org never got merged: https://github.com/bitcoin-dot-org/Bitcoin.org/pull/3435
If you look on the project's own site, https://bitcoincore.org, you'll see that 0.20.1 is available just fine.
I would be very surprised if anything at all changed regarding block chain synchronization in 0.20.1 vs 0.20.0. I suspect what happened is that your node initially just picked bad peers to synchronize from, but after (re)installing 0.20.0, that went away on its own.


The output is fine. The key fingerprint is the same. Alan merely has several uid records in this key.

See for yourself:

$ gpg --list-key 98832223
pub   4096R/98832223 2012-02-28
uid                  Alan C. Reiner (Offline Signing Key) <alan@bitcoinarmory.com>
uid                  Alan C. Reiner (Armory Signing Key) <etotheipi@gmail.com>
uid                  Alan C. Reiner (Armory Signing Key) <alan.reiner@gmail.com>
sub   4096R/DE6B2D74 2012-02-28

GnuPG simply chose to show you one of the other, completely valid uids for this key.


What is the fastest way to determine whether an address exists on the blockchain?

Using local blockchain.

If you are prepared to keep an up to date copy of the blockchain yourself (or if you already do) then I would expect it to be quicker to check locally yourself than to use a web service (which you seem to have decided for yourself already).

Using list of distinct addresses present on the blockchain.

If you are only looking for a True or False answer to the question "is this address present in the blockchain?" you could achieve faster responses by keeping an up to date list of distinct addresses rather than search the whole blockchain. Once the list is complete keeping it up to date only requires adding those addresses present in the latest block - a small task roughly every 10 minutes.

Using list of abbreviated addresses.

If your purpose permits a margin of error then you could improve speed further by using only the first n characters of the bitcoin address. Maintain an up to date list of distinct abbreviated length n addresses and abbreviate the candidate address to n characters before looking it up.

Even if you require very accurate results, using only half the characters in a bitcoin address will still give almost 100% accuracy, while giving a significant speed up.

Discounting most recent blocks.

If you don't need the most up to date information you could reduce the work required for keeping your abbreviated address list up to date. Only considering blocks more than m blocks deep will reduce the amount of redundant updates due to blocks that are later orphaned.

The improvements in speed described here will be irrelevant for most purposes unless you are processing a huge number of candidate addresses per second, but your question hints that you may be, for at least some of the time.


Multibit - error (or at least confusion) in 'How to check digital signatures" info for noobs

I also am having trouble getting the hashes to match on a Windows system (MultiBit, Bitcoin-Qt .zip and .exe).  I am using Microsoft's "unsupported" tool that the "hash document" references.  I suspect that I will have better results using Linux.

In response to your specific issue, the "$"  at the beginning of the command is the actual prompt.  This implies the command is being entered in a linux\UNIX "shell" (i.e. bash shell).  If it were a windows system you would see something like "C:\User\Sam> echo "Hello world" > example.txt"  The command still works in windows, but as you pointed out the output file is different.  In Linux/UNIX the same command would yield a file with only: Hello world     No punctuation, extra spaces or lines.  Therefore, the hash would be different under linux vs windows following the same command-line input.


There isn't even a database lookup in Bitcoin Core. All blocks and mempool transactions are indexed by hash in memory. It's typically just serializing from memory, or one disk read directly sending disk data to the network.


How to 'attach' metadata to a bitcoin receive address

That's all well and nice, but it turns out that courts aren't interested in "mathematical proofs" (with good reason).  I recommend reading all the books by Bruce Schneider.

Let's say you got someone to pay you at receive_public_key. Does that mean he has agreed to contract M? No.

The courts would still need to see documentation that your partner actually saw and agreed to the contract M. You could have emailed the guy and said "I'll give you $10 if you send Bitcoins to receive_public_key, then later claim that he agreed to contract M.

This same thing happened in the 90's, with vendors claiming cryptographic digital signatures had the property of Non-repudiation. But the courts disagreed. For example, someone can hold a gun to your head and make you 'sign' a contract (digital or otherwise). No court will consider that a valid contract, fancy math or no fancy math.


How do you return a specific amount of bitcoin to an address?

You should ask for a return address. Bitcoin transactions don't contain any "from address", it only references another (previous) transaction's output. An output can be a P2PKH (Pay to public key hash), but it can just as well be P2SH (Pay to script hash) and some other may be implemented in the future.

There's also a large possibility of getting a transaction referencing many previous outputs, as happens when someone paying you 1 BTC received many smaller transaction previously.

It would also be unintuitive to your users, as it's bitcoin best practice not to care about where the bitcoins come from and instead to generate a new address for every transaction received.

On top of that, you shouldn't implement any cryptography by yourself if you're not already a top-level expert, there are simply too many things that can go wrong. I would recommend using a proper API.


I invested in bitcoin mining. Is this legit?

Is this legit?

No, it's a scam. You gave money to a thief, don't give them any more.

Communicating to the thief is a waste of time, they are a confidence trickster who exploited your weaknesses once to trick you into giving them money. Don't let them trick you again. You have nothing to gain by communicating with them.

You will never get anything back, there is no way to undo this and get your money back. You can and should report this to the police but the scammer probably lives in a far-away country and the police will not be able to do anything for a 250 loss (even if that's BTC not USD or INR).

See Mining Scams

  my profits were shown on blockchain

I guess you mean in a wallet managed by Blockchain Luxembourg S.A.R.L (LU) - a European business who run www.blockchain.com, www.blockchain.info etc. They are certainly innocent in this (though you could argue, to the government of Luxembourg, in which I guess you have no representation, that this business has a duty of care to its customers or to victims of its customers).

If the thief created this wallet or you created it and gave the thief the password, it is almost certainly a useless watch-only wallet. The thief can move money into it to make it look like you earned profits but those are illusory and not real. Changing passwords does not make the wallet safe, it does not lock-out the thief - they retain control over any Bitcoins sent to that wallet in past present or future.  It would be prudent to not touch that wallet ever again.


Depending on which pool your mining, this is usually representative of how many valid shares are being passed back to the pool.

It has been displayed in a decimal fraction it seems, so 0.985 would be an amount of 98.5% valid shares returned.


Your address is in the native-segwit format (also known as bech32).

It's an entirely new address encoding scheme for segwit addresses, and many exchanges, explorers, and wallets don't currently support it.

If you are unable to send coins to it due to the sender not supporting these addresses, you will need to set up a new Electrum wallet, and during the setup process, use P2SH-P2PKH addresses, which will start with M.

If the sender still does not accept the address, you can convert it to one starting with 3 using https://litecoin-project.github.io/p2sh-convert/.

https://insight.litecore.io will accept addresses starting with M for balance checks, and show outputs to the ltc1 addresses, but it will not have an address page for the latter.


Bitcoin Address can't be found of client?

Under the tab 'Receive Coins', click 'New Address'


I have recently created a TestNet Faucet. It is available on

http://tpfaucet.appspot.com/

I hope this remedies the situation

To answer your question - while there is nothing stopping people from charging for TestNet coins, I think they should be freely available to anyone for testing. It lets newcomers get a feel for what Bitcoin is without risking their money. I hope that a few Bitcoin developers (or even the Bitcoin Foundation) will provide TestNet Bitcoins for free as long as the Bitcoin project is used.


You could create an index of all addresses and their balances by going over the whole block chain, f.e. using the RPC API.

I quickly wrote this script in Python. Note that I did not verify it! I only made it to give you an idea on how you can iterate over all transactions. Also, there is probably a more time-efficient way to do it by reading the block chain files yourself.

# setup bitcoind as RPC connection to your bitcoind client using JSON-RPC
block_hash = bitcoind.getblockhash(0)
while True:
    block = bitcoind.getblock(block_hash)
    for txid in block["tx"]:
        # you will need to run bitcoind with -txindex to be able to do this
        tx = bitcoind.gettransaction(txid)
        for det in tx["details"]:
            address = det["address"]
            amount = det["amount"]
            # do something with address and amount
            #  f.e. put them in a dictionary (this will take a lot of RAM)
            #  it is more advised to setup a db on disk
    if block.has_key("nextblockhash"):
        block_hash = block["nextblockhash"]
    else:
        break


What is the purpose of the 20 XRP cost to start a wallet?

Unlike a bitcoin receiving address, a funded Ripple wallet is a real thing on the ledger that has properties. This has advantages and disadvantages, but one of the disadvantages is that there's a cost associated with having one. To cover the costs imposed on the network, the XRP Ledger has a "base reserve" that is XRP that is not spendable or transferrable. You can use the reserve to pay transaction fees and, if the reserve drops, you can transfer out XRP to the new reserve level.

Some of the advantages of this scheme include:

The ability to change the key protecting an account without changing the receiving address.

The ability to configure an account for multisign and change the keys, signers, or quorum, again all without changing the receiving address.

Addresses can configure what assets they're willing to accept as payment and payments to them can automatically route through intermediary assets to find the cheapest path.

Accounts can place offers to trade one asset for another on a distributed exchange that follows deterministic rules.

The reserve goes up (currently by 5 XRP) for every additional object an account owns in the ledger (such as a trust line, offer, or escrow). You can reduce your reserve by eliminating these objects, but current rules do not allow the base reserve to ever be transferred or spent -- it covers the cost associated with recording the fact that the account has already performed certain transactions and without this recording, those transactions could potentially be replayed.


What is the value of these bitcoin certifications that have popped up recently?

It varies.

The first certification you posted, CBP, seems to be broadly well-perceived. As for the second one, I cannot find anyone saying anything about it, besides that it exists.

  but I'm not sure how valuable these things are.

I'm not sure either. Similar to security guard training companies, these certification organizations are going to exist along a spectrum of legitimacy.

Personally, (and this is where we go from facts to opinions) I think the CBP test would be worth taking if you already have the knowledge to do so, but beyond that, you're probably better off with a certification in a related field, like RHCE.


Who pays the fees for transactions initiated by a smart contract in Ethereum?

A smart contract can only initiate a transaction when it receives a transaction from either another contract or a user. Thus, all transactions must originate from some user transaction, and it is this transaction that must pay for fees. The amount of fees can be limited by setting the gas limit on that transaction to prevent a malicious contract from consuming a horrendous amount of fees.

Also, all transactions that are the result of a specific user transaction will occur before any other user transactions (and it's subsequent contract transactions) are processed.


Is there a way to retrieve a list of all the addresses that have had activities from a extended public key?

Yeah, using blockchain.info you can do that:

https://blockchain.info/xpub/Your Public Key Here


Can the same target address appear more than once on transaction output?

There is no protocol rule which forbids having multiple outputs with the same bitcoin address. Here is an example of such a transaction:

https://blockchain.info/tx-index/16459554/3baf2227efd23449822e181372389af762c26a4567362ef174fa8659cf61eb20?show_adv=true

It is not common to see this as there is no point in having mutiple outputs when it can be done in one, it just makes the transaction larger and hence increases transaction fees.


Which files do you recommend I start with to learn Bitcoin?

I certainly appreciate your level of enthusiasm to want to dig straight into the code, but if I were you I'd start with the Developer Guide on bitcoin.org, and perhaps also the Developer Reference. A whole lot of effort has gone into this documentation (especially thanks to this guy), and I think you'd be remiss to not to take advantage of it.

After digesting some of that content, you'll have a better idea of what particular aspect of Bitcoin Core interests you the most. As I'm sure you've noticed, it's a rather large codebase, covering consensus issues, blockchain/storage/pruning issues, elliptic curve cryptography, DOS issues, Bitcoin scripting issues, Bloom filters, wallet issues, UI issues, and tons of other things I can't begin to fathom. After getting a good technical overview of Bitcoin and posing a more specific question, I'm sure someone (perhaps not me) can give you a more specific staring point.


Is Bitcoin a decentralized time-stamping authority?

Yes, Bitcoin can act as a time-stamping authority. However, depending on your application the accuracy of the Bitcoin blocks may not be sufficient.

Nodes only reject blocks that are greater than 2 hours into the future, and blocks created earlier than the median time of the past 11 blocks. Therefore, timestamps may be off by several hours.

also see: How accurate is Bitcoin network time?


What is the motive of a miner to include transaction in a block?

Blocks can contain whatever is valid, anything beyond that is up to the miner to decide. Including no transactions other than the coinbase transaction is valid, and there is no way of having a rule where this is not the case (was there transactions to include at that point in time?). Miners will absolutely not wait for transactions to be available to mine, as their main source of income is the block reward.
Miners are incentivized to include transactions by the creator of the transaction paying a fee, and the miner collecting it. Including no transactions mean they miss out on income.
Mining is progress free, each attempt is completely unique and has the same chance of winning no matter how many you have made previously or what the contents of those attempts were. Inclusion or exclusion of transactions has zero effect on the chance of a block winning or not as the header is exactly the same length for each and every attempt.


Do I need to have a full node to create an online bitcoin wallet

If you need a reliable wallet, then you should run a full node rather than trusting a third party service or running a light node.


Is there an active testnet for Bitcoin Cash?

Yes, there is.  After many hours I eventually received blocks up to the present time.

There is a working DNS seed at testnet-seed-abc.bitcoinforks.org (hardcoded in the Bitcoin ABC source) which lists active Bitcoin Cash testnet nodes, many of which actually work.  Bitcoin ABC doesn't seem to prefer this seed - it tries lots of others that only have Bitcoin Core testnet nodes - but you can do manually do dig testnet-seed-abc.bitcoinforks.org and then addnode the resulting IP addresses.


Easy, low fee way to move fro one paper wallet to another?

If you simply import your paper wallet's private key to another wallet, then you will not be protected against the backdoor that is being used to steal funds stored on paper wallets created with the code you mentioned. This is because importing the key will not move the BTC to a new address, it will simply allow the new wallet to spend the coins that are stored at the paper wallet address. Nothing would stop the thief from also being able to move those coins.
To protect yourself, you need to move the BTC to a new address, which was generated using secure software/hardware.
I would strongly recommend against using a web-wallet. Instead, I would recommend starting here: https://bitcoin.org/en/choose-your-wallet


Does a HD Wallet log my IP when i do a transaction?

HD vs non-deterministic:

"HD" means "hierarchical deterministic".

"deterministic" means: all your private keys are generated from a seed, "knowing your seed = knowing all your private keys", so that frequent backup is no longer needed.

"hierarchical" means: you can manage multiple coins/accounts/address types with only one seed. Watch-only wallets are supposed to import account extended public keys only, instead of the master public key, so that: even if there's a security breach, hardened parent nodes could still protect other accounts from being hacked, as long as the master private key is not leaked.

HD only affects how your private keys are generated and how you should backup your wallet. It has nothing to do with how you broadcast a transaction, nor with your IP address.

Bitcoin-QT was once a non-deterministic wallet: all private keys are independently generated. This might be true even if you are using a modern version of Bitcoin Core (which supports HD since 0.13), since Bitcoin Core won't upgrade a legacy non-deterministic wallet.dat to HD automatically. You can upgrade it manually by restarting Bitcoin Core with -upgradewallet command-line argument - of course, you must backup your wallet once again after this operation. BTW, if you enabled wallet encryption, or executed something like importprivkey or sethdseed in the console, you also need to backup it once again.

However, Bitcoin Core uses hardened address derivation, which means you cannot export any xpub extended public key to a watch-only wallet. Besides, Bitcoin Core doesn't provide any mnemonic.

Full node vs light-weight client

Full node wallets like Bitcoin Core reconstruct your wallet balance and transaction history by rescaning the whole blockchain locally, so that the receiving privacy is almost perfect - however, this is true only for 3rd party surveillance, your transacting counterparty obviously knows that the address which you gave him belongs to you, so that he can still try to track your transactions, which is exactly why the users are suggested to avoid address reuse (including both receiving and change address).

Light-weight clients like Electrum ask other people for your transaction history and wallet balance, so there are inevitably some privacy leaks. However, Electrum uses TLS to encrypt the traffic, so that your ISP/public WiFi provider/etc won't know your transaction history and wallet balance. You may use Tor to hide your IP address, but the Electrum server is still able to log which addresses have common owner.

BTW: Electrum servers are not controlled by the developers. Anyone is able to spin up his own server to join the network.

As for sending privacy, the Electrum server which you are using obviously knows both your IP address and what transaction you are broadcasting. However, since your connection to the Electrum server is encrypted by TLS, middlemen like your ISP cannot sniff what transaction you are sending.

Bitcoin Core relays other transactions by default, which makes traffic sniffing a little bit tricky, but not impossible still. Anyone who's able to monitor your Internet traffic, including your ISP/public WiFi provider/etc, is also able to find out which transaction is sent by you. Elipse attack is also likely to be a threat. Therefore, to protect your sending privacy, you may use Tor to broadcast your raw transaction (you may use Tor browser with an online block explorer service which supports transaction broadcasting, like this).

Using Tor with full node is still not enough

All bitcoin transactions are public information. For example, sending coins (UTXOs in other terms) which were received from different origins can reveal that they had a common owner (this was mentioned in Satoshi's whitepaper). You may learn some more advanced techniques to protect your privacy further: https://en.bitcoin.it/wiki/Privacy


Is it possible to buy bitcoins via an exchange directly into cold storage?

You can generate a wallet for cold storage offline easily. You can then ask the exchange to use a public address of that cold storage as the recipient for a transaction. You'd still pay the fee the exchange demands to process the transaction though.

Standard practice is that all trades in the exchange are just bookkeeping and are not published to the blockchain at all. Simplifying things a bit: The exchange uses a single wallet to receive all bitcoin transactions for all users. Each user is credited that much in their account. Trading moves some of the balance from one user to another. Once you withdraw, you withdraw from the shared wallet to an address of your choosing. In most exchanges, you can't trade directly into your own wallet.


How to avoid contagious media stories affecting Bitcoins?

Can crypto's achieve the same shop use?

For Bitcoin, the trend is in the opposite direction.

Bitcoin’s soaring transaction fees, following the digital currency’s 1,300 per cent surge in value in the past year, have made it practically useless as a token of exchange in Hong Kong.
“A customer wanted to pay for a HK$56 cup of coffee, but since the transaction fee was HK$97, we had to decline,” said Paul Li, manager of the Crescent Moon in Kowloon, one of 30 establishments in Hong Kong that accept the digital currency in lieu of cash. “The transaction fee was only about HK$5 to HK$6 in August. Now there is no incentive for people to actually use bitcoin.”

SCMP

If a crypto has a giant user base

I guess Bitcoin still has by far the largest user base of all the cryptocurrencies.


Is there something like Mt.Gox Live but for Intersango?

There does not seem to be a chart like that for this website. Not every exchange provides a live chart on its own, and asides the two websites you mentioned, there aren't any other that would provide access to a more "live" feed.


According to the Bitcoin core developers reference, SendFrom is deprecated and you should use SendToAddress or SendMany instead.

Note that SendFrom sends from an account not from an address. The Account feature is being removed from Bitcoin core.

I assume the (HD) wallet rummages around for suitable UTXOs to use as inputs to the transaction.


I'm not entirely sure, but I think the intent of that change is to allow non-segwit wallets to generate payments to segwit wallets. Imagine that you're a business that uses segwit, but 1% of your customers insist on paying using a wallet that doesn't support segwit.


Exactly Who or What Assembles Transactions into Blocks?

Who or what assembles the transactions into blocks every ten minutes?

Miners do. They do this before they attempt to find a block solution. It's the reason that miners exist.

  Setting the required number of leading 0s for the winning hash throttles the speed at which blocks, and therefore transactions, are validated. Who adjusts that number?

The protocol defines how it should change. Each node works out the current difficulty independently, and each of them comes up with the same answer.


Calculating the mining profitability of Novacoin

If you already have the hardware and do not pay for your power consumption, then it follows that you would always have 100% profit. If you pay for your own power consumption, you need to be aware that performing mining calculations all day will significantly increase your computer's power usage in comparison to being idle.

I haven't checked the validity of the calculator, but you can calculate your potential mining yield from your mining power and the current difficulty.

Check out this answer on How much Bitcoin will I mine right now with hardware X? for a formula.

Then, it depends on whether it is actually possible to sell the coins that you gained (whether there is a market for it), and whether the above information is acurate, otherwise, it might well be possible to make a good amount of money mining altcoins.


Is the fee added to the cost of the transaction or subtracted from the received money?

The fee is paid by the sender. The sender technically specifies how much money goes into the transaction from where and how much goes out of it to where. The total output value – of course – can at most be as big as the total input value, otherwise the transaction is invalid.

When you send money using a wallet software, you specify how much money you want to send. That is, you specify how much money you want to arrive at the recipient. The wallet will then add the fee to it. Your balance will go down by the money you sent plus the fee you chose.


Where can one find the Bitcoin Dominance chart index?

Yes you can check it here: https://coinmarketcap.com/charts/

It shows the bitcoin market cap compared to the rest. You can click on the coins below the chart to enable disable them.


The usual process is this:

You create an account on the exchange.
You go through their menus to deposit bitcoins.
They give you an address to send bitcoins to.
You withdraw from Coinbase to that deposit address.
You wait about an hour.
You now have a bitcoin balance on that exchange that you can trade.


Can miners reject transactions from an address?

Technically it is possible to blacklist addresses, and it needs just the majority of the mining power to agree.

The problem is arriving at the agreement: Nobody stands to gain from witch-hunts, so a consensus to block an address would have to be carefully built on solid proof, which is hard when there is no central organs with jurisdiction, nor a way to get a statement from the culprit.

Also, blacklisting addresses, just like tracking tainted coins, has a strong implication on what we view Bitcoin to be: One of the sources of Bitcoin's value is that bitcoins are considered fungible – that each individual does not need to care about the history of a bitcoin, because a bitcoin is a bitcoin. If we start treating bitcoins differently in accordance to their transaction history, it will make the bitcoin economy more complicated and less useful.


yes, but then the "spammer" hasn't really accomplished anything.

essentially with spamming its either
1) you paid to get a "spam" transaction included in a block
or
2) you paid nothing to get it in the mempool

not really spam either way at this point


Working example of raw transaction utilising Boolean (OP_IF, OP_ENDIF) scripting REQUIRED


Setting up and running multiple C-lightning nodes on same machine

you can run lightningd --help and get a list of arguments you can use to start lightning from the output there ist:

--lightning-dir=<dir>                Set working directory. All other files are
                                     relative to this
                                      (default: "/home/user/.lightning")

this means that you can set your own lightning-dir by calling lightningd --lightning-dir=/some/path/to/some/directory

now you can either put all the config values as additional arguments to your call or you put a config file into /some/path/to/some/directory/ which sets everything. the default is to call it config but you can also use the command line argument --conf=/path/to/some/conffile from lightningd to set a different one in a different location.

One thing you need to remember that both lightning nodes need to run on different tcp/ip ports. you do this by setting the port in your accounce addr in the config  file announce-addr=IP-ADDR:PORT you need to replacei IP-ADDR with your address and the port with the port.

obviously when interacting with each of the nodes you need to tell lightning-cli which one. again the --help command helps (:

lightning-cli --help
Usage: lightning-cli <command> [<params>...]
--lightning-dir=<dir>  Set working directory. All other files are relative to this (default: "/home/user/.lightning")
...

this means you can for example do lightning-cli --lightning-dir=/some/path/to/somedir/ getinfo


Supposedly 'Satoshi' was found in Australia… is there any way to verify this?

If someone purporting to be 'Satoshi Nakamoto' wanted to prove it, he/she could do so by signing a message using one of the same signing keys that 'Satoshi Nakamoto' used to sign one of his early messages during the release of bitcoin.  Or, he/she could announce that they will make a bitcoin payment from an address believed to belong to 'Satoshi Nakamoto' to some other address, then actually do so.


Unconfirmed Transaction - 8days - Exchange to Hardwallet

I suggest contacting BTC Markets and asking them to increase the transaction fee. Ledger isn't the issue - most wallets display unconfirmed transactions.


Is there any way to estimate an average amount of transactions per user per month?

While it is not possible to know the exact amount of users, there are still ways to estimate it by making assumptions and looking at online polls to utilize the wisdom of the crowd.

currently, my estimate is somewhere between 80 and 100 million users, although that refers to unique individuals who has ever used bitcoin, rather than unique individuals who are actively using it today.

furthermore, it is impossible to correlate transaction counts to this number as some services and systems generate automated transactions.

the other answe suggest that you look at bitcoin days destroyed, which is a measure for how long tokens have been stored sonce last transferred.

you could use that if you correlate it to other data sets, but beware that the time between broadcasted transaction and being mined in a block is unaccounted for.


Is there a way to retrieve my LTC that did not go into my wallet?

No it is lost.

Basically because the transaction is now in the LTC blockchain with a send to address that no one has the private key for.


Does Bitcoin RPC API have a realtime websocket?

Since you only care about transactions involving your wallet, you can specify the walletnotify option in your bitcoin.conf or your bitcoind start command.

Since walletnotify allows you to execute an arbitrary command with the new tx info, it's fairly easy to make it call a webhook on your application, or invoke your application via the command line, or pass the information on in any number of other ways.


2 mBTC that was outputted as change in a transaction I just sent didn't come back to my wallet

You don't need to retrieve it.

Your own wallet created that output, and sent it back to a different address under its own control. Your wallet's balance should reflect this change.


Are there projects visualizing and analyzing historical transaction data?

Check this website. It has summary of the tools available http://block-chain-analysis.com/


Note: This answer was written in Spring 2016 and has since been overtaken by an actual spec and multiple implementations. I'm hoping to update this answer shortly.

Summarizing mostly from r/bitcoin: How are paths found in Lightning Network?, the currently suggested routing would be similar to the Border Gateway Protocol.

At intervals, the following process is initiated:

A beacon node B is selected via a pseudo-random process.
Neighbors of B broadcast their shortest route to B to their neighbors.
The neighbors of neighbors of B now become aware of a route to B and in turn broadcast their shortest route to B.
This cascades through the network until every reachable node has broadcasted their shortest route to the beacon node B.
Whenever a node becomes aware of a new shorter route, it broadcasts this updated shortest route as well.
After a short wait, start from top with a new beacon node B1.

Nodes remember their shortest routes to a number of previously selected beacon node.

Now, Alice wants to send 0.3BTC to Bob.
Alice has shortest routes to B, B1, and B2. Bob just came online and only knows B2. They add together their respective paths to B2 and thus find a path:

     Alice → N1 → N2 → B2 ← N3 ← Bob

If they have multiple common beacons, they can also compare different paths, and check whether any earlier nodes in their routes match. If they instead had found:

     Alice → N1 → N2 → B2 ← N2 ← Bob

They could shorten the route to:

     Alice → N1 → N2 ← Bob

Altogether, "shortest" would be some combination of reachable, sufficient liquidity, lowest fee, fewest hops, and most reliable. As Hash Time Lock Contracts are nearly trustless (only potentially locking your money for some time), and operating a routing wallet should have low resource requirements, it seems likely that the payment routing market should achieve a healthy competition, therefore discouraging nodes to lock money by establishing channels just to earn fees from routing. Payment channels between nodes that have some form of regular business relationship seem more likely as there is an immediate benefit.

Sources: harda, mmeijeri, mmeijeri.


Why do we need public key as part of Witness in P2WPKH transactions?

This was discussed today on the #bitcoin-wizards IRC channel.  The reasons offered by Andrew Poelstra (andytoshi) were:

"Segwit had enough scope already."  That is, it was already a large change that some people considered controversial, so minimizing further changes was considered desirable.
"Pubkey recovery is incompatible with batch validation."  Poelstra goes on to explain that Bitcoin doesn't currently have batch validation for ECDSA and the reasons why, but it doesn't sound to me like batch validation would be impossible to add at a later point (though perhaps it would require a soft fork); presumably devs would prefer to work on batch validation and signature aggregation using Schnorr signatures instead.

Later, Gregory Maxwell (gmaxwell) added that "Certicom has a patent on key recovery that could potentially apply" to a possible construction, which could've made using that construction controversial.

FYI: your second question asked in edits should probably be asked separately as it's a completely different issue.


Is there any mechanism in Bitcoin that allows it to dynamically adapt to the flow of transactions?

Why is there a limit? Why don't we change it?

No matter the number of transactions broadcast to the network, there is an implicit maximum number of transactions that can be included in a block (see @JamesC's answer), and the number of blocks found is regulated by the network's difficulty adjustment algorithm, aiming for an average of one block every ten minutes. This puts an effective cap on the number of transactions / second the network can confirm in the blockchain record.

You might therefore believe that adding an adjustment mechanism for the size or frequency of blocks would be beneficial to the network, but further investigation shows this to actually be detrimental to the health of the network. The reason there is no adjustment to the number of transactions included in a block (ie. an adjustable block size), is that such a mechanism would have undesirable implications for the ability of users to run nodes, and for the game theory of bitcoin mining:

For full nodes: In general, the larger a block is, the more computational resources (bandwidth, storage, computation) a node will need in order to validate it. So a larger block size puts pressure on the least capable nodes in the network, any increase in resource requirements should be expected to cause some number nodes to drop off the network. Thus we can see that a growing block size can be used as a DOS attack against resource-constrained nodes on the network, and this is obviously undesirable.

For miners: no matter the hardware, a larger block will take longer to download and validate. As a miner, this means that when you hear about a new block on the network, there is a brief period of time during which you will be downloading the new block, but are unable to begin mining on top of it before ensuring it is valid. This leads to an increase in orphan block rate, which will affect smaller miners more than larger miners. Thus we can see that a larger miner would be incentivized to create larger blocks, because the latency issues associated with large blocks will affect their competitors (smaller miners) more than it would affect themselves. Ultimately, we would expect this to concentrate mining power amongst a few large-scale operations, which is obviously undesirable.

What other solutions are there?

So all of that sounds pretty dismal in regards to scaling the Bitcoin network up to deal with a global transaction volume. BUT! The good news is that scaling the block size is perhaps the most obvious approach, but certainly not the only one.

For example, the lightning network (LN) moves transactions off-chain, allowing pretty much unbounded transaction volume to occur off-band between LN participants. Further still, LN channel factories could allow participants to transact with incredible cost savings. Note that there are trade-offs involved in using the LN, and the model of trust and security is slightly different than transacting on-chain.

Sidechains are also coming online, such an example is the Liquid Network created by Blockstream. Note that sidechains don't increase scalability, but they can increase scale, though again with a different security and trust assumption than that of the underlying Bitcoin blockchain.

Schnorr signatures provide a number of benefits over ECDSA, in terms of scalability we can see that signatures can be smaller (meaning less bytes per transaction), and more flexible signature aggregation (many participants represented by a single aggregate signature, effectively reducing the 'number of bytes per user' in a transaction). Note that Schnorr signatures are not currently used on the Bitcoin network, but many developers would like to see their implementation in the future.

In conclusion: lets reconsider what a 'transaction' can represent

To wrap all this up, I'll encourage you to move towards an understanding that a user interacting with the Bitcoin network to exchange some value does not necessarily have to map 1:1 to an on-chain transaction. An on-chain transaction can in fact represent a huge number of individual user transactions (eg. a transaction that opens a LN channel, or a transaction that includes an aggregated signature representing a huge number of individuals participating in a single transaction), or as Nic Carter put it:

  [Bitcoin transactions] are nothing like Visa transactions, which they are commonly compared to. I like to refer to them as containerships, not parcels.

Which is to say that a single on-chain transaction can represent the economic activity of a great number of individual users, not just a single user's transaction.

So we can see that 'number of transactions per second' is not a perfect measure of the social scalability of bitcoin, instead the 'economic throughput per second' is perhaps more interesting. If we can include the economic actions of more users per transaction, we may find a more viable path to scale the Bitcoin network to a global level.


How was bitcointalk attacked in Dec 2013?

The general description has been given before me.Here are technical details on the attack vector.

Assuming the following:

The attacker got a certificate that the client will accept, via poor cert validation or other means.
The attacker knows the IP address of the server, and is in a position on the network to do things like ARP spoofing.

Ettercap includes modules for ARP, DNS and DHCP "interventions", and supports direct SSL MITM


What kind of messages are those used by Bitcore

This is the answer I received from a Bitcore developer (see here)

Messages are stored in the BWS server database encrypted by the wallet encryption key.
Therefore, the BWS server maintainer can not see any of the messages, but the copayers can see it because they have the decryption keys.
These messages only exist on the BWS server, so if the BWS server disappears. So does all your messages.
Wallets can be restored outside of BWS, but messages are tied to the BWS server.


Transaction amount for bitcoin payment gateway

If you insist on using bitcoind directly, you could always use the gettransaction rpc call to get transaction info on that transaction.
Hopefully you're using xpubs or at least a list of pre-imported addresses, and not using that bitcoind to manage your wallet/generate new addresses itself though. You shouldn't keep your private key on the live bitcoind node connected to your public ecommerce site.


So I closed my wallet in MultiBit and there isn't a trace of my wallet

See here first,
https://multibit.org/en/help/v0.5/help_troubleshooting.html,
Then here,
https://multibit.org/en/help/v0.5/help_support_missingWallets.html

Also, has been asked previously,
Closed wallet in MultiBit, is it gone for good??


Lost bitcoin because of deleted receiving wallet id

Not sure exactly what you deleted, but it looks like one of two things.

The wallet as listed in your software.
The file(s) associated with your wallet that your software uses.

If number 1, depending on the wallet, the files containing the private keys might still be on your hard drive. Look in the program folders and see what you find. Without knowing more, plus your wallet software, that's all I can give you.

If number 2, your only hope is if you have the private keys. Wallet files are just a list of private keys and portion of the blockchain. So if you don't have the private key, you have no bitcoin. If you backed up the private keys in some way, that's your answer. Create a new wallet and "sweep" the private keys into a new address.


What i was looking for is submitblock RPC call.


How to know when a payment has been received by bitcoind?

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


How can I get coins from a personal pool?

Yes, it does.
Pools help reduce the variance in payouts, but aggregated over all your miners, it needs to have enough hashrate to at least find a block occasionally.


what is the primary factor responsible for the increase of block size?

The primary driver of Block size is the number of transactions. Below is the structure of a block and the size of each part in the block.

  Magic no, 4 bytes

  Blocksize, 4 bytes

  Blockheader, 80 bytes

  Transaction counter, 1 - 9 bytes

  Transactions, -many transactions

The only part of a block with a variable size is the transactions part.

See: https://en.bitcoin.it/wiki/Blocks

If you're exploring the scalability of Bitcoin, see: https://en.bitcoin.it/wiki/Scalability#Storage


How Blockchain ensures transactions are not lost?

Why do you think that the transaction will be "lost"?

It will simply stay in the mempool as long as it is broadcasted by the sender and it will stay there until a miner decides to work with it, and thus confirm it in a new block.

A miner dropping the transaction because he doesn't want to include it in the next block that they're mining simply won't make it disappear.

If node B fails to get the next block, where they intended to confirm Alice her transaction, it would simply mean that her transaction will be in the mempool until another miner uses it in his block.

Note that this can happen simultaneously, it seems to me that you think that it is only possible for a transaction to be mined by 1 miner at the time, although this isn't the case.


What's the difference between these two usb miners?

According to the specs, there is no difference between the hardware -- they have the same hash rate (330 MHz) and use the same amount of power (2.5 W), so they should be interchangeable. It is possible that there are software compatibility issues, but this is unlikely. The machines are likely identical, so there may be other reasons for the difference in price.

The value of pretty much anything related to bitcoin is volatile right now, including mining equipment, so it's reasonable to see fluctuations in prices like this based on the whims of individual sellers that don't reflect a broad trend across the market. Consider this: the seller with the higher prices also advertises a very limited stock. It's possible that both sellers started out at with same price, and while one decided to start selling off a large quantity at a discounted rate, the other decided to stick to the original price and just sell off all they have left.

So, since there's probably no real difference -- just buy the cheaper one.