How to parse transaction script to address the correct way?

I think to have figured out that the public keys in P2PKH-transactions scripts begin with 76 all the time, is that enough to determine the type as P2PKH?

No. The 0x76 is the number of the first opcode, OP_DUP. A full P2PKH transaction has the template OP_DUP OP_HASH160 0x14 <pkh> OP_EQUALVERIFY OP_CHECKSIG.

  Lastly, i wanted to ask, what other transaction types i could come across? I need to parse every transaction script to an address 100% correctly, thus i need to cover all possible cases.

Scripts can contain anything and there's not necessarily an address for them. Addresses represent specific data in standard transactions, of which there are only a few different types.

P2PKH (as above)
P2SH (OP_HASH160, 0x14 followed by the 20-byte hash of the redeem script and OP_EQUAL)
P2WPKH (witness version 0x00 followed by PKH)
P2WSH (witness version 0x00 followed by script hash)
P2MultiSig (OP_N, <pubKey1>..<pubKeyN> OP_M OP_CHECKMULTISIG where N <= 3)
OP_RETURN <data>

The first two, P2PKH and P2SH use base58 addresses beginning with 1 and 3 respectively on mainnet.

P2WPKH and P2WSH use bech32 addresses beginning with bc1 on mainnet. You can determine the difference based on their length. Witness versions > 0 are also standard, but have no known meaning - this is intended for future extensibility.

OP_RETURN and P2MS don't have standard addresses. Nor do any non-standard transactions which do not fit any of the above conventions. Addresses are intended for human readability and parsing, so that software can simply recognize what kind of output is used, and how to create the relevant scriptSig to spend them.

Standard transactions are only a policy in software used to determine which kinds of unconfirmed transactions can be accepted into the mempool. Transactions confirmed in blocks can ignore these standardness rules and contain arbitrary scripts, as long as they evaluate to true.

The full details for parsing the standard script types are defined in standard.cpp in Bitcoin Core.


how does a node searches a transaction among various blocks in blockchain?

Transactions are stored in the form of merkel trees inside a block. (I know how a merkel tree is made). A merkel root is calculated and stored in the block header.

All correct.

  An SPV can ask a full node about the balance of an address

No, it can only ask for a proof that a particular transaction was included in the blockchain. The Merkle tree has transactions as leaves, not addresses

At the protocol level there are no balances, only UTXOs. UTXOs (or "coins") are things with a value and an address, and every transaction simply "reforges" coins. It explicitly lists certain input coins which are melted down fully (destroying those coins in the process), and then constructs new coins whose value does not exceed the value of the consumed coins. Nowhere in this system does a balance appear.

  (which is an encryption of public key).

A hash, not an encryption. There is no encryption anywhere in Bitcoin (except locally to password protocol your wallet file).

  I want to know how does the full node get to know which blocks exactly contains those UTXOs?

This is unrelated. Blocks contain Merkle roots of transactions. They don't contain UTXOs.

One way to look at it is that there is an implicitly-defined set of UTXOs for each block. This set is empty for the genesis block. Every transaction processed deletes the UTXOs it consumes from that set, and adds new UTXOs to it for each output it has. As blocks are groups of transactions, they too are just aggregations of groups of UTXOs being deleted from and added to the UTXO set.

In fact, that is how full nodes work. They just maintain a database with all unspent outputs. Every block is just an authenticated "patch" of changes to make to the UTXO set.

  Does it the traverse merkel tree of each block till genesis block? or is there any way to know if the block contains those transaction or not just by utilising its merkel root.

I assume you're talking about BIP37 Bloom Filters? There is no searching involved at all. A light client tells a full node "hey I am interested in transactions to address X". Then it asks for a range of blocks. The full node reads through those blocks, and if a matching transaction is found, sends it to the light client along with a Merkle branch that proves the transaction was indeed in that block.

This approach has various downsides. First of all, it is inefficient, as it requires the full node involved to read and scan through all transactions in all blocks. Secondly, it is terrible for privacy. Even while the set of addresses the light client is interested in is hidden inside a Bloom filter, it is very hard to not make it leak what transactions a node cares about.

BIP157/BIP158 specify a more efficient and more private protocol called Neutrino to accomplish the same.


What shape of merkle tree does the Bitcoin client build?

When the number of transactions is not a power of two, how does the Bitcoin client represent the transactions?
Each time around, it hashes each transaction with the one next to it, until there's only one left.

If there's an odd number of transactions, the last one is hashed again.

In this example, we start out with 11, then 6, then 3, then 2, then 1.

What would happen if you made a differently-shaped merkle-tree?
When sending blocks around, there's no way to specify the shape of the merkle tree. If it's different, the standard client will just reject it.


Pseudo-Node and putative attack vectors on the network

A large number of interconnected psuedo-nodes makes launching a bandwidth-exhaustion attack much easier.  Bitcoin Core validates most information before relaying it, but psuedo-nodes don't validate---so if you can get some psuedo-nodes connected together, it's probably easy to get them to waste tons of bandwidth by relaying junk data to each other and then to their peers.

For example, if there are 101 psuedo-nodes (PNs) connected together, you can send PN1 a valid-looking inv packet announcing a single fake transaction (about 61 bytes plus TCP packet overhead).  Each PN relays that inv for a minimum of 6100 wasted upload bytes.

But those PNs are also connected to real nodes.  Lets say 500 real nodes, so now the wasted PN upload bandwidth is 36,600 bytes (plus TCP overhead)---all because an attacker created a single 61-byte inv.  Worse, the real nodes are going to request the transaction using a 61-byte getdata packet, wasting 30,500 bytes of real node upload bandwidth.

If the attacker sends 1MB of fake data per second for an entire day, he'll use 86 gigabytes of his own bandwidth,  but waste 52 terabytes of aggregate PN upload bandwidth and potentially 43 terabytes of real node upload bandwidth.

(Depending on how the PNs are written, they may waste even more bandwidth relaying the getdata packet around.)

Compare this to the cost of running the attack against a single real node.  For each 61-byte inv packet the attacker uploads, the real node replies by uploading a single 61-byte getdata.  So a bandwidth exhaustion attack against a real node requires roughly a 1:1 about of wasted bandwidth.  The real node doesn't further relay the inv until it receives and validates the transaction it refers to, so no other node has any wasted bandwidth.

  Is there any feasible contingencies in the protocol to delineate
  between a PN and a node? For example, would different Bitcoincore
  versions identify PNs (or a simple modification to the protocol)?

The protocol already has the notion of a DoS ban score, in which each
Bitcoin Core node assigns a private score to each of its peers for any
bad behavior they perform. Once the DoS ban score for a particular peer
reaches a threshold (100 by default), the node disconnects from the peer
and refuses further connections from its IP address for a time (one day
by default). Bad behaviour includes sending invalid transactions
and blocks.

Because PNs don't validate data, they'll happily relay invalid data. If
they become common, someone who wants to grief PNs could simply connect
to any advertised node and send it a bunch of invalid data. If it was a
real full node, it will disconnect (DoS ban). If it was a PN, it would
relay that data to real full nodes, causing the real full nodes to DoS
ban it. This would make the PN useless and would allow the griefer to
detect which nodes are PNs---the griefer could then publish (an
unauthenticatable) database of PN IP addresses.

This method works best against long-term PNs. To make it harder to
execute short-term Sybil attacks from lots of lightweight PNs, something
like Greg Maxwell's proof of storage to make distributed resource
consumption
costly
could be used.


Is there a way to predict somehow the required storage for a specific blockchain?

This depends on a number of factors,

1) The amount of transactions

2) How the blockchain will be compressed in the near future.

Now as i'm not quite familiar with the altcoins you stated, I can't go in depth about their compression development, but it would be fairly easy to find out what the MAXIMUM size of the blockchain could be.

Simply calculate every block as if it would be filled up with transactions ( maximum size), and multiply that by the amount of blocks  for/until the next year.


How to get total transactions on the network with RPC

I'm reasonably sure this is not exposed by the RPC API.

You could parse debug.log and look for lines like:

2019-08-20T12:17:58Z UpdateTip: new best=0000000000000000000e6c402b311740e21f79a42ed84ecf69a3ae4fe88ce882 height=590956 version=0x20000000 log2_work=90.9855 tx=446914655 date='2019-08-20T12:17:55Z' progress=1.000000 cache=277.1MiB(321228txo)

Where tx=num gives the total transaction count. I reckon that most explorers maintain a separate database of the transactions, and simply run a query against that instead of pulling data like this from a node or log.


do you know why this block is so unusually small?

Miners can include as many (under the block size limit of course) or as few transactions as they like in a block. There may not be any particular reason for a lower number of transactions, thats just up to whatever algorithm the miners used to select transactions to mine in that block


Lightning Network LND - Retrieve payment by hash

I don't think you can look up payments by their paymentHash but you can look up invoices which contain a lot of the same information using a paymentHash: https://api.lightning.community/rest/index.html#v1-invoice


How to restore Multibit HD keys using cloud .zip.aes files

If you have your seed words, I would suggest giving up on Multibit and either using "Simple Bitcoin Wallet" or "Breadwallet", apps for Android/iOS - other users are saying they are able to retrieve their Bitcoin using their previously MultiBit-managed Bitcoin holdings by simply importing their seed words. If you get this to work, please let me know.

MultiBit has been discontinued as a supported product and hundreds of users are having these problems.


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

You cannot create your specified spend conditions with Bitcoin script directly, because you cannot specify the nature of a future output within an input's script. Put differently, an input's script cannot define the outputs created from it.

You could perhaps achieve a similar result using a multisig address, and a third party 'rule engine' signer or similar (credit to @RaghavSood in the answer I linked to above), but it is not possible to program a Bitcoin address to behave this way independently.


You can extract the entire last validated ledger as a giant JSON file if you want to. Be patient, it might take a while. Your server has to have an RPC port open with administrative permissions. You can use this command:

  rippled -q json ledger ' { "ledger_index" : "validated",  "expand" : true, "full" : true } ' > ledger.json

