Bitcoin multi-sign and the amount of storage it required

Didn't find the reference of your text... I'll define usage of multisig and length a bit more generally.
With a multisig scheme, you create a "funding" transaction with a redeem script. This redeem script is the hash of the n-of-m multisig identifiers, and the required pub keys. So the funding tx is not bigger than normal tx.

Then spending the multisig, the V_IN structure gets bigger, whereas V_OU remains the same size. Assume a multisig requires n-of-m signatures, and a typical sig looks like this:

48: OP_DATA_0x48:        push hex 48 (decimal 72) bytes on stack
30: OP_SEQUENCE_0x30:    type tag indicating SEQUENCE, begin sigscript
45: OP_LENGTH_0x45:      length of R + S
02: OP_INT_0x02:         type tag INTEGER indicating length
20: OP_LENGTH_0x20:      this is SIG R (32 Bytes)
    4673096ED91CC985:B05F64780BA123E1
    C193FC860B2163DC:B3B5D4F3049F30D2
02: OP_INT_0x02:         type tag INTEGER indicating length
21: OP_LENGTH_0x21:      this is SIG S (33 Bytes)
    00DE2CA5EBBCB5D1:19877AD737930BC5
    7F2356CBAC646405:DC881270CFAE78BF
    1D
01: OP_SIGHASHALL:       terminates ECDSA sig (ASN1-DER structure)

then the first byte already indicating the length of sig (there is comment from me at the top, to a link from Pieter Wuille, explaining length of Sigs to be 71 or 72  Bytes long).  Additionally to the added signatures you have also the redeem script added to the tx, behind the signatures in the V_IN structure. The redeemscript has in a 2-of-3 music the typical structure:
<2><3>
Now it depends, if you use compressed or uncompressed pub keys (33 or 66 Bytes long). This increases your overall length of the tx. Summary for spending funds with a bitcoin tx:

normal tx has 1 sig          (at ~70 Bytes) and 1 pub key  (@ 33 or 66 bytes)
multisig has  n (-of-m) sigs (at ~70 Bytes) and m pub keys (@ 33 or 66 bytes)


The bulk of the work lies in verifying each transaction within the block.  This means that the signatures need to be checked for each transaction input, which requires a lot of CPU processing.  So, one way to improve the verification speed would be to have a hardware-assist for the verification process (such as a specialized ASIC chip).  I don't know if a miner ASIC could be used, but it is an interesting thought.


No, your public key are generated from your private key it cannot be changed.

Private key have one public key and each public key have one adress


How can I get a private key for my watch only adress

I have bitcoins that are stored on watch only address

What are watch-only addresses?

A watch-only address is a public bitcoin addresses you’ve imported into your wallet. This is a cool, useful feature if you want to monitor activity at a particular bitcoin address. You can import any existing bitcoin address.

There is no way to get access to those bitcoins because it's a watch only address. You can only watch it, but you can't do anything else (sending BTC away, exporting the private key, signing something...)


Can I restore old MultiBit wallet with receive address and password?

There is no relationship between the password and the wallet itself.
Without the wallet file the password is of no use to you.


Bitcoind becomes non-responsive over JSON-RPC, have to manually restart all the time

Upgrade to the very latest stable version. We saw alot less memory leakage with .10 on ubuntu
run a cron job to restart it every night around 4:00 am est when there are fewest ransactions. This will cut down on memory leakage
make sure your box has at least 4 gigs of ram and a 2 gig swap partition.
give us some more info here. like linux distro, machine stats and what kind of rpc calls u often do.


Is it safer to use one type of hardware wallet of several?

Personal, I would use multiple wallets just in case some exploit is found in the future. For the more paranoid/safety conscious person, I would also place the hardware wallet in a mini faraday cage, until needed. The reason behind the faraday cage is that electromagnetic radiation of WIRED or even hardwired devices can be picked up from up to 65 feet away; you could turn off the device to combat that possible risk (instead of a mini faraday cage)... Don't take my word for it... here is a short youtube clip of this in action. I would also use only a external hardware wallet which only connects to the internet by Ethernet cable for the same reasons described above. When not in use, simply disconnect it from the internet... this further improves the security of the store private key.


How to transmit fraudulent commitment transaction on lightning channel?

As far as I know the lightning clients that I know of (LND, c-lightning) do not offer this possibility through their API.

So you'd be right to patch the code yourself. For LND, you should have a look at the ForceClose, which is the code that handles unilateral closing of a channel. It uses a CloseTx which it get's from the wire. If you could change that Tx to an earlier one, you would unilaterally close the channel with a fraudulent commitment transaction.

Take a look at the code here: https://github.com/lightningnetwork/lnd/blob/c37ea68ba6e1153478419914d1aa3bfcaf7abe5b/lnwallet/channel.go#L5684


How to resolve Minera cgminer "no devices found" error after installing additional GekkoScience USB-Antsticks?

Ok, any hardware additions to an existing Raspberry Pi * Minera environment or any adjustments to the hardware parameters specified in Minera Settings > Manual-options do indeed require recompiling cgminer.  In order to resolve, proceed with the following:

cd /var/www/minera
sudo nano build_miner.sh
Scroll down to the cgminer config and append -enable-blockerupter so the entire line displays CGMINER_CONFIG="--enable-avalon2 --enable-bflsc --enable-bitforce --enable-bitfury --enable-drillbit --enable-hashfast --enable-icarus --enable-klondike --enable-modminer --enable-blockerupter"
Exit and Write.
Run sudo ./build_miner.sh all
Upon compiling, exit from your host-session, unplug the antsticks, power-cycle the Raspberry Pi and then plug-in antsticks.
Log-in to the Raspberry Pi and sign-in to Minera- you should see verifiable success displayed in the Minera Dashboard > Device Tree.


If a block contains no SegWit transactions, does a miner send an (empty) witness?

BIP141 only requires a commitment to the witness tree to be present when there is at least one segwit transaction (= a transaction that spends a witness output) in the block.

This means that old miners in theory can keep working after segwit activates, as long as they don't include segwit transactions (easy, as they are nonstandard to them) and don't build on top of invalid blocks (harder, as it requires an updated full node).


Does a transaction with a lock time need more time to be confirmed?

Mempools are constantly changing. Each node has its own policy (how much of it to keep, when it gets cleared, which ones stay when a block is found, etc) so it's difficult to know if your transaction is on the network. Generally, you can be sure that a tx with a sufficiently high locktime won't be in the blocks before that locktime, but you are not guaranteed that it will be in the blocks after for a lot of other reasons (insufficient fee and mempool turnover being the two big ones). Generally with these types of transactions, it's recommended that you broadcast after the locktime has passed.


I suspect the source of the problem is this line

HTTP request failed: Protocol "stratum+tcp" not supported or disabled in libcurl

libcurl is a library (developed for the command-line "curl" program that can be used to fetch web-pages).
I suspect the most likely way to fix your problem is by updating MacMiner to the latest version and by checking that your computer also has the latest version of the libcurl library (using whatever package manager is appropriate for your computer)
I'm not familar with MacMiner or slushpool but you may also be able to configure MacMiner to use HTTP instead of STRATUM+TCP?


What is the tradeoff between privacy and implementation complexity of Dandelion (BIP156)

In my view, the main implementation detail to be worked out with Dandelion
is ensuring that there are no new DoS vectors introduced.

In the existing transaction relay model of Bitcoin Core, transactions that
do not make it into a node's mempool -- a proxy for what we expect to be
(eventually) mined -- do not get relayed to other nodes.

In the Dandelion protocol, transactions are relayed (in the stem phase) prior
to acceptance into a node's mempool.  As a result, there are potential DoS
vectors if transactions can be systematically relayed via Dandelion but
ultimately not be accepted to any node's mempool -- this could either introduce
a bandwidth DoS, where the Bitcoin network's bandwidth is used up or wasted
relaying ultimately useless data; or a CPU-exhaustion DoS, if
expensive-to-validate transactions can be relayed without ultimately being
mined.  [In general, the only way attackers "pay" for the network's resources
they consume when relaying is via the transaction fee in their transactions; if
attackers can generate transactions that do not ultimately get mined, then any
side effects of the relay -- such as validation cost and bandwidth used -- can
be achieved for free since those transaction fees are never actually paid,
which typically implies that the network's resources could be utilized entirely
(since it would be costless for an attacker to ramp up usage).]

It turns out that -- in a naive Dandelion implementation -- it would not be
very difficult to generate transactions that would propagate in the stem-phase
but never be accepted to the mempool (at very low cost).  This is largely a
consequence of the complexity around mempool acceptance logic, and seems
particularly unavoidable given the mempool's own anti-DoS limits.

The existing mempool acceptance logic attempts to prevent or limit the effect
of these kinds of DoS attacks.  Transactions don't have their signatures
checked until just before mempool acceptance, after all other transaction
policy rules have been met, to avoid CPU exhaustion attacks.  Preventing
bandwidth attacks is more involved:

transactions are only relayed after being accepted to our own mempool
if our mempool fills up (it is a memory-limited data structure), then we can
evict low feerate transactions to make room for new transactions, but new
transactions are subject to a higher minimum relay fee, designed to offset/pay
the relay fee for transactions which were evicted from the
mempool (and will thus no longer be mined until they relay again).

In short, there's quite a bit of complexity in the mempool acceptance logic to
prevent DoS.  So in my view, the questions around a Dandelion implementation are:

(a) Do we need something as complex as the current mempool logic in order to
avoid DoS vectors with Dandelion, or can we do something simpler?

(b) Are there acceptable modifications to the Dandelion protocol that would
simplify the DoS analysis and allow for a simpler implementation while still
providing a significant privacy boost to the network?  As an example: would it
be acceptable to implement Dandelion in such a way that under DoS scenarios, we
just fall back to the current relay model?

(c) If we don't have simpler solutions that work, is it worth implementing
something akin to the current mempool logic (called a "stempool" in some of the
discussions) in order to introduce Dandelion into Bitcoin Core?  Is the code
complexity worth the privacy benefit that Dandelion would confer?  While
improving privacy on the network is obviously a good thing, the privacy
benefits of Dandelion are limited, so is this the kind of thing that's worth
spending a lot of energy to implement and maintain, or should we focus our
mental energy elsewhere?


What are the chances of someone coming up with a new and simple/out-of-the-box solution for the double-spending problem?

