Pruning Blockchain, what does it remove?

What
Raw block data for blocks older than a given height.
If we look at https://bitcoincore.org/en/releases/0.11.0/, it says

This release supports running a fully validating node without maintaining a copy of the raw block and undo data on disk. To recap, there are four types of data related to the blockchain in the bitcoin system: the raw blocks as received over the network (blk???.dat), the undo data (rev???.dat), the block index and the UTXO set (both LevelDB databases). The databases are built from the raw data.
Block pruning allows Bitcoin Core to delete the raw block and undo data once it’s been validated and used to build the databases. At that point, the raw data is used only to relay blocks to other nodes, to handle reorganizations, to look up old transactions (if -txindex is enabled or via the RPC/REST interfaces), or for rescanning the wallet. The block index continues to hold the metadata about all blocks in the blockchain.

So if raw block data and undo data are deleted that presumably leaves the block index and the UTXO set as the two of the "four types of data" that are unaffected by pruning.

...
Modified RPC calls:
getblockchaininfo now includes whether we are in pruned mode or not.
getblock will check if the block’s data has been pruned and if so, return an error.
getrawtransaction will no longer be able to locate a transaction that has a UTXO but where its block file has been pruned.

So some RPC calls return an error for pruned data.
When
However the most recent 288 blocks are kept (approx 2 days worth) regardless of whether all their transaction outputs have been spent.
There are some additional details about the timing of deletion of files that contain multiple blocks that are individually marked for deletion. I don't think this substantially affects this answer but it may be something that you should study - depending on what you are trying to achieve.

Would it interfere with rpc calls to show info on a transaction/block?

Obviously, if the block has been pruned it would hamper the ability of the node to report on it. As mentioned above, some RPC calls will return an error if a block has been pruned.

a full explorer?

Ditto.

Does it interfere with showing transaction histories?

It may interfere with showing the history of arbitrary transactions but you should still be able to view all transactions that were created by this wallet/node.
I think you wouldn't always be able to immediately retrieve full details of the sources of transaction inputs back through prior transactions all the way back to the "coinbase" transaction that created the money currently being controlled by the pruning node.
So it may depend what you mean by history?

transactions previously created by this node
historical transactions referred to by own "live" transactions directly or indirectly.

I think the intent of a pruning node is that it should be fully functional as a personal wallet but require much less disk storage space.
If you are using it as something other than a personal wallet you may find that there are significant disadvantages you have to explicitly work around. I guess it depends on the precise details of the intended usage.

See

How do I get old blocks while running a pruned node?


Is the RAM or the computing power more important for the hashrate?

The 3.2 gigahertz machine. Ram is necessary but the hash rate is determined by processing speed.


Has PoS really been proven secure under comparable assumptions as Bitcoin?

The Ouroboros line of work proves security comparable to Bitcoin's security. The proofs of security in Ouroboros are similar in style to the Backbone proofs of security, which show that Bitcoin is secure. To my knowledge, there are no alternative proofs of security for Bitcoin which are formal - these are the best results we know of that illustrate that Bitcoin is secure, beyond informal hand-wavy non-mathematical arguments (such as "but you can't find a security bug, so it must be secure").

In both of these settings, there are certain assumptions made, which are as follows:

For proof-of-work, in the first version of Backbone from 2014, Bitcoin was shown secure in a synchronous model. This model splits time into discrete portions ("rounds" in Backbone, "slots" in Ouroboros) during which the players are allowed to mine and then broadcast any blocks found throughout a round. Messages sent during a round are anonymous (i.e., unauthenticated) and can be reordered by the adversary (hence the need for a consensus protocol). The adversary is also "rushing" in that it can use its own mining power after it has observed what the honest parties have done during that same round and prior to allowing messages to travel on the network. The assumption is that no messages are lost. This is a necessary assumption to prove Bitcoin secure - if the network is split, then you can't hope for your 50/50 honest majority to continue creating the longest chain.

The synchronicity requirements were relaxed in the current version of backbone revised in 2017 in which the model is semi-synchronous. The first version of Backbone also showed that Bitcoin is secure if the difficulty is kept constant. A follow-up work on Backbone from 2016 showed that it remains secure in a variable difficulty setting. These proofs hinge on an honest majority assumption which is made precise in the papers. More precisely, it is required that the adversary has mining power which is lower than the honest mining power by a fixed constant which makes up for non-uniquely successful rounds (i.e., rounds during which multiple honest parties find a block and hence will cause a short accidental fork on the blockchain).

The assumptions in the proof-of-stake setting of Ouroboros are similar network-wise to Backbone. The model is mostly borrowed from Canetti's Universal Composability framework, in the sense that there exists an environment which can influence the execution. Proofs in the "environment-including" model are powerful in that they can speak of any execution in which the adversary is able to tell people exactly what to do beyond the requirement that the honest parties run the honest protocol. For example, the adversary can corrupt players of their choice.

In Ouroboros, the assumption which is dual to Backbone's "honest mining majority" is "honest stake majority", i.e., that at any moment in time, the majority of stake belongs to the honest parties. This is a strong assumption which may or may not hold true, so it depends on what you're willing to accept. Another assumption made in Ouroboros is that stake shifting is bounded. This seems like a reasonable assumption: It means that all money cannot change hands instantaneously. However, the construction hinges on this bound to specify the security parameters such as epoch length. In the practical system, these parameters take concrete values which allow for specific bounds to be attained.

Ouroboros Praos achieves better security guarantees than Ouroboros: It allows the adversary to corrupt any honest party instantaneously, whenever she feels she needs to. This is a strong adversary (hence the system is more secure), and is also a similar assumption to Backbone. For proof-of-stake, it's an important achievement, as the adversary could retroactively corrupt parties who were successful in staking a block so that she can create multiple competing blocks. To my knowledge, practically deployed proof-of-stake chains such as Blackcoin do not enjoy such guarantees (and really cannot make any claims, since they do not have security proofs).

Ouroboros Genesis makes the above results stronger in that the parties are dynamic (and can, e.g., go offline) and the security is proven in a stronger model.

All of these works (the proofs for both Bitcoin and Ouroboros) also use the Random Oracle assumption, which some cryptographers dislike.

All of these approaches are comparable to other lines of work such as Snow white and ALGORAND. In my opinion, Ouroboros achieves better guarantees, has good design decisions, has formal security proofs, and functions in a model that is quite similar to proof-of-work-based systems (especially Praos). It would take an extensive analysis to compare them all side-by-side.

In the end, whether you are happy with the security assumptions and threat model in these works is up to your requirements. Overall, these works achieve some good guarantees, but some results are left to be desired. For example, honest majority may hold most of the time, not all of the time, but there has been no exploration of whether security is guaranteed in these settings (neither in Bitcoin nor in Ouroboros). I do suspect that Bitcoin is more resilient to extreme conditions, but no such guarantees have been proven.

Generally, one thing to note is that these limitations/assumptions also hold for Bitcoin: The best formal proofs we have for Bitcoin work in a limited model which is close, but not exactly the same, as the real construction. To conclude, Backbone is the best analysis we have for Bitcoin, and it makes an analysis which is comparable to Ouroboros. Hence, its security guarantees do match the security guarantees we have for Bitcoin, if you equate staking honest majority with mining honest majority, at least as long as provability is required.

If you'd like to understand these papers yourself, and judge for yourself whether they achieve your desired outcomes, I recommend that you read the GKL Backbone paper first. You can read the first portion where it talks about Common Prefix, Chain Quality and Chain Growth, as well as Liveness and Persistence. Then I recommend that you read Ouroboros, maybe followed up by Ouroboros Praos. These should give you a good idea of what this line of work is about. You're right that understanding Ouroboros Genesis has a lot of prerequisites. You can get a good understanding of the results regarding the security of proof-of-stake without reading that particular paper though.

Disclaimer: I am Aggelos' PhD student (Aggelos wrote Backbone, Variable Backbone, Ouroboros, Ouroboros Praos, Ouroboros Genesis - I did not contribute to these papers); my current scientific work is used in Cardano, which is an implementation of Ouroboros. My view may be biased.


Are there algorithms that could have been chosen for mining that balance CPU/GPU?

The scrypt key derivation function was explicitly designed to be resistant to hardware optimization, with an explicit trade-off allowed between memory and cpu usage:

  The scrypt key derivation function ... is designed to be far more secure against hardware brute-force attacks than alternative functions such as PBKDF2 or bcrypt.

This makes it better than SHA-256 or bcrypt if the intent is to give more of an advantage to CPUs.

Another option would be to include the same sort of variety of primitives that are provided for general purpose CPUs, e.g. a combination of floating point operations, access to large memories (perhaps including something that would use a large random access memory like a disk), etc.

But as Thilo point out, including some sort of anti-botnet feature might also be needed.  A CAPTCHA might also make it rather unpopular, but some sort of work load that would indeed be noticed by a regular computer user might make it hard to hide botnet activity.


Why won't a transaction with 888/byte confirm after 11+ hours?

It won't confirm because the grandparent and parent of your child transaction aren't confirmed. The grandparent transaction was also paid with a really low fee(51.573 sat/B).

I did the math for you.

Grandparent + parent + child = total transaction size:
3878 Bytes + 226 Bytes + 225 Bytes = 4329 Bytes

Add up all paid fees:
200000 Sat + 200000 Sat + 200000 Sat  = 600000 sat

Divide total paid fees with total transaction size:
600000 / 4329 = 138.6 Sat/B

Subtract to find difference needed:
450 Sat/B - 138.6 Sat/B = 311.4 missing Sat/B

To sum it up.
On average, the three transactions were paid with a fee of 138.6 Sat/B each.
The fee needed to confirm within 6 blocks is presumably around 450 Sat/B right now.
So the three transactions are short 311.4 Sat/B to reach the target of 450 Sat/B.