Be patient, this will take awhile. And your server may use a bit more memory and CPU when it's running.

When it's done, you'll have a giant file (about 1.7GB as of right now) called ledger.json that contains the entire current ledger. This will contain every account, every XRP balance, every offer, every trust line, every escrow, and so on.


That message means that the sender created two transactions that attempted to spend the same coins. This is called "double spending" and is not allowed. One of the two transactions has to be marked as invalid by any Bitcoin node that sees the two. I believe most Bitcoin nodes will initially set aside whichever they received last. Over a short time time, the network as a whole comes to a common view about which transaction is accepted (so some nodes may change their decision after a few tens of minutes from their initial decision).
The transaction that you are looking at has long ago been determined, by all participants in the Bitcoin network, to be the incorrect one of the two.

How to fix the issue.

You can't.
If you are the creator of the transaction, you should be able to find the other transaction where you spent that money.
If you are a recipient, you just treat that transaction as if it never happened, you were not paid.

Related

Can this double-spend attack happen in Bitcoin?
Other quesions about double spending attack


Transferring bitcoin from old bitcoin core wallet to electrum

I have a 7 year old wallet.dat file

I guess that predates HD wallets. Which I think means you'll need to sweep all private keys which have money (UTXOs) currently associated with them.
For an HD wallet I believe you can probably sweep the Extended Private Masterkey shown at  the top of the dumpwallet output.

I'm stuck at the step dumpprivkey, because I don't know what <your bitcoin address> means.

listunspent should help by giving you a list of addresses which actually have money associated with them.


How to deterministically generate large number of bitcoin addresses and monitor them

One options would be a bitcoinJ - bitcoin java library.

new ECKey().toAddress(new MainNetParams()).toString();

gives you a valid bitcoin address.


Can Ripple XRP be a good store of value with >50% ownership known?

If the company were to cease operations or break down in some way, the code would immediately become open source. At least one developer has that clause in their contract. If something were to happen to the company's store of XRP before the network is sufficiently distributed, at worst, the ledger would be reset. (We have contingency plans that mitigate damage, but they're not pretty.)

These are risks, and they're part of the reason that getting the network distributed and the server source code open is a high priority for us. It's not just a matter of trying to do the right thing, these are threats to OpenCoin and risk is a drag on adoption. So we want them gone as much as anyone else does.

Personally, I don't think XRP is a particularly good store of value now. It's not so much the risks you mentioned, because I think they're small. It's the unpredictability of the value of XRP due to market forces, widely variable speculation, and so on.


Is bitcoins generate-seeds.py and makeseeds.py the scripts to register DNS-seed ips?

No, not at all. Those scripts are for creating the hardcoded seed nodes list which is retrieved from an existing DNS seeder.

To add a DNS seeder, you would need to add it to the list of DNS seeders in src/chainparams.cpp. Furthermore, you need to have a running DNS seeder which requires special software. One such is https://github.com/sipa/bitcoin-seeder.


How miners on the same pool search non-overlapping sets of nonce candidates already tried by other miners to find a solution?

The pool gives a different template for a block to each miner. Each miner then generates lots of different blocks from their template. For each of these blocks they try all the possible nonce values, or at least some of them. They could even use a fixed nonce value and only change the other parts of the block - that would be just fine too, although less efficient as the nonce is a quick thing to change that won't require a new merkle root.

Trying all possible nonce values for a block only takes a split second and has almost zero chance of finding a block below target.

Duplicate work is avoided by the pool never giving out the same block template twice.

So a miner cannot do the same work as another miner, because it never has the same block template. It can still do its own work twice if it is very badly designed. But in that case the duplicate work results get rejected by the pool.

What's happening with mining is that you try billions upon billions of different blocks to find one with a hash below the current target. Changing the nonce value is only one (very limited) way of generating more blocks. If you only change the nonce then you'll only have a few blocks to try and it is extremely unlikely that any of them will have a hash value below the target.


Some general questions about blockchain consistency

For example bitcoin has a huge amount of nodes so its impossible to be connected to all nodes. Is there some kind of connection broker, root node thats always online or broadcasting that holds a list of nodes?

No, there is no hierarchy to the nodes. There is no reason to be connected to all nodes, messages are flooded to the network by peers.

There is a list of DNS seeds that will help a new node find peers to download the blockchain from when they don’t know any peers to connect to, read more here.

  If a transaction is sucessfully hashed and published, how does it reach all nodes so that nobody will work on an already added transaction because he think its not finished yet? Ii think in some businesses its like on the wall street to fight about milliseconds.

The FIBRE network allows miners to have exceptional connectivity, we can see the success of this in the low orphan block rate on the network.


Security within a deleting blockchain model

Your system is pretty easy to implement. The major reason why Bitcoin nodes don't delete old blocks is that old transactions are needed to tell if new blocks are valid. But if the validity of new blocks doesn't depend on old blocks, than the contents of those blocks can be deleted without consequences.
You mention the problem of having a node on the network pretend that an old block is new. Bitcoin solves this problem in three ways:
Separate block header and block contents; keep block header forever
Bitcoin block headers are 80 bytes. They look like this:
<4 byte version> <32 byte hash of previous block header>
<32 byte hash of the block contents>  <4 byte timestamp>
<4 byte difficulty> <4 byte nonce>

That's small enough to avoid having to delete the block headers, ever, but enough to include a merkle root of what's in the block. You can delete the block, but keep the block header around. The difficulty field is necessary because Bitcoin difficulty can vary. The 4 byte nonce is added to make mining easier.
Record timestamp in block header
The timestamp is recorded in the block header, and the Bitcoin client rejects any block headers that are too far into the future or the past.
Record previous block in block header
Bitcoin includes the hash of the previous block header in the block header, which means that you can't take a previous set of block headers and pretend that they're new.
For example, if you've got these block headers:
A>B>C>D>E

You can't take C and append it to E, because other nodes will notice the mismatch between E and C's parent, B.


Mining Bitcoin- Simple Example for transparency