The double-spending problem had been unsolved in decentralized protocols for decades. It seems unlikely that a second (different) solution would suddenly materialize.

It never was a problem in centralized setups, where the central entity would provide a referee function.


Let me describe when a hash function can (not) be calculated efficiently by using ASICs or GPUs:

ASICs: I'm speaking of simple in design, cheap ASICs, because in theory you can design an ASIC for every digital function. Simple ASICs are mostly designed for linear workflows. So they do not use loops (or loops with a hardcoded count), no recursion and a very limited memory requirements and local memory access (payload size is known). So the designer has to know the exact digital formulas. Imagine them as a calculator for mathematics terms (no jumps, every input/output as variable).

GPUs: They are good when it comes to small functions which are executed very often and having medium memory usage. Recursion doesn't work very well and complex, non-parallelized functions aren't handled in an efficient way.

So if you want to design a hash function that doesn't work well on either of them, use a complex function with high random memory access. Also make sure that the hash function does not contain parallel small parts (good for GPUs). Use data dependencies to ensure this. Please consider that it is always possible to build better more expensive ASICs for every function. So it's about cheap ASIC development VS complexity of the hash function.

Explanation of some used therms:

Complexity: doesn't mean theoretical complexity Here it's about the length of the description, the number of function calls / jumps and dynamic behavior (non hardcoded loop counts / memory requirements)
Recursion: a function calls itself one or multiple times, so a stack structure is required.
Data dependency: To calculate the next subresult (e.g. when using loops), you need the previous subresult (e.g. from the last loop body execution).


Are channel ids inherently linked to node ids in the Lightning protocol?

BOLT#7 outlines in the rules for receiving channel_announcement messages, that any previously known channel with differing node_ids, should result in the blacklisting of all associated nodes for both the current message and the previously known channel.

if it has previously received a valid channel_announcement, for the same transaction, in the same block, but for a different node_id_1 or node_id_2:

SHOULD blacklist the previous message's node_id_1 and node_id_2, as well as this node_id_1 and node_id_2 AND forget any channels connected to them.

EDIT:
I suppose a potential way around the above would be to wait over 2 weeks and publish no updates. Since the software will generally forget about nodes or channels which they have not received an update for in two weeks, then when you broadcast a node_announcement for a previous channel under a new node_id, then other network participants will just see it as a new channel.
This would need negotiating with the channel partner to not close it and to re-establish it under a new node_id, which there is currently no means of doing so in the existing spec.


You appear to be using the main Bitcoin network but the transaction you are spending from does not exist on mainnet. It only exists on the test network. You need to restart your node in testnet mode in order for it to work.


I think you are correct that almost all of the cryptocurrencies are derivatives of Bitcoin.  From that fact it would follow that they would all be decentralized.

That being said, there are centralized aspects of cryptocurrencies, including Bitcoin.  For example, online wallets, exchanges and mining pools are all centralized.


Is Bitcoin trading anonymous and untraceable?

Bitcoin transactions are anonymous but traceable. Many wallets and exchanges are now linked to your bank account and ask you to furnish personal details beforehand. Hence, If needed they can trace you easily.

You can avoid it by buying BTC in cash.


How can one estimate the amount of Watts that is consumed by the mining network as a whole?

The majority of mining occuring with CPUs ended in late 2010, though the plurality may not have (i.e., there were more miners using CPUs but most mining was based on GPUs by the end of 2010).  Most who remained using CPUs were pretty much squeezed out during Spring 2011.

GPUs could be purchased at retail, and were about the only technology that mattered from the beginning of 2011 into early-2012, so estimates could presume most hashing during that period was on GPUs.  Efficiency of various GPU models varied widely, but most miners were using roughly similar hardware because of the combination of price, performance and availability.

FPGAs include custom FPGA designs targeted to Bitcoin (e.g., BFL) and others that were offering commercially available off-the-shelf products. Unit shipment numbers are generally not known.    At their peak, FPGAs might have been less than a third of all hashing combined.

ASICs are just now impacting the hashrates, but in a few months will statistically completely displace all GPU and FPGA mining.


The 32-byte double-SHA256 of a transaction (TxID) is not what gets signed.

Future-proofing note: The description herein of transactions, TxID calculation, signatures and signatures scripts, etc. don't apply to segregated witness.

Let's look at an example with a transaction I created earlier. I called:

createrawtransaction '[{"txid":"0c71ea829dfb117442c1c0d0c492725794d890bbcbcd8234b1108d1b1d4ca2e9","vout":1}]' '{"1PkCAVKjPz1YK7iJwT8xTLxBXR1av8dL98":0.004}'

which created an (unsigned) transaction:

0100000001e9a24c1d1b8d10b13482cdcbbb90d894577292c4d0c0c1427411fb9d82ea710c0100000000ffffffff01801a0600000000001976a914f97df8f593e0056d337c274fd81a163f47a17d3788ac00000000

And then I asked bitcoin-rpc to sign the transaction, and received:

0100000001e9a24c1d1b8d10b13482cdcbbb90d894577292c4d0c0c1427411fb9d82ea710c010000006b483045022100d9a5433c1381b39b7e02b0b0f042990e7c16cfea252b05ccfef2e85c2dab2a6f022057c7def782fe3b0d7e5e0eae277d2a5890844da7d72309817a2dac22a6307c6001210390d78cb0c1d34d4417db7e0a9a9f125a689dc29dc2197a01a5f827a20f870f62ffffffff01801a0600000000001976a914f97df8f593e0056d337c274fd81a163f47a17d3788ac00000000

Here is that signed transaction data again, with the signature and related script data bolded:
0100000001e9a24c1d1b8d10b13482cdcbbb90d894577292c4d0c0c1427411fb9d82ea710c010000006b483045022100d9a5433c1381b39b7e02b0b0f042990e7c16cfea252b05ccfef2e85c2dab2a6f022057c7def782fe3b0d7e5e0eae277d2a5890844da7d72309817a2dac22a6307c6001210390d78cb0c1d34d4417db7e0a9a9f125a689dc29dc2197a01a5f827a20f870f62ffffffff01801a0600000000001976a914f97df8f593e0056d337c274fd81a163f47a17d3788ac00000000

If you look at the unsigned transaction, all of the material before and after that bolded section is identical (aside from one padding byte which turned from 0x00 to 0x62), because only one signature (and associated script) was required to successfully spend the input.

Here's a visual diff between the decoded versions of the unsigned transaction (left) and the signed transaction (right):

You'll see that the unsigned transaction has a different txid (because the TxID is the hash of the full, signed transaction). Additionally, you'll see that the unsigned transaction does not have the scriptSig, whereas the signed transaction does. The scriptSig is the bolded inserted section from earlier.

To get back to your question, signing a transaction requires access to the actual transaction (rather than just the hash), because you need to sign the transaction data itself AND insert the signature into the transaction.

On a side-note, since the signature script is part of the data which is hashed to produce the TxID, the signature can actually be modified to still be a valid signature for the data. The signature signs a hash of other portions of the transaction so those can't be altered, but nothing protects the signature script itself from modifications. Any modification to the signature script which doesn't change the functionality of the signature script changes the TxID without invalidating the transaction.

Say you propagate a transaction to the network which sends Bob 2 BTC. Any peer (including block miners) could manipulate the script signature to appear differently while still validly signing the transaction. While this doesn't allow them to redirect those 2 BTC from Bob to anyone else, this modification does change the TxID of the transaction. If someone were waiting for the original TxID to be propagated across the network, it would appear that the transaction never executed if the modified transaction is included into a block instead.


I want to accept bitcoin on my raspberry pi

Any special situation for you to want your wallet IN your rapberry?
A wallet doesn't need to be in a physical machine, actually it can be in a sheet of paper (cold wallet). So if you don't need your server to do anything special with those coins you can just create a paper wallet, and if what you really want is to check if you receive coins, you only have to check from your raspberry your wallet's public key in blockchain to see how many coins has it received.

If you want to create a wallet, you can use vanitygen. Keep the public and private keys in a safe place and you are ready to go. The day you need to move those coins you will need to install bitcoin-qt wherever you want and import your private key to the default wallet created by bitcoin-qt. Once you've done that you can operate with your coins from that place.


How does the blockchain prevent transaction based on outdated note

the blockchain is in essence a distributed ledger

It is more accurate to think of it as a replicated journal for the following reasons:

unlike a distributed database, individual nodes hold a full copy (replica) of the whole data, not some coordinated subset of it.
Ledger and Journal are accounting terms. The Blockchain is a simple list of transactions in approximate chronological order. Just like an accounting journal. There are no accounts and no balances so it is unlike an accounting ledger.

how does systems implemented using blockchains prevent erroneous transaction based on their outdated, and not yet up to date view of the network?

The answer depends on what you mean by an erroneous transaction.
A network node that does not yet have the latest block of the blockchain will reject (or put aside) any transactions that depend on outputs of transactions in the missing block.
So it errs on the side of caution.
It will still reject new transactions that erroneously attempt to spend outputs of older blocks it knows about which have already been spent.
It will still reject new transactions that break any of the rules that don't depend on knowledge of prior transactions.
Bitcoin nodes don't need to know about people or balances because Bitcoin is electronic cash not an electronic bank account. Just as the person who sells you a cup of coffee doesn't care about your name or your bank balance, they only care that the coins you gave them look and feel genuine.


What is the best way to download a "recent" UTXO set snapshot?

Yes, by default bitcoinj downloads full blocks, from the Genesis. Only if you connect a wallet it uses optimizations like checkpoints and filters.

Just downloading the UTXO set (in a trust free way) isn't possible, because the Bitcoin protocol isn't designed for that. You can get UTXOs from block explorers and Electrum servers, but it will be without crypto proof.


ScriptSig does not validate with seemingly valid signature

Signing transaction is a bit more complicated than just signing the hash of unsigned transaction

Look at the explanations here:

Redeeming a raw transaction step by step example required
How to redeem a basic Tx?


Loosing 20 ripples for resetting ledger nano for new seed

Since your Ledger's Ripple address is tied to the seed, if you reset the device and choose a new seed, you will lose those 20 XRP.

If you reset the device and restore the old seed, you can reuse the address.

There is no way to use a new seed and the old Ripple address on a single ledger.


Is it possible to reference an input outpoint more than once in a transaction?