That is accurate. Let me start explaining how Bitcoins work from the beginning:

Bitcoins are first created when they are mined by solving a block. The first transaction in the block is basically you saying "I'm giving myself 50 Bitcoins to my address A" (plus transaction fees from the block).
When you want to spend Bitcoins, you have to point to one or more transactions that show where you got them from, and say how many Bitcoins you are transferring where. It's like saying "I got Bitcoins at transaction X. I'm sending 20 coins to address B."
The point is that more often than not you don't want to send all the coins you got from the transaction, so you also specify how much change you are sending to another address, usually controlled by yourself: "I got Bitcoins at transaction X. I'm sending 20 coins to address B and 30 coins to address A."
Since all of the above is cryptographically signed, one can be sure nobody can spend coins they don't have (spending more than they have, spending someone else's coins, etc).
To make sure nobody is cheating, everyone is looking at everyone's hands by checking each transaction that comes their way. If you cheat, your transaction does not get forwarded.

I hope that explains the concept of how Bitcoin works in regards to your question. Just to be clear:

"Does each bitcoin has a unique identifier, like currency notes have serial numbers?"

Not like currency (that each bill has a serial number and you can't break them apart), more like bank statements (the identifier identifies the transaction on a certain amount of Bitcoins), but that's still a simplification.

"If so, could you trace a particular bitcoin's ownership chain (ie. find the current owner of a particular bitcoin by its identifier)?"

You can trace the history of transactions on the set of Bitcoins up to who mined them, but not on a particular 1BTC. It's like saying "Alice paid Jill $10. Jill got $20 from Bob. Bob got $50 from the mint."


nBits refers to the target. The target is inversely proportional to the difficulty, and is encoded as a compact representation of a 256-bit number. The first byte of the 32-bit field represents an exponent and the remaining 3 bytes encode a mantissa.

Image via btcinformation.org
E.g. the first (and maximum) target was 0x1d00ffff, which is the compact representation of 0x00000000ffff0000000000000000000000000000000000000000000000000000, a 256-bit number with the leading 32 bits set to zero, followed by sixteen bits set to one, followed by the remaining bits not defined by the mantissa also being set to zero.
The block hash is usually represented as a hexadecimal number (which include the letters from A–F for the numbers 10-15), but block hashes result from SHA256d hashing and the output of SHA256 is a 256-bit number (hence the name). When miners are searching for a valid block, they create a multitude of block candidates. When one of these candidates' hash digests (interpreted as a 256-bit number) is smaller than or equal than the target, the miner has found a valid block.

You can calculate the difficulty from the target with the following formula:
difficulty = max_target / current_target

where max_target stands for the above mention initial target and corresponds to the minimum difficulty. Alternatively, the formula works out to:
difficulty = 2^208 * 65535 / current_target.


Sidechains cannot create the same asset that is pegged to Bitcoins to use as a reward for mining. Obviously, it would be problematic if anyone could put in a certain amount of Bitcoins into a sidechain, and get out more/less than what was originally put in.

However, there are many other ways to reward miners. Transaction fees is one example that is also used in Bitcoin. The sidechains paper lists some alternative reward mechanisms in section 6.1 such as demurrage (percentage of held coins are redistributed automatically to miners) and creation of a seperate unpegged asset on the side chain to reward miners.


What would be the Internet Usage For 100 Antminer S7?

Mining in a pool setting actually doesn't require all that much bandwidth. This is because you get block templates sent to you and that single template can be used by all 100 miners. A block template isn't very big, it's less than 1k and looks something like this:

{
 "error": null,
 "result": {
   "coinbasetxn": {
     "data": "0100000001000000000000000000000000000000000000000000000000000000
0000000000ffffffff1302955d0f00456c6967697573005047dc66085fffffffff02fff1052a01
0000001976a9144ebeb1cd26d6227635828d60d3e0ed7d0da248fb88ac01000000000000001976
a9147c866aee1fa2f3b3d5effad576df3dbf1f07475588ac00000000"
   },
   "previousblockhash": "000000004d424dec1c660a68456b8271d09628a80cc62583e5904f5894a2483c",
   "transactions": [],
   "expires": 120,
   "target": "00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
   "longpollid": "some gibberish",
   "height": 23957,
   "version": 2,
   "curtime": 1346886758,
   "mutable": ["coinbase/append"],
   "bits": "ffff001d"
 },
 "id": 0
}

You'll get that maybe once every few seconds, so from a downloading perspective, you only need about 20k/min download and that's sufficient to keep all your miners busy.

For upload, you'll need to submit shares to the pool. Depending on the pool, each share has to be below a certain target and the share targets are adjusted normally so that it doesn't take up much upload bandwidth. The actual upload for each share is on par with a get-block-template call. In addition, if you're using stratum, there's very little overhead in terms of requests since the same connection is used for both uploading and downloading (unlike http which incurs a large overhead).

Depending on the pool and the policies they have, though I'd guess that they normalize to reduce the number of shares submitted to be less than 100k/min. Again, depends on the pool and what shares they accept. But basically, the network bandwidth should not be the limiting factor even with a normal home internet connection.


How can I choose the address bitcoins are sent from?

As long as you're running a relatively recent version of Bitcoin Core you can use Coin Control. This feature let's you pick which unspent outputs will be used in the transaction.

To enable Coin Control, go to Settings->Options->Wallet->'Enable coin control features'.

Now in the Send window, you can click 'Inputs...' to select which unspent outputs you want to use. Easy!


Every bitcoin wallet user has one Private Key or every address has one private key?

There seem to be a couple of misunderstandings that I will try to clarify (briefly).

In public-key cryptography a pair of keys is used; a private and a public. The private is kept secret and the public shared. Assume that Bob has the public key of Alice. Alice can then sign a message using her private key and send the signed message to Bob. Bob can use the Alice's public key to verify that it was indeed signed by that private key. Because of the mathematical properties of public-key cryptography only the owner of that private key could sign that message.

A Bitcoin private key can be used to derive a Bitcoin address.
A HD key can be used to derive several private keys which in turn can be used to derive a Bitcoin address.

So, to answer your question:

A private key does not really uniquely identify a user. It just allows someone to prove that he owns a private key (has control over a specific address)

Nowadays wallets are HD wallets thus use a master key that all private keys (and thus addresses) are generated from.

So one user can have multiple address because they have multiple private keys associated with them. The private keys could be generated from one master key (HD wallets) or randomly (several non-HD private keys). Anyone holding a private key can prove that he controls the derived address without revealing that private key.


Do exchange rates between countries' currencies have an influence on Bitcoin exchange rates?

Bitcoin follows very closely to USD and RMB, because US and China are the biggest players in the bitcoin market now. You can see the trade charts here: http://bitcoincharts.com/charts/volumepie/

Hence US and China exchange rates will affect the worth of Bitcoin.

In regards to travelling, the merchant accepting Bitcoin will list prices in their local currency. If you pay with Bitcoin, they will use the exchange rate found on one of the exchange networks (e.g. mtgox)


Laymans guess to determine how many hashes must be computed to you find a specific value

It's pretty simple. Since the hashes are uniformly distributed, 25 zeroes is as likely as any other possible value for the first 25 hexadecimal digits. There are 16 possible values for each hexadecimal digit, so the number of possible combinations is 16^25, or about a 1,2676506×1030. This also means that on average, one in 1,2676506×1030 hashes will start with 25 hexadecimal zero digits.

To verify the solution, you just compute the hash once and check if it starts with the required number of zeroes. So, it's 1030 times easier to check the hash than to find it.


http://blockexplorer.com/q/nethash/2016 provides the necessary information and shouldn't be too hard to parse. Every row corresponds to the first block at a given difficulty.


Is every bitcoin transaction (eventualy) validated by every miner?

Welcome to Bitcoin.SE!

Each node validates all transactions in every block and, every block in its entirety.

The confirmation count is how many blocks are mined on top of the block that includes your transaction. A new block is mined every ten minutes on average.


Dogecoin daemon (dogecoind) not responding to RPC requests

Figured it out.  It had to do with adding rpcallowip lines to the config file.  Adding these three lines solved it:

rpcallowip=127.0.0.1
rpcallowip=192.168.1.*
rpcallowip=0.0.0.0

The last line is what eventually allowed it to work.  I'm not sure why, but netstat said it was listening on 0.0.0.0:22556, so adding 0.0.0.0 to the rpcallowip list solved it.


How many coins are needed to ensure stability i.e. neither inflation nor deflation?

This question would be better for Economics SE, if it was still around. But oh well.

You can't really prevent short-term inflation and deflation spikes, as anyone with substantial enough money supply could sway the economy until it balances itself out. Also, a similarly rich person could cause the Bitcoin to rise and fall in value in a pump-and-dump cycle by buying Bitcoins over a long period of time, and then spending them all at once for profit. Rinse, repeat.

For a long term, you'd need to generate Bitcoins at the same rate as the Bitcoin economy grows. As the value would be really hard to estimate, setting it in advance would be impossible.

The main way I can see Bitcoin having a stable-ish value while allowing for the economy to grow and shrink would be through the use of a system akin to Digital Coin. Generally, the idea is that everyone could be creating their own currency that would be exchangeable for Bitcoin at a varying rate. The rate would vary based on the supply and demand of the private currency. There are a few mechanics to encourage people to use the private currencies, which I won't go into detail here. In this scenario, Bitcoin will be used as a standard of value - meaning everything will be compared to Bitcoin, but actual Bitcoins wouldn't be spend under normal circumstances. This way, Bitcoin in most cases wouldn't undergo inflation, but the economy built around it could.


What is the hash function used by Bitcoin proof-of-work?

Bitcoin uses SHA256d to hash block headers, which is sha256(sha256(x)).

In anticipation of your next question, it uses a double hash to protect against length extension attacks (source).


Where can I access the original, Satoshi written Bitcoin code?

The Bitcoin client has been hosted on GitHub for a while now. It's very close to what Satoshi initially wrote. Here's the first commit dated back to 2009: https://github.com/bitcoin/bitcoin/tree/4405b78d6059e536c36974088a8ed4d9f0f29898

You could also browse all the commits from way back: https://github.com/bitcoin/bitcoin/commits/master?page=151

Some other research points me to the actual first email sent to the cryptography mailing-list by Satoshi where he actually delivered the 0.1 version: http://www.metzdowd.com/pipermail/cryptography/2009-January/014994.html

Here's the direct link provided by Satoshi but it doesn't seem to work anymore: http://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar

Googling a bit I found this, which is what you're looking for: https://bitcointalk.org/index.php?topic=68121.0


what do red and green bars at bitcoinity.org mean?

If you click on the WTF on the upper right corner you get explanations for all of the graphs. But not yet for the bars being below or above zero. The author will add that soon (2013-03-23).

Meanwhile you can look at a reddit question here: http://www.reddit.com/r/Bitcoin/comments/1aqtgo/a_note_for_newbies_about_market_forces_feel_free/c8zz2ro

green bars above the axis represent increases in buy/bid orders
red bars below the axis represent decreases in buy/bid orders
red bars above the axis represent increases in sell/ask orders
green bars below the axis represent decreases in sell/ask orders

(I think you can replace axis and above/below by current price and right/left, then it is correct. Though this does not explain the bars above and below the line parallel to the x axis)

Well, I didn’t completely understand, why they are above and below, but I understood from the WTF explanation on the site, what red and green means. tl;dr: Green has different meaning, if it is left of the current price or if it is right of the current price. Same for red bars.

Maybe comboy, the author of that site, adds a good explanation for this soon (he promised to do so on freenode irc chat).


Are non-SegWit transactions still malleable?

It's important to point out that segwit doesn't prevent malleability: in many ways the actual transaction data can still be changed by third parties. It just makes it harmless for the purposes of dependant transactions/higher level protocols, because when malleated, the resulting transaction will still have the same txid as the original.

To get this protection however, all transaction inputs must be segwit. As old style inputs by definition must be compatible with non-segwit software, their signature will contribute to the txid just as before.


generating random pair key has standard?

Developers of reputable wallets use a suitable source of randomness and will generate a key in the whole range available, not restricted to some arbitrary small range.
So far as I know there is no standard (e.g. BIP) that specifies this. It is assumed knowledge.
For example see https://www.freecodecamp.org/news/how-to-generate-your-very-own-bitcoin-private-key-7ad0f4936e6c/


Bitcoin boom and bust - Inherent instability of Bitcoin

and they eventually generate Bitcoin faster than the market demands.

This assumption doesn't apply, unfortunately. The production rate of Bitcoin is self-regulating and does not correspond to the overall mining capacity. This is due to the difficulty resets that happen every 2016 blocks which adapt the production to the network's mining capacity.

So, when miners compete, they do so for a roughly fixed amount of new bitcoins. When one miner grows their hashrate faster than their competitors, they may get to produce a larger share of the total, but they will not be able to significantly increase the overall production.


Blockchain to store private data and ownership

I think these links should be more useful for you than direct answer

http://www.cryptograffiti.info/
https://app.originstamp.org/home
https://bitcointalk.org/index.php?topic=1023190.0
https://github.com/petertodd/python-bitcoinlib/blob/master/examples/publish-text.py
http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html


How to completely empty wallets - problem with fees

Two options, depending on your skill level and comfortability with command-line:

Try updating your settings in bitcoin.conf to allow a low (or none) transaction fee:
https://en.bitcoin.it/wiki/Running_Bitcoin#Bitcoin.conf_Configuration_File
Try running in ./bitcoind in command-line with the option -paytxfee=<amt> with whatever amount you can pay to transfer these balances out. https://en.bitcoin.it/wiki/Running_Bitcoin#Linux_Quickstart


The getaccountadress command needs an argument: a string giving  the name of the account with which you want the new address to be associated.


How to use getblocktemplate method with Bitcoinlib Library

If anyone else need it i post the solution here:
Dim seg As JToken = JToken.Parse("{""rules"": [""segwit""]}")


At this point 2 TH/s is ok for small miners, 2 GH/s is crazy slow and 2 MH/s is probably not enough for the pool to even detect that you are mining at all. So that's most likely your problem.

Even the best gaming computers had to give up in 2013. Mining is now done on ASIC hardware. Computers are just too slow.


I sent myself a test BitCoin, now what? I don't see it, how long do I wait?

The transaction has more than enough confirmation, so if it doesn't show up, it's probably because your node hasn't catch up with the network yet.

Watch out though, looking at the numbers in your comment up there, the block height is the mainnet one, testnet figures would be a lot higher. Your transaction has been mined on block 1,584,207.

If this is so, it's totally normal your transaction doesn't show up in Bitcoin Core as they are two distinct networks. You should turn off your node with bitcoin-cli stop, and turn it back on on testnet with bitcoind -testnet. It might take some time if your node need to sync on testnet (but it's usually far faster than mainnet).


What causes the wallet functions to be disabled?

In Bitcoin Core 0.11 pruning is experimental, and incompatible with the wallet.

So turning on the prune= option automatically disables the wallet function.

In 0.12 the wallet will work with pruning (though you obviously won't be able to rescan past the pruning cutoff).


wallet will not sync it has been a week and I still do not have my money in the wallet. It took out my account

You are using wallet-software that requires you to download the whole Bitcoin ledger before it can read your balance. The Bitcoin ledger (the blockchain) is currently about 210 gigabtyes, so you would need a very fast internet connection to download it in just six days. If you don't have 210 gigabytes of spare storage, your laptop's disk will fill up before it gets to the part of the blockchain with your transaction and you'll not be able to see it.

You may therefore want to consider importing your address into some other wallet-software that's able to read a remote copy of this enormous ledger. Such wallets are very popular, but ultra security-conscious people do like to have their own copies of the blockchain, and only you can decide how much security you need.

In the meantime, any blockexplorer web site will tell you whether or not your coins have been sent to your address. If they're at your address, you have nothing to worry about other than the minor inconvenience of either waiting for the blockchain to download or importing your address into some other wallet-software before you can spend your coins.

It will make more sense if you remind yourself that bitcoins are not stored in wallets. Wallets are just tools for drawing up & signing transactions (and they also let you view your balance). The coins themselves exist only on the blockchain.

EDIT
Putting together the information in your two comments, it sounds like you've already transferred your coins to an address controlled by you (check your address on a blockexplorer web site). If so, your predicament is like having a faulty debit card (i.e. the money's in your account but you can't see it). I suggest you study how to export the private key for the address that you used. Once you've exported it, you can import it into a lightweight wallet that doesn't insist on downloading the whole blockchain. Personally I would use Electrum, but other lightweight wallet software is available. Electrum has a create new wallet wizard, with an option to “Import Bitcoin addresses or private keys”, where you should be able to paste your exported private key.

Private keys are valuable to you and to anyone who hacks into your computer, so you want to proceed carefully. Consider disconnecting your computer from the internet during the export/import process. You don't need the internet for key management chores.


Can double-spends be automated by malicious custom bitcoin clients?

What could be done in order protect against such an attack?

Wait for N confirmations before accepting a payment as successful.


Your understanding is basically correct. Keep in mind two things:
First, chain length isn't really the correct metric but accumulated chainwork. For practical discussion we can imagine for now they are the same thing.
Second: the entire purpose of Bitcoin full node software is to find the chain with most accumulated work. The whole meaning of its life is to discover that chain and synchronize its database with that chain (specifically, the UTXO set aka list of unspent coins aka "the ledger").
So it does not matter who mined what block. As long as it is running, the full node will try to stay in sync with its peers by sending locator messages (getheaders) and responding to new block announcements.
When a full node receives a valid block header that has more chainwork than its own tip, it attempts to download whatever blocks are necessary to verify that chain. If those blocks are valid and require "rewinding" the current chain, the node will do so, iteratively.
Consider this set of chain tips:
A-B-C-D-E-F
       \
        G-H-I

If your node synced blocks A through F then some time later learned about block header I, it will first download and verify headers G through I, then if they are valid download blocks G through I. If those blocks are valid, the node will disconnect F from its own chain, then disconnect E, then connect blocks G through I from the common ancestor D.
To address your points specifically:

You don't really "request +100 blocks" what you do is tell your peers about your own chain tip and ask them if they know about any chains with greater work.

"orphaned blocks" are blocks with no parent and this does not really ever happen on Bitcoin any more. I think you mean "stale blocks" here, but even then if peers do not respond with a greater-work chain, your node does nothing and assumes it is on the correct chain tip.

You would never "lower" your chain unless you were doing a reorg as I described above. In fact, if there were two blocks at height 10 you still wouldn't do anything until one of those chains got extended to height 11. THEN -- you become aware there is a greater-work chain out there and your node will attempt to download and verify it.


bitcoind crashing due to insufficient memory?

Are you sure 9051 is the right port for tor? 9050 is the default port.
You can check it by using sudo netstat -plnt | grep ':9051'.

And is the tor service active?

When it still doesn't works try disabling selinux(If you are running linux). I had some problems with tor because selinux was blocking it. But don't forget to put it back on. If it is selinux you can make a rule for tor/bitcoin in selinux.


How to use python rpc bitcoin to get the historical transaction record of a wallet address

To communicate with your bitcoin core, you must change your bitcoin.conf and set
server=1
Then connect to your bitcoin core with "http://user:password@127.0.0.1:8332"


Recall that transactions have inputs and outputs: when an output is listed as the input of another transaction, that output is spent.

So you go through the block chain from the beginning and make an index of unspent outputs.  For each transaction output you see, you add it to the index; for each input you see, you delete the corresponding output from the index, because it has been spent.

When you have an index of all unspent outputs, you look for those whose recipient is the address X.  Adding up the amounts of all those outputs gives you the "balance" of Bitcoins available to address X.


Using bitcoinj to discover peers and download the block chain

The class WalletAppKit is a good start. Here's a snippet of code that dumps the most recent block, you can probably take it from here. It will take a while to download the block chain and then it will print out the most recent transactions.

public class DumpLastBlock {
public static void main(String args[]) throws Exception {
    WalletAppKit kit = new WalletAppKit(MainNetParams.get(), new java.io.File("."), "test");
    kit.startAndWait();
    BlockChain chain = kit.chain();
    BlockStore bs = chain.getBlockStore();
    Peer peer = kit.peerGroup().getDownloadPeer();
    Block b = peer.getBlock(bs.getChainHead().getHeader().getHash()).get();
    System.out.println(b);
}
}


In the Ardor API, how can one return more than 100 results from an API call?

The 100 results per API call limit, is a DDOS protection mechanism when connecting to a remote node.

To remove this limitation and allow any API retrieve as many results as possible, do one of the following:

Connect to a localhost node.
Connect to a remote node and specify the administrator password (adminPassword parameter)

You can learn more about setting the admin password here: https://desk.zoho.eu/portal/jelurida/kb/articles/what-is-the-admin-password

Alternatively, as a node operator you can customize the number of records returned when no password is specified using the nxt.maxAPIRecords property.


Mining Theory: A theoretical mining based attack

Is there any known cases of this occurring

Yes, see Bitcoin Cash. While Bitcoin Cash had their "Emergency Difficulty Adjustment" algorithm in place, many miners would game that to cause the difficulty to significantly decrease and then quickly mine many blocks again to generate Bitcoin Cash much faster.

  what preventative measures could be taken to avoid this?

You could use an algorithm which does more than just the simple difficulty adjustment algorithm that Bitcoin uses. If you do something that adjusts more frequently or has overlapping windows, you can avoid this issue as the difficulty would ramp up and down more quickly to compensate for the sudden influx of miners. However, such an algorithm could cause the difficulty to oscillate and generally behave strangely, so you will want to do simulations and study the algorithm before deploying it to an actual coin.


Given the probability of finding a block, and time taken, can I infer hashrate?

As I understand your question it has two parts. One is how to calculate an approximation of someone's hash rate externally, like from a server or proxy that can see their mining results but not their actual hashing process or hash rate. The other part is how to calculate the probability that a block would be found after a given amount of work, or a given amount of time and hash rate.

I will write the formulas as javascript code, with X to the power of Y written as Math.pow(X, Y). You could run them in your browser by typing them into the address bar like for example javascript:alert((Math.pow(2, 32) * 27939) / 600).

Approximation of hash rate:

With an arbitrary target, count one share at difficulty X the same as X shares at difficulty 1. That's how pools deal with variable difficulty.

  hashrate = (Math.pow(2, 32) * shares) / seconds-elapsed

An average of one share (at difficulty 1) is found for every Math.pow(2,32) hashes. This is only an average and that is why the hash rates displayed at pool web sites are only approximations.

Block solution probability:

The probability of one or more blocks being generated from a given number of shares (proofs of work):

  prob = 1 - Math.pow(1 - 1.0 / difficulty, shares)

That's from 0 to 1. Multiply by 100 if you want a percentage.

Let's say the difficulty is 4367876 and someone has been mining with a hashrate of 200 Ghps for 10 minutes. That's 200 * Math.pow(10, 9) hashes per second for 600 seconds, with an average of one share (at difficulty 1) found for every Math.pow(2,32) hashes. This gives us the following:

  shares = (200 * Math.pow(10, 9) * 600) / Math.pow(2,32) = 27939
  shares

  prob = 1 - Math.pow(1 - 1.0 / difficulty, shares) = 1 - Math.pow(1 -
  1.0 / 4367876, 27939) = 0.00637...

In other words the chance that someone would make one or more blocks with the given hash rate and difficulty within 10 minutes is about 0.64%

Note: if you see how many shares (proofs of work) they send in, of course you don't first calculate their hash rate only to calculate it back into a number of shares. Just plug it into the formula.


How to add coinbase transaction with libblkmaker

To set a generating address, use set_generate_addr. blkmk_init_generation3 may also be what you're looking for.

The author of that library also wrote a miner, BFGMiner, that uses his library. Look at how he calls these libblkmaker function to add a coinbase transaction to the block header in miner.c.


Short answer is no. Accounts are a way to keep track of coins in "sub-wallets" of your wallet. When you receive coins to an address, the balance of that account is increased. After that, though, the link between those coins and the address balance stops.

Moving the address to a different account doesn't take all coins that the address has ever received with it, it only indicates that any future coins received on that address should go to the new account specified.

Similarly, moving the account balances doesn't change the amount received/owned on a particular address. Accounts are really just an accounting feature to keep sub-wallets, but moving money around in your accounts doesn't actually move them on the blockchain.


Extract lightning network funding transactions with python bitcoin blockchain parser lib

Firstly, you are off by two bytes. The output script is 0020982b5322310807d368d1dc261143095dc7d02fba6d6708bb7621519f312908b2, but you have selected 00220020982b5322310807d368d1dc261143095dc7d02fba6d6708bb7621519f312908b2.

Secondly, complex output scripts are never just put in the output. They are always wrapped in some form of Pay to Script Hash. In this case, because it is segwit, it's Pay to Witness Script Hash (P2WSH). So you can't know the actual script used without the output being spent from. Everything in LN is P2WSH, no scripts are just put in the outputs.

To break down this script, first you have 00. This is the witness version number, version 0. Then you have 20 which is a length indicator for the next chunk of data. In this case, that is 32 bytes. Lastly 982b5322310807d368d1dc261143095dc7d02fba6d6708bb7621519f312908b2 is the SHA256 hash of the script itself. That script will be a 2-of-2 multisig, but you won't be able to know what it actually is until this output is spent from.


What's the best way for a website to detect payments from green addresses?

It is now possible to determine the list of addresses that sent a transaction using the raw transaction JSON-RPC API calls that were released with bitcoind and bitcoin-qt version 0.7. The pseudo-code to accomplish this is:

txid = <relevant transaction id>
addresses = []
raw_tx = decoderawtransaction(getrawtransaction(txid))
for(input in raw_tx['vin']) {
  input_raw_tx = decoderawtransaction(getrawtransaction(input['txid']))
  addresses.push(input_raw_tx['vout'][input['vout']]['scriptPubKey']['addresses'][0])
}

Once you have the list of sending addresses stored in the addresses array, you can compare these addresses to a list of pre-approved green addresses. In most cases, you should expect there to only be a single unique address in the addresses array.

In order to get a list of suitable green addresses, you could hard-code it into your application, or you could use a dynamic source, such as Deepbit's JSON feed. This feed however, is notably missing Mt. Gox's Green Address


How can I best implement Bitcoin in my business?

Just some quick tips to get you started:

run with 'noirc=1' so that your node IP isn't discoverable via IRC
run with several 'connect=' so your node only connects to other specific nodes that you trust
do not expose the json api to the internet at large, confine it to localhost or specific ip only.
if you plan to hold a significant amount of bitcoins, then estimate how many you'll need for your daily float, and save the rest in an offline wallet (also generated on an offline computer - don't leave traces of your keys on any internet-connected disk)
do not accept 0-confirmation transactions, other than for really trivial amounts where speed of delivery is of the essence.
do use new bitcoin addresses for every new customer and order. address reuse makes it easier to track your customers.

There are probably a more items that could be added to the list, this is certainly not to be treated as comprehensive.


Does the low difficulty for my pool give my miners more guesses per block?

The "difficulty" being given to miners by a pool is used for tracking if the miner is doing useful work that could possibly result in a block, paying out the miner accordingly. The number of attempts a second, the overall income, and the resulting probability of solving a block are unchanged.


The bitcoind 'gen=0' setting - implications?

"gen" is by default 0 (off), so you should not really need to specify "gen=0" anywhere.

"gen" will generate bitcoins (mining), but you should only do this if you know what you are doing (you probably want to mine in a pool, and use proper tuned hardware/software).

And yes, you will only get transaction fees if you mine a block.


What is the best way to purchase Bitcoins quickly?

On LocalBitcoins.com you can get bitcoins bought under one hour. Just pick a trader who has good reputation (not a scammer) and low response times.


coinb.in wallet balance does not match "confirmed balance"?

Coinb.in uses blockr.io for fetching UTXOs. Blockr.io is currently 153 blocks behind the bitcoin network (not sure why).

Current Blockheight: 476961,
Blockr Blockheight: 476808

This is likely why you are having issues.


Bitcoin Blockchain - Verification process

Assume both Bob and Adam found a new block, but it will not be verified until someone finds a next block. So my questions is whats is happening in a situation if Adam will find a block |5| first. Will Bob get his reward for finding a block?

No. If Adam finds block |5| first and it is a valid block, Adam will quickly broadcast this to the bitcoin network and the proliferation of said block will take place very quickly across the entire bitcoin network. Nodes that receive Adam's block 5 will also start to orphan Bob's block 4 since Adam's block 5 is now the tip of the longest, valid chain. Other miners will also quickly switch to mine on this block tip to avoid mining on an orphaned block.

  Or it means if Adam found one block, he has to find the next one which is extremely difficult without a huge network of computational resources in order to verify his previous block |4| and get reward for block 4 of 12.5 bitcoins, because the nodes will only accept the longest blockchain?

Not necessarily. Once Adam's block (i.e. block 5) is broadcasted, another miner might be lucky and they could extend block 5 to block 6. Adam's block will remain as part of the canonical chain.

  If my assumption is true, it means there is no way how can a single person to earn anything from mining without a huge network ?

More or less true. Your chances of finding a block is based on your hash rate proportional to the network hash rate. Under today's conditions, the probability of a solo miner finding a bitcoin block is very small, but still a remote possibility. Therefore, we have mining pools in bitcoin.


What is the meaning of "Position in mempool" for a transaction?

To illustrate this let's imagine the mempool as big vertical list of transactions.

Let this list be ordered by the feerate each transaction is paying, the higher the feerate the higher the transaction in the list.

Miners will under normal circonstances take the highest virtual MB of transaction in this list/queue.

This website is a good visualizer of this concept.

NB: The tip in this context is the transaction in the mempool paying the highest feerate.


Multiple Inclusion of Transactions in a block

It doesn't matter if it's included in 10 blocks, as far as one of them will survive in the longest chain.

All others will be in obsolete forks or orphaned blocks.


Choose where to install bitcoin-qt (linux)

Run bitcoin with the flag

-datadir=<path to a directory>


How to get my 24 word seed using bitcoin-cli

You can't.
Bitcoin Core is not BIP39 compliant.


As you mentioned, bringing coins into the network is one of the main purposes of mining. But this reward is just an incentive to do the other more important part of mining: 'processing' transactions.

Immutability

As detailed here, when a block has been solved, not a single bit can be changed without invalidating it.

This means that all of the transactions in the block have been processed, and are 'final' in the sense that they are in the blockchain and will not change (assuming that block is a part of the best/longest blockchain). Imagine how bad it would be if you could change the transaction ledger to mark someone no longer being paid, or not being paid the amount that you said you paid them.

Security

Requiring billions of mathematical steps to be taken to solve a block means that it is very hard to accomplish. Honest miners that mine on the tip of the blockchain get rewarded for this in the form of bitcoins. But attackers who try to go back in history and replace old blocks with new blocks are at a disadvantage because doing so requires an enormous amount of hash power.

While the attacker was going back and trying to re-mine old blocks, the rest of the network continued mining on the tip of the blockchain, making it even harder for the attacker to catch up. Hence, for someone to create blocks faster than the rest of the network they have to be in control of >50% of the network hash power. This would take millions of dollars, currently.


There are a number of badly worded or misconceptions in there, but in future it would be better to ask specific questions rather than posting an entire description of bitcoin and asking if it is right :)

  and why validation of a transaction takes on average 60 minutes if everything goes well

This is slightly badly worded, validation of the transaction is easy (just makes sure its a valid transaction spending valid inputs). Its confirming it which you might like to take up to an hour for, but technically you don't have to wait for confirmations if you want to sacrifice a bit of security for speed (1 confirmation should be plenty for smaller purchases).

  it used to be 25 BTC

Note that it started at 50, this makes it sound like it started at 25.

  an easy part: a list of transactions since the last block was found, this is to validate the transactions.

The block just has a list of the transactions in the block. Your wording sounds weird, and it doesn't necessarily include all transactions since the last block, just the ones picked by the miner.

  a difficult part: a code that proves the identity of the miner that mined it (so that the network can award him the 12.5 BTC).

The miner doesn't prove their identity. They just include a special coinbase transaction in the block which pays the block reward to an address of their choice. And the block hash isn't really a "code", its just a valid block.

  at defined rate every 10min

The 10 minutes is just an average, the difficulty of finding a valid block changes to adjust for hashpower changes every 2016 blocks. You mention this, but you make it sound like somehow the decreasing supply of bitcoin per block is related to it. Its not, the difficulty just depends on how quickly the last 2016 blocks were found (technically 2015, due to an off-by-one error in the code).

  Now the problem is that there is since origin a limitation in the size of each block: 1Mb. This corresponds to ~ only 3 transactions by second. If the transaction rate goes significantly higher, it will create further delays in the validation process. This is the reason of the bitcoin forks.

This is outdated, it ignores the changes by segwit such as block weight instead of size, and the softfork to a maximum of 4Mb blocks. And where did that 3tx/s number come from? Also, the forks are hugely political in nature, you're oversimplifying.


Change difficulty using bitcoin-cli/bitcoind in regtest mode

No there isn't. Regtest is not designed to test mining ASICs and the motivation for such a RPC seems limited given regtest is for local testing.
However, if you want to experiment with mining on a network with limited network hash rate you could either try mining on the default Signet administered by Kalle Alm and AJ Towns or you could set up your own custom Signet network and then use the Signet mining utility in this PR (19937) to mine blocks. AJ Towns lays out some examples in a PR comment.
e.g.

Generate blocks indefinitely, at 10 minute intervals, paying block
reward to the given address, using bitcoin-util to do multi-threaded
proof-of-work:
 ./contrib/signet/generate.py --cli='./bitcoin-cli' generate 10 --block-time=600 --address="tb1..." --grind-cmd='./bitcoin-util grind'


Is declining number of peers (hosts) threatening the network?

Kozuch, you linked to another post that is related to this issue.  However, your question and the linked post are two separate issues: the other question is asking why grow the amount of miners in the bitcoin network.

On the other hand, the question you asked is about the number of hosts.  Specifically, peers, also known as full nodes in the bitcoin world.  These are the people who run the full bitcoin client instead of multibit / electrum, which is the light client since they don't require hosting the blockchain.

The number of peers on the bitcoin network does not affect the security of the bitcoin network.  Whether or not there is 1,000 people running full nodes or 100,000 people, it makes no difference to the security of the bitcoin network.  What matters isn't the number of peers, but the number of miners.

I run a full node myself because I use Armory and Armory requires a full node.  But I am not surprised that the number of people who run full nodes has gone down by 1/3 in the last year.  There are two reasons for this: bandwidth and hard drive space.  I have a 25 Mb internet connection now, which is fast enough that the bitcoin network almost never slows down my internet connection.  But my old (much slower) DSL connection was immensely slowed down by the peer-to-peer bandwidth taken up by bitcoin.

A potentially bigger issue, at least for me, is hard drive space.  The bitcoin blockchain was about 9 GB when I downloaded it in April 2013.  I just checked my blockchain folder and it's now up to 20.9 GB, which is exponential growth in the size of the blockchain.  My hard drive is only about 221 GB, with 98 GB free.  I expect to get at least a couple more years out of my current computer, and if the blockchain continues its trend of exponential growth, I will eventually need to buy a bigger hard drive to continue hosting a full node.

So that's the long answer on why it's likely that the bitcoin network lost a lot of peers in the last year.  Short answer?  Running a full node is rather expensive in terms of bandwidth and hard drive space.


How BitcoinJS sync bitcoin blockchain/transaction data?

BitcoinJS does not link directly to the bitcoin network, it is simply a collection of bitcoin-related functions.

Taking your example above, if we wanted to create a transaction with BitcoinJS' transaction builder function, we would have to find the inputs ourselves via API's (or asking your own full node if you have one) and add then it with tx.addInput(txId, 0).


Consensus rules are often a lot more delicate than they might first appear. Having a tie breaker can actually enable attacks.

If I find a block with a really low nonce, I can gamble to keep it secret and then only when a competing block is found, I can simply neutralize it by broadcasting my low-nonce block. This makes other miners waste their time on a block that will never become part of the chain and it gives me a better chance of finding the next block myself.

I'm not sure if this is true for all possible tie breakers. At least not to the same degree.

The answer by @hedgedandlevered looks at the question from another perspective ("What use would a tie breaker have for the system as a whole?") and is probably generally correct (that is: little to nothing).

However: another example of a tie breaker might be where SegWit signaling blocks are treated preferentially during a tie. That would (assuming support is already > 50%) increase the likelihood of SegWit activating a little as well as providing a slight monetary incentive for (all) miners to activate SegWit. This can be seen as an advantage to the system as a whole and as far as I know does enable attacks by miners in the way the nonce example did.


How can Blockchain.info wallet send unconfirmed bitcoins?

No, it does not lend you bitcoins but rather it spends the very same TX outputs that you have sent there. Thus, if your transaction turns out to be surpassed by another one (double spend), then also the transaction spending its output will be considered invalid.

It's like cutting a branch on a tree: all sub-branches will go down with the root one.


Is it possible to verify or audit an exchange to determine how much bitcoin they have on deposit?

If they want to publish this information, it's certainly possible.

If they don't, nobody really knows. They have at least one Bitcoin address for receiving money from each customer, and probably many, many more. Knowing and tracking all of them would be impossibile.


Why aren't balances appended to transactions?

First, blockchain space is at a premium, since every node has to store the whole thing forever.  So in general it is better not to store redundant information in the block chain, and to let each node compute it instead.

Second, the "balance" in an address can be affected by multiple transactions which are not necessarily ordered with respect to one another.  Suppose that address 123abc initially has no incoming transactions, so its balance is 0.  Now suppose that Alice decides to send 1 BTC to that address.  So by your logic, her transaction should show the "final balance" of the address as 1 BTC.  Simultaneously, and with no knowledge of what Alice is doing, Bob sends 2 BTC to that address, and so naturally his transaction shows the final balance as 2 BTC.  But the "true" final balance is 3 BTC, so both of their statements as to the final balance are wrong.  So anyone who wants to know the true final balance has to calculate it themselves anyway, and can't rely on the numbers in the transaction.

To make this work at all, you would need some sort of rule that you can't send more coins to an address until the previous transaction has some number of confirmations.  This would be completely impractical for addresses which are supposed to receive lots of incoming transactions (think of a donation address on a popular website).   It would also mean that an attacker who knows your address could prevent you from receiving an important transaction by sending you lots of tiny transactions which would have to confirm one by one.


Are you aware of the stratum protocol definition? I found a description here: https://slushpool.com/help/#!/manual/stratum-protocol. As a prerequisite, you need to know how block hashes are computed. See https://en.bitcoin.it/wiki/Block_hashing_algorithm for the definition.

When you'd compute hashes for solo mining, only hashes that meet the current difficulty are valuable. In contrast, when pool mining, you will submit hashes to the pool which meet a significantly lower difficulty requirement, so the pool can see that you're actually working. The number of "shares" that you produce will determine the portion of the block reward allocated to you when the pool finds a block.

Note that I cannot provide code samples or more detailed explanation, as I've never coded a bitcoin miner. Since you want to write the mining software, it's your job to find out :-)