Initially miners get their work directly from other peers on the network.  The peer to peer network is publishing transactions constantly.  It is through the process of mining that these transactions are distributed to the entire network.  The tool that you need to help confirm transactions on the network is a mining application.  Some examples are cgminer, bfgminer etc. If you are interested in solo mining and contributing to the network I do urge you to understand difficulty and the formula used to generate a block and why you are very unlikely to ever generate a block of Bitcoin thus confirming the transactions that your node has seen on the network (unless you are mining with many ASIC's and have several Tera-Hashes per second).  As you requested I will not discuss profitability only the probability of this occurring.

From another thread I will reference an equation for how frequently a Bitcoin can be generated with a given hashing power:
Current difficulty = 908,350,862
Hashing power(based upon mining hardware) = 1000/Mhs or 1/Ghs
We will be solving for the approximate amount of time that it will take (on average to generate 1 block of BTC)

By solving for time we get roughly every 1083704 hours ~= 45154 days ~= 6450 weeks ~= 124 years.  Sadly we know that the difficulty is continuing to grow exponentially and it gets recalculated every 14 days or so thus making the average time to generate a block increase.  That being said if you would like to solo mine this is how you would do it.

Simply by launching either bitcoind or bitcoin-qt in server mode the application is ready to accept work from your mining application.  You can then direct your mining application to obtain work from this service via IP (generally on port 8333) Mining pools run an application server such as a stratum or http service that helps to calculate how much work is accepted from each miner if you do not have such an application running you will not obtain statistics from the Bitcoin service unless a block is generated by your miner.


Irrespective of bullish or bearish outlook, there are two attitudes a trader can have in the market: active or passive.

Limit orders and stop orders are "passive" trades because they don't move market price. These types of orders are offers to buy or sell bitcoin at a certain price. Passive orders are placed in the exchange order book and remain waiting there until cancelled (by the trader) or consumed by another trader.

Market orders are "active" trades because they consume limit and stop orders in the order book. A market order is executed immediately and moves market price ("last" price) to the level of the last order it consumes. Market orders are not shown in the passive order book, instead they are shown in the trade history column to indicate market activity

Example

Three traders: A, B and C. Market price is at $1,200.

A wants to sell 1 BTC at $1,201 and places a limit sell order in the order book and waits.

B wants to sell 0.5 BTC at $1,202 and also places a limit sell order and waits.

C wants to buy 1.4 BTC as soon as possible at any price near market price. Because C doesn't want to wait, C executes a market order for 1.4 BTC. It consumes A's order for 1 BTC and consumes 0.4 BTC of B's order at $1,202.

After execution of C's buy market order:

last price moves to $1,202
C has bought 1.4 BTC
A has sold 1 BTC
B has sold 0.4 BTC

C's market order for 1.4 BTC is entered in the trade history as the latest buy.

A's order is removed from the order book since it has been "filled".

The remaining (unconsumed) 0.1 BTC of B's "partially filled" limit sell order remains in the order book until another buyer consumes it, or until B cancels the order.

Summary

Traders who intend to buy or sell at specific price levels place their offers to buy/sell in the order book as passive orders. Active buyers and sellers consume passive orders via immediate market orders. Market orders move price and are entered in the exchange's trade history.

"Market size" is the total of all passive orders waiting in the order book. As traders place and cancel passive orders, market size changes.

"Trade volume" is the total of all active trades (market orders as reflected in the trade history) for a particular period of time.


Well that is simply bad luck. It can happen if the miner uses multiple Bitcoin nodes to handle the getwork or stratum requests. In the case of GHash.io my guess is that they either have so many resources that a single nodes cannot handle all the work to keep them working, so they created multiple nodes and distributed the resources on them.

Another reason might be that they have multiple locations, and in order to keep latency low, they have local nodes feeding work to the resources. This scenario would fit pools like btcguild.

While certainly annoying, it is not really anything you can do against it, if they'd known from the other block from their own network they would simply have dropped it and we wouldn't have known about it.


How exactly does bitcoin code change happen in a decentralized system

I have long been under the assumption that bitcoin was just a "protocol" or a "contract“. Different nodes run their own implementation, on different hardwares. Some are efficient, some not, and they have to agree to the bitcoin protocol to function in this ecosystem.

That's correct. There are dozens of implementations of nodes, wallets, and various other pieces of software that speak the P2P protocol.
There are optional features, and new things that get added to the protocol, but these are almost exclusively done in a compatible way: negotiated between peers that support them, and falling back to older alternatives between peers that don't.
Part of this is negotiated through the protocol version, which used to be just the version number of the Bitcoin client, but since Dec 2011 these are separate.
Most Bitcoin protocol implementations these days are compatible back as far as the Bitcoin 0.2.10 release (from June 2010, a time when there was just a single implementation), when checksums were added to the protocol. Using a protocol adaptor (a node that speaks both the old and new version), software written today can even speak with the very first code (Bitcoin 0.1.0, January 2009).

But I found out there is actually a centralized bitcoin code base that's frequently updated!

Bitcoin Core is a project that maintains an implementation that is an evolution of the original codebase by Satoshi. It is often called a reference implementation, and a focal point for development. However, it is not the only implementation, not even the only fully validating node implementation, and it does not decide what the protocol rules are (though there are some optional protocol features that are only implemented in Bitcoin Core).

How do they even ensure that every nodes update to the newest code?

They don't; strictly speaking there is no need. The protocol rules and rules about which blocks are valid don't really change. There are good reasons to update (e.g. security improvements, speed improvements, new features), but that's anyone's individual choice. Bitcoin Core very deliberately does not have an auto-update feature, as that is deemed to give too much control over the network by the client's maintainers.

And how do they ensure that the code compiles for every single hardware?

Extensive continuous integration testing. All code changes are tested on a variety of platforms, including Windows, MacOS, Linux (for ARM32, ARM64, x86_64, RISC-V, POWER), and since recently also Android. More systems may work, but are not guaranteed to.

Or, I guess most imporantly, were there any backward incompatible changes in the history that require every node to update?

Yes, but they are very rare (and ancient history by now).
Bitcoin 0.2.9 (protocol version 209) introduced checksums in every protocol message. Initially these were negotiated, like very other protocol feature. However, Bitcoin 0.2.10 (June 2010), the feature was implemented so that as of February 2012, the checksum would become mandatory - and included in the messages used for negotiating versions themselves. This meant that by February 2012, node software before 0.2.9 stopped working.
Another source of incompatibility is the network's consensus rules. These are the rules that determine which transactions and blocks are valid, and the most complicated part of the system. The entire network has to effectively implement them identically, or there is a risk that the network splits into separate currencies. There are many questions on this site on this topic, if you want more information, but the short summary is that almost all changes to these rules are now done as so-called "soft forks": rules that only tighten which blocks are valid, which implies the network is safe from splits as long as a majority of the hashrate also enforces these rules. Other changes are called hard forks, and apart from an debatable one in 2013 (due to a change in the database layer, see BIP 50), there have not been any of these since August 2010. For more information, see https://blog.bitmex.com/bitcoins-consensus-forks/.
Disclaimer: I'm a contributor and maintainer for Bitcoin Core, and have been involved in some of the changes mentioned. The protocol 209 checksum change was before my time.


Is it possible to use Bitcoins from an old or changed adress confirmed on the blockchain?

You are likely being scammed.

An address remains valid and usable forever as long as its private key is accessible. If any service is generating and deleting private keys, it is run by completely incompetent people and should not be used.

The "Delay of network" argument is equally baseless - if they have received the coins, they are in sync with the network, and can spend those coins trivially.

Do not send these people any more money. Essentially all mining services short of buying and operating your own mining hardware are scams.


Bitcoin public key — why do we have a compressed and uncompressed version?

My understanding is that the public key can start with 04 if it's uncompressed, or 02(x-coor) or 03(y-coor) if it's compressed.

That's not exactly right. There are two encodings:

Uncompressed encoding: (0x04, X coordinate, Y coordinate)
Compressed encoding:

(0x02, X coordinate) if Y is even
(0x03, X coordinate) if Y is odd

What's the purpose of this?

And if this is indeed the case, why would you want a compressed public key?

If you're asking about intent, you need to be aware that these standards for encoding aren't specific to Bitcoin. They're defined by SEC1, and adopted by many other systems. Presumably their goal for having both is:

Compressed encoding is smaller, and thus desirable when space/bandwidth considerations matter more.
Uncompressed encoding is slightly more efficient to work with, so if space/bandwidth isn't a concern it's faster to choose this.

If Bitcoin was designed today, it would probably only have compressed keys.

Greater entropy as we can have a larger public key if it's uncompressed?

Wouldn't it be safer to use the larger one?

No, there is a one-to-one conversion between compressed and uncompressed keys, in both direction. There is no difference in entropy (both have 256 bits of entropy) and thus equally secure.


How do I recover bch sent to external btc address?

Most likely, you can't.

I am going to assume this happened recently.  If you recently sent BCH to a BTC address, then most likely it was sent to a segwit enabled address. If that is the case, they are probably gone and locked up forever.

IF you sent them to a legacy address, they will show up in the wallet. BUT, there may be more problems.  If the client that contains this wallet is segwit enabled, you CAN'T and should not attempt to just send them back without first disabling segwit.

The best scenario, is they were sent to a legacy wallet address on a legacy client. i,e. no salt, no segwit, etc.  Then you may recover them.

No matter what the case, it is worth at least trying.  You can try with one of these. https://bch.btc.com/docs/help/bch_segwit_recovery

Good luck!


re : minimum sizes of transactions and blocks

That limit (which is different today) pertains to node policy and transaction standardness. It is important to keep in mind that something that is non-standard is not necessarily invalid. Validity and standardness are two different things, although standardness is a subset of validity.

A transaction smaller than the standardness minimum can still be valid. It will just be considered non-standard and not be accepted by nodes following that particular policy (which is most nodes as that is part of Bitcoin Core). The limit today is 82 bytes which is the smallest size a standard transaction can be.

  If relevant to minimal transaction size, my question then would be, was this standard introduced after or before the answer provided.

This policy rule was introduced in 2010, long before the referenced question and answer. Furthermore, that wiki page was written containing that information in 2011. Also note that the wiki page is outdated as the rule in question is incorrect.

  Also, did the answer provider care about distinguishing between valid transactions and invalid transactions ?

The answerer (me) did. The smallest valid transaction is as I state in that answer. Such a transaction will be considered non-standard and will not be relayed per the policy rule, but if a miner were to include such a transaction in a block, it would be accepted by nodes as being completely valid.


If more than one coin did the "mini-blockchain" proposal, would that make the weaker coin vulnerable?

While I didn't see it addressed explicitly in the paper, the attack could be defeated by requiring a competing blockchain to have common ancestry in the proof-chain in order for it to be considered.

Out of the proposed triplet account-tree, mini-blockchain, and proof-chain, the proof-chain has by far the least memory requirement with only 512 bit (64 byte) per element. If applied to a coin with a blocktime of 1 minute, one year worth of proof-chain would only have 32 megabytes (containing 525600 proofhashes), while one year worth of proof-chain should be sufficient to allow for any valid competing chains.

The above assumes of course that each of the triplet does what it should be doing. I had one follow-up question though, posted here: Mini-Blockchain proposal: How is the proof-chain secured against injections?


What should you set as rpcpassword and rpcusername in BitCoin?

I suggest you don't use rpcuser and password if you don't need to. If you don't set them, Bitcoin Core will use a cookie in your .bitcoin directory as a mean to identify you.

Besides rpcuser and rpcpassword are deprecated now, you're supposed to use this python script to generate a password and copy the output in your config file like this : rpcauth=[user]:[long random string]

But once again, I suggest you don't use it if you don't need it.

As for the alice username, it's just a common placeholder name originally used in cryptography, "Alice" and "Bob" are the two parties that try to communicate, Eve is the passive eavedropper that tries to snoop on their private conversation and Mallory is the active attacker that tampers messages or disrupts communication. I think there's no harm using it as a rpcuser name though.


I've deleted my wallet and never backed up my files. How can I recover my coins?

First, don't panic!

Second, make an image backup of the wiped drive to a physically different drive.

Third, you maybe able to recover the deleted files with tools such as magic rescue so long as the sectors on your drive that your wallet was wiped from are intact... otherwise you may be out those coins... I've had OK luck with rescuing data off drives for friends but also some failed attempts to because of rewritten blocks corrupting deleted data.

In other words this will cost you in either time or in the coins you've lost. Right now you're in limbo and I would suggest you do a dd backup of your wiped drive and try to use recovery tools on the backed up drive image so that you don't accedentaly wipe the target data off the original drive.

I'll see what I can find in my notes in a few hours on the subject of drive imaging and recovery for ya.

Updates

Here's an edited version of my private notes on data recovery steps that I've used to recently recover a corrupted USB drive that was being used to backup a client's Windows user account files. Note file names did get mangled during the process so be aware that there will be cleanup after this process.

Setup

You'll need second drive with enough free space to house double the total number of bits of the target drive. Or in my case I had to get two drives of greater than 64gigs; one for the backup image and the other to receive recovered files. This is because we are going to be copying every bit off the target drive; even the zeros. In my case discussed here there was only 13~gigs used out of 63'ish but we still had to copy it all.
You'll need a USB or CD bootable Linux distribution. I used Kali Sana for my recovery because it has pretty up to date tools for this job but you might want to hunt for a specifically designed distro. Web search for terms like "USB recovery Linux distro" and you'll likely find a top 10s list of someone's testing results or recommendations; there be choices in flavor so I'll keep this based off my expenses with Kali.
You're going to need to locate the dev file path for your target drive, in this example it's /dev/hda but for you it maybe different. Hint use mount & blkid commands to show drives, their file paths and other info. Once located unmount it so you're normal programs don't write or read from it by accident. For example my target drive was mounted at the following umount command directory path

umount /mnt/usb/damaged

  Repeat above for any mount points associated with
  the target drive to be backed-up. For my revival there
  was two partitions associated with /dev/hda physical
  drive and both had to be unmounted. Also be on the look
  out for swap partitions associated with the target; mine
  didn't but if you roll the next command with any
  of the target drive's mounted you run the risk of a bad
  backup image being made to work from.

Backup command

dd if=/dev/hda bs=4K conv=sync,noerror | tee mybackup.img | md5sum > mybackup.md5

Be very very careful with the above because dd is not forgiving! Also note that the directory path is different than what was used with umount because we're now operating on the target drive a a whole and not a partition within the target drive. Hint, the previously mentioned  mount & blkid commands used to reveal mounted directory paths should have shown the dev related path too.

-if=/dev/sda should be the drive location of the hard-drive you need to recover data from. Don't include any partition numbers as you'll want every bit from start to finish.
bs=4K is the bite count per read/write (I think) and lower values will take longer but be less prone to errors.
conv=sync,noerror are options to keep dd chugging away even if there's a bad sector or two.
| tee mybackup.img redirects (and duplicates with tee) output from dd reading the target drive and saves it to mybackup.img. Note this fine path should not point to the drive your imaging; if you write to the same drive you'll likely wipe bits you want back for good from your drive because right now the addresses/sectors are marked as available for writing that use to contain your data.
| md5sum > mybackup.md5 takes the duplicated output from dd and writes a signature to mybackup.md5 same rules for file placement as the image file too.

Now the above is going to take some time; for the 64~gigs I had to recover I used an RPi board (cheaper on the electric bill) and ran the above in screen for one full night and half a day. The above also isn't going to give you any feedback or process until it's done. In other words, grab a book or watch a season of Firefly to pass the time.

Eventually it'll report the number of records in/out and the time it took in seconds. And we can roll some tools over the backup image instead of on the target drive; this means mistakes can be made and you're just out the time of making another image.

To verify that the backup image you've saved is good you can run the md5 command against the image file and compare against the one generated during backup. Furthermore if really worried you can roll the md5 command against the target drive and compare that all three signatures/fingerprints are equivalent. The following are steps that I used to verify the image I took.

dd if=/dev/hda bs=4K conv=sync,noerror | md5sum > drive.md5
## Above should modified to point to your target drive
## Bellow should point to your backup image
dd if=mybackup.md5 bs=4K conv=sync,noerror | md5sum > image.md5

Use cat to show the contents of each md5 file, they should all match or show the same human unrelated junk. Note for other readers, yes collisions (false matches) can happen but we're not trying to make any collisions so chances are low.

Tips for keeping sanity on next steps

if you've the space then make a backup of your backup because it's safer that way and will save your target drive from any accidents when having to start a whole new dd command ;-) beware of sleepy terminal user input.
if possible unplug/disconnect the target drive or attempt the next block of steps on different hardware operating only on your backup image.
take your time at this point. There's little reason to rush at this point, well unless you liked waiting for the next backup image to complete. Not going to judge if that's what you're into.