No, this is not possible - once an outpoint is consumed by a transaction, it is considered spent, including within the same transaction.

Your only option here would be to have an intermediary transaction splitting A (or using another input), and then using the two outputs from that as inputs along with SIGHASH_SINGLE | SIGHASH_ANYONECANPAY for your flags.

A -> A1
 \-> A2

A1 -> B
A2 -> C
D  -> E

Note that SIGHASH_SINGLE signs a single output and all of the inputs. If you want someone else to be able to add inputs, you need the ANYONECANPAY flag as well


How is the security of Mastercoin different than that of Bitcoin?

Mastercoin Founder here.

Mastercoin inherits its security model from bitcoin, with some minor changes. To undo a Mastercoin transaction, you'd have to undo the bitcoin transactions containing the Mastercoin transaction data, so we have almost as much security as bitcoin itself. I say "almost" because the order of Mastercoin transactions in a bitcoin block matters, and a block-chain reorg can affect that ordering, because bitcoin miners don't pre-validate mastercoin transactions before including them in a block (bitcoin transactions must be valid before they will be included by a miner). Consequently, in the event of a blockchain reordering event, a Mastercoin transaction which was previously invalid can become valid due to reordering.

The end result is that a Mastercoin transaction with 3 confirmations is less secure than a bitcoin transaction with 3 confirmations, but more secure than a bitcoin transaction with 2 confirmations. I typically say that Mastercoin transactions are "half a confirmation less secure" than bitcoin transactions against double-spend attacks.