Is there anything like a "blank" blockchain?

Yep. Do all of the normal steps for creating an altcoin. https://bitcointalk.org/index.php?topic=225690.0

Then, replace the CheckProofOfWork function with something else.


This will happen because you are upgrading from a non-segwit node to a segwit node. This behavior happens because Bitcoin Core will rewind the blockchain to the point where segwit was activated so that it can download the missing segwit data and verify that the blocks are valid.


ASIC or Application-specific integrated circuit is a type of circuit that has become very popular in the Bitcoin mining community.

wikipedia defines it as

  "An application-specific integrated circuit, or ASIC /ˈeɪsɪk/, is an integrated circuit (IC) customized for a particular use, rather than intended for general-purpose use."

Traditionally computer chips are made with variability of input in mind, meaning that a given chip should be able to do a wide range of things. Because Bitcoin miners only ever use their chips for Bitcoin mining, you can make chips that are really really fast if you make them solely with that purpose in mind.

This is how companies like butterfly labs can get such ridiculous speeds of up to 500 GH/s!


Why the block's order in blockxxxxx.dat is different from blockchain.info

The blkxxxx.dat files contain the blocks in the order that they were downloaded from peers.  Since the client requests blocks from many different peers in parallel, and different peers may respond at different speeds, it is quite possible for blocks to be downloaded out of order.  (Headers are downloaded first, as a separate step, so the client knows what hashes to request before it gets the full blocks.)