Optional, install Windows partition compatibility

## For many Debian/Ubuntu based distributions
sudo apt-get install ntfs-3g
## Kali Sana
sudo apt-get install ntfs-config
## and some Ubuntu flavors
sudo apt-get install ntfsprogs

Using apt-cache policy ntfs-3g, subbing in application name to check, it's possible to see which is available to your system if using apt and a package manager.

Install software for working with drive images

sudo apt-get install kpartx

Install software for working with partitions

sudo apt-get install parted
## Either above or below, 'g' stands for GUI
sudo apt-get install gparted

Install software for data recovery & inspection

sudo apt-get install safecopy magicrescue testdisk testdisk-dbg

Getting documentation

Any of the above can have its manual or help docs printed via the following syntax

man magicrescue
safecopy --help

About kpartx

Using kpartx the backup image can be opened and it's internal partitions can be mapped to the /dev directory for later mounting to a path(s). This bit is better in use cases where corruption or deletions do not need to be recovered from.

## Make some directories for the image partitions to be mounted to
mkdir -p /media/rescue_p1
mkdir -p /media/rescue_p2
## Map image to dev loop paths
kpartx -v -a /media/backup_drive/mybackup.img
## Note the output of above command it will be similar to below
##  but not identical.
mount /dev/mapper/loop0p1 mkdir -p /media/rescue_p1 -o ro
mount /dev/mapper/loop0p2 mkdir -p /media/rescue_p2 -o ro

Note the use of - o ro means read only. Remove it if you wish to do stuff without protection to backups and like loading another backup image.

Files within the drive image should now be available to the same extent as the original target drive, however, because your files where deleted and my client's files where corrupted then there's still more work to do. So let's un-mount for now and install another tool. For now know that you've this power of resurrection unlocked.

unmount /dev/mapper/loop0p1
unmount /dev/mapper/loop0p2
kpartx -d /media/backup_drive/mybackup.img

information gathering

Now some info about the drive image needs to be know for you to make use of the following block

## Take note of Disklable in following output
fdisk -l /media/backup_drive/mybackup.img
## Take note of Partition Table, Type, & File system
##  in following output
parted /media/backup_drive/mybackup.img
## you may have to look for quit (q) command to get back to the terminal.

Now prepared with knowledge about your drive the following blocks can be tried on your backup image

About testdisk

Test disk is a command line, menu driven, application. So be very aware of what context your keyboard input will be read under. To test disk recover any files we should first cd  to a directory safe for it to dump in to. For my recovery I mounted the second drive I had and changed directories to it as shown

mkdir -p /media/salvaged/testdisk
## mount recovery drive partition to above, then cd
cd /media/salvaged/testdisk
## start testdisk against image file
testdisk /media/backup_drive/mybackup.img
## Choose Analyse & Deeper-scan to go deeper
## Use bundled photorec program to try and recover deleted our corrupted files
photorec /media/backup_drive/mybackup.img

After using the above two recovery tools, the results can be reviewed using logs saved to your current working directory. Here's the command I ran

ls -hal /media/salvaged/testdisk | less -R5
## use letter q on keyboard to quit, arrow keys to
## move up and down though output in five row chunks
## and page keys to move though output based on
## the entire screen hight.

About safecopy

The safecopy tool can be used to read drives even when blocks within go bad. Supper useful if you run into a situation where a drive is reporting health issues or similar errors or into situations where partitions where messed with. It saves image files kinda like what we did with dd but unlike dd it's able to really dig into sectors marked as bad.

## Copy target drive source, bad block marks are listed in
## stage1.badblocks output file in your terminal's
## current working directory. They'll come in handy in the
## next steps.
safecopy --stage1 /dev/hda stage_one.img
## Attempt to read bad blocks marked in
## stage1.badblocks with no repeats marking ends
## of bad areas in stage2.badblocks
safecopy --stage2 /dev/hda stage_two.img
## Give no heed to bad blocks and attempt to copy
## everything. Note this next one will retry forever on
## every uncooperative block so it may take forever
## or just a ridiculously long time. Additionally if your
## target drive is a platter style then if there are problems
## with the mechanics of the drive this may cause
## increased ware and tare.
safecopy --stage3 /dev/hda stage_three.img

Next try any of the recovery tools already suggested to try and recover lost data. Even if these backups still don't have your data there are likely other tools you can try.