In the future, Mastercoin will be MORE secure than bitcoin - specifically against theft and loss. Mastercoin features include the ability to put restrictions on a "savings" address such as temporary reversibility and spending limits. These limits directly prevent theft, and indirectly prevent loss (since it is safer to have more backups of a wallet which can't be stolen).


What's the easiest way for a user to create a transaction with 2 receiving addresses?

It's a built in feature of the reference Bitcoin-QT client. Make a transaction as normal, and click the [+] button to add a second recipient.


Why was the time between these two blocks not approximately 10 minutes?

There are a few things to know about the frequency of blocks:

Every hash has the same chance of finding a block. So, times between blocks are randomly distributed.
The difficulty (i.e. the expected number of hashes required to find the next block) is only adjusted every 2016 blocks. With ten minutes between blocks that would be every 14 days. However, since a lot of hashing power is being added to the network every day, the hashing power quickly starts to exceed the difficulty that it was estimated to accomodate, and the average time between blocks starts to get lower until the difficulty is adjusted again. So right now, we are probably closer to a block every 7 minutes in average than every 10 minutes.


Error while syncing with the blockchain on my Raspberry Pi

As @MartinSolie noted, it might be helpful to look into the debug.log file.

Based on what you describe, it sounds like your Bitcoin Core node crashes at some point while synchronizing. You mentioned that you copied the chain from another device. Since you mentioned you are waiting for the blocks to match the headers, I'm not sure the transferred chain is correctly recognized by Bitcoin Core. Your Bitcoin Core is either re-indexing the whole chain or even downloading it. On a Raspberry 3 this can take quite a while (i.e. multiple weeks).

Bitcoin Core probably crashes, because it runs out of memory. One way of solving that would be to add a SWAP file on your HDD (don't do it on the SD Card! Swapping kills the SD card over time).


open the wallet which youd like to delete so that you see the balance and transactions
click the settings icon in the top right corner

scroll down to the bottom
last config option is called „delete wallet“


What software do exchanges use to manage wallets?

From an exchange's perspective, the best option would be to write mostly your own software. From a technical perspective, an exchange only has to fulfill the following in order to be accepting a crypto-currency:

Must allow deposits of Bitcoin or coin the exchange claims to accept.
Must allow withdraws of Bitcoin or coin the exchange claims to accept.

Normally bitcoind or the altcoin variant of it, litecoind, dogecoind, etc., take care of both for a user of a crypto-currency. But an exchange has special demands. Here are some issues I can think of that may happen to an exchange if they used the core client.

Core clients are not designed to work in a multiple server environments, something vital for large exchanges.
Private keys and corresponding addresses need to be stored under special conditions. An exchange may want add a username along with an address or even reuse addresses for efficiency.
Core clients aren't exactly lightweight. An exchange doesn't need a lot of features commonly packaged together with a core client. As an example, accounts; it's purely for organizing money cosmetically, something exchanges don't need.
Core clients don't allow for more intricate control of transactions or other components, SatoshiDice is impossible to create using bitcoind because it require manipulation of transaction inputs to create sends, something you can't currently do with bitcoind.

So what should an exchange be doing?

Using a combination of the two, or even ditching the core client. There are many programming libraries that simplify all aspects of Bitcoin technology, libbitcoin is a C++ library that allows you to make a partial or full node in no time. SatoshiDice is constructed on BitcoinJ, a popular Java library for Bitcoin. There are also many libraries available for other languages, but the point is that building a node isn't too hard.

I recommend a hybrid use because bitcoind is a lot more safe and bug-free than your own code. You can accidentally create code that creates invalid transactions or even accidentally send coins to the wrong address. I'd use a library and my favorite language to detect deposits and accredit them to accounts, and then push raw transactions to a bitcoind instance running on my own or possibly the same server where it will validate it and take care of sending it other nodes in the network. Less space to mess up in code.

For altcoins, you'd need an instance running or just doing small modifications to the code to differentiate. There isn't a huge difference between the protocols all the crypto-currencies use. You should know anyways if you're planning to accept a coin as an exchange.

TL;DR

Exchanges should be using software they're wrote themselves. This isn't hard to do as there are many libraries available that give you nitty-gritty access to Bitcoin. Core clients can be a bottleneck at times but can be used in conjunction to avoid said bottlenecks while maintaining a safety net for an exchange and can even simplify certain parts.


Using the Bitcoin API, how can I see the sending address?

If you use gettransaction on the transaction ID, the keys used to claim the inputs are in the scriptSig fields. They're the string starting with 04. You'll have to hash them and then convert them to base58 get account IDs.

Note that these account IDs may or may not actually mean anything. If you're being paid out of "change", then the account IDs are essentially random.


When does a node start mining the next block?

To start with, nodes no longer mine in Bitcoin. Bitcoin's difficulty is too high, and mining is now done via a series of mining pools, which distribute the work to tens of thousands (if not hundreds of thousands) of ASIC miners.

  Mine right away.

Miners do start mining a new block as soon as the previous one is discovered, regardless of if it was discovered by them or another miner.

There is no penalty for mining multiple blocks in a row, since mining is not a operator-linked operation - That is to say, as far as the blockchain is concerned, there is no such thing as defined mining entities, and there is no database or registration against which the blockchain can check to see if a two blocks have been mined by the same entity.

Of course, the output in the coinbase transaction could be checked, but it is trivial to just send that to a new address each time.

Moreover, mining pools would usually assign a different block template to each participant, since ASICs can cover the nonce and timestamp space in a trivial amount of time. They then move on to updating the extraNonce, and by distributing different templates to each miner, pools can ensure work is not done twice.


Bitcoin with transaction fee exceeds balance

It sounds to me like Coinbase has paid the fee for you, as a courtesy.  They have a policy of doing that:

  Using our wallet services to send, receive and store digital currency is free. We even pay the network transaction fees which are included with most digital currency wallets.

My understanding is that Coinbase doesn't maintain an individual set of private keys per customer; rather, it pools all deposited funds among its own private keys, and tracks each customer's balance in its internal records.  (More like a bank account than a safe deposit box.)  So when you requested BTC 1.00 to be sent, it didn't come from an address of "yours" containing only 1.00 BTC, but from some internal Coinbase address(es) with a potentially much higher balance.  Thus there should be plenty of funds available in the inputs to pay the extra BTC 0.01 if Coinbase wants to write the transaction that way, and it sounds like they did.

A transaction fee is implemented by having the inputs of a transaction exceed the outputs.  So if the transaction does in fact have a fee of BTC 0.01, in addition to your output of BTC 1.00, then by very definition, it must have inputs of at least BTC 1.01.  (There might be other "change" outputs sending whatever is left over back to Coinbase, or making payments requested by other customers.)  If the inputs weren't valid, that would be a bug in Coinbase's software, and the block explorer you checked should have detected this and warned you about it.

Everything is fine and the transaction should be confirmed soon.  When that happens, the payment is irreversible and you can stop caring about how it happened.


Bitcoind transactions in regtest mode always fail with -25 error

I have found the solution: the problem was that I was generating an insane fee by specifying an amount which was too small compared to the inputs.

I have discovered it by compiling the last version and not using the precompiled package, which seems to be older...


How many characters you need to mistype at minimum to get another valid address?

Check sum is a result of 2 hash-functions: SHA256 and RIPEMD160. The length of checksum is 4 bytes. Hash functions are indistinguishable from random oracle, so it is possible, if you make 1 mistake in non-checksum character, you get the same checksum. But probability of this is 1/2^32.

Added later: not exactly correct due to base58 encoding. Correction in the another answer.


What happens to a miner's work when they restart?

Now my question is, we hash the previous block chain's hash with transactions and the nonce?

We can look at the form of a block here.

The information that is actually hashed include the version, previous block hash, the merkle root of the transactions the miner has included in the block, the current time, the target difficulty of the block, and the 32bit nonce. The rest of the information here is infered.

There's more information about the block format on the wiki.

  Furthermore, if the first try is not successful the nonce is changed as a result to compute a new hash?

The nonce is incremented until the 32bit space is exhausted, at which point the header is modified to give a different work for the miner. At the present time this may happen many times a second.

  If we start adding transactions to a block and another block is created before our block, what happens to our work?

The current work is discarded, and the miner starts working on top of the highest block the know about.

  Moreover, can we include blocks with 0 transactions to the block chain?

No, a block must contain one transaction containing the miners reward, which can be any value up the limit of the current block reward, at the time of writing this is 25BTC. 1 transaction blocks are quite common, as they're less likely to be orphaned (another is created while the minted block is making it's way across the network).


What prevents a node from sending a different version of the blockchain?

In the scenario you describe, in which the only peers a bitcoin core node can connect to are owned by an attacker or colluding attackers, there is a minimum-chain-work-required for the block headers, so the client will not accept a chain which has a total amount of work less than the amount hardcoded into it here. There may be more forms of protection too, my knowledge is incomplete, but that at least provide a lot against such a situation. The node performs headers-first-sync which means it will know what the work of the chain is before it spends a lot more bandwidth and processing power validating the blocks themselves.


Do i need to sign each input in a raw transaction?

Technically, yes. But software like Bitcoin Core Client signs all inputs where the private keys are known. And of course, leave unsigned/untouched all other inputs.


Is there any RPC Java library using which I can call lite coin methods?

Litecoin has forked the Bitcoinj project so that you can use Litecoinj

Repo's are here: https://github.com/hank/litecoinj

and here : https://github.com/hank/litecoinj-new

I think the last one is the most recent and active repo.


Is there a way to prove control over specific number of BTC kept in cold storage?

You can sign a message with your private key. But you would have to reveal your public key so that the signature is verified. But that kind of defeats the purpose of cold storage. You can just as well send a small amount from that address to the other party.


Runaway exception on 0.9.3 Bitcoin client startup 64 bit Windows 7

I'm not an expert on Windows, but I suspect your problem is caused by your anti-virus program.  As widely reported, some griefers have placed virus signatures in the Bitcoin block chain.

These virus signatures can't actually harm your computer---the block chain is non-executable---but virus programs detect them and quarantine the files anyway.  You may want to poke around your anti-virus program's settings and see if there's a way to exclude bitcoin-qt and its data directory from your scans.

Although it won't help you now, it might ease your mind to know that the Bitcoin Core developers are working on this issue.  If I understand correctly, their plan is to optionally allow each Bitcoin Core user to store the block chain with a slightly different encoding[1] so that virus signatures in the block chain are uniquely obfuscated on each computer.

[1] For compsci geeks: they plan to allow XORing the block chain it by a bitstream unique to each instance.


Cost of transfer from multiple addresses

More inputs will mean the transaction will take up more bytes. Since miners have only so many bytes in a block that they can fill with transactions, they won't put in a bigger transaction unless it pays a bigger fee.

This means that small outputs can be effectively unspendable (because the fee for the additional bytes it would take to claim them exceed their value) until and unless fees decrease.


Why is attacker revenue in the selfish mining disproportional to its hash-power?

Selfish mining is based on delaying the propagation of the blocks a selfish miner (or pool) has mined. Following such approach, other miners continue mining on the top of an old block, wasting their time and  hash power.

There are different situations depending on how many blocks a selfish mining pool is able to mine in a row before any other node mines one (all the possible cases are described in the paper you cited). Moreover, selfish mining also requires fast block propagation through the network, since in some of the situations they try to take advantage of other nodes mining on the same block as them, virtually extending the hash power of the selfish mining pool.

Block propagation speed matters since when the blockchain forks in two branches of the same length, nodes start mining by default on the top of the first block they hear about.


Large pool of addresses means more anonymous? how?

The pool of addresses is meant for consistency among offline backups. Not for anonymity. See: https://en.bitcoin.it/wiki/Key_pool

Generating and using a new address on-the-fly vs generating thousands in advance doesn't really make any difference in terms of anonymity. Just would create a lot of overhead.  What might help more is using a new address for each new transaction. Maybe.


Intrinsically useful proof-of-work using Mersenne or Fermat numbers factorization. Could it be possible?

How would solving these problems secure the network? Miners are rewarded for the proof of work they do because the specific proof of work they do -- hashing block headers -- in fact secures the system. Solving other problems doesn't secure the currency. If you want to pay people for doing work, you certainly can. But don't at all confuse it with the proof-of-work that crypto-currencies use to solve the double spend problem -- that must be the actual proof-of-work that actually solves the double spend problem.

The point is that the block hashes are tied to a specific block and to specific transactions in that block. The proof of work cannot be severed from the block header and the transactions. Thus the proof of work secures that block header and those transaction. Factorization of Mersenne numbers isn't tied to a specific block or set of transactions, so it does not secure the block chain.


How to compute profit and loss with currency trading?

I will assume that the base currency is C1 since that is the initial balance.

Day 1: 1 C1
Day 2: sell 1 C1 for 10 C2, no change in price, so 0% gain, still 1 C1
Day 3: price falls to 1 C1: 1 C2, so 900% gain, sell 10 C2 for 10 C1
Day 4: sell 10 C1 for 1,000 C2, no change in price, so 0% gain, still 10 C1
Day 5: price rises to 200 C1: 1 C2 from 100 C1: 1 C2, sell 1,000 C2 for 5 C1, so 50% loss, now 5 C1

To sum:

0% gain by 900% gain by 0% gain by 50% loss
= 1 * 10 * 1 * 0.5
= 5
= 400% overall gain

I can provide more detail if needed, but a base currency must be selected.  The price only needs to be taken into account if there is a position still open; in other words, the price should be applied in this case if you still own something other than C1, the base currency.

If all positions are closed out before accounting for gains, only the trades need to be used to calculate the rate of return.

The simple formula for measuring relative prices is x_final/x_initial, and the change/return/yield is x_final/x_initial-1, with gain >= 0% and loss <= 0%.

Directly applying this formula to the trades, denominated in C1 is:

(10 C2/1 C1) * (10 C1/10 C2) = 10
(1000 C2/10 C1) * (5 C1/1000 C2) = 0.5

The overall relative prices is 5, expressed in percent is 400% because the percentage gain of 5 is (5-1)*100%.

If there is an open position, to account for change:

(# of C1 paid/# of C2 received) * (current price expressed as quotient of C2/C1)

Arithmetic vs geometric returns

I reread the final portion of your question.  First, the calculations are incorrect, so you should follow my example.

Second, one cannot add returns, the total arithmetic return.  They must be calculated geometrically, and that is why the each final/initial should be multiplied.


The current king of the hill is BitMain and their AntMiner S9. They provide 14 Th/s, but it's sold out at the moment.

Unfortunately, the industry changes so fast that it's hard to have anything current. Companies go bankrupt, new manufacturers appear out of nowhere and it's hard to keep up. The best directory of manufacturers and their wares is here:

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


Requirements for a Bitcoin Miner Data & Bandwidth needs

Bandwith usage of a Bitcoin miner is almost negligible, in the order of 0.125 KB/sec source

Connection stability it's more important to keep the miner working 24 hours a day.

Also, some altcoin has block generation every minute, in this case also round trip time to the mining pool is important because otherwise you have high percentage of dead share. This doesn't really apply to Bitcoins because block generation is every 10 minutes.


Comparison between Bitcoin and other currencies

Ripple is a centralized system with Know Your Customer integration (passports and bank accounts etc.).

Litecoin and dogecoin add zero innovation over Bitcoin, let alone in the privacy department.

Bitcoin itself however does have some exciting privacy enhancing features in store:

Confidential Transactions, which encrypts the amounts in the transactions making them unreadable to anyone but the sender and recipient.
Signature Aggregation makes it much easier to do coinjoin where transactions of multiple people are combined into one so that it becomes harder to identify which bitcoin belonged to whom. And it actually incentives doing this by making combined transactions smaller (cheaper).


How do I get rid of an unconfirmed transaction on Bitcoin Core 0.14.1?

Since 0.14.0 the mempool is stored on disk when Bitcoin Core is closed. To apply -zapwallettxes to remove a transaction you also have to delete the mempool.dat as the transaction is otherwise reintroduced into the wallet when the mempool is imported.

To remove an unconfirmed transaction with 0.14.0 you have to:

Shut down Bitcoin Core.
Find your Bitcoin directory
Delete mempool.dat in the Bitcoin directory
Start Bitcoin Core with -zapwallettxes

Previous versions didn't persist the mempool to disk, so step 1. and 4. are sufficient to remove an unconfirmed transaction.
The interaction of -zapwallettxes and the persisted mempool was fixed with Bitcoin Core 0.15.0, so it is sufficient to set -zapwallettxes after that again.


Bitcoin Wallet for Android - Issues decrypting the wallet backup BIN file using OpenSSL

i managed to decrypt a backup by doing this  :

openssl enc -d -aes-256-cbc -md md5 -a -in ./walletbackupfile > decrypted_wallet

however, i have not managed to getting at the private keys from the output.

i have tried wallet-tool dump --dump-privkeys --password=..pin

but it seems like no private keys are dumped in the output

i have also tried wallet-tool raw-dump --dump-privkeys   --password=..pin

that seems to dump some encrypted private keys of some kind, but i am not sure how to proceed from there.


I have not received my bitcoin after 2 days and 115 confirmations

1 of the addresses is Spent and the other is Unspent?

The simplest transaction has one input and two outputs. One output is the amount to be transferred to the destination-address. The other output is the left-over change being returned to the sender (to the wallet containing the sending-address).

One way of interpreting what you wrote is that the recipient has already spent what you sent them.

Another way of interpreting what you wrote is that you have subsequently spent the change in a second transaction.

  It only required 3 Confirmations but is now 115?

The transaction is confirmed. It is not pending. If you wait longer nothing will change.

  Where is my bitcoin

Someone has already spent it (i.e. spent the amount sent or the change returned).

  and how do i receive it?

It has already been received.

You don't say explicitly that you "own" the sending address and both of the receiving addresses (perhaps in more than one wallet) but if so, your wallet has been compromised and you should immediately move everything into a completely new cold wallet

lets look at the transaction

Transaction: 0ec3e57ee26a68f73030f331fa18184bc3290833fb5b40509caedbd434c99301

Source of funds: Address: 18gLw9DF8aBW2PzY3rVi35bFiuSTNgiv7s
                 Amount:  0.02849847 BTC

Outputs:         0.02054938 BTC to 16FsHnvTqnYrvdPXTH4c7tXD8ZE4r8rXJg - (Unspent)
                 0.00781349 BTC to 1NtLEd3y5wEmR3bsQ1LEeN6g8H3DbxSmiU - (Spent)

Only you know which is the amount transferred and which is the left-over change. So only you know whether the amount or the change has been spent.


There’s no way of easily disabling obfuscation, but you could build a version that sets the keys to zero, resulting in no change when the XOR is used. Generally it has no impact on anything, so it’s left enabled even on non-windows systems where it’s generally not useful.


How to use bitcoin from the command line in Windows?

You can use bitcoind and bitcoin-cli in windows too. See this post for more information.


There is no math that would get the private key from a public key. That is the whole point of the Elliptic-Curve Cryptography. You can always get the public key from a private key, but not the opposite since this would mean that anybody could spend the Bitcoins of anybody and Bitcoin itself would be worthless.


Send and Receive BTC with Same Address from 1 Person

Yes, this works, change either needs to be sent back to Address A, if the amount is less, or an additional previous transaction output needs to be used if the amount is greater than what was sent from Address1. Here is an illustration of change.

Let's say 1 BTC is sent from Address A to Address B. Then 0.5 BTC is sent from B back to A.

TX #1

Input                         | Output
----------------------------- | ------
(some output 1 BTC to A)      | 1 BTC to B

TX #2

Input                         | Output
----------------------------- | ------
(TX #1 output 1 BTC A to B)   | 0.5 BTC to A
                              | 0.5 BTC to B (change)

Note this doesn't account for tx fees, which would decrease the change amount back to A


Can Bitcoin be stored in a computer without a wallet , just like a normal file?

On the technical level, there is no such a thing as a Bitcoin. What there actually are are transaction outputs. Transaction outputs consist of a output script and a value. The value is in satoshis, and that is what gives your wallet a "balance". The output script specifies a set of conditions  that are required to spend the value associated with that output.

Typically the output script requires that a digital signature be made with a public key whose hash matches a hash provided in the output script.

So, no, a "Bitcoin itself" does not have any associated files that you can store. However you can store the Bitcoin blockchain (thus store the transaction data, including transaction outputs) locally, and that is what nodes do. But storing it offline would mean that it becomes out of date very quickly and thus missing new transactions.

Alternatively you can store the private keys which are necessary to spend from the typical type of transaction output. These can be stored independently of any wallet software. But you still need some software to create a transaction and then broadcast it to the rest of the network. In order for a transaction to "go through", you must broadcast the transaction so that it can be added to the blockchain. Just making it offline won't do anything.


I want to program one that emits the coins when someone has performed
  some verified work in the real world.

This is fiat currency. You receive some coins for performing some work for someone :) No blockchain needed


bitcoin-cli deriveaddresses always returns an error

There are multiple things you are doing wrong.

Firstly, in your first descriptor, you have a miscellaneous space between the origin info (the stuff in square brackets) and the xpub. Secondly, this descriptor is also invalid because you have not computed the correct checksum for it. The checksum is the stuff that appears after the pound symbol (#) at the end of the descriptor. The checksum you have there is the checksum for the one from the help text which is only valid for that descriptor.

In order for your descriptor to be valid, you need to remove the space and recompute the checksum. Remove the checksum, including the pound symbol separator, and pass the non-checksummed descriptor into getdescriptorinfo. This will give you a descriptor with the correct checksum. Please note that it will change the hs in the origin info to single quotes (') which may need to be escaped.

Furthermore, because you are changing the xpub in your descriptor, the origin info in your descriptor is incorrect (although Bitcoin Core does not know this). You should change the origin information to match your xpub, or remove it entirely.

The reason the second descriptor you are trying does not work is because it does not have a checksum. The PR for deriveaddress was written before descriptors had checksums. The RPC was updated and changed when checksums were introduced.


Bitcoin-qt falls behind on blockchain, how to replace?

I know that there is a torrent where you can download the blockchain to jumpstart your fresh installation. This should also help to update your local wallet. In order to download and import the blockchain manually have a look at the instructions and the download link in this bitcointalk thread:

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


Do I need to join a pool if I have a 3TH mining rig?

It is hard to decide right now, knowing that till you will buy, and the company will deliver your hardware, the difficulty will change many times.

Right now with a current difficulty, solo mining with 3Th/s will give an estimation of mining a block in 2 weeks (during this two weeks the difficulty may change). So even right now I would rather have a steady 2 BTC per day then to risk. Especially if after buying this hardware, you need to break even as fast as possible.


I've been working on this as a part of a bigger Bitcoin tools Python 2 library for a while. You can find it on github.

You can run the code on ldb_parser.py which will give a txt with all the UTXOs from the chainstate parsed in a json. (Notice that this is a huge amount of data.)

Then you can call the decode_utxo function using the data from the json and store the result in a file to analyze it. (This file will be even bigger!).

Here you have an example (once you have run ldb_parser.py):

from bitcoin_tools.utils import load_conf_file, decode_utxo
from json import loads, dumps

fin_name = "utxos.txt"
fout_name = "parsed_utxos.txt"

# Load config file
cfg = load_conf_file()

fin = open(cfg.data_path + fin_name, 'r')
# Output file
fout = open(cfg.data_path + fout_name, 'w')

for line in fin:
    data = loads(line[:-1])
    utxo = decode_utxo(data["value"])

    fout.write(dumps(utxo) + '\n')

fout.close()

And each line you will get in parsed_utxos.txt look like:

{"coinbase": 0, "version": 1, "outs": [{"index": 1, "amount": 14250000, "out_type": 0, "data": "865e218ff25929eee880e0e3b6f95280b2d05443"}], "height": 468349}
{"coinbase": 0, "version": 1, "outs": [{"index": 0, "amount": 132000, "out_type": 1, "data": "0b2a00367244680f6da18acd861a08f0a89cb3b4"}], "height": 449294}
{"coinbase": 0, "version": 1, "outs": [{"index": 1, "amount": 2423800, "out_type": 1, "data": "7f172a63c49c5d03e3307d432bd6b784b69d0e0d"}, {"index": 2, "amount": 10000000, "out_type": 1, "data": "1d0c4b60e8270f9b6ca5f167f08a5466a0cee565"}], "height": 474328}
...

Where each entry in outs in an output and, and data corresponds to the transaction data (hash160 of the address for P2PKH transactions).

Now, you have to take into account some considerations:

Not every single UTXO is a P2PKH, so what you will find in data depends on the out_type field.

out_types 0 and 1 correspond to P2PKH and P2SH respectively, and will have 20 byte of data (hash160 of the public key for P2PKH and scriptHash for P2SH).

out_types 2,3,4 and 5 correspond to P2PK outputs, and will contain 33 bytes of data (1 byte for the type of public key and 32 bytes for the actual key).

Finally, any other out_type will imply that the data hold by the UTXO is not compressed, and the value will correspond to the data size + the number of special scripts (nSpecialScripts) which is currently 6). This is the case of P2MS transactions and non-std transactions.

All this has been directly extracted from the Bitcoin Core source code.

Finally, notice that in order to use the library you will need to install the python dependencies in requeriments.txt and create a conf.py file to set your chainstate path and data path (or modify the code to not use the config file).


How to create bidirectional channels using LND?

It is bidirectional by default. In fact LND does not even allow for single-directional channels.

What you're experiencing though, is the drawback of having created a single-funded channel. That means, that all of the funds in your newly created channel are sitting on your side, which means that for now, you can only send money but not receive any money. Or in other words, you don't have any inbound capacity on that very channel. As soon as you do have both inbound and outbound capacity, you will be able to both send and receive money over that channel.

Note: For now the Lightning implementations do not allow for mutually funded channels, but this feature is in the works and soon to come.

So.. what are your possibilities now to circumvent this problem and get inbound capacity? Here are some options:

Wait until other nodes open channels to your node
Push money to the other side of the channel by buying something
Send money over Lightning to zigzag.io and receive it back on-chain.

Once you have inbound capacity and you are routing payments, your channels will get rebalanced in the process and you will hopefully get inbound capacity on all of your channels over time.


Is it chain of headers rather than a chain of blocks?

Blocks contain a header, and headers are chained, so blocks are chained also.  Note the merkle root from your question: this attaches the transactions in the block to the header, making them a logical combined unit:

That is, you can't attach an arbitrary block to an arbitrary header---each header only attaches to one set of transactions.
You are correct that this expression is wrong: "every [valid] block contains a hash of the previous block".  That phrasing may be useful for non-techies, but if you find it in any editable technical documentation, you should probably change it.


How to use Electrum with a local regtest network?

Electrum doesn't connect directly to Bitcoin nodes. Instead it connects to Electrum servers using the Electrum protocol. These servers run Bitcoin nodes and additional Electrum server software in order to provide the data that Electrum actually needs to operate. So you need to be running an Electrum server software that connects to your node and then connect Electrum to that Electrum server.
Some Electrum server software:

Electrum Personal Server: EPS is designed for use with a single Electrum wallet and is probably the easiest to get an Electrum wallet connected to a full node
Bitcoin Wallet Tracker with Electrum plugin: BWT is like EPS but does more stuff and isn't just limited to Electrum
ElectrumX: ElectrumX is the official Electrum server software. It is a full fledged Electrum server software that is intended to be used by any connecting Electrum wallet. As such, it indexes the entire blockchain. If you want to do experimentation with the Electrum protocol, you may want to use this.
Electrs: Like ElectrumX but written in Rust.


What is a "serialized signed transaction"?

I would like to comment on your "mess of stuff"... maybe not the best way to get support, if you don't understand what it is, and define it as such. I decode it here for you:

VERSION
 01000000

SEGWIT (BIP141): this is a segwit tx, marker=00
       (BIP141): flag=01

TX_IN COUNT [var_int]: hex=02, decimal=2
 TX_IN[0]
  TX_IN[0] OutPoint hash (char[32])
  9F96ADE4B41D5433F4EDA31E1738EC2B36F6E7D1420D94A6AF99801A88F7F7FF
  TX_IN[0] OutPoint index (uint32_t)
  hex=00000000, reversed=00000000, decimal=0
  TX_IN[0] Script Length (var_int)
  hex=49, decimal=73
  TX_IN[0] Script Sig (uchar[])
  4830450221008B9D1DC26BA6A9CB62127B02742FA9D754CD3BEBF337F7A55D114C8E5CDD30BE022040529B194BA3F9281A99F2B1C0A19C0489BC22EDE944CCF4ECBAB4CC618EF3ED01
  TX_IN[0] Sequence (uint32_t)
  EEFFFFFF
 TX_IN[1]
  TX_IN[1] OutPoint hash (char[32])
  8AC60EB9575DB5B2D987E29F301B5B819EA83A5C6579D282D189CC04B8E151EF
  TX_IN[1] OutPoint index (uint32_t)
  hex=01000000, reversed=00000001, decimal=1
  TX_IN[1] Script Length (var_int)
  hex=00, decimal=0
  TX_IN[1] Sequence (uint32_t)
  FFFFFFFF
TX_OUT COUNT, hex=02, decimal=2
 TX_OUT[0]
  TX_OUT[0] Value (uint64_t)
  hex=202CB20600000000, reversed_hex=0000000006B22C20, dec=112340000, bitcoin=1.12340000
  TX_OUT[0] PK_Script Length (var_int)
  hex=19, dec=25
  TX_OUT[0] pk_script (uchar[])
  76A9148280B37DF378DB99F66F85C95A783A76AC7A6D5988AC
 TX_OUT[1]
  TX_OUT[1] Value (uint64_t)
  hex=9093510D00000000, reversed_hex=000000000D519390, dec=223450000, bitcoin=2.23450000
  TX_OUT[1] PK_Script Length (var_int)
  hex=19, dec=25
  TX_OUT[1] pk_script (uchar[])
  76A9143BDE42DBEE7E4DBE6A21B2D50CE2F0167FAA815988AC

WITNESS TXIN[0] stack elements: hex=00, decimal=0
WITNESS TXIN[1] stack elements: hex=02, decimal=2
 WITNESS data[0]:
  47304402203609E17B84F6A7D30C80BFA610B5B4542F32A8A0D5447A12FB1366D7F01CC44A0220573A954C4518331561406F90300E8F3358F51928D43C212A8CAED02DE67EEBEE01
 WITNESS data[1]:
  21025476C2E83188368DA1FF3E292E7ACAFCDB3566BB0AD253F62FC70F07AEEE6357

 LOCK_TIME
11000000

So the 02 at the beginning indicates two inputs (TX_IN COUNT), and it's witness data is displayed at the end.


API for getting the Hash-of-thing-to-sign

Try the page at https://2xoin.com/getRSZfromRawTX/
Paste a raw transaction into it, it will return the z values of each tx input.
The z value is the hash of the message that was signed.
It only works for bitcoin at the moment.


You can serialize a binary tree with n leafs (such as a merkle tree) as an array of 2n-1 entries. The root is entry 1 and for each node the left child is at position 2n and the right child is at position 2n+1. This gives you a compact representation of the entire tree.

Another option would be to just have the n leaf nodes in a list since the inner nodes are actually generated from the leafs.

Both need to be checked by a program, since checking the validity of a tree involves computing cryptographic hashes. Visualizing them in a human readable format does not really provide any security if it cannot be verified.


Is there a limit to how many blocks can be rolled back from a 51% attack?

For example if I owned 51%+ of the network, mined 1000 blocks privately and the rest of the network was at block 990 and then I broadcast the data would everyone switch to my chain and would the last 990 blocks be orphaned?

This can certainly happen. There is no limit on how many blocks can be reorganized. However, while nodes will still perform the action to rollback those 900 blocks and replace them with the 1000 privately mined ones, there will be lots of warnings if this does happen as Bitcoin Core (the most commonly used node software) has checks for large work blockchain reorganizations. These checks will trigger warnings if there are reorgs of more than a few blocks so that the node operator can take action if necessary.


Importing private key to bitcoin node is slow. Can it be faster?

No.

Bitcoin core is a full node and doesn't use SPV or any equivalent. Therefore, when importing a private key, it must scan the Blockchain copy it holds rather than trust third parties.

Sweeping the private key into Bitcoin core ought to be faster.


how can I hardcode a private key in bitcoinJ - ECKey constructor?

If all you are after is getting an ECKey object for that private key, then Bitcoinj has a DumpedPrivateKey class for just such an occasion.

import org.bitcoinj.core.ECKey;
import org.bitcoinj.core.DumpedPrivateKey;
import org.bitcoinj.params.MainNetParams;

public class Example {

    public static void main(String[] args) {
        String priv = "L4...5";
        ECKey key = DumpedPrivateKey.fromBase58(MainNetParams.get(), priv).getKey();
    }

}

If you would like to use an ECKey constructor explicitly, then you should be able to get the code you need from here:

  https://github.com/bitcoinj/bitcoinj/blob/release-0.14/core/src/main/java/org/bitcoinj/core/DumpedPrivateKey.java#L70-L91

With respect to the constructor you listed, it is a protected constructor, so it's probably not one you would be looking to use. It lists a private key and public key parameters. The private key may be null if the ECKey instance is only going to be used for verifying signatures, not actually producing them. The public key must not be null, and it saves time by not needing to re-compute the public key, which is a CPU intensive operation.

Note that most of the public ECKey constructors are deprecated. The preferred way of creating the ECKey objects now is to use the static factory methods.


Electrum transaction, 1 confirmation but i want to cancel it

If a transaction has 1 confirmation then it is in a block. Every ten minutes (on average) it will get another confirmation. It should have 6 confirmations after about an hour.

There is no way to cancel it.


Manually crafted multisig Tx: non-mandatory-script-verify-flag

I was sending an extra signature.

The transaction required 2-of-3, and I sent the 3 signatures. The extra signature was not popped off the stack by OP_CHECKMULTISIG, and the remaining stack looked like this:

EXTRA_SIGNATURE
OP_0 # null-dummy for Bitcoin Core's old bug

The extra signature took the place of the dummy, and bitcoind detected this when verifying the dummy was an OP_0.


The p2pool node communicates on more than one port. By default, miners connect to the node on port 9332 and other p2pool nodes ("peers") connect on port 9333.

So just switch your miner to port 9332, that should fix your issue.


you're providing alpha to "high frequency market makers". Since they can tell that you are not a bot, they are assuming its a real bid, so they can bid on top of you and then they are now in a risk free position.

if they get hit, they will immediately place an ask at a price of:  last + (last-bid). they will wait hoping you will pay up, they may even entice you by placing another bid higher... then (within a couple of seconds) they will hit your bid, and take the small loss.

as long as the spread is much wider than the tic above you, they are in positive alpha.

in general, you should not try to play this game. just place "marketable" limit orders.. so buys at the best ask, and sells at the best bid, otherwise you are giving away your hand.


How does the bitcoin core protect against initial DNS seed changes?

Generally there's some discussion about attacks against the bootstrapping of Bitcoin Core, but there's not a whole lot in terms of being able to defend against it. Fortunately the DNS seeds are only really used on the first launch of the software, the rumoring of peers within the network is used for all subsequent connections.
There's not a whole lot that could be done with gaining this sort of access without a lot of cost beyond just subverting DNS seeds. The clients have an idea of the total amount of work needed for the chain to be valid, so won't be fooled by an entirely new blockchain that has no connection to the real one. Mining with a low hashrate at the tip of the real blockchain is not possible either due to there being a maximum amount the difficulty can drop in each period; you can't simply mine 2 weeks worth of blocks and have the difficulty drop to nearly zero.
Ideally we'd now have the DNS seeds, but the risks they introduce are manageable, the bootstrapping issue isn't unique to Bitcoin, it's something that all P2P networks need to contend with to some degree.


Transfering Money From My Bank Account To Bitcoin?

If you don't want to deal with the hassle of an exchange you could try our new service for UK users:

https://blockchain.info/wallet/deposit-pingit

The fee is slightly higher at 3.49%


How is it legal to award miners with coins made out of nothing?

Miners spend energy to create blocks/getting rewarded bitcoin, it's not out of thin air. As new miners try to create new blocks and get the block rewards, the energy needed to create a new block increases and it gets harder and harder to create a new valid block. This difficulty is adjusted every two weeks. For example, at the start of the year the difficulty was 5,618,595,848,853 and now is 12,876,842,089,682, which means it costs more than double to create a bitcoin now than at the start of the year. If you try to mine bitcoin with your laptop/desktop/smartphone you will get less bitcoin for the electricity that you spent than you would get if you bought it at an exchange.

The cost of creating one bitcoin with an electricity cost of $0.05/Kwh, for this era, is apr. given by:

Cost($/BTC) = difficulty[trillion] * energy_efficiency[J/Gh] * 4772

So, for an antminer S9, the current cost would be about $6144 per bitcoin.

Also keep in mind that the cost of mining bitcoin doubles every four years (halvening event).

Some resources you might want to check:

Bitcoin difficulty - https://btc.com/stats/diff
Energy efficiency of mining equipment (ASICs) - https://www.cbeci.org/methodology/


It says it is a Lifetime contract, does that mean I'll pay $1.20 and keep earning bitcoins forever? Seems a bit too generous to me.

It is too generous. Read the fine print.

  Lifetime contract*
  * as far as mining remains profitable
  Maintenance fee: 0.01 $ / 1 MH/s / 24h

i.e. you pay a fee for the electricity and colocation, and if that fee exceeds the revenue of mining, the contract is over.


Is there a way to buy or sell Bitcoins for Iceland Kronas?

Trade with others who might be local:

http://www.LocalBitcoins.com

Forum users might check in on a thread like this:

http://bitcointalk.org/index.php?topic=109453.0


How to revert back several blocks in Bitcoin Core without re-syncing from scratch

If the state is corrupt, there's no operation that will be able to restore it. A reindex will re-sync using the block files already on disk without having to re-download them where possible, but there's no escaping needing to do the CPU expensive operation of synchronization.


The timestamp is used primarily for establishing the difficulty. Without a timestamp, new nodes would not be able to determine the correct difficulty to be used for each 2016 block period as they wouldn't know how long it took to mine those blocks. So that everyone calculates the difficulty correctly, the block timestamps are used instead of real time.

This of course means that the difficulty can be manipulated by miners messing with the timestamp, but nodes do still check them against real time and will ignore blocks that are outside of a certain range of times based on its own internal clock time.


Bitcoin transactions with multiple participants from input side

Multisig inputs typically have multiple participants. Usually multiple parties are required to sign the transaction.


Why bigger blocks will bring bigger memory usage for miners?

Mike Hearn pointed out earlier on the mailing list, Satoshi added a block limit to avoid people mining "troll blocks". These are blocks where a miner includes a Gb worth of transaction output/scripts in the coinbase transaction, or thousands of small transactions. A hard block limit puts a cap on our exposure to this.

There is no minimum block size, since you can still have empty blocks, so increasing the block limit will have no effect on miners.


Yes you will be able to access the same coins with both devices. You can think about it like if you make a copy of a key to your home, and give it to someone; both people will be able to open the same door.


Is writing unit tests a good way to start contributing to Bitcoin core?

Jumping straight to writing unit test can be hard, I suggest You check the official github page for how to contribute to the bitcoin core:

https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md

If I wanted to contribute I would personally start by trying to solve some of the problems on their issues page because it is fresh, there is a lot of work, some can be easy and help is always needed:

https://github.com/bitcoin/bitcoin/issues


What is so special about chacha20 stream cipher along with poly1305 for message authentication codes?

There is nothing special about the combination. It's just a combination of two constructions (ChaCha20 for the stream cipher, Poly1305 for MAC) that are designed with similar goals in mind:

Easy to write a correct implementation in software
Optimized for performance of software implementations running on general purpose hardware. This is in contrast to many cryptographic primitives which are optimized for hardware implementation, but are suboptimal in software. This is mainly due to the use of integer addition operations in ChaCha20.
128-bit security level.

Furthermore the key derivation is informally standardized, allowing using a single key for both encryption and authentication. Having real-world constructions (for example OpenSSH) use this constructions gives confidence about security.

  What does it mean that one can efficiently seek to any position in the key stream in constant time?

Assume you're given n GiB of incoming encrypted data, but for some reason you're only interested in the last 1 MiB. With some ciphers, you'd need to do O(n) work to "skip" the first n GiB. ChaCha20, like most stream ciphers, permits decrypting any one MiB with same amount of work regardless of its position - essentially deriving the cipher output for arbitrary positions (aligned to a 64 byte boundary at least) with as much work as decoding sequentially.


Why downloaded Block Size doesn't match with actual block size mentioned on network?

For one, there is no JSON block format - different APIs have different ways of interpreting and displaying a block in a JSON response, and none of them will ever match the block size.

Your mistake appears to be saving the actual hex block as text.

1996396 = 2 * 998198

You must write the data as an actual binary file. i.e., write 12 as the byte 0x12, instead of saving the text "12" directly, which will write the bytes 0x3132 to disk, doubling the size of the file saved. Saving it as text will double the file size, as you've noticed already.


How to handle POST data sent from Blockcypher WebHook API

Full disclosure: I'm BlockCypher's Developer Advocate.

I'm not a PHP expert, but I know a number of our customers have had issues reading return data from PHP. This thread on Stack Overflow might help:

https://stackoverflow.com/questions/8945879/how-to-get-body-of-a-post-in-php


It is because in the developer guide they are referring to the outpoint, not the output. The outpoint is a data structure used to refer a particular output, that consists of:

outpoint = txid(32 bytes) + output index (4 bytes)


How does the Bitcoin block propagation process recover when false positive happens?

The purpose of IBLT-based block transfer mechanism is reducing bandwidth (how much data is sent in total) and latency (how long it takes to transfer the block), and depending on which has the priority there are different solutions.

If latency is of no concern at all, you would simply send a block header together with a list of (truncated) txids, and the peer would reply with "i'm missing transactions 3, 7, 112, and 234", followed by just sending those transactions. Such a solution would require several round trips: first sending the txids, the peer requesting the ones he is missing, and us sending the transactions.

If latency is a concern however, that's still just 3 steps, but each of those steps may be in the order of half a second or more, depending on how far away you are. If your network connection is over 10 Mbit/s, you could just transmit the entire block in the extra time wasted by the roundtrips.

So this is where IBLT and other efficient block propagation protocols come in: they try to construct a single packet that gives enough information for the peer to reconstruct the block, but without sending the full block. Occasionally that attempt will fail, false positives will occur, and the reconstruction will fail (as the block hash doesn't match what was claimed). In that case we just fall back to the naive version: go request the transactions you're missing, and incur the associated extra latency.


For the amount of time you would spend setting up a CPU miner, at minimum wage in the US you would be at a loss.

Even GPU mining is barely profitable for most people right now. It would definitely be more profitable to speculate, and even more profitable to operate a Bitcoin business. There are a great deal of people who want to use their Bitcoins for purchases.

At the current exchange of under $10:1BTC, the most efficient graphics cards are taking months to pay off their initial investment (with free electricity).


What does the 'n' in nLockTime and nSequence stand for?

It stand for a number, it is commonly used in programming to designate a variable that gonna hold an amount of something see: https://en.bitcoin.it/wiki/NLockTime and https://en.bitcoinwiki.org/wiki/NSequence


It is completely different.
Ethereum offers a standardized way to create new tokens on its blockchain called the ERC-20 protocol. ERC-20 is not a piece of code, software, or technology. Rather, it is guidelines that facilitate the integration of various currencies.
Tron is an ethereum based token that means it is powered by Ethereum blockchain. It will use resources of the ETH blockchain Tron is not a blockchain started from scratch.


How do I pay Utility Bills anonymously with Bitcoin?

If you are in canada, Bylls.com is exactly what you are looking for. It is for Canadians only though.


How can I consume my whole bitcoin balance in a single transction? Is it possible to use multiples UTXOs in a single transaction?

Of course, you can add as many UTXO's as will fit in a block. In fact, you usually have to because you don't always have a UTXO for the exact amount you are trying to spend. Note that more UTXO will result in a higher transaction fee because the fee is based on the current market fee rate (satoshi/kB) and more UTXO increases the kB.

For example, check out this transaction, it uses 7 UTXO as inputs.

See Bitcoin Wiki - Transactions


Is it possible to detect mining of bitcoins on an enterprise network?

An enterprise network administrator concerned with the operation on its systems of software that contradicts policy should already employ some kind of security scanner software. Adding the known miners to that list of flagged software is the best recourse. Additionally, watching for outbound connections to the known DNS names for peer lookup or outbound connections on a certain few known ports could yield better results with less software impeding operation.

In short, they're just programs, and administrators should already have in place the tools and knowledge necessary to block the programs from running or detect that they are running.

For ethics, the general vibe in the community is mine only on hardware you own, but obviously, not everyone follows that.


There are a few goals of coin selection.

Firstly, we want to select enough coins for the user. Secondly, we want to minimize transaction fees. Lastly we want to reduce the UTXO set.

Reducing the UTXO set requires creating less outputs than there are inputs in a transaction. By solving the subset sum problem, we can avoid making a change output and thus help to reduce the UTXO set.


I was sending the data across the socket in hexadecimal format, but it appears that it should be in binary.

This does the trick: hex2bin($message)

Link to just-about-working script: https://bitcoin.stackexchange.com/a/48399/24926


Viability of Bitcoin due to transaction fee?

Relative economic advantage

As you've noted, transaction fees are paid for block space and not relative to the amount that is transferred. This causes an obvious economic advantage to larger value transfers and would inevitably push out smaller transfers if supply remains the same and demand increases.

Supply increase

This is why for several years, there have been proposals to increase the blockspace supply. This would probably mitigate the problem in the short term, however would probably quickly reestablish the same problem at a lower fee level that would continue to rise as demand catches up.

There have been some proposals to create automatically adapting blocksizes, but these proposals have so far been incomplete and especially deficient in providing a mechanism to push for blocksize decreases. The latter is important to actually achieve a self-balancing system as a quickly growing blocksize would cause other parts of the system to fail due to vastly driving up the cost-of-node-option.

Demand management

The other side of increasing the supply would be to manage the demand. This has happened in the past to some degree by transactions moving offchain, e.g. into third party custodial wallets such as the service ChangeTip that facilitated tipping internet contributions or wallets such as Coinbase. A lot of work has gone into a decentralized second layer that basically acts as a aggregation layer for transactions. This Lightning Network is thought to settle on a fee system relative to the transferred value as the costs of relaying payments scale with the amount transferred. If it should gain widespread use it is expected to provide a haven for small value transactions that automatically rebalances with on-chain demand.


deriveChild and signing transactions using Bit-Wasp

Did a bit of digging and in order to extract the private key, you can use:
$privateKey = $key->getPrivateKey()->toWif(); And then sign the transaction.


How is time measured in the context of updates to mining difficulty?

Yes, bitcoin should not trust anyone, but it trusts itself, i.e. its own blockchain. So, when the time comes to update the difficulty (as you said, every 2016 blocks), code grabs the timestamp of this last block, and the first block in this difficulty period (block with the index of: last index - 2016).

Comparing timestamps of those 2 blocks gives us the timespan between 2016 blocks, and allows for difficulty calculation.

You can check the code for it here:
https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L55

actual_timespan = last_block->get_timestamp() - first_block->get_timestamp()

More information on what block timestamps are considered valid can be found here  http://en.bitcoin.it/wiki/Block_timestamp


It is not more secure to use different adress for every bitcoin you receive, it just gonna give you more privacy since it is gonna be harder to track you.

I guess the exchange use different bitcoin account then generate different adress for them just like we could, and keep a track of all that.

I think you are just confuse about the way exchange keep your coins, once you send them your bitcoin, you do not have a bitcoin key to access the adress you send
your bitcoin to, they just have keep track of it, and if you want to withdraw your bitcoin to your cold wallet, they will use one of their wallet to send it.

And as I said it is safe to use the same adress to receive your bitcoin, but you are right in your example they gonna be 2 transactions.


Can you verify partial blockchain information from a third party, without yourself having an entire blockchain?

You could use the Simple Payment Verification, or SPV, protocol.
In a nutshell, this works by synchronizing only the block headers for the longest chain. Once the chain is established, individual transactions are proven by using merkle paths leading up to the merkle root in the previously synced block headers.
Note that this only allows for proof that the supplied data exists in the chain - it does not allow the user to verify that you have provided them with all data - it is possible for operators on SPV systems to Lie by omission and simply claim a transaction or block doesn't exist.
Consumer wallets usually get around that by querying multiple such nodes - if at least one node is honest, the wallet is able to detect the lie.


The raw block data is downloaded, and nothing else.  All block and transaction indexes are created locally.  In the process, block hashes are checked and transactions are verified (to various degrees) as to whether they spend valid inputs, are properly signed, and so on.

Each block is checked and added to the index immediately after being downloaded.    The software doesn't wait to download all the blocks before starting to index them.

The files in blocks/index contain information to help locate blocks.  For instance, it would contain an entry for each block with its hash, other relevant header data, the number of the blk*.dat file where it is stored, and the position within that file.  If txindex is enabled, these files also contain one entry per transaction, pointing to the location of the block which contains the transaction, and the position of the transaction within that block.

The index of unspent transaction outputs is found in the chainstate directory.

The best resource to learn about these indexes is to read the Bitcoin Core source code.  There is an older writeup at https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_2):_Data_Storage, but as of 0.15.0 at least the chainstate index has changed significantly (thanks  Pieter Wuille).  It is also explained at What are the keys used in the blockchain levelDB (ie what are the key:value pairs)?.


There’s no such thing as a block without a coinbase transaction. Even if the block reward plus fees is zero, it is still a mandatory transaction at the start of every block, it just pays nothing.


I cannot see the expected OP_CODE in transactions


How exactly is Rucoin different than Bitcoin?

The "author" (if you can call a blatant 1:1 copy of Bitcoin authoring) has not backed up those claims.

The website provides no further explanation and a lot of vague nonsensical "answers"

A crude but human translated English version of Russian homepage is here:
https://bitcointalk.org/index.php?topic=48582.msg586451#msg586451

  What is the specifics of the Rucoin?
  In short - more stable course

  It is difficult to talk about stability when the system is at the forefront of the struggle of interests.
  Constant fierce struggle of interests causes course instability, which creates a number of disadvantages for practical use of such currency.
  Another thing - Rucoin.
  This project was not born on the battlefields. At the heart of Rucoin - ready, proven solutions and lessons learned.

Those "solutions" and "lessons" are never explained except with vague double speak.

  Conceptually, Rucoin - this is a layer of stability and security, when, instead of blind hope for "the invisible hand of market" principles are used strict currency regulations. Instead, to give the exchange rate at the games speculators, who for the sake of their earnings will generate most unpredictable chatter in the system, Rucoin provides some tools functionally similar to central bank and the stabilization fund, whose main task - to make the course of crypto-currency stable, predictable and guaranteed .

  Rucoin, unlike Bitcoin, totally unsuitable for currency speculators, but it is very suitable for the conservation and savings to ensure a stable and reliable infrastructure of payment systems new generation.

  In addition, Rucoin towards Bitcoin may well serve as a reserve currency, into which can be converted part of the funds for the insurance of all kinds of surprises.

So the author claims to implement a central bank and stabilization fund but makes no mention on how that is possible or how it will be implemented.  Given that exchange and a direct to cash mining pool were launch prior to the actual block chain my suspicion is this is merely a poorly designed pump and dump.

Since the launch the author has not provided any further information on how the claims will be implemented.  Based on the volatility seen at http://btc-e.com (largest exchange offering RUC trades) there has been no "currency regulation", "central bank" action or effective use of this so far unseen "stabilization fund".


Bitcoins exist as 'unspent transaction outputs' (UTXOs), not as an 'address with a balance'. If you really feel the need, you could import your keys into some wallet software which will allow you to exercise 'coin control', which means you will be able to pick and choose which UTXOs are used as inputs when creating a transaction. So then you could just choose all your UTXOs and send them to a new address in a single transaction, and then do the same for your wife's UTXOs.
But doing so will put your funds at additional risk, as you'll have to trust the new wallet software/device you import your wallet into. Mishandling private keys can lead to a loss of funds (theft), so you shouldn't do this unless you feel it is absolutely necessary.
Really, I would just create a transaction that pays you your share of the coins, and another transaction paying the remaining coins to your wife. Within a bitcoin transaction, it does not make any sense to point to some specific output and say "these bitcoins came from this specific input". Rather, it is as if all of the input coins are melted down into one blob, and then the output coins are forged anew from this blob. So it doesn't make too much sense to worry about tracking 'your specific coins' through time, as each 'specific coin' is 'melted down' when it is used as input to a transaction.
Think about it like this: when you do your accounting, do you worry about the serial numbers printed on the $20 bills, or the value of them? Your bitcoin accounting can work in much the same way: how much bitcoin did you buy? How much did you sell? This is the relevant information.

Will this work and be cool to the ATO?

Questions about how to satiate the demands of any particular tax authority are going to be off-topic here, you'd do better asking an accountant or tax lawyer if you need such advice.


No Account number or Address in listtransactions for generated blocks

There is an embryo of a  patch on github which was precisely meant to solve this issue. It was announced on the dev mailing list but never received much attention. Now it's a bit outdated (the latest merge with master is from Sep 26). Maybe you can start from here.


Mining on a smartphone is unfavourable and might drain your battery very fast. For bitcoin-mainnet and bitcoin-testnet don't even try to mine on a smartphone (it won't be fun).

If you like to do this for testing or research purposes, you probably should use your smartphones GPU over openCL or renderScript.
Also have a look at bitcoin-cores mining code if you like to know more about how mining works (in detail).


Bitcoin multisig contract - to Lock coins with nTimeLock (BIP65)

No, it is not possible.

"Bitcoin contracts" are executing when spending funds from UTXO. If the receiver can do it without signing the transaction - everyone can do the same thing.


Why does the Segwit developer guide recommend to estimate fees on basis of vsize instead of weight?

The advantage of using vsize is that it is a smooth transition from size; every non-witness transaction has vsize equal to size.

All code and infrastructure that used satoshi/byte before, will keep working when substituting size with vsize, and give consistent results. Switching to weight would be confusing - would we be talking about satoshi/weightbyte?


How we know this is a scam:

a guy approached me

That's a red flag, its how many scams start

claiming to mine bitcoins

That's another red flag, real miners don't approach strangers asking for $700 investments.

multiplying my bitcoins 10 times.

Another red flag, such big profits don't happen quickly - or at least are exceptional and cannot be predicted by a miner or investment expert or broker. In reality your $700 is almost as likely to turn into $70 as $7000.

the blockchain wallet after 24 hours showed me $7000 worth bitcoins

Another red flag. 10x gain in 24 hours never happens.

it was non-spendable

Another red flag. The scammer had altered the wallet to show someone else's money not money that you control.
What you see in a wallet isn't always real, a watch-only wallet or a watch-only / non-spendable address shows you someone else's money not yours.

The guy told me to give him half the commission

Another red flag, there's generally no such thing as commission in Bitcoin. Third-party business that act as a middleman may charge commision but you never really need to do business through a middleman.

now he is asking for a transfer fee

Another red flag, there's no such thing as a transfer fee normally. Theres a different thing that sounds similar - the transaction fee. But that should be a few cents.

Your questions

Is this a scam?

yes

How can I recover my initial investment?

You can't.
Beware. Now that you are known as having been tricked once. Other tricksters will contact you and offer to help you recover your money or tell you about marvellous people who can get your money back. All lies.

Where can I report him?

Local police.
They won't do anything for a $1050 loss though, other than provide advice and then update crime statistics, which may eventually lead to a change in their priorities.

How this happened
A bitcoin wallet doesn't contain money.
We talk about it as if it does but that's just a convenient shorthand, the reality is complex and its easier to talk about wallets as if they contained money. They don't,  it's an analogy, a misleading analogy alas.
A bitcoin wallet normally contains a secret number called a private-key. That's the only valuable thing in it.
Bitcoin payments are made to Bitcoin "addresses". An address is just a number, it doesn't identify a place or a person. Normally your wallet generates addresses from the private key using a mathematical procedure that can't be reversed. Wallets also allow you to add other unrelated addresses you want to watch (see the balance and payments in and out). Without the private-key for those other addresses you have no control over money sent to those addresses.
Even though you created the wallet yourself, you then gave control over that wallet to a criminal. The criminal changed the wallet by adding an address to it that they controlled not you. This is called a watch-only wallet or a wallet that contains a watch-only address. Some wallet show this money as "non-spendable". Same thing.
If you give control over your wallet to someone they can extract and copy the private-key. They can create their own wallet and put that copied private key into it, giving their new wallet control over any money associated with the original wallet. They could also (or instead) put watch-only/non-spendable addresses into the wallet.
Changing the password on a wallet has no effect on any extracted copies of the private-key that the fraudster made when you gave them access to your wallet.
You should throw away that wallet. Any money put into it in future is under the control of the fraudster no matter what passwords you change.

You mention that you use your email-address to access your wallet. I hope you didn't give anyone the password to your email account.
You may have created a type of online wallet called a custodial wallet - these are the least secure types of wallet. A custodial wallet is controlled by a business not by you. If the business goes bust, is hacked or closed, you have no money.

The terms and conditions at Blockchain.com say

5.5.2 When you create a Wallet, you must: (a) create a strong password that you do not use for any other website or online service; (b) provide accurate and truthful information; (c) protect and keep secret all credentials for the Wallet; (d) protect access to your device and your Wallet; (e) promptly notify us if you discover or otherwise suspect any security breaches related to your Wallet; and (f) use the backup functionality provided through the Wallet and safeguard your backup files. You agree to take responsibility for all activities that occur with your Wallet and accept all risks of any authorised or unauthorised access to your Wallet, to the maximum extent permitted by law.

(My emphasis)
You didn't do this unfortunately.


Yes and yes. Nobody other than you knows that you are sending to yourself since they can't see any connection between two bitcoin addresses. So it will be just like any other transaction. If you want fast confirmation you should include a fee.

And if you are using bitcoin-qt then it's always downloading blocks automatically. The latest transactions are contained in the latest blocks so it will have to download them before it realises that you have the coins. You don't have to worry about this since it is all automatic.

Edit: To clarify the second question you can always receive coins no matter what. But to see the latest receipts in your bitcoin-qt window and to spend those coins you have to be in sync with the network.


How did these 3 tx make it into a block in the main chain?

The script page of the bitcoin wiki tells us that:

A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero)

To validate a transaction's input, first the input's scriptSig is run, then the scriptPubKey of the output it's trying to spend is run.

The transactions in question have a scriptSig of '1' and the outputs they're spending have a  scriptPubKey of OP_DUP OP_DUP OP_DUP.  Running these will cause a '1' to be put onto the stack, and then for the '1' to be copied three times, ending up with a stack of: [1, 1, 1, 1].  The top stack item is non-zero, so it's fine.

To address your question about crypto signatures, while it's true that any OP_CHECKSIG in either script has to pass there was none in these scripts, so none of them were bad.

The current version of the client rejects "non standard" scriptPubKey scripts in the individual transactions that it receives from the network, and refuses to pass them on, but doesn't appear to do the same for transactions in already-mined blocks that it receives.  So this block was likely mined by the person who made this transaction, using custom software.

Anybody seeing those outputs could have immediately claimed them.  Note however that these easily-redeemed outputs were created and redeemed in the same block, leaving no risk of someone else redeeming them.