Sorting by timestamp isn't safe either.  See Why are the blocks out of order?  The protocol does not enforce accuracy of the timestamps, and a later block can legally have an earlier timestamp.  At last check there were almost 14000 examples of this in the blockchain.

The only correct way to sort them is to actually reconstruct the chain, using the "previous" field of each block's header to identify the block that should come before it.  This will also help you identify and remove orphan branches and disconnected blocks.


Is there a paper wallet generator for the new bech32 bc1xxx segwit address?

https://kimbatt.github.io/btc-address-generator/
You can generate bech32 segwit, p2sh-segwit, and legacy addresses here.
I made this site because I couldn't find any paper wallet generators that support bech32 format. Source code is available on GitHub.


How does the mempool work? What happens to the mempool when there are two equal length chains on the network?

Is there just one mempool or does each node keep a copy of the mempool?

Neither. Every node has their own mempool of transaction they expect to see confirmed. It's not a copy as there is no consistency between nodes.

  From my understanding each node needs to keep a copy of the mempool.

No, mempools are completely optional. You can configure your node to not keep one at all. The only downside is that you won't know about transactions until they confirm.

  If that is true then how is mempool consensus reached?

There is no mempool consensus. If there was, we wouldn't need a blockchain.

  What happens to mempool transactions when there are two equally long chains on the network?