While there's still a chance that you've lost your coins, such as if a new file was written over it, the above steps should increase your chances at recovery. Try searching for terms like forensic drive imaging and similar to find even hope of recovering data from that state. Last but not least there maybe a place in your area that can open up the drive (it's platter style) and use specific tools for literally imaging the data off it; mom & pop tech shops and state level law enforcement are two good places to chat-up for suggestions on where they send out drives for full revival. However, that route will cost in time and in money so reserve this as last resort.

Hopefully the first image is the only one needed and you get your coins back without issue. In either case save these notes somewhere so that you can impress a luckier soul with your wizardry.


Do you start from the LAST NONCE to find the correct HASH to solve Hash Puzzle in Bitcoin Mining?

The for-loop you describe is for a given block only.

So yes, when mining the next block at the next block-height, the nonce can be reset to zero, because the the header hash pre-image is now a new block template (new transactions, new header, potentially new difficulty). A zero nonce will not hash to the same header hash as the previous block with the same nonce, since the rest of the pre-image has changed.

Also, note that the nonce field no longer provides sufficient range for the difficulty on mainnet, meaning the for-loop can potentially complete without ever finding a valid header hash. In this case coinbase input script data can be iterated to "expand" the nonce-range.


You can either wait until the synchronization is finished (at which point there will be quite a decent amount of storage space used by Bitcoin Core) or you uninstall Bitcoin Core if you don't want to synchronize the entire blockchain and use an SPV client instead.

Have a look at this table. It shows you how long it will take to get a certain wallet up and running and how much storage space it will need.


You can limit CPU (even per core) usage per process. Doing so would keep your CPU cycles low and wouldn't cause all that trouble to your computer.

The best way to do this is to set soft limits directly to your O/S, as described here.

A freeware that also works is: cpulimit, although I would strongly suggest you tune you real-time process management directly from your console, as described above.


I suppose an application means a cryptocurrency (btc, eth, etc.).

This is usually, but not always, the case - for instance, the Ethereum application on the ledger device handles Ethereum, Ethereum Classic, and many other chains that are ethereum forks.

  Is there a private key for each application or is it a single private key for all applications ?

Ledgers use BIP 32/39/44 to derive keys from a single root key, expose that root key as seed words for ease of backup, and follow a common convention for deciding which coin will derive which subkeys from the root.

Each ledger application accepts a derivation path as part of its usage. This path specified how to derive the subkey(s) required from the root key. The device will then derive them and sign the transaction, without exposing the keys to the controlling computer.


Lightning: Why would Bitcoin Network Accept a Breach Remedy?

You are right. If the dishonest party publishes an outdated commitment transaction it is most likely be accepted by the Bitcoin network.

The key trick is that the old state has an output script that gives the other party the opportunity to spend all outputs (even the one that was supposed to belong to the dishonest party) with the so called breach remedy transaction. This mechanism works via a time lock in one output of the commitment transaction and is called a Revocable sequence maturity contract (RSMC)

So if Alice and Bob have a channel with 5 mBTC for Alice and 7 mBTC for Bob. But Alice decides to publish an old commitment transaction in which Alice has 9 mBTC the outputs of that tx look like this :

Bob can immediately spend 3 mBTC
anyone with a Revocarion secret can immediately spend 9 mBTC
alice can spend 9mBTC after a timelock of for example 144 blocks.

The breach remedy transaction is the transaction spending the revocable output. So it is not an alternative to the fraudulent commitment transaction but rather a guaranteed way to spend the output of the commitment transaction that is supposed to belong to the dishonest person. It is guaranteed as the timelock prevents the dishonest person from spending their output.


How can I mine Monero or other altcoins using Azure Cloud Services?

Sure - you can run cpuminer-multi on Azure or AWS, and it will CPU mine. You will need to find a pool to mine with.

Alternatively, if you want to solo mine, then you merely need to run a full Monero node, and from within bitmonerod you use the start_mining command. Details on the options you can pass to that command are available via the help command within bitmonerod.


Bitcoin full node running on Synology not visible to network

That is the block count of testnet: https://live.blockcypher.com/btc-testnet/. The Docker script automatically generates a bitcoin.conf configuration and launches bitcoind. Somehow testnet=1 got set in bitcoin.conf or bitcoind was run with -testnet at the command line.


Does Segwit mean easier government monitoring?

No, that's completely wrong. There is absolutely no anonymity benefit to third-party transaction malleability.

Third-party transaction malleability makes use of a symmetry in ECDSA signatures that allows changing a transaction's id to exactly one alternative id. The alternative signature has been deprecated and non-standard for years, but miners could still confirm a malleated transaction if they chose so. In fact, it's rather simple to convert transactions from one txid to the alternative txid, and this happened recently, when Bitclub mined a few malleated transactions. Besides a few poorly coded websites suffering hiccups, this was largely a non-issue. However, this issue currently delays use-cases that rely on chains of unconfirmed transactions which would be broken by a malleated transaction in the middle of the chain being confirmed.

Transaction malleability is completely irrelevant for tracking, because tracking typically happens after the transaction is confirmed and therefore has already become immutable. Since the connection is made via following from transaction outputs to outputs, there is no hindrance whatsoever due to a malleated transaction.


Why are transactions grouped into blocks? (how are new blocks-to-solve formed)

Why are transactions grouped into blocks when put onto blockchain?

Blocks provide a way for transactions to be committed to the blockchain. They are what allow transactions to become immutable. By grouping transactions into a block, they become protected by the Proof of Work that the miner had to do in order to create the block. This means that in order for anyone to change a transaction, they must also perform the Proof of Work to modify the block too, and all blocks that come after the block a transaction was in.

Lets say we have just put a block on a chain and there are no blocks at the moment that users mine. At that moment how many new blocks will get created for users to mine? Will only one block-to-solve get created, or more of them?

If more blocks will get created (to be mined on), how will the miners distribute themselves on the blocks?

Mining does not work like this. Blocks are not distributed to miners to be worked on.
You can think of minining more like this: each miner creates a block, hashes it, and sees if it is less than the target. If it is not, they throw away the block and make a new one that is slightly different. They do that over and over until a block is found that has a hash that is less than the target. Miners will end up making quadrillions or even quintillions of invalid blocks until they get lucky and make on that is valid. Each block is unique and constructed by the miners themselves.


How to transfer all my funds to another wallet

Yes. Make transactions sending all of your coins from each wallet to one or more addresses in your central wallet. Note that this will require you to pay transaction fees. There is no way to move coins without making a transaction.


The encrypted JSON file likely contains individual private keys, or seed bytes. The first step would be to actually decrypt it, which can be done via openssl:

openssl aes-256-cbc -d -a -in Test-Copaybackup.aes.json -out wallet.txt

Once you have that, looking at the decrypted file should tell you what kind of data you're working with. If you see regular private keys, just import them normally. If you see a mnemonic seed or something similar, you'll need to convert it to keys.


Public Key + Private Key enough to backup?

Knowing your private and public keys is enough to be a backup of that address. If you only have one address all you would have to do is create a new wallet and import that private key.

Why backup the entire wallet.dat then?

Because restoring the wallet.dat saves you the step of importing the keys from the command line. Most people find it easier to backup a file than understand the details of keys and addresses.
Because many users have a lot of addresses. If you have a hundred addresses, restoring one wallet file is quicker than restoring each private key.
Because of change addresses. The default client ends up creating a lot of change addresses automatically. You may think you know your private/public key pair, but if you've conducted some transactions in the standard client it is likely that you also have a bunch of change addresses that you aren't directly aware of and aren't displayed in the GUI.
Because of the address buffer. The standard client keeps a buffer of 100 addresses that it intends to use. This means that even restoring a wallet.dat can sometimes save you even if you don't have an up-to-date backup of your wallet. (Because the transactions/addresses that aren't in your wallet are probably in that buffer of addresses.)

In short, yes, the private/public keypairs are the important thing and if you know them (say by keeping them in a paper wallet or encrypted somewhere) you can recreate your wallet. But there are lots of mistakes you can make (such as forgetting change addresses) if you are manually tracking keys. If you aren't certain what you are doing, you may find backing up the wallet.dat as the easiest approach.


How to estimate optimal fees for transaction in bitcoind?

The other answer is outdated. estimatefee is deprecated.
You should use estimatesmartfee

  Please use estimatesmartfee for more intelligent estimates.
  Estimates the approximate fee per kilobyte needed for a transaction to begin
  confirmation within nblocks blocks. Uses virtual transaction size of transaction
  as defined in BIP 141 (witness data is discounted).

  Arguments:
  1. nblocks     (numeric, required)

Example:

bitcoin-cli estimatesmartfee 6


What are some of the Bitcoin inaccuracies in the CBS Show "The Good Wife"?

Is there a Bitcoin manifesto written by Mr. Nakamoto?

Not really. Satoshi wrote some political stuff, but not much. Mostly he focused on the technical issues. This article is the most political thing Satoshi wrote, and it sounds kind of like a manifesto:
http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source

The line from the show was very unlike anything ever written by Satoshi, though.

  Is it possible to embed a character string in the block chain?

Yes. Anyone can do it. Run strings -n 20 on blk0001.dat and you'll see all of the strings that people have put into the chain.

Notably, the very first Bitcoin block (created by Satoshi) contains this text:

  The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

Also, after The Good Wife someone actually put "Stack is innocent" into the chain. :-)

  Was Bitcoin incorporated?

No. Still isn't.

  Was there a lawyer involved who paid people to write code?

As far as is publicly known, no one was ever paid for Bitcoin coding until after Satoshi left.


What happens when there are no Bitcoins miners anymore

The reward for a miner when it finds a new block is already composed of the subsidy (currently 12.5 BTC) and sum of transaction fees that the miner included into the block. If you look at the blockchain right now, the minimum transaction fee sum of last 3 blocks was 0.5075 BTC. This means that much sooner than before last bitcoins are mined (i.e. reaching 21M cap) the part of the reward from transaction fees will be much greater than the subsidy itself.

After next halving, the subsidy will be 6.25 BTC, then 3.125 BTC, ... and after 7 halvings, the subsidy will be less than 0.1 BTC. And this is going to happen in cca 30 years (while the last bitcoins will be mined in more than 120 years). So much sooner than what you are referring to, the transaction fees will become major dominant part of the reward.

At any point of time, miners will only stop mining if that stop becoming profitable for them. So currently, the reward from a block is about 12.5-14 BTC, which translates roughly to $31k per mined block (at current difficult over 700G). So many different scenarios can play out in 30 years. For example, price per 1 bitcoin can raise from $2.4k to $50k. At that point, if subsidy is 0.1 BTC and sum of transaction fees are just 0.5 BTC, you've got 0.6 BTC total reward, which would translate to $30k. That might be enough if difficulty stays at 700G and prices of electricity stagnate as well, or of hardware mining chip technology advances and provides better cost per hash (very likely to happen), or it might not be enough if electricity cost or difficulty goes up a lot, ...

But every transaction in the ecosystem already has to pay a fee. That will become more and more important over time as the subsidy goes down. That does not mean the cost for end user will go up. It may temporarily, but new scaling solutions are coming and are promising to reduce the need for on-chain transactions for small payments.

Also, the blocks are going to be bigger, which means more transactions will be allowed to a single block, which could mean higher reward for miners from the fees.

So many different scenarios are possible, it is impossible to predict what exactly will happen, but the sole fact of lowering subsidy is not a big problem. To answer your final question - yes, the system still can work as it is now, even after 30 years, and even after all bitcoins are mined.


What factors affect the value of a Bitcoin?

The price for a bitcoin, e.g. for trading with other currencies, derives as usual from the interaction of supply and demand.

The supply of bitcoins increases over time, as determined by the rules in the software which is run by the majority of miners, and increases regularly over time, in decreasing increments.  It can also decrease when people lose access to the private keys which are needed to spend bitcoins.

The demand is driven by a variety of factors:

Bitcoin's utility as a flexible medium of exchange, with low transaction costs, efficient micropayments, little effective regulation, ease of becoming a merchant, pseudonymous accounts, and a worldwide market.
Impediments to the bitcoin economy caused by the friction and inconvenience of using bitcoins due to idiosyncratic software, difficulties obtaining bitcoins, relative lack of people who have bitcoins to spend, the risks of a new experimental currency, lack of understanding, etc.
Demand from new users, derived from recent publicity or new uses.
Speculation as to the future of bitcoins as an investment, over the long-term as well as the short term
Competition from related transactional or investment options such as Paypal, gold, etc.

Update Note that as long at the overall exchange market is relatively small, the market price can be manipulated by sufficiently well-funded investors who can expand the supply of available bitcoins, or increase demand, to meet their own goals.