Nodes have just one active chain which they treat as correct. There may be competing chains, but nodes will typically assume that the version they see first will win. If they keep a mempool, they try to keep it consistent with the blockchain as they accept it, not with any possible alternate versions of history.

  Is there a chance that the BTC gets forever lost in a mempool when one of the chains is rejected?

Miners have complete power (together) in determining which transactions are accepted into the chain. It's certainly possible that you issue a transactions which never gets included, but that has nothing to do with chains being rejected.


How does transaction confirmation work through mining process?

Yes, the system is designed in a way that you should expect a new block to be mined every 10 minutes, which is what is needed for a new transaction to confirm. As more blocks are mined on the top if it, the transaction gets more and more "confirmations". Each user decides how many confirmations are required for the transaction to be considered "safely completed".

Although it should take roughly 10 minutes to create one confirmation, due the nature of the process, it can be much faster (think tens of seconds) or much slower (think more than 1 hour). So definitely, in some cases, you may need to wait a long time before you get the number of confirmations you want. Another factor here is the number of transactions that are currently waiting to be confirmed. If there are many such transactions, your transaction may not make it into the very next block, thus prolonging the delay even more.

This is the reason for many different technologies to emerge. You can see many altcoins that change the parameters to lower the time needed for the successful "completion" of the transaction. But even on Bitcoin, you can see technologies like Lightning Network to emerge that promise very fast completion times.


Checks to Verify money sent to any address in a transaction

So you're asking for 3 things: confirmed, valid and that a particular address in a particular txout has received the specified amount.

Confirmed: You've already worked this out.  If getblockcount - blockheight > 0 then the tx has at least 1 confirmation, and so on.

Valid:  Tx are confirmed in two ways:

by validating nodes (full Bitcoin nodes like bitcoin-qt).  Each time a tx is broadcast across full peers, it is validated.
by the network.  This network validation occurs when the network agrees that the block containing the tx is valid, which occurs first time at 1 confirmation and increases in confidence with each additional confirmation.  Being included in a mined block also means that (1) above has occurred at least once (probably much more).

So if you're only considering confirmed Bitcoin transactions, they've already been fully validated by the network and its nodes, so you don't have to do this yourself.  This does not necessarily apply to unconfirmed transactions.

Particular address has received specified amount:  There are rules of thumb here, but to be absolutely sure about this last item, you have to consider the tx script.  Fortunately, all this entails for most transactions is checking for OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG.

This is the relevant part (for you) of the script contained in the scriptPubKey.  As long as it contains this text, you can be sure it's a simple payment in the amount specified to the address specified, regardless of whether it is change or whatever.

If the scriptPubKey contains something else, then you'll need to actually parse the script to figure out the tx details.  How to do this is beyond the scope of this question.

So in brief, to fulfill all your conditions, you need to wait for 1 confirmation and check for the exact scriptPubKey text shown above, or else be prepared t ofully parse the script in the case of a complex contract.


Electric power efficiency - why is increases so fast

The mining hardware industry started very recently and their chip fabrication technology was way behind that of traditional chip manufacturers (ie Intel, AMD).

Chip energy efficiency depends on the distance between the transistors of a chip. The closer the transistors are the better. Intel produced their first 14nm (distance between transistors) in 2014. Mining hardware manufacturers resently produced their 16nm ones. They started with 28nm (or worse) ~4years ago.

Still mining hardware almost reached the chip density of Intel which is remarkable for only 4 years of development. It would be very interesting to see, if mining incentives remain high, whether it reaches or surpasses the big players in chip manufacturing.

Note that mining hardware is now very close to the best available chip so we can expect that the energy efficiency of mining would follow Moore's Law from now on (just as Intel hardware does).


Hard fork without non-mining full nodes = weak network?

It's not great, but non-mining full nodes are relatively inexpensive to operate, and if ordinary users start switching to that fork, some of them will bring their full nodes with them.  The network will get along okay with fewer.  If it really starts to be a problem, miners, exchange operators, and others who have a vested interest in the success of the fork, can fire up some full nodes.

If ordinary users don't switch to the fork, then it's doomed regardless of how many miners choose it.  It doesn't do you any good to mine lots of a currency if nobody wants it.


What is the fastest possible way to download the blockchain?

To download the blockchain with maximal speed you want to be connected to nodes with high bandwidth.

On default bitcoin will search and connect to random nodes. One can add nodes to bitcoin conf to tell bitcoin to connect to specific nodes.

To add a node to the bitcoin client to connect to, add the following to the bitcoin.conf file in:
Windows:/appdata/roaming/bitcoin/bitcoin.conf

Linux: $USER/.bitcoin/bitcoin.conf

ADD THIS TO BITCOIN.CONF

addnode=127.0.0.1

To find high bandwidth nodes go to:

  blockchain.info/hub-nodes

for example and browse the hub nodes section.
It is not required to add the node port, bitcoind will find the correct port.

....
Enjoy downloading at full speed.

EDIT: since the question / answer gained such an attention i decided to make this a community wiki :)


How to get a description (comment) of the transaction?

The comment field seen on the blockchain.info blockexplorer is a feature of the blockchain.com wallet. The data for that comment field is created by users of their wallet, stored only by blockchain.com/info and published by blockchain.info.

This comment is not part of the Bitcoin transactions stored on the Bitcoin blockchain, it's only stored in the databases of a service by a company called Blockchain. The comment thus cannot be retrieved by other wallets. It may be possible to retrieve it from the blockchain.info API.


Amount of block locator hashes in "getblocks" message