See also the question and answers at What economics/finance methods and tools can be used to analyze and predict the Bitcoin market?.  (Previously I linked to this, which is now deleted:
What technical indicators might be appropriate for analyzing Bitcoin currency trading? - Personal Finance and Money - Stack Exchange)


1) Yes. You can see some statistics here: http://bitcointicker.co/networkstats/

2) "Normal" will depend on network usage and how much others are paying. So can't give a definite answer there. Let's just say your fee should be competitive if you want your transaction included in reasonable time.

3) Shouldn't matter as all transactions are distributed around the entire network. Most of the miners should "see" your transaction very fast, so the time will depend on whether all the miners or just some of them decided to include your transaction in the block they're working on. Miners are free to have whatever policy they want on what transaction they want to include. Usually it's the highest fee that gets in. If the miner who included yours "wins" the block, your transaction will most likely stick on the blockchain, and after a few more confirmations, definetely.

4) Not exactly sure on this one, but it doesn't make much sense to me. I know miners sometimes decide to mine an empty block. Not sure what is the benefit though, could have something to do with network propagation. Maybe someone else could shine some light on this.


How does a full node decide which outbound peers to have?

Addresses for outbound connections are largely chosen at random. The filtering of addresses comes at the time the addresses are first received by the node before they are added to the address database. This filter checks what services the nodes offer, what network they are on (e.g. IPv4, IPv6, TOR), and the time that they were reported to last be seen. Your node will choose to store addresses that are recent, use a network that your node is connected to, and offers full node services (NODE_NETWORK and NODE_NETWORK_LIMITED). We also avoid nodes that have been recently disconnected or banned.
These addresses are stored in buckets. These buckets are based on /16 for IPv4 and /32 for IPv6. In the future, these buckets will be determined by Autonomous System.
When making outbound connections, nodes are basically chosen at random. Your node will ensure that each outbound node belong to different buckets. If a node is chosen that belongs to a bucket that already has an outbound connection, it is skipped. We also try to choose nodes that we didn't already try to connect to recently unless we have built up a lot of failed connection attempts. Lastly, your node will try connect to nodes using the default port unless there have been a lot of failed connection attempts.
For nodes that you are specifically adding with addnode, these nodes do not take up the standard outbound connection slots. There are an additional 8 addnode connection slots. If these are full, then the node that you are adding will simply wait until one of those nodes disconnects before a connection to it is attempted. So there is no kicking of outbound peers at all.


Is there a Bitcoin gadget for Windows 7?

This is the one I'm using: http://www.domchi.cc/mybitcoins/


Why won't bitcoind work correctly on windows 7?

What are you expecting it to do?  It is a daemon (server) that is waiting for RPC connections on port 8333.

Your bitcoin.conf needs to have configured the rpcuser and rpcpassword.  Then you can access the bitcoin API.

With Bitcoin-Qt version 0.7 and higher, the Debug window gives you access to run a console, so you don't need to run bitcoind if you are just trying to execute some commands interactively.


Of course. QT, the GUI framework Bitcoin Core uses, is one of the most portable GUI frameworks. Sooner or later, Apple Silicon support will be added. Meanwhile you can track the progress here: https://bugreports.qt.io/browse/QTBUG-85279
Then Core developers will do the rest: https://github.com/bitcoin/bitcoin/issues/20371


Ethereum: Cannot use master password on Ethereum wallet

I never managed to solve this particular problem, however I'm now using Mist to great effect.

I found that it was possible to move keystore files from one installation to the new Mist installation and use the passwords I originally created with minimal fuss.

So, my suggestion to anyone having similar problems is:

Backup the keystores: %appdata%\Ethereum\Keystore
Uninstall Alethzero (seriously, I still don't understand what the hell that software even is!)
install the official Mist client, which is beautiful and slick, much easier to understand and can be found here:
https://github.com/ethereum/mist/releases

You should then be able to copy your keystore files back over - each seems to represent an account and will have a password attached. Mist will just pick them up when you start - and you'll need the password for each account when you attempt to use it.

Best of luck.


What's the advantage of making a new node sync from the genesis block?

The great advantage of a new node starting from the genesis block is that the node is able to individually verify every transaction is valid and does not need to trust any other node to know that when done the entire blockchain is valid. The blockchain is verified independently and the integrity of the blockchain is established.

For those not interested in that, it is possible to just run an SPV client which just uses the headers.


What does the FBI think about Bitcoin, in brief?

The most interesting part of the document isn't that long, as half of the pages explain some terminology and how Bitcoin works.

The main points made are:

Bitcoin is the world's first decentralised currency, thus it is hard to audit and control it
Bitcoins can become popular among criminals as they offer a lot of anonymity
Bitcoins can be used to commit money laundering
It is very likely that people wanting to steal Bitcoins will target third-party services (such as exchanges), and users' wallets
It is hard to link user's identity to their Bitcoin address, but can be quite easy when they convert their Bitcoins into a fiat currency

There are also a couple other, smaller points made and it is generally a good read. As a side note, the paper appears to have a small mistake on page 4 - listing Bitcoin's lowest price since the bubble as 4$, whereas it was as low as 2$ at some point.


That's correct. You have no taxes and no need to report them if you have not sold/spent any of the coins in the tax year.

You do need to keep records of your purchases, because when you do come to sell, you'll need to work out the potential gains you've made.

If you do need to work out your gains, you can use https://bitcoin.tax or other capital gains calculators that can work out the total gains from all your selling or spending.


How can I sell bitcoins and transfer the funds to my bank account?

Although you can find a more comprehensive list here on the Bitcoin Wiki, some of the most popular exchanges in the community are:

Coinbase - https://coinbase.com
Bitstamp - https://www.bitstamp.net

You can exchange your bitcoins for US dollars on these websites and have them funded to your bank account.


Who first defined/coined The Double-Spending Problem?

Does there exist a proper academic write up, defining the problem, that predates bitcoin?

Google ngrams shows the phrase being used as early as the 1970s but that is probably not in the context of digital currencies.

The earliest reference I could easily find is in several articles in "Advances in Cryptology - CRYPTO '93"

For example in "Untraceable Off-Line Cash in Wallet with Observers" by Stefan Brands.

Since several articles mention double spending I expect the coinage of this phrase in this context is older than 1993.

However there were no mentions in CRYPTO '92.


How does ASICMINER use the blockchain to record share ownership?

ASICMINER management (generally friedcat on Bitcointalk) keeps records of all ownership of shares in their database. The only way to confirm ownership is either through friedcat's acknowledgment or by receipt of dividend payments. Share owners' bitcoin addresses are tied to their shares for dividend payouts.

If a share owner wants to transfer his ownership to someone else, he must provide friedcat with the new bitcoin address. With auction sales, this is typically done through a third-party escrow service for the safety of both buyer and seller.


What is "difficulty" and how it relates to "target"?

Difficulty is basically a different representation of the target to make it easier for normal humans to understand it.

Difficulty represents how difficult the current target makes it to find a block, relative to how difficult it would be at the highest possible target (highest target=lowest difficulty).  The current difficulty of 6,695,826 means that at a given hash rate, it will, on average, take ~6.6 million times as long to find a valid block as it would at a difficulty of 1, or alternatively, it will take, again on average, ~6.6 million times as many hashes to find a valid block.

Difficulty is the largest possible target (0x00000000FFFF0000000000000000000000000000000000000000000000000000) divided by the current target (as of right now, 0x00000000000002816E0000000000000000000000000000000000000000000000).


Why is this transaction unconfirmed after a few hours?

ETA in 4 blocks (13.24 vMB from tip). Why is ETA in 4 blocks?

Estimation by https://blockstream.info block explorer which is explained here: https://github.com/Blockstream/esplora/issues/262#issuecomment-706230773

What does it mean by 13.24 vMB from tip? What is the tip?

There are 13.24 vMB of transactions between your transaction and tip as shown in the below image from https://mempool.observer

My transaction fee is 27.6 sat/vB which seems to be high enough.

Fee rate above 100 sat/vByte would have been high enough looking at the mempool right now.

Fee rate distribution of all unconfirmed transactions. Source: https://btc.bitaps.com


How much Bitcoin was lost in the Jul. 2011 MyBitcoin site shutdown incident?

According to this speculative thread at bitcointalk.org forums, a minimum of 27,000 BTC (worth $370,000 USD at that time), with a possible maximum of 75,000 BTC, estimated.

Here's a screen cap of the first post in the thread, in case the forum later disappears:


Bitcoin script verification fails after certain time period

This isn't possible with a single bitcoin sript, but your example can be realized quite easily by simply adding one more transaction to the equation:

So the premise is that given an input, it can be spent by either party A or party B. The restriction is that party B must spend it within the 1st 30 mins else after that A must spend it.

Party A and party B cooperate to create a 1-of-2 multisig address, and then have coins sent to it
After 30 minutes, party A will create a second transaction which pays the coins to an address that only party A controls
Now party A can spend the coins, party B cannot

This depends on party A publishing the second transaction, but that step could also be automated and happen during the initial setup of the multisig address. The second transaction could even have a timelock added, such that it could not be published early (though party A can otherwise spend the coins at any time, so this seems unnecessary).
Otherwise, as mentioned in the comments, this sort of construction isn't possible using bitcoin script alone.


This post on bitcointalk is a good starting point.

The basic idea is to:

fork an existing coin
Customize some values (block reward, block time, hash algorithm, etc.)
Boot strap the coin by mining then encoding some checkpoints.


I've been hunting for this information myself, and had to dig to the bitcoin source code to find the answer - couldn't find it anywhere else.

There is a hardcoded logic in bitcoin for P2SH validation:

The stack is backed up between the steps 2 and 3 (generally - between scriptSig and scriptPubKey execution).

After both scripts are executed and verified, the stack is restored from the earlier backup, the redeem script is popped from the stack, deserialized, executed and verified. This is done by internal bitcoin code, not by any script.

Corresponding source code:
https://github.com/bitcoin/bitcoin/blob/6fef85bfa3cd7f76e83b8b57f9e4acd63eb664ec/src/script/interpreter.cpp

Stack is backed up at 1493, and restored at 1529, where all the magic begins.


Is there a reason to why Bitcoin Core does not implement BIP39?

BIP 39 is not in Bitcoin Core largely for implementation reasons and because BIP 39 is not as secure as it could be.

The structure of Bitcoin Core's wallet doesn't really allow for BIP 39 to be implemented. The current structure doesn't allow for 512 bit seeds as BIP 39 specifies, and adding it would require some significant changes to the wallet code. Implementing BIP 39 would also require implementation of PBKDF2, although that isn't very hard.

Also, more generally, many Bitcoin Core contributors don't consider BIP 39 to be secure. It uses PBKDF2 which is generally regarded to be a fairly weak KDF so it isn't considered to be good for the secure storage of all of your Bitcoin. Some software (such as Electrum) used BIP 39 in the past but have switched to using their own mnemonic algorithm because of this weakness in BIP 39.

BIP 39 mnemonics have some other issues as well such as version numbering (or rather lack of) and the use of a fixed wordlist. Electrum has documented their reasons for why they don't support BIP 39, and those reasons are the same for Bitcoin Core.


Bitcoin Core 0.13 How many addresses it can **effectively** manage?

Try it yourself. In Tools, Debug Console, try getnewaddress. Create as many as you want. See if your wallet performance changes. wallet.dat size will grow, but I can't 4MB vs 32MB has made much of a difference.

DASH wallet when it generates 1,000 addresses at a time for its PrivateSend feature, I can't notice any difference in performance.

"Effectively" manage is really seeking an opinion where the system components the node is running on will tell you what it can handle "effectively".


It's pretty simple, to do this conversion all you need to do is:

decode the address using base58check
change the first byte from 0x32 to 0x5
encode using base58check


Unfortunately, the information presented on Bitcoin Wiki is misleading. All I had to do is to call getblocktemplate with
{
  rules: ["segwit"]
}

JSON object (it happened to be crucial to pass exactly a JSON object, not a string). And for the work completion all I needed to do is to send submitblock request.
Hope it helps someone who's also struggling to find any info about solo mining with
Bitcoin RPC.


How can I code a Bitcoin JSON-RPC "getwork" request in Java?

The JSON-RPC protocol is very simple.  You POST to the mining pool (or the bitcoind client):

{"method": "getwork", "params": [], "id": "anything"}

and get back:

{"result": {"data": "hex bytes....", "target": "hex bytes...", ...}, ... }

You just need the first 80 bytes from result.data - you change the last 4 bytes (nonce) and compute the hashes.  Then, when you find a hash that is less than "target" (generally a hash with the high order 32 bits equal to zero), you call getwork again to report your hash (and earn a share in the pool):

{"method": "getwork", "params": ["hex-header"], "id": "anything"}

There a bunch on wonky byte-order encoding in the standard getwork call.  You'll generally want to reverse the bytes is each long integer (4 bytes) before hashing it, and do the same before reporting your found block back to the pool.  See the sample pyminer for a simple reference implementation of a miner (in python). Inside the Miner.work() function is where the magic happens. The work function takes two parameters: datastr, this is the value stored inside result.data and targetstr this is the value stored inside result.target.

One other thing - most pools require that you use Basic Authentication when you POST, so you'll need to include your username and password in the header of your request.


How do i can track all my own transactions in ripple.Whether any user is submitting or withdrawing ripple

If you want to use an api, then there are few methods you could use as:

Get Account Transaction History

Get Account Payments

Get Transaction By Account And Sequence

Also, you could use Ripple accounts explorer to check your account history with user interface.


Withdrawal transaction made 8 hours ago still has not had any confirmations

That transaction is 90 KB in size; presumably the exchange is aggregating deposit transactions from many customers.  And its fee is about 1.3 satoshis per byte.  As you can see here, there are currently lots of outstanding transactions offering a higher fee rate; as such, a miner would likely prefer to confirm 90 KB worth of smaller and more lucrative transactions, rather than this one.

The output address type doesn't have any direct effect on confirmation time or miner preference, as far as I know.

The size of the mempool in MB is not a particularly useful statistic in estimating confirmation time (until it gets below the block size, at which point you would roughly expect that the next block will confirm everything).  Transactions don't get confirmed first-come-first-served; a low-fee transaction can languish indefinitely as long as more higher-fee transactions continue to arrive and be given priority.

Note that as a customer, this is not your problem.  Your job was done once your deposit transaction was confirmed, and the exchange should have credited your account at that point.   What they do with the money after that is solely their concern.  It's quite possible that they've intentionally lowballed the fee.  If a lull in transactions occurs sometime soon, maybe they get lucky and it confirms at this low fee.  Maybe they don't care whether this happens anytime soon; after all, it's probably just money moving around inside their organization.  If at some point it becomes more urgent, they can offer a higher fee (e.g. using RBF or CPFP).  But none of that is any concern of yours.


How can get Bitcoin client API account() name

From the API page that you linked:

getaccount <bitcoinaddress> Returns the account associated with the given address.


Who would benefit from Taproot deployment?

Taproot benefits everyone who uses it, but it has the most benefit to those who use complex scripts and multisigs. Since that group is a small portion of users of Bitcoin, that may be why some people are saying it is useful only to that small part of the population. However I would not characterize such statements as meaning Taproot is not useful to anyone else, nor interpret those statements as meaning Taproot is detrimental to anyone else.
The vast majority of users use single key addresses. These are the typical P2PKH and P2WPKH addresses. At this point, we are almost as simple as it gets for single key things - provide a signature and a pubkey and that's it. While Taproot brings improvements to single key things in the form of Schnorr signatures and a pay to pubkey scheme, the vast majority of users are not going to experience a whole lot of difference between P2WPKH and P2TR. The user experience is going to be almost the same - you click on a button to get a new address, people send money to that address, and then you can click on another button to send Bitcoin elsewhere. The only tangible difference is that it will be slightly cheaper to spend P2TR outputs and slightly more expensive to send to P2TR outputs. Even then, the difference is not that big so many users may not even notice it.
However for users who make multisigs or complex scripts, Taproot is a huge boon. All those multisigs and complex scripts can be really compressed down when spending. Instead of having to put large scripts into the blockchain, in the typical "everyone agrees" case, spending a Taproot output will make the transaction way smaller which really saves on fees. It is a significant improvement to those workflows because much less money is spent on transaction fees. There is also the added benefit that such transactions look just like single key transactions which is good for privacy. For those who have very large multisigs or very large scripts, the difference in fees will be noticed.
Even when it comes to using Taproot script paths, only the used parts are revealed in the transaction. This both reduces the transaction size and increases privacy by not revealing unused script paths. This is also a huge improvement.
Thus Taproot provides most of its benefits to users who make multisigs or complex scripts. This is a small part of the users of Bitcoin. It is not incorrect that Taproot is directed towards improving the experience of scripts and multisig. And since not many people use scripts and multisig, it is not incorrect to say that Taproot only affects a small part of the population.
However this does not mean that we shouldn't want Taproot. This doesn't mean that Taproot is bad. And people who state these things are not necessarily being misleading, lying, or don't want Taproot. They are stating what Taproot is going to be used for and the people that it provides the most benefit to.
In the context of the discussions I believe you are referring to, the argument is not that we shouldn't get Taproot, but rather that it isn't so important that we need to have it ASAP. Taproot provides a benefit to all of the people who will use it, but for most users, this benefit is not significant. We don't need it right now so there is no need to have so much urgency in trying to get Taproot. We want Taproot and it would be nice to have it now, but we shouldn't let the feeling of "I want it now" to get in the way of developing a safe way to activate it that can also be used in future soft forks.


How can I send thousands of small amounts (10'000 sat.) to bitcoin wallets without paying to much fees?

Thanks for all the visitors, which have thought about that.
I found now the solution for that problem. I use the blockchain.info API. There is an option to send to many addresses at the same time.
https://github.com/blockchain/api-v1-client-python/blob/master/docs/wallet.md


What you're describing is called structuring, and it's illegal in the United States. It is probably illegal in other countries, too.


Bitcoin library vs script to develop application

Before you take on trying to use Script I recommend doing whatever you can with an existing API. I've used Blockchain.info's which has worked well.

Here's another API package for Java that might work for you https://github.com/blockchain/api-v1-client-java

Once you have gotten comfortable with the abstracted interface, and have a need to go lower level, go for it. That being said, you may find Blockchain to propagate transactions more quickly than your own server since it has many many peers.


So which is it? Does "hard fork" describe a condition of the network, or a software update?

Either is acceptable. You can say that version so-and-so causes a fork, and you can say that the network is currently forked.

  Was the March 2013 fork a hardfork?

It depends on your definition. The March 2013 incident initially appeared to be a hard-fork, but a later investigation showed that it was possible to trigger the issue even when all nodes were running the same version.

Quoting from BIP50:

  This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page).

However, it was a hardfork in the sense that newer clients would create and validate blocks that an older client would not see as valid.


Answer to the title question

Can I receive bitcoin to a cold storage device without an exchange being involved?

Yes, you can.

Do I have to use for example "coinbase" or another exchange to receive bitcoin to a "Ledger" device?

No, there is no requirement of using any centralized exchange. If you want to acquire bitcoin you can do it in P2P fashion. You can buy it on P2P exchange (bisq, hodlhodl) or at your local bitcoin community meetings. Or you can ask friend who already have bitcoin to either gift you some or sell it to you. Or you can earn it. So no, you don't have to use exchange, but it's the most frictionless option for most people, due to KYC process that you have to go through, stamping your identity on the coins you want to acquire.
It doesn't matter if the address is in cold storage or "hot" storage to be able to receive bitcoin into it. Addresses don't have to be "hosted" to be able to receive bitcoin.


The two are entirely uncorrelated.
There's no requirement for a miner to run a fully validating node at all.


Getwork - can the miner increment timestamp?

Yes, the miner can increment the time stamp by a limited amount, but only if the pool advertises X-Roll-NTime as a feature. DiabloMiner and CGMiner both support this.

See the official spec for more information.


Block size depending on transaction count

Is the estimate above correct, or am I missing something?

Your estimations seem (more or less) fine.

  If it's correct, what are the impacts of switching from a 1 MiB block size to 586 MiB?

The two major ones I see are:

large blocks make full nodes more difficult/expensive to operate (i.e. requires better specs and better upload/download speeds); thus bad for decentralization as not many people will be able to run a full node
the blocks will take longer to propagate through the network, thus it increases the chances of orphan blocks and double spends.

For a more detailed list see here.

Note, that these concerns/drawbacks for an increased block size were raised for a 4, 8 or 32MBs increase... a 586MB increase would be way too excessive. And if you keep the parameters similar to bitcoin you would have the same issues in the side chain.


possible to generate privatekey based on private key using bitcore.io?

I think BIP-32 "Hierarchical Deterministic Wallets" (https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) is usefull for you.


Unable to run the Miner using 2Pac BM1384 USB miner

I had a similar problem when I first started with the 2pac. You didn't mention if you are using a Windows or Linux platform, but the solution is similar either way.

Solution: Ensure your CGMiner binary is compiled to support the Gekko 2Pac. It seems your BM1384 2Pac is not being recognized properly by CGMiner.

This output you provided:

"0: AMU GS-10018: | 528.0M / 516.0Mh/s WU: 5.6/m"

...shows that it is being enumerated as an "AMU" (which is usually ASICMINER block erupters ) It should be "GSC" for a GekkoScience device.  That's also why you are seeing the low hash rate and hardware errors.

So, be sure you have a gekko-enabled CGMiner binary, and also ensure your batch file points to that same correct binary. (correct path)

If you need more detailed help, please state whether you are on a Windows or Linux platform.


I was under the impression that even an individual could, if he completes the proof of work first, cause the addition of the block to the blockchain? What am I missing here?

That it could happen that 2 blocks are found at the same time. Which usually causes the network to split into two chains, ( One part of the network is going to build/find a new hash based on block y, and the other part of the network is trying to find a new valid hash based on block X.).

Whoever finds Block Z first creates the longest chain and thus invalidating the shorter one. ( Miners who build on block Y find block Z so now block X ( which is the shortest chain) gets orphaned )= now invalid.

The same principle applies to a 51% attack, since you have majority hashpower you will always (hypothetically) find a valid hash faster then the other chain which has 49% hashpower.

In that case, no individual ( unless the individual owns 51% of the hashpower) is going to be able to "mine" a block/(or rather, - get a block added to the longest/valid chain).

Your title is something else then your question,

  Do multiple miners contribute to mining the same block even if they are not in the same pool

Well, yes, if there's only 1 chain, every miner is going to be building upon that chain, which means they'll all be looking for a block ( or rather a hash) that is going to be valid on that chain ( basically the next block?)

I wouldn't use contribute though, it's not like they share their hashpower, but they do indeed share the same goal. -> Finding a block with a valid hash that is valid on the current chain.


The amounts returned by Bitcoin Core are accurate. They are not actually doubles; they're just output that way for convenience. Bitcoin Core internally uses a int64 and the amounts are satoshis. When outputting for users, the int64 is used and a string formatter just puts a decimal point in the appropriate place. Since it already is exact, you just need to drop the decimal point. The easiest way to do this is to take the output as a string, remove the decimal point, and convert that string to an integer.


How do I handle the risk that my hard disk crash?

Your wallet file contains the keys needed to sign transactions that transfer Bitcoins from your accounts. The system doesn't care who accesses what, it just cares that transactions are signed with the appropriate keys.

Back up your wallet file so you don't lose the keys you need to spend your Bitcoins. But remember, if someone gets their hands on any unencrypted copy of your wallet, they can spend your coins.


How can I check if a bip32 xpub key is valid using python?

The code you linked works for me in Python 3.4, so I'll assume you're looking for something for Python 2.7.

This code is straight from here on GitHub:

import base64, hashlib, collections, struct

def int_to_bytes(int_rep, min_length = 0):
    """convert an unsigned integer to a string of bytes (in big-endian order)
    :param int_rep: a non-negative integer
    :type int_rep: long or int
    :param min_length: the minimum output length
    :type min_length: int
    :return: the raw bytes, zero-padded (at the beginning) if necessary
    :rtype: str
    """
    assert int_rep >= 0
    hex_rep = "{:X}".format(int_rep)
    if len(hex_rep) % 2 == 1:    # The hex decoder below requires
        hex_rep = "0" + hex_rep  # exactly 2 chars per byte.
    return base64.b16decode(hex_rep).rjust(min_length, "\0")

dec_digit_to_base58 = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
base58_digit_to_dec = { b58:dec for dec,b58 in enumerate(dec_digit_to_base58) }

def base58check_to_bytes(base58_rep, expected_size):
    """decode a base58check string to its raw bytes
    :param base58_rep: check-code appended base58-encoded string
    :type base58_rep: str
    :param expected_size: the expected number of decoded bytes (excluding the check code)
    :type expected_size: int
    :return: the base58-decoded bytes
    :rtype: str
    """
    base58_stripped = base58_rep.lstrip("1")

    int_rep = 0
    for base58_digit in base58_stripped:
        int_rep *= 58
        int_rep += base58_digit_to_dec[base58_digit]

    # Convert int to raw bytes
    all_bytes  = int_to_bytes(int_rep, expected_size + 4)

    zero_count = next(zeros for zeros,byte in enumerate(all_bytes) if byte != "\0")
    if len(base58_rep) - len(base58_stripped) != zero_count:
        raise ValueError("prepended zeros mismatch")

    if hashlib.sha256(hashlib.sha256(all_bytes[:-4]).digest()).digest()[:4] != all_bytes[-4:]:
        raise ValueError("base58 check code mismatch")

    return all_bytes[:-4]

def base58check_to_hash160(base58_rep):
    """convert from a base58check address to its hash160 form
    :param base58_rep: check-code appended base58-encoded address
    :type base58_rep: str
    :return: the ripemd160(sha256()) hash of the pubkey/redeemScript, then the version byte
    :rtype: (str, str)
    """
    decoded_bytes = base58check_to_bytes(base58_rep, 1 + 20)
    return decoded_bytes[1:], decoded_bytes[0]

BIP32ExtendedKey = collections.namedtuple("BIP32ExtendedKey",
    "version depth fingerprint child_number chaincode key")
#
def base58check_to_bip32(base58_rep):
    """decode a bip32-serialized extended key from its base58check form
    :param base58_rep: check-code appended base58-encoded bip32 extended key
    :type base58_rep: str
    :return: a namedtuple containing: version depth fingerprint child_number chaincode key
    :rtype: BIP32ExtendedKey
    """
    decoded_bytes = base58check_to_bytes(base58_rep, 4 + 1 + 4 + 4 + 32 + 33)
    return BIP32ExtendedKey(decoded_bytes[0:4],  ord(decoded_bytes[ 4:5]), decoded_bytes[ 5:9],
        struct.unpack(">I", decoded_bytes[9:13])[0], decoded_bytes[13:45], decoded_bytes[45:])

In particular, you'll want to call base58check_to_hash160() to check a "normal" address, or base58check_to_bip32() to check a BIP-32 extended address (an "xpub" or "xprv"). They will either return the results of decoding the address, or raise ValueError if the address is invalid.

It's technically licensed under GPLv2, but if you'd like me (as the original author) to relicense it under something less restrictive for your project, e.g. BSD or MIT, I'd be happy to. Please just let me know in a comment.


Privacy approach for a light-weight wallet

I conducted an extensive research on the topic and to date the lightest weight wallet, that is resistant against network analisys is a full-SPV wallet.
The structure of it is evident and some are already working on it, including me. This wallet would basically sync the headers and only download blocks from the creation of the wallet, and would store them in a pruned manner.


What resources are required for bitcoin mining?

I'm not sure it's worth the bother any more - there's no point at all mining bitcoin with a computer, or even a bunch of graphics cards. It's now done by dedicated mining machines like an Antminer S9 - mining farms have thousands, maybe even tens of thousands of these things in warehouses plugging away at getttibg hashes. You could buy one, join a pool of other people who also have them, and get paid a share of the pools winnings if one member finds a block, based on how much computing power you represent to the pool..

.. but then there's the question of whether your pool will ever find a block, as the only way your machine will return on its investment is if it does, and it's not a sure thing. And maybe the antminer s11 will come along and be 50 TH and the same price as your s9.. and then it makes it a whole lot harder as mining farms get 4x more processing power.. they're much more likely to find a block than you are..

Hmm, so.. look into it some more. The conclusion I came to is that it's just not worth mining bitcoin any more. Maybe some altcoins, but work out how they're best mined and mine them with the best value method

Side pondering: If only satoshi nakamoto had made the work-done something like protein folding, cancer cure calcs, something useful (instead of trying to find a number smaller than another number) all that electricity burnt on this huge distributed computing effort would have had some great benefits


You need to use JSONRPC interface used by bitcoin daemon.
See this: https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)
or specific PHP example: https://en.bitcoin.it/wiki/PHP_developer_intro


Is it worth it to mine while using my laptop for misc. purposes?

It is unlikely you would make any profit CPU mining unless you have free electricity. Even then the potential for shortening the life of your laptop would likely reduce profitability. There are a few altcoins that aim to allow people to mine with a CPU but its unlikely you will make more than a few cents per day.

Mining on the laptop will make the CPU operate at 100% capacity all the time. This will increase the temperature, decrease the battery life and increase the noise of the laptop (fans speed up as it gets hotter). Overall its likely you increase the chance of the laptop breaking as well.


Is there a Bitcoin casino that is willing to collaborate on some economics research?

A lot of gambling games are completely on-chain, you can analyze the blockchain and look for these transactions to get the data you're looking for.