getblocks message pushes a maximum of 500 block invs to the caller. It will lookup the given block locater in the active chain and pushes up to 500 MSG_BLOCK invs to the caller (it might stop earlier because the called node reaches the chain tip). The corresponding code for bitcoin-core 0.10 can be found here (https://github.com/bitcoin/bitcoin/blob/0.10/src/main.cpp#L3888).

Also notice that bitcoin-core now uses the headers first approach and therefore getblocks is no longer in use when acting as a "calling node".


How can I process Bitcoin transactions in my store?

StrongCoin has developed a PHP script for fast handling of micro transactions. You can read more on it here:

https://strongcoin.com/blog/bitcoin_micropayments_with_strongcoin
http://www.thebitcointrader.com/2011/12/monetizing-blog-with-bitcoin.html?m=1


Is there some kind of draft to support a chain split+merge, like Version Control systems do?

There is one inherent problem with the solution you described in regards to Bitcoin: the block chain is created in a very specific way. Each block in the block chain links to one and only one previous block, and it is encoded in such a way that if you change the internal structure of the block, it is no longer valid. You should look into the block hashing algorithm. Generally, if you wanted to merge two blocks together, you'd have to solve them all over again.

This does not mean, however, that the transactions from the invalid branch are lost. Unless the coins were already spent in the valid branch, one can take those "lost" transactions and include them in the next block to be mined. This would mean that the transactions would end up having a couple less confirmations, but they would still go through.


The JSON export seems indeed to be broken. A quick workaround is to simply get the graph page and extract the needed data from there:

curl -s https://blockchain.info/charts/hash-rate | grep data: | grep -oE '\[[0-9\.,]+\]'

That should give you the JSON array. The array contains a daily sample of the hash-rate starting from timestamp

curl -s https://blockchain.info/charts/hash-rate | grep pointStart | grep -oE '[0-9]+'


Start your own node and access the page http://localhost:7876/test for a list of public APIs. You can also find some public peers which enable API access. Take a look at peerexplorer.com for an up to date list.


Can one tell which way the market goes from sell and buy orders?

Market direction, as with any direction, only applies when you have more than a single data point.

So, the value of the trade at t-1 compared to the value of the trade at t can tell you if the market moved "up" or "down".  The value of t, by itself can only ever tell you the value of t.  There is no way to determine direction or velocity from a single point value.

If an individual API provides direction, then you could use that; however that is up to the individual API to provide.


The domains listed in chainparams.cpp are for DNS seeders. DNS seeders are not nodes themselves, but rather are DNS servers that serve the IP addresses of nodes that are available to be connected to. These can be connected to for both a normal connection and just one to retrieve more IP addresses of nodes.

The IP addresses listed in chainparamseeds.h are the IP addresses of nodes that can be connected to. This connection can be an actual connection or just one which retrieves more IP addresses of nodes that can be connected to.

To setup a seed node, you just need to run a normal node for your altcoin and add its IP address to chainparamseeds.h. There should be a script that actually constructs this for you in contrib/seeds.

To setup a DNS seeder, you will need special software to do that for you. You can start with this software and modify it as necessary to work with your altcoin.


Have you tried understanding why you have that desire? It might help you understand more about what makes you tick.

You might like to try mining Litecoins, or even on the Bitcoin Testnet. Or, you could try some Bitcoin mining with the Eligius pool, which from memory will pay out any amount after 2 weeks (whereas most pools have a minimum payout). If you can manage to mine 0.01BTC, that is enough to make a transaction from most eWallets (again, they often have a minimum transaction, usually 0.01BTC), and you could possibly even buy something from coindl.com with it.

Alternatively, you might get more satisfaction by playing Minecraft (it has a free trial), which can give the same sense of satisfaction when  you find something of "value".

Another option to consider is earning some dollars, or whatever your local currency is, and exchanging it for bitcoins. Or even just save some dollars on electricity by not mining, and exchange those for bitcoins. Or, sell something on bitmit maybe?


How are transactions propagated through the bitcoin network? (In-depth)

I read briefly in a paper that there is some sort of transaction queue that the node keeps for each neighbor and that they will only select a random (?) amount of those transactions and send in an INV message to those nodes.

Note that this is specific to Bitcoin Core. Other full node software may not exhibit this behavior.

When Bitcoin Core receives a transaction, it adds the transaction to lists that it maintains for every other node it is connected to. Each node has its own list and that list contains all of the transactions that your node has received but may not have been received by the other node. After a certain random time delay, your node will then send messages to the other node. Among the messages it sends is an INV for transactions in the list for that node.

However not all transactions in the list are sent. Only some of them are sent. To select which transactions are sent, your node will sort the transaction list by the number of ancestors it has (so that parent transactions are relayed before child transactions) and by its feerate. Those transactions with the fewest ancestors and highest feerate will be at the top. Transactions are selected from this sorted list until either the INV message reaches its limit (which happens rarely) or there are no transactions remaining. Once transactions are selected, the INV is sent.

  Why don't they send them all the transactions in the queue and why does it wait a random amount of time to send the transactions in the queue?

The random delay between sends is done for privacy reasons. The sorting of transactions is done to prioritize the transactions that will be selected first by miners. It also helps with privacy.

The reason these help with privacy is because a spy node that has connected to your node will not be able to always know what transactions your node has received and what your mempool looks like. It won't be able to know which transactions you have received first. Furthermore, due to the random delays, if a transaction originates from your node, it is possible that a node connected directly to yours receives your transaction from someone else first, thereby reducing the certainty of such analyses.


How to spend from the "master_private_key": “df484533kf5mzv83892a234a44ae9z83m832987a82mqwmdkks018121204v95las9"

While you may be able to import the key into another wallet, it is better to create a new wallet with a new key and transfer all the bitcoin out of the old wallet and into the new one by making a regular bitcoin transaction on the blockchain. This eliminates all sorts of possible complications, including the security risk of disclosing the keys from your old wallet.


In the case, bitcoin transactions are becoming less frequent, will the blockchain become unsafe?

It's not the number of transactions that determines the security level, it's the amount of work done to partially invert the hash function. For the same difficulty level, this is proportional to the number of blocks mined (though Bitcoin scales the difficulty to even out the time between blocks). In the short run, the miners do not really care if there are many transactions or few transactions available to include in the block -- they've already invested in the high fixed cost of ASIC mining hardware.

To pull off a 51% attack, the attacker would have to provide as much computing power as all legitimate miners do. A slight drop in the popularity of Bitcoin isn't going to cut it.


My first bitcoin transaction with core and coldcard

That is a viable method for using a Coldcard with Bitcoin Core. HWI is intended for the case where the hardware wallet is plugged into the machine running your wallet software. For the Coldcard, it is just an alternate way to use it. However for other hardware wallets, the MicroSD card method is not available so HWI provides a way to use them with Core.


Is there a list of established sites that have started accepting Bitcoin?

http://stuffexists.com/  has a good list.


Why are Bitcoin transactions sometimes confirmed instantly if blocks are mined every 10 minutes?

A little more information is necessary to tell you exactly what happened to your transactions that were confirmed "almost instantly" but what you've said is correct:

The bitcoin protocol is such that new blocks should be mined, on average, every 10 minutes.
A transaction is "confirmed" (has 1+ confirmation) only after being included in a block. Before this, the transaction is "pending". Some merchants require more than one confirmation for the transaction to be final, many choosing to wait for 3 confirmations before being deemed complete.

However, the situation can arise where after publishing your transaction a block is then mined a few seconds later that has your transaction in it. This could give the appearance that your transaction was confirmed "almost instantly".

Possible source of confusion: Blocks aren't mined 10 minutes after your transaction, they're mined 10 minutes (on average) since the previous block was mined.


Can I get all the information I need to create a payment transaction from BlockExplorer?

To create a payment, you need a private key with an associated public key that has funds, a public key of the recipient, have the hash of the last transaction made on your public key, and perform some hashing on all of those.

Block explorer provides all the information but the private key. If you have that, you can generate a valid transaction on your own.


How can I get the private key from multibit?

If you want to use the original version of MultiBit (called MultiBit Classic) then the installers are available on the https://multibit.org website.

Click on the 'Download' button at the top of the page and then look at the bottom of the 'Releases and signatures' section.

The new version of MultiBit (called MultiBit HD) uses a set of wallet words to deterministically generate private keys and addresses. You restore directly from the wallet words rather than exporting/ importing individual private keys.


Litecoin miner crash with no apparent reason

Your settings look good.  If it was working OK with same settings for a while, then started acting up, either you have a software upgrade that's causing issues, or (more likely) you have a new/developing hardware issue.

I had one doing the exact same thing last week (would run for a few hours and then reboot). I ended up reloading the os and then from windows to linux (bamt) and it was still doing the same thing. Under closer inspection, turned out two of the gpu card's power wires were burned straight through and had broken off (both yellow ones in my case).  Don't know how it worked at all with two missing power wires, but maybe it was getting some power from the motherboard and only needed the extra capacity under heavy load.  Either way, I replaced the burned out pciex power connectors and it's been running with no issues for a week now.


Lightning Network: Isn't there a risk in spending more BTC than needed?

I have to send a 0.1BTC transaction to Jim to create the Payment and hope he doesn't close the channel. If he does, then the 0.1BTC is sent to the main blockchain?

Opening a channel doesn't involve "sending coins to Jim", it involves "opening a channel with Jim". You do not need to trust Jim to not steal your funds, because of the threat of revocation if he misbehaves and attempts to publish an old channel state. If Jim closes the channel honestly, he will be paid out according to the current channel balance. The 0.1 BTC locked into that channel will be split according to the current state of the channel, with Jim's share going to Jim, and your share being returned to you.

  If all I have is 0.01BTC to start with, all I an send to Jim is 0.01BTC once. The only way I can send more is if there are already other funded payment channels between myself, Jim, and another node that have remaining capacity?

Yes, there is no such thing as debt on the Bitcoin or Lightning Network. In order to pay someone, you need the available funds or channel capacity. This capacity can come by routing a payment to Jim, using some other node(s) you are both connected to.


What are the implications of Schnorr signatures?

Warning: I've never actually worked with the Schnorr signature scheme.  The
following is my analysis based on reading the Wikipedia
article, the ed25519
page, and some discussions between devs in
#bitcoin-dev.

Likely Changes

Changed op code behavior: we will need an op code to check
Schnorr signatures. With a hard fork, we can redefine
op_checksig and
op_checksigverify to also check Schnorr signatures. With a soft
fork, we can redefine one of the reserved no-op op codes to check
Schnorr signatures.
Increased P2SH usage (maybe): I think it's highly unlikely
that a new address format will be introduced to do the same thing
for pubkey scripts paying Schnorr public keys that
P2PKH does for
ECDSA public keys. That means people who want an address to use
Schnorr even with just one key (non-multisig) will have to use
P2SH. Of course, for applications that don't need addresses (like for
mining or when using the
BIP70
payment protocol), they can just use op_checksigverify_schnorr (or
whatever) directly in their pubkey scripts.
Smaller multisig transactions: one of the most widely touted
advantages of the Schnorr scheme is that it can allow multiple
signers to combine their signatures into a single signature which can
be authenticated against a single public key created by all the
authorized parties. This accomplishes the same thing current Bitcoin
multisig does but uses fewer bytes. This may be especially useful if
dozens or hundreds of signatures are required, such as in a
crowdfunding situation.  Note: if I understand correctly, this is
also possible also with ECDSA, but in a less flexible way. (2018 note: there's now a paper out that details how to do script-less scripts on ECDSA, including 2-of-2 multisig)
Slightly smaller for all transactions: assuming Bitcoin uses the
ed25519 curve, which has a similar key
strength to the secp256k1 ECDSA curve Bitcoin currently uses,
compressed Schnorr public keys and signatures will be (respectively)
32 bytes and up to 64 bytes compared to current compressed Bitcoin
secp256k1 public keys and (non-compressed) signatures that are 33
bytes and up to 75 bytes.
Plausible deniability for multisig: using Schnorr threshold
signatures it
may be easier to prevent multiple signers or third-parties from knowing who else
signed or didn't sign. That's because the individual signatures are
merged into a unified signature that doesn't directly reveal who
signed it. This can be used in situations where the signers are
afraid of reprisals for spending funds in a particular way.
Plausible deniability of authorized parties using a
third-party organizer (which doesn't need to be trusted with private
keys), it's possible to prevent signers from knowing whether their
private key is part of the set of signing keys. Although not
directly relevant to Bitcoin transactions, I seem to recall[1] Greg
Maxwell saying he'd like to see this property used for distributed
forum moderation: choose a bunch of senior forum members, get a
public key from each of them, create a threshold public key from
some of the individual public keys, and then let individuals submit
a signature when they think a post should be removed. The
third-party organizer (probably an automated program) will combine
the signatures without leaking whose signature actually contributed
towards meeting the threshold. If nobody knows whose signature
actually matters and the pool of possible moderators is large,
effective reprisals against moderators become very expensive. [1]: #bitcoin IRC about 4 months ago; unfortunately that chatroom is not
publicly logged.
Theoretical better security properties: the experts agree general
Schnorr signatures have better theoretical security
properties
than equivalent ECDSA signatures. The most notable of these
improvements is that the hash function used in Schnorr doesn't need
to be as collision resistant as the hash function used in ECDSA.
(Bitcoin would likely use the same hash function for Schnorr that it
uses for ECDSA: SHA256.) Also, the ed25519 page linked above
describes several ways it is resistant to side-channel attacks, which
can allow hardware wallets to operate safely in less secure
environments.
Faster signature verification: it likely takes fewer CPU cycles
to verify an ed25519 Schnorr signature than a secp256k1 ECDSA
signature. This is probably only a tiny improvement for Bitcoin:
Bitcoin Core verifies signatures before adding a transaction to its
mempool. When a block is received containing transactions already in
the local mempol, Bitcoin Core does not re-verify those transactions,
so as long as the local node and the mining node have identical
mempools, no signature verifications need to be performed. (Recall the
coinbase transaction doesn't have a signature.) However, signature
verification is currently a bounding factor for nodes during initial
blockchain download (assuming a high-speed connection and Bitcoin
Core 0.10.0), so "faster would be better."
Multi-crypto multisig: with two (slightly) different
cryptosystems to choose from, high-security users can create 2-of-2
multisig pubkey scripts that require both ECDSA and Schnorr
signatures, so their bitcoins can't be stolen if only one
cryptosystem is broken.  Unless we hardfork in Schnorr (see point #1),
they won't be able to use standard op_checkmultisig---but they can do
something like <ecdsa pubkey> OP_CHECKSIGVERIFY <schnorr pubkey> OP_CHECKSIGVERIFY_SCHNORR

Uncertainties (To Me)

Maybe changed TXIDs: I'm not familiar enough with Schnorr
signatures to know how they might be malleable (changeable by
third-parties without invalidating them), but crypto expert Adam Back seems to think they'd be pretty malleable. His solution would be to change how TXIDs are calculated from hash(<whole transaction>) to hash(<almost everything except the signature>).  This would fix some current malleability-based problems, such as slow micropayment channel creation, but it also be a major hard fork that affects effectively all Bitcoin software.  The last fork of that scale---the soft-fork P2SH implementation---still doesn't have support for it from all Bitcoin programs after three years of discussion, two years of implementation, and fairly widespread use.

Public key recovery from signatures: I don't know whether a Schnorr public key can be recovered from a Schnorr signature the way an ECDSA pubkey can be recovered from an ECDSA signature.  This could be important: the Bitcoin Core verifymessage RPC uses key recovery to verify messages signed with the signmessage RPC or by another client's sign message implementation.  (Note: this point left unnumbered because it was added after the original posting.)

Non-Changes

Just to be clear, here are some things that don't change.

Deterministic signatures: there has been a drive towards
deterministic ECDSA signatures
in Bitcoin software. For example, Bitcoin Core will begin using them
in the upcoming 0.10.0 release. Schnorr signatures can also be
generated deterministically. With deterministic signatures, you
don't need a high-quality source of entropy (randomness) to create
secure signatures. However, you do still need high-quality entropy
to generate private keys or root seeds (see point below).
HD wallets: it looks to me like the hierarchical deterministic
(HD) key generation
protocol
will work for Schnorr key pairs with a few small modifications. You
can even use the same root seed for both ECDSA and Schnorr
hierarchies.
Key (address) reuse: as with properly-implemented ECDSA, it's
possible to securely create multiple Schnorr signatures for different
transactions, meaning it's secure to receive multiple outputs to the
same address or public key. This is in contrast to
some signature
schemes which
only allow you to securely use a one signature per public key.  However, key reuse
can still be less secure than using unique keys for each transaction,
and key reuse will always be much less private for you and your
trading partners.

Priority

Just as a matter of my opinion: Schnorr seems to provide some nice
advantages over ECDSA for power users, but nobody seems to be begging
for those features---so adding Schnorr signatures is probably low
priority. I'd guess that Schnorr signature support might be one of the
first improvements that will be fully tested in a sidechain (PDF
link) before being ported back
to Bitcoin.

P.S. Sorry for the long post, but thanks for asking such a fun question!


Steem content is rewarded based on a voting system, described well here:

https://steemit.com/steem/@smooth/voting-is-a-popularity-contest

Not that payment is made in Steem not fiat and Steem value will fluctuate over time.

The developers were able to mine a huge portion of the total Steem supply due to the relative complexity if the mining process at launch.  The fairness of the process has been a matter of debate:

"First, they did a typical instamine/flashmine/freemine scam (yes scam) where they released

(1) no compiled wallets
(2) no instructions to build
(3) incomplete and inaccurate instructions to mine

This wasn't bad enough. After the first 12 or so hours of mining, all their miners crashed, exposing that they were mining to 100 different witnesses to hide the fact that they (he) was one entity. The devs wouldn't have been caught except that their mining instructions were wrong, and no one else was mining because, even if they couldn't get the client to build, they entered mining commands that caused them to get no blocks. The devs will claim this isn't on purpose, but check the original thread. You'll see that no one mined a block when the dev's miners were down.

Then, as I have stated many times, when their miners crashed again, I mined a significant amount of steem that night in their absence. To prevent my vesting that and driving the price of vests up on them, they relaunched to ensure COMPLETE CONTROL AND CENTRALIZATION.

After the relaunch, no one would challenge them on mining because if they did, the devs would just relaunch this scamcoin again. So, no one who pays attention (and the people who have the means to procure whatever hashes they want are also the people who are paying attention), would challenge them on the hashes. As they hoped, no one did and they completely dominated the hashes for 1 week."

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

The "stealth" mining by developers raised a lot of Steem which are now being deployed in part to attract new users.

"At the conclusion of the pure-PoW mining phase, all of the coins from the developer mining accounts were merged into the transparent 'steemit' account, with a stated plan to sell them off to pay for development and distribute them for free to new users (each new account requires 10 STEEM funding). These actions have occurred and are transparent on the blockchain."

https://bitcointalk.org/index.php?topic=1513252.msg15232327#msg15232327


How to recognize which output is used as input for a new transaction

A vin contains both a txid and a vout.  As you've correctly identified, the txid part is the transaction that contains the unspent transaction output (UTXO) being used for this input.  The vout part is a zero-based index for which output on the transaction is being used.

For example, if vout is 0, this input points to the first output of the transaction.  If vout is 3, it points to the fourth output.  Think of the these parts of the vin structure as being an address for a particular UTXO on the blockchain.


Will it be possible to export a key and only allow it to be imported once?

No, there is no way to keep track of what people do with their private keys. You could easily write down the key before exporting it and you can use it without ever importing it to a wallet. It's possible to construct a transaction from the private key manually or using some 3rd party software and then broadcast that transaction to the network.

It sounds like you want to be able to send money without using the blockchain by simply passing private keys around. You then run into the double-spending problem. This is exactly the problem that the blockchain is solving. So, no, if you want to securely send bitcoins you will have to use the blockchain.


The way to do this is to validate each and every block before beginning work on the next block.  If you validate the block you will have verified each and every transaction included in the block.  This then gives you the knowledge you need to determine if particular transactions were included or not.  When they have been included in a block they are also removed from the mempool.  The process of first validating a block can be slow and is not always popular so many miners take shortcuts and mine using SPV (only the headers)  they are thus unaware of which transactions are included in each block while validation is occurring so to keep miner busy they will mine a block without including any transactions.