Most people think of Bitcoin as a currency, but this is only one use of its protocol & network.

No. It is just a currency. The Bitcoin protocol can be used for different services, but the Bitcoin network is certainly not for gene distribution, or any other form of data back-up. That is not the intention of Bitcoin. You can, however, abuse the protocol to store unnecessary unrelated information. And yes I say abuse, because we as normal Bitcoin users have to download larger blocks for reasons that are opaque to us and no not necessarily concern us (like your genetic code). They are interfering with the purpose of Bitcoin.

Getting to your questions now:
you cannot really store data in Bitcoin in a normal fashion, simply because that is not what Bitcoin is concerned with. You can, however, embed additional information in transactions, which are broadcasted and distributed to the network, in multiple ways, thus essentially storing your information in the blockchain. This assumes you know the storage format of course, since you need differentiate the ordinary transaction information from your additional data.

No nothing prevents the block chain from getting arbitrary large. In practice, however, this will not fill your hard drive so fast (especially if you take Moore's law into consideration), because you need to pay a fee for each transaction per kilobyte.


Does Merkle Tree root hash changed when miner node not found POW nonce?

Not necessarily. If a miner runs out of nonces, there are still other things in the block header he can change. The version number and timestamp can both be changed to effectively increase the number of nonces that can be tried. However there are not as many possible version numbers of timestamps that can be used as they have to fit within certain constraints.

If the miner does not change those, then he will change the merkle root. This is most commonly done by incrementing a value in the coinbase transaction known as the extranonce. This value is stored in the coinbase script where miners are free to place up to 96 bytes of arbitrary data. By incrementing the extranonce, the merkle root will change and the miner can continue with searching through nonces again.

If the miner runs out of nonces and extranonces, he can reselect transactions to be included or reorder transactions, both of which will also change the merkle root.


How to run multiple bitcoin RPC commands through the command window?

Yes, I can generate a new address through the bitcoin-qt command console, but how might I run a for loop to generate 100 different addresses? What kind of file does the bitcoin client take?

You can't. It only accepts specific API commands as described here or by calling the help command in that dialog.

  Can I run a python script through the bitcoin command console?

If by the "bitcoin command console" you refer to QT's dialog then no, you can't. You can run a script from your console, though, if you have Python installed in your system or go for a more elegant approach a use a proper RPC API wrapper.

  How exactly does sending multiple commands to a command prompt work?

It has already been answer above.


What prevents a pool miner from stealing the block if they find the solution?

I found the answer:

  [7] You might wonder why a miner doesn't cheat. If they successfully mine a block, why not submit it themselves so they can claim the full mining reward, rather than splitting it? The main reason is the coinbase transaction has the pool's address, not the miner's address. If the miner submits the block bypassing the pool, the reward still goes to the pool. And if the miner changes the address, the hash is no longer valid. - righto.com


If the supply of Bitcoin is regulated, how could it be said to be decentralized?

Bitcoin is decentralized because the authenticity of all transactions depends on the 'decentralized' network of miners who compute SHA-256 proof of works hashes. The Bitcoin cap is completely arbitrary and doesn't really matter since Bitcoins are divisible to multiple decimal places. Whether there will be 2,100 bitcoins or 21 trillion bitcoins, the cap doesn't really matter. Its all relative. I feel as though the 21 million number was picked with consideration to the number of potential users in correspondence to the size of ints, floats, etc.

Many people debate as to how 'decentralized' bitcoin really is. It seems as though those who create or own ASIC miners are the ones who really have the edge on the market. Some say that certain altcoins that cannot be mined with ASICs may be more decentralized, since CPUs and GPUs are more widespread.


You have the right idea when you wrote:

  allows multiple parties who don't trust each other

Then you proposed:

  just have one miner who publishes...

That would mean that everyone has to trust and rely on that one miner to publish accurately and correctly.

But the whole point of the system is to not trust anyone.

Proof of Work (POW) is the mechanism that creates a trustless system without any central node.

P.S.  There are potentially lots of ways to tamper with a block chain other than forking.   There are double-spends, re-writing old transactions, forging new transactions, and denial of service attacks.  So far, the POW scheme seems to be an effective defense against all of these attacks.


nlocktime transactions are probably the closest thing you have at a protocol level.

Essentially, you can make a signed transaction that pays a bunch of your relatives on January 1st 2016. If you should die before then, the transaction goes through and they get their inheritance. If you are alive on December 31 2015, you would publish another transaction that invalidates the first transaction. If at this point, you want to continue with the same estate plan, you can publish another transaction for July 1st 2016 that pays out the inheritance. And again, on June 30th 2016, if you are alive you would publish another transaction that invalidates the TX about to be published on July 1st.

You can do this as long as you want and a similar transaction can be used in place of a trust (X gets some amount of bitcoins on their 21st birthday). You do have to be careful about this, as the bitcoins you're dispersing must not be moved in any way on the blockchain for the nlocktime transaction to work.


Yes. Channels are associated with a node_id, which is just the public key of the node. The association of a node_id to an IP address (or Onion address) is dynamic and is broadcast over the P2P gossip network when your node connects to another. It only takes a few minutes after reconnection for your new IP to propagate through the entire network.
However, you should reconnect as timely as possible after turning your node offline. If parties you have open channels with find you unresponsive for so long, they may attempt to unilaterally close the channels they have open with you. If they also believe you are offline and not monitoring the channels, they may attempt to broadcast an expired channel state to take more of the balance than they currently have in the channel.


What is this 18-word seed of random letters?

It's an armory backup seed. See https://www.bitcoinarmory.com/. It's a wallet that requires bitcoin core full node so you'll need that as well.


Blockchain.info send may transactions API v2

As of January 2016 Blockchain.info made changes to the wallet API service that now requires you to run a local nodeJS service to handle the calls. This will require you to have root access to your webserver so you will need to use a VPS instead of a basic shared web host.

Also I don't recommend hand-coding the JSON yourself when using sendmany. Instead create an array and then use the json_encode function.

$array = array(
    "1someAddress" => 20000,
    "1someAddress2" => 150000,
    "1someAddress3" => 314159
);
$addresses = json_encode($array);

You're not the only one that has hard time with the new version of their API. If you still need some help check out these resources.

https://www.youtube.com/watch?v=X8jsaf4sEgs
http://btcthreads.com/how-to-setup-blockchain-wallet-service/

I started a PHP library for communicating with the nodeJS service, (still needs work, some functions are missing) https://github.com/coinables/blockchain-wallet-APIv2-PHP-Library


How to read a block nonce in command line?


How do miners know how to remove recently confirmed transactions?

How does a miner proceed in this scenario - dropping the 200 and adding 200 others from the mempool and trying to mine a block?

If the miner is trying to build on top of the block that was received, then he will have to drop the 200 transactions that were included in the other block. He will also not be able to include the other transactions in the next block that were present in the block he received. Apart from this, he is not restricted which valid transaction he can include. He can fill in more valid transactions, remove some or remove all the transactions and just mine the block with coinbase transaction. It's up to his discretion.

  Two blocks are created almost at the same time and they each have some of the same and some different transactions.

Imagine a scenario where two miners find a solution at the same time and both the blocks are valid. As soon as they find the solution, they will relay the block to the full nodes. The nodes will add the block that reaches to them first and add it on top of the existing blockchain. However, when they receive the other block at the same height, they will not discard it but maintain a copy of it. So here you have a blockchain fork, where around half the nodes have a different version of the blockchain at the best height. Other mining nodes will start mining the subsequent block based on the copy of the blockchain that they are seeing (on top of the block that they received first.) Now, one of the miner will find a solution and propagate it to the network. More likely than not, it will not happen to be simultaneous like the previous block. So when that block is propagated, the network converges back to a shared state. Now, as the network converges the full nodes will discard the transactions from the mempool that are already confirmed.


What is the "witness reserved value" for BIP-141?

It's a reserved value.

That means it is reserved for future extensions, but for now there are no rules about it. It's encouraged to not use it for anything, as that may conflict with later use.


Why does Bitcoin-Qt not launch the program, on Mac

Right click the icon and quit Bitcoin-QT, then restart it. I have it on my iMac and occasionally it goes completely unresponsive. If necessary, force quit. See:

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

For instructions on backing up your wallet for future.


Will the miner be provided with reward if a hard fork occurs?

Miners are rewarded iff they produce valid blocks that become a part of the blockchain record. The reward is included in the block itself, so the only way to receive a block reward is by publishing a valid block to the network.
Miners cannot force a hardfork upon the network, doing so would just mean that the network's nodes would ignore those blocks, since they would be invalid by the network's rules. The hard fork blocks would be effectively creating a new network, that only(?) the miner is on, making the blocks worthless. If some users happened to join the hardfork network, so that both the legacy and hardfork networks remained active after the fork, then miners on either side of the fork would be creating blocks that contain rewards of some value.
A majority of miners can force a soft fork onto the network though, if they work to make all non-soft-fork-compliant blocks stale. In that case, any miner that wanted to participate in the network (ie, receive rewards) would need to create soft-fork-compliant blocks. If a minority of miners wants to activate a soft fork, they will not be able to do so. The minority could still mine softfork-compliant blocks, and receive the block rewards for them, but the rules of the softfork would not be enforced on the network at large.


Automated transactions to addresses from database

You need to speak with each wallet through it's JSON RPC API. To speak with the wallet you need to write some code.

If you want to test this api go to your wallet in the menu Help->Debug->Console and write the 'help' command, it will give you the list of all the available commands.

To enable this RPC for external applications you need to create a .conf file. Try to run the wallet from the command line and it should complain that you must create this file. This file contains the credentials that external applications use to access the json-rpc api of the wallet. This is different than the password that you need in order to send the coins.

There are some security considerations that you need to keep in mind:

by default the JSON RPC calls are transmitted in plain text so you need to enable encryption explicitly
minimize the amount of coins you have in the server hot wallet. Instead use one external script to replenish the wallet as needed (also it could compare the addresses in the database with the amount spent)
set the credentials for the wallet access in a secure way


Could blockchain technology be used to implement a verifiable voting system?

Blockchain voting could be done easily. Each citizen could send an amount of bitcoin (say, 0.1mBTC) to the addresses of their favorite candidate address.
One obvious problem is that anybody could vote. A trusted third party could set up a site where each citizen gives his bitcoin address with his id number. There would be a window to give everyone a chance to vote (and, if one wishes to, change it).
After voting, the trusted third party could check the blockchain for the last transaction each citizen made.
We would still have to trust this party in counting valid votes, because presumably, it would be the only one with access to the database.
The database could be available once the election is over to allow complete transparency, but then, voting wouldn't be private anymore.
Furthermore, currently at 1MB per block capacity on the bitcoin blockchain makes voting on it a very big challange if not impossible.


Why is syncroning taking forever on BitcoinCore

It depends of your internet speed as the QT has to download the data. I would suggest using electrum if you dont want to download everything.


Can't pay with Electrum - invalid password?

Be sure that you are entering the correct password you've set (be careful with added blank spaces, keyboard localization...). You can try to crack your own password if you remember most of it.

Maybe the transactions that you remember were on imported keys? If so, they are only in that encrypted wallet file. Your seed can only restore the keys derived from it.

Electrum servers are all the same and give the same information (they only differ from hardware).


Hack/Use a Butterfly bitcoin miner as gaming pc

This is not possible.

ASIC mining devices like those sold by Butterfly contain hardware that is capable of computing SHA256 hashes at high speed, but nothing else.  They are not general purpose CPUs and cannot be reprogrammed to run other code.

They might contain a simple microprocessor or microcontroller to control the ASICs and interface with the host computer, and in principle you could run other code on that, but it would have to be your own custom code as these chips are presumably not x86, and the performance is probably too low to play anything more complex than Pong.  Moreover, these devices have no graphics hardware and no obvious way to connect it.  It would be like trying to play Call of Duty on your microwave oven.


How can I limit the mining to specifics miners authentified by private key or something like that?

I'm not sure I see why you'd want to do it (increased centralization, likely decreased anonymization, and decreased mining incentive are generally considered bad things), but here's how I think I would do it, in general terms.

Have one (or more) master public keys hardcoded into the app. Have a special type of transaction that must be signed by a master's private key that authorizes an address to mine. Only blocks that have a reward, with the reward paid to an authorized address are considered valid. The address-authorization could exist in the same block that it's mined in, or any prior block in the chain.

(optionally) Allow blocks with no reward.
(optionally) Have another special type of transaction that authorizes
a new master key, to try to ensure that you won't be left without
valid masters in the future.
(optionally) Make the authorization limited by time and/or number of
successfully mined blocks, so that it must be renewed periodically.


Transaction delayed >12 hours by Satoshi Bitcoin client

That transacation has over 1,400 confirmations. I think you might need to run your client with the rescan option on. (That rescans the blockchain for transactions it might have missed)


Configure esplora to point to the bitcoind servers ip address - Part 2

"Address already in use"

It probably means you have another instance of the process running on the background


How to reduce Bitcoin loaded wallet memory?

There is different way to optimize, configure or reduce the memory usage of bitcoind, I invite you to see this page from the bitcoind github who talk about it: https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-memory.md


Listening to all transactions of the Bitcoin network

You can do this using BitcoinJ by implementing the PeerEventListener interface.

The OnTransaction will be called every time a new Transaction is broadcast out and received from a Peer.


what happens if i sent bitcoin to a clubcoin address (address starts with a C)?

There are no Bitcoin addresses defined that start with a C (only P2PKH addresses which start with 1, P2SH addresses which start with 3, and P2WSH or P2WPKH addresses which start with bc1).

As a result, it is impossible to even create a transaction to such an address. There is nothing to refund of nofify - it's simply impossible to perform.


As mentioned in Daniel's comment, if you are trying to connect to the Bitcoin-client that gathers the information for the Blockchain.info site this is not trivial as the IP does not match the one of the website.

If you are just interested in adding the same nodes the site is connected to, that's no problem.

With Linux or OS X you'd do something like this:

curl -s https://blockchain.info/connected-nodes | \
grep -oE '([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)' | \
sort -u

which gives you a sorted list of IPs to connect to. If you want a complete string to just append to your bitcoind client as options then try this:

curl -s https://blockchain.info/connected-nodes | \
grep -oE '([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)' | \
sort -u | \
sed 's/.*/-addnode=&/g' | \
tr '\n' ' '

this additionally adds the -addnode= prefix to each address and joins the line.


How many Integer Operations on a GPU are necessary for one Hash?

The ALU OP numbers are correct. The numbers vary based on the video card but are basically in the range of 1,300 to 1,700 operations per double-hash. On the x86, you need more instructions (around 3,700 - 4,500 depending on the exact CPU) but these CPUs can average more than one operation per clock cycle, so you can't convert instruction counts directly into execution speed.

All sensible mining implementations (CPU or GPU) attempt more than one hash at a time. On an x86 CPU, it's typically around four hashes at a time (one per core). On a GPU, it's more like 1,000 - 3,000 hashes at a time (one per core). Hence the superior hashing performance of GPUs.


How to return Bitcoins to sender through Bitcoin API?

If the address is in your wallet, gettransaction includes the input addresses:

http://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

If this is done by an agent where the addresses might not be in the wallet, v0.7 getrawtransaction gives you access to those transactions.

http://en.bitcoin.it/wiki/Raw_Transactions

There are other tools that you can use to build this capability as well.

libBitcoin
Armory (see Extras)
Bitcoin ABE


Just to give a little background first: Bitcoin uses a so-called UTXO model. You own UTXOs (or "coins", to give an analogy). Every coin has a value (which can be any number of satoshis) and has an owner (script) "stamped" into it. Every transactions "melts down" a number of existing coins, and "forges" new coins. The value of the new coins cannot exceed the value of the melted coins. The difference between the amount melted down and the amount forged is the fee of a transaction.
This means that the protocol really no concept of a "balance". There are just coins. You can have 3 BTC in your wallet, consisting of a 1 BTC coin X and a 2 BTC coin Y. These can be stamped with the same script (address) or not. It doesn't really matter - a wallet can consist of many addresses.
So say you want to pay 1.5 BTC to someone else, who has given you address A. Your end goal is creating a transaction that consumes the 2 BTC coin, and produces a 1.5 BTC coin (to the payee) and a 0.5 BTC coin (minus fee) back to a new address of your own wallet (called a change address). It's also possible to consume both the 1 BTC and 2 BTC coins, and outputs 2x a 1.5 BTC coin. Let's assume that's what you're doing.
How would you do this using the Bitcoin Core RPC? There are a number of ways:
The most automatic way
If you're using Bitcoin Core's built-in wallet (i.e. the Bitcoin Core wallet is what created the addresses involved, and it manages your coins), you can make it do everything. Just do:
bitcoin-cli sendtoaddress <A> 1.5

Where <A> is the recipient address. It will automatically determine which of your UTXOs to use, and create a transaction that spends those, pays <A> and creates change, then sign the result, and broadcast it on the network.
Manually but using the wallet still
If you want more control, you can perform the things sendtoaddress is doing one by one yourself, allowing you to observe the intermediary results.
The first you do is create a raw transaction that pays <A>, and nothing else:
bitcoin-cli createrawtransaction '[]' '[{"<A>": 1.5}]'

It will report a hex raw partial transaction with just that one output, and no inputs. Next you want to add inputs and change. You could do that manually (see further), but you can let the wallet do this for you. This is what fundrawtransaction is for.
bitcoin-cli fundrawtransaction '"<output from CRT>"'

This will give you another unsigned raw transaction, but now one that includes inputs (sufficient to cover the 1.5 BTC you're trying to send) and change (for whatever is left of the inputs spent after subtracting 1.5 BTC, plus a reasonable fee based on network estimation, and estimation of how big the transaction will be after signing).
Then you sign it, and broadcast it.
bitcoin-cli signrawtransactionwithwallet '"<output from FRT>"'
bitcoin-cli sendrawtransaction '"<output from SRTWW>"'

The advantage of this approach is that you can inspect the intermediary results at every stage (using decoderawtransaction amongst others), or make many changes to the process. Perhaps you have a multisig wallet with another device - and you need to make a pass by there doing another signrawtransactionwithwallet (or whatever equivalent that other device/software has for working with raw transactions).
Fully manual
If you want the most control, you can do everything manually - including the ability to include inputs that don't belong to your own wallet. This is the example you gave in the question, but if that's all you plan to do, you're much better off using one of the previous two methods.
As you pointed out, you first need to gather a list of UTXOs that can be spent. This can be done with listunspent, but you can also include other UTXOs - including ones from other people if you're participating in a CoinJoin transaction for example.
bitcoin-cli listunspent

Then you have to construct the (full) raw transaction, including the inputs you want to use from before, the output to the recipient, and including a change output back to yourself. If you want that change to go to you own wallet, you can use getrawchangeaddress (which is like getnewaddress, but will treat outputs to it as change rather than an incoming payment). You also need to manually estimate the vsize of the transaction will be after signing, determine a fee to use based on that (the block space market prioritizes transactions based on fee per vsize), and subtract that fee from the change you're creating. This is a bunch of work, and mistakes are easily made.
Next you'll need to sign the transaction. If you have the private key in your own wallet, you can use signrawtransactionwithwallet like before (note that signrawtransaction from your example no longer exists; it has been split up into signrawtransactionwithkey and signrawtransactionwithwallet). If not, you can either use signrawtransactionwithkey if you have the private key, or you could transfer the raw transaction to other devices/people, and sign there too.
Finally you'd use sendrawtransaction just like before.
Using PSBT
At this point I need to point out that all the raw transaction based transaction APIs have been superseded by the PSBT-based RPCs (see BIP 174). If you try to use the RPCs above you'll notice they really only work with simple scripts, and you need to pass a lot of information along everywhere. In particular, signrawtransactionwithkey will need information about the UTXOs again, the scripts used in those, what type of scripts they are. This is pretty painful, and easy to screw up.
PSBT is an interchange format for transferring/storing partially signed transactions, along with any information signers or other participants may need to be able to sign. It'll convey UTXOs, script information, information about the keys in it, ...
The equivalent of "manually but using the wallet still" would be:

walletcreatefundedpsbt instead of createrawtransaction + fundrawtransaction
walletprocesspsbt instead of signrawtransactionwithwallet
finalizepsbt to convert a fully-signed PSBT to a raw transaction
sendrawtransaction like before to broadcast the result.

The equivalent of "Fully manual" would be:

createpsbt instead of createrawtransaction
walletprocesspsbt instead of signrawtransactionwithwallet. There currently is no equivalent for signrawtransactionwithkey, but PSBT is supported by various other pieces of software (most notably, HWI which allows PSBT signing and other operations with hardware wallets.
Again, finalizepsbt and sendrawtransaction like before.

PSBT has a lot more utility functions, such as combinepsbt (mostly for multisig), joinpsbts (for doing CoinJoin-like things), decodepsbt and analyzepsbt that can tell you what to do next, utxoupdatepsbt to gather information from the UTXO set and add it to a PSBT file (which works even if your Bitcoin Core wallet is not involved), etc.
TL;DR
You can use a workflow with or without fundrawtransaction. If you don't use it, you have more manual control and aren't forced to use the Bitcoin Core wallet itself.


How to generate public and private key pairs from the 12 seed words in python

Please try the following demo, and the result is same with https://iancoleman.io/bip39/.

$ python3.6 test.py
{'addr': '1A9vZ4oPLb29szfRWVFe1VoEe7a2qEMjvJ',
 'coin': 'BTC',
 'mnemonic_words': 'aware report movie exile buyer drum poverty supreme gym oppose float elegant',
 'privatekey': 'L3g3hhYabnBFbGqd7qReebwCrRkGhAzaX4cBpYSv5S667sWJAn5A',
 'publickey': '029dc2912196f2ad7a830747c2490287e4ff3ea52c417598681a955dcdf473b6c0'}

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

import pprint
import binascii
import mnemonic
import bip32utils

def bip39(mnemonic_words):
    mobj = mnemonic.Mnemonic("english")
    seed = mobj.to_seed(mnemonic_words)

    bip32_root_key_obj = bip32utils.BIP32Key.fromEntropy(seed)
    bip32_child_key_obj = bip32_root_key_obj.ChildKey(
        44 + bip32utils.BIP32_HARDEN
    ).ChildKey(
        0 + bip32utils.BIP32_HARDEN
    ).ChildKey(
        0 + bip32utils.BIP32_HARDEN
    ).ChildKey(0).ChildKey(0)

    # return {
    #     'mnemonic_words': mnemonic_words,
    #     'bip32_root_key': bip32_root_key_obj.ExtendedKey(),
    #     'bip32_extended_private_key': bip32_child_key_obj.ExtendedKey(),
    #     'bip32_derivation_path': "m/44'/0'/0'/0",
    #     'bip32_derivation_addr': bip32_child_key_obj.Address(),
    #     'coin': 'BTC'
    # }

    return {
        'mnemonic_words': mnemonic_words,
        # 'bip32_root_key': bip32_root_key_obj.ExtendedKey(),
        # 'bip32_extended_private_key': bip32_child_key_obj.ExtendedKey(),
        # 'path': "m/44'/0'/0'/0",
        'addr': bip32_child_key_obj.Address(),
        'publickey': binascii.hexlify(bip32_child_key_obj.PublicKey()).decode(),
        'privatekey': bip32_child_key_obj.WalletImportFormat(),
        'coin': 'BTC'
    }

if __name__ == '__main__':
    mnemonic_words = "aware report movie exile buyer drum poverty supreme gym oppose float elegant"
    pprint.pprint(bip39(mnemonic_words))


Re-index/Re-download from specific height?

A reindex will not redownload the block. However, after safely shutting down Bitcoin Core, you can delete the block file containing that block. When you start it again, you will need to reindex, but once it gets to the blocks that you deleted, it will redownload them.


Does block size effect Miner's Hashing speed?

Only block header gets hashed, and it has fixed size, so the total block size doesn't matter.

From Wiki:Block hashing algorithm

  The body of the block contains the transactions. These are hashed only
  indirectly through the Merkle root. Because transactions aren't hashed
  directly, hashing a block with 1 transaction takes exactly the same
  amount of effort as hashing a block with 10,000 transactions.


How many transaction and btc have been cancelled?

How many btc have been transferred in orphan blocks, but then never
  included in any later block?

This is not a statistic that's normally published by anybody, as far as I can tell.

  How many btc have been transferred in zero-confirmation transactions that have never been included in the blockchain? How could one find this info?

The data necessary to do this analysis is out there, though it's really hard to know if it's complete.

Blockchain.info has a list of orphaned blocks back to March of 2014. It's hard to prove whether this list is complete since orphaned blocks don't propagate well (hence their being orphaned). But given these 400 or so orphaned blocks, you can grab all the transaction hashes, see how many of these transaction hashes can not be found in other blocks and that should set an upper bound for possible fraud activity.

You'll also have to see if the transactions that spend certain inputs in the orphaned blocks end up going to the same outputs but have a different signature and thus a different transaction hash. You should eliminate those as well.

Finally, you'll have a set of possible fraudulent activity for the past 11 months or so. Not perfect, but given that very few have any incentive to keep orphaned blocks around, this is a good a method as any.


Is the transactions in one block effect the hash of the next block? How?

What i'm asking is, does the contents -transactions- of one block effect the hash of the next block? if so, how it happens?

Yes. The block hash of block X is explicitly included in the header of block X+1. So if you change the transactions in block X, it will affect the hash of block X, and that would change block X +1 as well.

  For example, lets say that we mined 10 blocks. Then, we hacked block number 5 and changed the transactions.

The nodes on the network that already know about block 10 would not accept your new block 5 because it is a shorter chain (less work than the chain that is at block 10). They can recognize the new block 5 as being altered because the longer chain does not include it.


BITCOINJ: how to make my wallet aware again about change of my transaction status after my server restart?

Try synchronizing your wallet again, you can delete the file .spvchain


Building many btc adress on your website for users?

run a bitcoin client with json-rpc enabled. you can then communicate from you backend with this bitcoin rpc interface. See

https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)

https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list


Why does witness use count instead of length?

Note that witnesses are not scripts. They do not contain opcodes. They are stack elements. Witnesses do not have explicit opcodes (witnessScripts are scripts but are single witness stack elements so their opcodes don't count).

The count is used as it clearly delineates between the end of the stack items for an input and the beginning of the stack items for the next input. The use of a count follows the standard serialization methodology used elsewhere in Bitcoin for serializing arrays of items. In this case, the witness data for an input is an array of arrays of bytes (in code, that's std::vector<std::vector<unsigned char>>).

So, following the standard serialization method of std::vectors, at the top level we get the number of items in the next level down (i.e. the number of std::vector<unsigned char> elements) which happens to be the number of stack items. Then the next level of serialization we get another length for the number of items in the level below (i.e. the number of unsigned char in each vector). So now we have the length of each stack item. Then comes the stack item itself.

The reason this method was used for segwit is likely because stacks in Bitcoin Core are implemented as std::vector<std::vector<unsigned char>>. Furthermore the serialization of vectors in this manner is used everywhere in Bitcoin so the serialization code for this basically already existed in every existing wallet software.


Assuming that the block size fork goes through, will the Bitcoin developers use the alert key to tell people to upgrade?

Yes, according to Gavin Andresen via Reddit.

Even if they didn't to do so, Bitcoin Core already has two other mechanisms which will produce automated alerts as the hard fork approaches: one which will take effect before the hard fork occurs, and one after (as per BIP-50).


What is the computational power required for just verifying maybe two transactions

Transactions can be verified as being valid by inexpensive software, such as a cellphone.

Transaction confirmation requires a miner to include the transaction in a block. Confirmation is not done on a transaction-by-transaction basis, so "how much power to confirm just a couple of transactions" is not really a good question to ask. Instead you could ask "How much computational power do you need in order to mine a block?", with the understanding that many transactions can be included in a single block.


How do I clear a stuck Bitcoin transaction.The other answers did not help my situation

if the transaction did not use the optional replace-by-fee scheme, then after 14 days it should be dropped from all mempools and the sender would have the coins back.

if the sender is unavilable or uncooperative and you need the transaction to go through, look for miner priority services; they allow you to pay a fee to get the transaction prioritized.


Can anyone use your private key if its encrypted on bitcoin core?

If you trust someone else to provide a private key for you, it doesn't matter if you encrypt your wallet. They will forever be able to control and spend your money at their leisure with no regard to any password you add.


Account system is deprecated. Now, how can we set a "from account" when using the "sendmany" function?

The problem is, for instance, when I call sendmany method to send BTC 1 out of my service node, the asset distributed in the user addresses of my service would be randomly reducedand the total reduction volume should be BTC 1. In other words, I cannot extract the BTC 1 certainly from the targeted user address whose owner should have used our service to pay for something worth BTC 1, and the burden of BTC outflow shall be shared for all.

It never did this in the first place. The "from account" never did what you described; it did not select coins from addresses belonging to that account. Rather what it did was it would select coins from the entire wallet (so "from" all accounts) and the resulting transaction would say that it was reducing the "from account"'s balance. At no point in time did the "from account" parameter effect what coins were being selected.

If you truly want user address separation, you can use the multiwallet feature where each user has their own wallet file with its own keypool, private keys, transactions, etc.


How to restore locally a MyWallet backup?

I wrote a small Python script which can be used to decrypt your encrypted MyWallet.  It does the same as the MyWallet JavaScript, only in Python.

Edit: the code below seems to be outdated, here's a working version as of May 2012.

Copy the following into a file, make it executable, then run it:

#!/usr/bin/env python
import base64, hashlib, hmac, json, sys, getpass
from Crypto.Cipher import AES
from Crypto.Hash import RIPEMD, SHA256

base58_chars = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'

def prompt(p):
    return getpass.getpass(p + ": ")

def decrypt(encrypted, password):
    encrypted = base64.b64decode(encrypted)
    iv, encrypted = encrypted[:16], encrypted[16:]
    length = len(encrypted)
    encrypted += ' ' * (15 - (length-1)%16)
    hash = (hmac.new(password, iv + "\x00\x00\x00\x01", hashlib.sha1).digest() +
            hmac.new(password, iv + "\x00\x00\x00\x02", hashlib.sha1).digest())[:32]
    clear = AES.new(hash, AES.MODE_OFB, iv).decrypt(encrypted)[:length]
    return clear

def base58_decode(v):
  value = 0; ret = ''
  for c in v: value = value*58 + base58_chars.find(c)
  for i in range(32):
      ret = "%c"%(value%256) + ret; value /= 256
  return ret

def base58_encode(v):
    value = 0; ret = ''
    for c in v: value = value*256 + ord(c)
    while value > 0:
        ret = base58_chars[value%58] + ret; value /= 58
    return ret

def to_sipa(s):
    version = 128 # or 239 for testnet
    key = chr(version) + base58_decode(s)
    return base58_encode(key + SHA256.new(SHA256.new(key).digest()).digest()[:4])

clear = decrypt(prompt("encrypted wallet"), prompt("password"))
obj = json.loads(clear)

if (obj.has_key('double_encryption')):
    print("wallet uses double encryption")
    password = obj['sharedKey'].encode('ascii') + prompt("2nd password")
    for key in obj['keys']: key['priv'] = decrypt(key['priv'], password)
for key in obj['keys']: key['priv_sipa'] = to_sipa(key['priv'])
print(json.dumps(obj, indent=4, sort_keys = True))

It will prompt for the wallet backup and one or two passwords, depending on whether the wallet is single or double encrypted.  Paste the wallet backup in rather than saving it to a file.

You'll probably need Python 2.x.  I've been unable to find a package of the pycrypto stuff for Python 3.  Apparently it will be available in the upcoming 'precise' Ubuntu release.

Edit: It seems the backup format has been changed and so this script doesn't work on recent backups.


Is transaction malleability an issue when receiving payments?

If you wait for a confirmed transaction you will be fine. The common mistake people/large exchanges make is when they constructed "withdraw" transactions from unconfirmed "deposit" transactions. Those invalidate quickly due to double spend rules. The Satoshi client does this as a last resort when picking unspent outputs.

The code that deals with it is here, removeConflicts is defined here.


That error means that the block got corrupted somewhere so it became invalid. The only way to fix this is to re-download the block.

To do so, first stop Bitcoin Core. Then go to the Bitcoin Core data directory and then the blocks folder within that. Delete the highest numbered blk*.dat and rev*.dat files. Then start Bitcoin Core again. When it asks whether you want to reindex the databases, choose yes. Bitcoin Core will now rebuild the block indexes and then continue with syncing once it is done. Note that while it is reindexing, it will look like it is syncing the blockchain again, but it is not. It is using the data on disk to build the block index and chain state until it needs to download blocks again to continue syncing.


How can the blockchain keep only one version of the ledger equal across all nodes

Each miner will take the first valid block they received and begin working on the next block with this as the previous one. They do not achieve any consensus on whether X or Y are the valid block at this stage, and some miners may be working on X, with others working on Y.

The tie is broken as soon as one of the miners creates block Z. If the previous block of Z is X, then the consensus is reached that X was the correct block and Y is discarded by miners who were working on it. Z now represents the longest chain and so all miners will begin working on this.

There may be several disputes in a row, and each miner will just work on the block they received first. The dispute will eventually be resolved because the probability that blocks will be mined simultaneously for several blocks in a row is very low.


Trying to find the raw genesis transaction length

Unfortunately, the genesis block is not indexed in most altcoins (because they forked from bitcoin and kept the same bug), so you can't really get access to it via the RPC methods.

What you could do instead:

Use a block explorer that will tell you the size of the transaction. For example, blockchain.info makes this information available (204 bytes).
Find the parameters file and put a print the size of the genesis block to stdout.

The second option basically entails putting the following lines at the end of CMainParams() and then compiling.

CDataStream ssBlock(SER_NETWORK, PROTOCOL_VERSION);
ssBlock << genesis;
printf("block: %s\n", HexStr(ssBlock.begin(), ssBlock.end()).c_str());
printf("block size: %i\n", (int)::GetSerializeSize(genesis, SER_NETWORK, PROTOCOL_VERSION));
printf("tx size: %i\n", (int)::GetSerializeSize(genesis.vtx[0], SER_NETWORK, PROTOCOL_VERSION));

This will print the raw block data, it's size, and the transaction's size. (Note, this is untested, but something along these lines should work)

NOTE: It's possible, although not the norm, to put multiple transactions in a genesis block. Just check that your assumption is correct.


Any way to create a multisig address from Bitcoin addresses (instead of public keys)?

While you can't generate a multisig address directly from a number of non-multisig addresses, you can easily get their public key on a single call. In bitcoin-core you have to call validateaddress and then retrieve the pubkey field from the response, which is the hex value of the raw public key that you can then use to generate your multisig.


Well, the answer to this question mostly depends on what kind of implementation you choose for your multiple-input 32-bit wide adders (there are several different solutions to this speed versus gate count trade-off). Usually, when using the term "gate equivalent," engineers are talking about FPGAs, where it is a cool marketing slogan that tries to persuade you that the FPGA is much more powerful that you'd think from its number of logical elements because some of them can implement complicated circuits that would need a high number of gates otherwise. In this case, you will almost certainly use whatever special provisions your FPGA chip has for wide additions (and your GE count will depend on whatever its manufacturer's marketting department believes to get away with for translating that into "typical" gate counts of comparable circuits).

If your goal is to estimate how much of SHA256 you can fit into a given FPGA, you may be even better off comparing with what others have achieved. This may take a bit of digging, but will give you good estimates. The FPGA section of this wiki page for mining hardware comparison could give you initial links. I don't have numbers at the ready, but I remember having concluded ca. 15 month ago that those FPGAs that were mature enough then to have single-unit bare chip retail prices around 100 $ (the most computing per money you could get then) tended to be just about big enough for a fully unrolled and fully pipelined double-SHA256 implementation.


How do I get merkle branches using the Stratum protocol?

I'm using the HTTP post version of the Stratum protocol and content type "application/stratum".

The HTTP version of stratum isn't supported in the later server versions, it's unlikely you'll be able to use them in any sort of capacity in the future. When connecting to the TCP+SSL version of electrum-server your command works perfectly, though the block height field in your example should be an integer and not a string.

telnet electrum.be 50001
Trying 88.198.241.196...
Connected to electrum.be.
Escape character is '^]'.
{ "id": 1, "method": "blockchain.transaction.get_merkle", "params": [ "967d009ee103340d6762819ebf452107561423fe97b04fbf501594f231e212c4", 369863 ] }
{"id": 1, "result": {"merkle": ["d844420b0f01398953b809b844bc9a5987f41d1373dab3180b6b4fe4de8633c4", "3c1f63dae13e84aaba94d6ee12c7b48fa7b470eacfbe6e183ba008b7cbc3725c", "0c5141f62f1ad58a6ebcee98868451ff392bc49bfb6daa5e4f492b6d175812cf", "e414fd7ee39a83b7bd524f98ed09efa279a97fecbeeca68087de384eda71fc31", "47fbf181989f2549d0d7a9fee2337ea60295059df0c0267cca173fd43b8e8596", "bc441c955a6d9bc629e3a8e428aa7670d2bf631a9d11887bb4ad6b534fcf4817", "1985800e12a150e6196ac07119278ea84ad296f1d8b2c88b2c85f61035f6a7cd", "fc02dfab3083ca9185bce4e8b9357b5aacacce2172c969ac543da04eaa1c0c1d", "6a36f10f34da6d66fdf75d4d97e0796106e7594409d354b8419a248231ab6935", "cbc02af67b294fe7bad08a69f9435b520f8f89fa221583e0a84c8d9c9dc469a0", "1043c7a6b9b4c42243e84a49a1f40476692b5d36d2f64dfb14409490ca3dfad2", "fbbaec1ca9d29ba9ee6a89214428556827b4e5a254de59de5adabbabb2621f54"], "pos": 2917, "block_height": 369863}}


There are two sites that I know of: bitcoin-rigs.com and bitcoinrigs.com

If you have a local computer shop near you, you could also order the parts and ask them to mount. There is a wiki entry for mining rigs that has a few standard configurations (including two setups with 5850s).

You might also want to check the Marketplace section of the bitcointalk forums. Sometimes people sell used rigs there.


Inconsistent mining profitability calculations

The problem is that you're not using the correct conversions:

  The reason I am dividing difficulty by 100 above is so I can keep using my hashing power in TH/s

There are 1,000 GH to a TH.

  difficulty / hashrate[GH/s] = time[s]

difficulty and hashrate stand in the following ratio:

difficulty = hashrate[H/s] / 7158388.055

Note that the formula uses hashes not gigahashes.


Nxt aliases do not expire now, and probably never will (since it would be unfair to change the rules after people paid for them). There is an upcoming change to allow them to be transferred, so you may then be able to buy them from squatters.


how does the creator of Bitcoin get paid?

The creator, Satoshi Nakamoto (referred to as a "he" hereafter even though it might be a woman or a group of individuals), seems to have mined many of the early Bitcoin blocks. There have been several analyses identifying blocks mined by a specific single program, based on the nonce and so on, and it is mostly rational to assert that this was Satoshi.

There are other theories as to who this miner is, but it is naive to imagine that the system's creator wouldn't at least be somewhat interested in mining and supporting the network, and the evidence is consistent with that.

Either way, those mined coins have not moved as yet, and it is possible that he burned the private keys for them.

Of course, it is likely that there are other blocks he mined that have not been identified as his, and he has a reasonably sized stash he can spend as he sees fit.


In order for a node to relay a transaction, the transaction must satisfy the node's minRelayTxFee. This fee rate cut off is by default set to 1000 satoshi per kvB (= 1 satoshi per vbyte).
Your first transaction could get included in a block if the miners were aware of it, but likely it doesn't reach them.
You should try to either broadcast the first transaction with 1 sat/vbyte or to directly submit them to miners via their respective APIs.

Update 2019-09-29:
There was recently a change of the Mempool Acceptance rules merged to Bitcoin Core that allows multiple transactions to be relayed as a package. This explicitly facilitates transmission of CPFPed transactions that wouldn't usually meet the fee minimum of the receiving node.

The Bitcoin Optech Newsletter #65 describes the pull request as follows:

  Bitcoin Core #16400 refactors part of the mempool transaction acceptance code. We don’t usually cover refactors, but this one has a tantalizing comment: “this is in preparation for re-using these validation components for a new version of AcceptToMemoryPool() that can operate on multiple transactions (‘package relay’).” Package relay could allow nodes to accept a transaction below the node’s minimum feerate if the transaction came bundled with a child transaction whose fee was high enough to pay the minimum feerate for both it and its parent. If widely deployed, package relay would allow users who create transactions a long time before broadcasting them (e.g. timelocked transactions or LN commitment transactions) to safely pay the minimum possible fee. When it came time to broadcast the transaction, they could use Child-Pays-For-Parent (CPFP) fee bumping to set an appropriate fee for the current network conditions.


Importing an arbitrarily created Master Private key to Bitcoin Core

It is currently not possible to import a master private key into Bitcoin Core.


How did transaction fees work in the version 0.3.24?

The minimum transaction fee is zero.

Transaction fees are enforced in two places. First, a client can be configured not to accept or relay a transaction that doesn't include a sufficient fee. Second, a miner can choose which transactions to include in any blocks they mine and will typically try to include transactions with the highest fees.

Most normal transactions will have a required fee of zero. The three most common exceptions are:

If a transaction uses coins that were very recently received, a fee of .005 bitcoins may be imposed.
If a transaction "gathers" bitcoins from a large number of other transactions, a fee of about .0002 bitcoins per input source may be imposed.
If a transaction "spreads" bitcoins to a large number of destinations, a fee of about .0002 bitcoins per output may be imposed.

This is because these types of transactions tend to look a lot like spam transactions used to maliciously load the network. Currently, there are still clients and miners that will accept any valid transaction regardless of the transaction fee. So if you're willing to go to the trouble, you can get any transaction into the public chain eventually with no fee. (Just manually configure your client to connect to them and be patient.)


Is there a webpage showing some of the latest orphaned blocks?

If you're looking for an absolute authoritative source that will show you latest orphaned blocks, its impossible and anyone that claims otherwise is scamming you.

Why?

The Bitcoin network is a fully decentralized peer-to-peer network, therefore in the event of a temporal split (i.e. two blocks of the same height racing in the network), a block-tip that was accepted to extend the canonical chain will not relayed to adjacent peers (though it it is stored locally for record-keeping purposes). In that sense, it is only natural that no one can tell with absolute certainty of the existence/or the non-existence of the latest orphaned blocks.

You can increase your likelihood of capturing all orphaned blocks by sampling across more nodes that you personally run. But the only way for you to get the them with absolute certainty is for you to own the entire network -- which is impossible.


As far as I know:

Yes, Bitcoinica's prices were based on MtGox ticker
Using the MtGox price, they had an algorithm to build their spread (you will always buy on bitcoinica at a higher price and sell at a lower price than the reference mtgox price, thats where a broker like bitcoinica makes profits).
Yes, Bitcoinica had some charts, where you could see the reference price, and the spread (the graph was called "daily quotes"), so yes you were able to check the price and spread and understand why you had been liquidated.

No guarantee on these answers, I'm not in the Bitcoinica code, this is just how I understand this.


P2PKH why the hash and not the address itself

You can also do Pay-to-Public-Key.

But public keys are bigger in size that public key's hash. Thus, Pay-to-Public-Key-Hash was invented by  Satoshi to make bicoin addresses shorter.

Compressed public key - 33 bytes

Public key hash - 20 bytes


If the blockchain records all transactions, how does losing your wallet imply that you lose your Bitcoin?

You've answered your own question - "all you would need to be able to do is prove that that address belonged to you." To prove the address belongs to you you need the associated private key, which is secret and typically kept on your computer. If you lose your key you are no different than any other pretender to the address.

This is why you must back up your wallet file containing the keys, so should something happen to your computer you can still access the coins using your backup.

Remember, this is a decentralized digital currency. There is no clerk you can go to with some documents who can authorize that this is your address. You must prove ownership in a universally verifiable digital way - by using your private key to provide a cryptographic signature.


Does RevokeSSL Require Self-Signed Certs to Work?

RevokeSSL requires one of the following:

self-signed certificates
certificates signed by CAs that are willing to include extra information in what they sign.

This is because there is a false revocation attack available if the certificate does not contain the information (the address that's going to be used to create the verification transaction) needed for RevokeSSL to work.

Victor (the victim site owner) is up against Mallory (the malicious adversary who wants to harm Victor's site reputation):

Victor creates site, creates certificate, but doesn't include the RevokeSSL verification address.
Mallory obtains Victor's site certificate.  (He does not need to obtain any private keys.)
Mallory creates a RevokeSSL-formatted transaction, containing the OP_RETURN value that is the hash of the certificate he wants to falsely revoke.
Some time later, Mallory "spends" the transaction, revoking Victor's site certificate.

If the hash of the certificate were used to search the OP_RETURNs, this attack would work.  If the original certificate includes the address used to create the verification transaction (and the verification transaction includes the hash of the certificate in question as OP_RETURN), then this attack cannot falsely revoke the certificate.


As you can see in the protocol documentation the inv-object contains a field inventory (Inventory Vector).

Inv-Object:

Inventory Vector:

You need to check the type field to know what the other node is sending. You will always receive a hash value, which is the identifier of a block or transaction.


Is is possible to prove you possess an amount of BTC without actually spending it?

You can sign any text with the private key you own and anyone can verify that with a public key associated with a given Bitcoin address. As long as you make the message relevant to the conversation, say "This is LethalFractal, at 2013-09-07, I claim ownership of address 1234567890... as a proof for negotiations with John Smith", the person can know that it is in fact you owning a given address, and since they can check the balance of that address, you will have proven that you have access to that money.


When you buy a bottle of soda at the convenience store, where does the money go?

The money goes to the party that sold it to you -- that party owned the bottle before you owned it.  You might be able to trace ownership of that bottle all the way back through the supply chain, to the point at which it was manufactured.   It probably had several prior owners before you got it.

Bitcoins are like a commodity that works the same way.

If you purchase from a market exchange (like Mt. Gox), here's how that works.  Mt. Gox, like most market exchanges, operates using deposit accounts.

To buy $100 USD worth of bitcoins you must have deposited $100 to your account with the exchange.  To sell 10 bitcoins you must have deposited 10 BTC to your account with the exchange.

So when you trade your $100 USD for someone else's 10 BTC, your $100 goes to their account, and their 10 BTC goes to yours (if there were fees, the amounts would be adjusted appropriately to cover fees).

Then when you withdraw your BTCs, the exchange will send that amount of bitcoins from the exchange's wallet to yours.  When the seller withdraws the USDs (or whatever currency the coins were sold for), the exchange will send those funds.  This generally occurs through the banking system, with the funds eventually arriving in the seller's bank account.

There are other types of bitcoin sellers -- direct sellers, who have an inventory of bitcoins that they purchased previously, or will make a trade behind the scenes to be able to deliver your order.  So the dollars from your purchase goes to them in exchange for the bitcoins they owned.

Then there are other types of trades which involve risk.  These include financial derivatives where you may speculate on bitcoins using cash but until you actually withdraw those bitcoins to your own wallet, you only own a claim against those bitcoins (or against a financial position on bitcoins).  But that is an example where there is not a simple buying and selling of bitcions at a certain price.

Now every bitcoin in existence originated from mining.  Mined coins arrive 50 at a time about once every ten minutes.  They are earned by a mining operator (or mining pool and distributed to the mining operators who were mining).  To mine, one must buy expensive hardware, expend the effort to build and operate the equipment, and purchase the electricity expended during mining.  The mining operators can then deposit their bitcoin proceeds to an exchange to sell them and receive cash in exchange.


solo mining payout maturity vs pool mining

I'm still not completely sure that I am understanding your question correctly, but let me take a guess.

As you know, when a block is first mined, the coins from its block reward are considered "immature".  They may not be spent until 100 blocks later, or in other words, until the coinbase transaction has 100 confirmations.

Now, there are a couple of ways a pool can make payouts to its miners.

When creating the block template for mining, include a coinbase transaction that pays appropriate amounts to all pool members who are due to receive payouts.
Include a coinbase transaction that pays its coins directly to a wallet controlled by the pool operator.  The operator then makes additional transactions for payments from that wallet (or another wallet he controls) to the pool members.

For a pool that uses method 1, members will receive payouts that are immature, and they will have to wait 100 blocks to spend them.

For a pool that uses method 2, if the pool operator has a sufficient balance in his wallet, he can make the payouts right away by using coins that have been in the wallet for a long time already, long enough that they have become mature.  In this case, the payouts are ordinary transactions; they confirm like any other, and the miner can spend them immediately (or perhaps after 1 confirmation, depending on the requirements imposed by her wallet software).

Method 2 is certainly more convenient for the miner members if all goes well, but it has some other problems.  In order to maintain a sufficient balance, the pool operator has to keep some of his own coins in the wallet at all times.  These coins are then tied up there, which may be inconvenient or costly for the operator.  Also, if the block reward is paid directly to the operator's wallet, there is a chance he will decide not to make the payout to members, but instead will keep the coins himself.


Is performing a 51% attack / double spend on Bitcoin illegal?

A double-spend would be blackletter law illegal, guys.  Fraud and theft include a wide variety of intentional deception wrongfully depriving someone of property - use of a government-minted currency is not, and never was, a required element.  Look at any larceny or fraud statute - it will refer to loss of or damage to person and property not "dollars."

Schwarz - when you double-spend, you are representing to the seller as an existing fact that you are passing a valid bitcoin, which is a misrepresentation.  Your representations as to fact are readily, and usually, implied from conduct in fraud and "larceny by trick." You don't have to literally state them in words.  this goes for more than bitcoin.  If you were considering stealing puppies to return them for a reward, it's a legal problem for the same reason.  But do I really have to tell you this?

Of course, these are just general legal notes, and not legal advice.  Before you consider undertaking any questionable business activity, consult an attorney.


Why are my profitability calculations for Litecoin mining with an Antminer off the chart?

The Antminer S5 mines SHA-256d hashes as used by Bitcoin.

However, Litecoin uses Scrypt as its hashing algorithm instead of SHA-256d. That means that the S5 cannot be used to mine Litecoin and the numbers are not comparable.


How do I calculate the txid of this raw transaction?

TXIDs have two forms; the form used internally for outpoints and merkle leaves (internal byte order), and the form used in RPC calls and block explorers (RPC byte order).  These are often called, respectivey, little-endian byte order and big-endian byte order (although those descriptions aren't quite accurate).

Here's python code from the Bitcoin.org Developer Documentation generating both forms for the TXID for the transaction in your question:

#!/usr/bin/env python

from sys import byteorder
from hashlib import sha256

## You can put in $data an 80-byte block header to get its header hash,
## or a raw transaction to get its txid
data = "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0704ffff001d014dffffffff0100f2052a01000000434104e70a02f5af48a1989bf630d92523c9d14c45c75f7d1b998e962bff6ff9995fc5bdb44f1793b37495d80324acba7c8f537caaf8432b8d47987313060cc82d8a93ac00000000".decode("hex")
hash = sha256(sha256(data).digest()).digest()

print "Warning: this code only tested on a little-endian x86_64 arch"
print
print "System byte order:", byteorder
print "Internal-Byte-Order Hash: ", hash.encode('hex_codec')
print "RPC-Byte-Order Hash:      ", hash[::-1].encode('hex_codec')

And here's the output:

Warning: this code only tested on a little-endian x86_64 arch

System byte order: little
Internal-Byte-Order Hash:  660802c98f18fd34fd16d61c63cf447568370124ac5f3be626c2e1c3c9f0052d
RPC-Byte-Order Hash:       2d05f0c9c3e1c226e63b5fac240137687544cf631cd616fd34fd188fc9020866

The internal byte order used by the Bitcoin is in fact Little-Endian, while the RPC byte order is Big-Endian. For details explaining how this works refer this link.


Can the Lightning Network work on any other cryptocurrency?

The answer to this question depends on how broad you define the Lightning Network:

If you want to run the currently specified protocol (and any of the current implementations without having to modify them), you'll need to use either Bitcoin. Litecoin is partially supported by some of the implementations, but Lightning is being built first and foremost for Bitcoin.
If you are talking just about the specification, you'll need to have a Bitcoin derivative that also implements Segregated witnesses.
If you want to port Lightning onto a cryptocurrency, you need to at least support the UTXO model of accounting, and a malleability fix. In addition you need to have some form of knowledge contingent payment similar to HTLCs to perform multi-hop payments.
If you want to drop the UTXO model, you might get away by reworking the functionality in major ways, like the folks at raiden did for Ethereum.

So it's all in the eye of the beholder, but these are the requirements for various forms of payment channels and off-chain payment networks, from simple (and precise) to really hard (and fuzzy).


Can I use opcodes traditionally used for verifying keys to verify payment sizes?

This isn't possible.

You can use those arithmetic operators to compare any numerical values that you can get onto the stack - they are not inherently restricted to signatures and keys. But you would have to get the relevant data (output addresses, output amounts) onto the stack in the first place, and there is no opcode  to do that.   The script doesn't get to see that information, so you can't  restrict the spending of a transaction in such ways.

Related: Can an account define conditional tags to blockchain


What exactly did `Bitcoin-Qt -rescan -reindex` do?

-rescan likely did nothing at all. It goes through the blockchain to find transactions that are missing from your wallet. It is only very rarely needed (like when you manually changed things in wallet.dat).

-reindex throws away the block chain index and chain state (the database of all unspent transaction outputs), and rebuilds those from scratch. It is exactly like downloading the block chain again from peers, except the blocks already on disk are used.


What's the point of the hash160 field in blockchain.info API?

The information that the company displaying is correct, though there's no standard for displaying this to end users. You have unpacked the address and included the version byte and checksum as well in the string, note that only the hash160 is used in a pay to pubkey bitcoin script.

Base58Check    1N3Xxt13zbDLU66aSBiMB7AjRW1UiUFAau
Decoded        0x00e6d55202fe5e9e9e2973aab12bbb91db6794813840292932

Version Byte   0x00
Hash160        0xe6d55202fe5e9e9e2973aab12bbb91db67948138
Checksum       0x40292932


The checksum is expressed in Hex, so I believe the first character '3' represents the first four bits of the checksum string? If so, this is 0b0011. Word "about" is actually index '3' because the word list is 0-indexed (hence all zeroes maps to "abandon").


Why do first bitcoin transactions receive most confirmations?

Once a transaction has one confirmation, it gets a confirmation whenever the network creates a new block (roughly every 10 minutes). If one of your transactions gets a confirmation, the rest will also get a confirmation if they have at least one confirmation already. So the difference in non-zero confirmations between your transactions will always remain the same (except in very rare cases when the block chain gets reorganized).

Going from 0 confirmations to 1 works differently.

https://en.bitcoin.it/wiki/Transactions
https://en.bitcoin.it/wiki/Blocks
https://en.bitcoin.it/wiki/Block_chain


Would it be possible to have an ARM hashing based Cryptocurrency?

You can pick a proof-of-work function that runs more efficiently on ARM architecture but you can't define something that's ARM-only. The same function can always be ported to run on Intel CPU or even MIPS.


Where can I sell Amazon.com Gift Code for Bitcoins?

bitmit.net has quite a few gift cards already listed for sale, therefore with the right price you will be able to sell yours with no problem.


Can I reload my node's config from the command line without restarting the node?

I don't think so. There's a feature request about this, but I don't think a feature like that has been added.


Satoshi essentially named Gavin project lead by putting his contact info on bitcoin.org, giving him a copy of the alert key, giving him control of the SourceForge project, etc. Not many people have a problem with this, since Gavin has done a great job. I don't think anyone else in the Bitcoin community could have done better.

Gavin doesn't have exclusive control over many assets, so development can continue without too much trouble if he disappears without "naming a successor". Releases can even now be created and published on bitcoin.org without Gavin. bitcoin.org and the Bitcoin Forum are owned by Sirius, not Gavin. I have a copy of the alert key.

If Gavin disappears, I'd expect the project to continue reasonably well without a clear leader for a while before someone steps up to Gavin's responsibilities and is recognized by the community.


Not only can you write such a program, you probably already have one.  If you run the standard Bitcoin Core client, you will see that debug.log logs the IP addresses of every network node it communicates with.  (It's irrelevant whether you use the client for mining or not - even non-mining nodes need to connect to peers, and could keep track of which peers they have found.)

On the one hand, an attacker could consider these targets more tempting, on the grounds that there might be bitcoins stored on those machines.  On  the other hand, since at present Bitcoin users tend to be more  technically skilled than the general public, these machines might be better secured than the average computer on the Internet, making them harder targets.

Ordinary clients and solo miners are both likely to run regular Bitcoin clients.  I don't know of any reliable way for an attacker to tell whether a node is mining or not.  The best approach might be for the attacker to have a large number of nodes, each connected to a large number of peers, and watch for the first appearance of a new block.  The first node to have sent out that block is somewhat more likely to be the miner that found it - but the attacker can't rule out the possibility that that node was simply relaying a block sent to it by someone else.

Anyway, it's not clear that a solo miner would be a more profitable target than anyone else on the network - miners don't necessarily store their earned coins on the mining machine.  The attacker could take control of a solo miner and make it mine for her instead, but odds are that she would be discovered long before the miner finds a block.  (She would certainly be discovered as soon as it did find one, when the miner notices that the block reward didn't go to the right place.)

Pool miners don't need to participate in the peer-to-peer Bitcoin network, so they could not be discovered in this way.   The pool operator can run a regular Bitcoin node that looks no different from any other node.


Which bitcoin documentation is the official one for bitcoin core?

As far as I know there is no official documentation.

The closest you can get to it is the combination of the GitHub:
https://github.com/bitcoin/bitcoin

With the whitepaper:
https://bitcoincore.org/bitcoin.pdf

Changelog appears with every version on the core site, e.g.:
https://bitcoincore.org/en/releases/0.12.1/

And lastly, while I already linked to GitHub it is probably worth mentioning that open and closed issues are documented there:
https://github.com/bitcoin/bitcoin/issues?utf8=%E2%9C%93&q=

Hope this helps.


One node to rule them all and in the darkness bind them

Run a Raspiblitz (EUR120)
https://github.com/rootzoll/raspiblitz

Then run slave devices on ESP32 (EUR5)
https://github.com/musdom/sploony
https://github.com/arcbtc/1.21

121 would need to be ported with macroons


I transferred some bitcoin to my bitcoin core wallet, at the bottom it is still showing "Synchronizing with network" and my funds have not yet appeared.

That's normal. If your transaction is included in block 100, then you won't see that transaction until your Bitcoin client downloads block 100. That means that you won't see it until your client is almost done with synchronization.

  Did transferring funds to my wallet before this process was complete cause my funds to not go through?

You can send Bitcoin to an address made by a client that is not done synchronizing. Your client cannot tell you what your balance is, but the balance exists anyway. Once synchronized, the client will show the money, if there is any.

  The site I transferred from did say successful transaction.

That doesn't necessarily mean that the transaction was successful, or that the transaction exists at all. They can say whatever they want.


A transaction could go unconfirmed indefinitely.

The order in which transactions are confirmed is decided by miners, and generally they will be incentivized to include only the highest fee-rate transactions, to maximize their revenue.

Even a low fee-rate transaction may eventually confirm, once the mempool clears out. But there is no guarantee of this, if the mempool is full for an extended period of time, many nodes may drop the lowest fee-rate transactions from their mempool, to free up memory resources (otherwise, you could DoS attack the network by publishing infinite low-feerate transactions).

Ultimately, once you publish a transaction to the network, you cannot be certain if or when it will be confirmed, until it is. By paying a high fee-rate, you can help increase the chances you will see a quick confirmation. On the other hand, a low fee-rate transaction may never be confirmed, as eventually all nodes may 'forget' about it.

If you have been waiting a long time for a transaction to be confirmed, you could publish a new transaction that spends the same output, but with a higher fee. You may have to force your wallet to forget the old transaction so that it will craft a new one (eg bitcoin-cli abandontransaction "txid" when using bitcoin-core), but not all wallets will include this functionality.


Hashflare: cannot go back to Not Reinvest

You can click on 'Reinvest' and when you see the list for which one you want to reinvest with (SHA-256/ Scrypt) there should be an option at the top that says Do not reinvest. It should be updated within 24 hours!


How to do paper backup and restore for bitcoin core

Bitcoin Core does not allow you to restore from a given seed or master private key (xprv). There is currently no mechanism for importing seeds or master private keys and no mechanism for exporting seeds (and a convoluted workaround for exporting master private keys).

Note that you can import individual private keys, not just seeds, mnemonics, or master private keys. These can be imported with importmulti or importprivkey and can be exported with dumpprivkey.


The state update order of Lightning Network when exchanging private keys and new commitment transactions

I think this is one of the situations where a video and visualizations help more than a long text. I have explained this process in this video https://youtu.be/5YfQpMITUfI at 1:13:00 during a workshop at BTC2019 in Denver.

When the funds are updated this is done with htlcs. There is an intermediate state where the recipient of funds has two valid commitment transactions but not released the recovation secret (what you called the key). This is not an issue though as they cannot steal funds by publishing the old commitment transaction as they have a lower balance on the old one. The exact process with all the technical details is also described in bolt 2 but again I think this is one of the cases where video content is more helpful than a long text which is why I decided against writing it here again which would be similar to the part in bolt 02 anyway.

In general first the new state is created and signed an then the recovation secrets are shared


In the output there is a field "scriptPubKey" that for a standard transaction looks like this:

OP_DUP OP_HASH160 62e907b15cbf27d5425399ebf6f0fb50ebb88f18 OP_EQUALVERIFY OP_CHECKSIG

The hex number is what you get the address from; this is the result of step #3 in https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses. To get the address continue the process in that example. (Though, arguably the hardest part is calculating Base58Check, for which an example is not given.)

Also relevant is https://en.bitcoin.it/wiki/Script#Standard_Transaction_to_Bitcoin_address.


Is 165aBmgtQJFDLkSYPU5C8jq5gpnAtHdKBh a scam Bitcoin address?

There is no way to know.  Bitcoin addresses are designed to be used only once.  As you can see here, nobody except you has ever sent coins to that address, and in all likelihood nobody else ever will.  And Bitcoin addresses are anonymous, so it is likely to be difficult to trace the address to its owner.


Bitcoin Core does not have mining code anymore, at least for mainnet. You cannot use Bitcoin Core to mine. Instead you will have to download other mining software such as cgminer or bfgminer. However, none of those software include support for CPU mining because mining with CPUs (and even GPUs) is not efficient nor worth the cost. Mining these days is done with specialized mining hardware.

  How long does it take on an intel i5 to generate the smallest bitcoin fraction as possible.

Probably a few days or weeks, possibly never. In order to "generate the smallest bitcoin fraction", you need to join a mining pool. It isn't possible to just generate a small fraction of the block reward, mining doesn't work like that. To get less than the block reward, you have to join a mining pool. To even get a chance at getting any sort of reward, you have to join a mining pool. But in order to even get any reward from the pool, you will need to be able to mine a share, which is essentially a block but at a lower difficulty than the network (the pool sets that difficulty).

With CPU mining, it is unlikely that you will even find a share. Even if you do, you will need to find a lot of shares just to reach a pool's minimum payout. So you will never get "the smallest bitcoin fraction" just by CPU mining.

Furthermore, just running some mining software isn't going to teach you anything about how Bitcoin works or how mining works.


What's the POST endpoint to broadcast a transaction in copay's server?

Multisig and singlesig wallets use the same flow. A Tx proposal need to be created in singlesig wallets also. Copay syncronize across devices, so you can have a non-signing copayers in a 1-1 wallet that submit proposals, for later approval.

The flow is:

create => publish => sign => broadcast.

You can check the official client https://github.com/bitpay/bitcore-wallet-client for details, and also the CLI client should be useful to see examples:
https://github.com/bitpay/bitcore-wallet


Asset creation on cryptocurrency/blockchain

That depends on the protocol you are using to create the assets.

For instance, with Colu's Colored Coins protocol (a protocol that works on top of Bitcoin), the issuer of an asset explicitly specifies if the asset is reissuable in the future or not (when he first issues the asset). If the asset is issued as locked, then even the issuer can not reissue more units of the same asset in the future. On the contrary, if the asset is issued as unlocked, then the issuer is able to reissue more units in the future. Note that if the asset is unlocked, then the issuer alone may decide to create new units of the asset (there is no need for the "network" to agree on this).


Transaction fees, just like in the bitcoin blockchain.

The level of mining would then adjust up and down with the amount of usage.  You might need to subsidize it to get any participation from the start.

If demand is too low where fees don't justify this, then demand is too low where fees don't justify this.

Perhaps you can use Namecoin, which already exists, to solve your problem?  Namecoin can be used for namespaces other than just .bit domains.


What are fee_method and fee_level in Electrum's getfeerate RPC call?

There are 3 options(fee estimation methods) available for fee_method: static, eta and mempool
static - static fees
eta - based on confirmation within N blocks
mempool - based on mempool depth

fee_level for ETA can be one of these values in Electrum GUI: 25,10,5,2
FEE_ETA_TARGETS = [25, 10, 5, 2]
https://github.com/spesmilo/electrum/blob/ea22d0073ea5f61d53449a7afd072c3fd78003e8/electrum/simple_config.py#L23

fee_level for Mempool can have one of the value mentioned below in Electrum GUI:
FEE_DEPTH_TARGETS = [10000000, 5000000, 2000000, 1000000, 500000, 200000, 100000]
https://github.com/spesmilo/electrum/blob/ea22d0073ea5f61d53449a7afd072c3fd78003e8/electrum/simple_config.py#L24


Why can non-standard transactions be mined but not relayed?

doesn't this just leave miners with the ability to perform an attack whilst leaving everyone else restricted?

Not necessarily. Many of the attacks that the standardness rules protect against require large and many transactions that are expensive to verify. If a node is sent a lot of expensive to verify transactions, it can effectively go down as it spends time verifying those transactions instead of verifying and relaying other "normal" transactions and blocks.

However by virtue of mining, a miner can only create transactions that are limited in size, and they are limited in the number of transactions that can be sent in a block. So non-standard transactions that are large and expensive to verify can be included in blocks (and they have been before), but because there are few of them and they happen, at worst, infrequently, it isn't that big of a problem. The problem is only when there are a lot of such transactions which can only happen via normal transaction broadcast, and then standardness rules will prevent those from being verified (standardness is checked before any expensive verifications happen) and relayed.


What is the reason for using PoW in bitcoin?

Why is it not designed in a way to use consensus algorithms what ripple uses?

A consensus algorithm requires that you can trust contributing nodes. Otherwise, you're open to a Sybil attack, where an attacker creates many dummy nodes. Ripple was built on the idea that you can establish trust in some entities, trust that they will not collude to defraud you.

Proof of work, as Bitcoin uses, has some advantages over this: proof of work does not require trust of any kind, and it doesn't require that you know anybody's true identities. Instead, you trust the proof that someone put a lot of work (time/money) behind establishing a block. Since Bitcoin aims to be a completely trustless, decentralized network, that allows some anonymity, it makes sense to use proof of work in it.

Of course, proof of work also has some disadvantages: a slow block time (say, a minute or more, to keep the orphan rate low) is necessary, which slows confirmations. It can be overtaken by someone controlling >50% of the network's hash rate. And it results in work just for the sake of work, wasting electricity. Also, while ideally each user/node would have an equal share (just their own CPU), ASICs (and their predecessors) instead focus this control in more-centralized miners.


How bitcoin exchange wallet system works?

Exchanges will often move funds from the deposit addresses to some other internal storage wallet. This wallet may be a cold storage wallet that is more secure than the wallet that initially holds your deposited coins. This will happen regardless of whether a trade occurred.


Where is Australia's second bitcoin ATM machine?

The one in Nimbin is definitely a Lamassu, I used it in mid-January this year (2014), and apparently I was his first customer!  You can find them on coinmap.org


Do Multi-Signature Wallets Require Two Separate Bitcoin Wallets?

No, two wallets are not required. It sounds like you might be confusing wallets with addresses, where one bitcoin wallet can house many bitcoin addresses and keys.

If you want to be able to execute a 2 of 3 multisig from one wallet you can do so with bitcoin core with raw transactions. You will have to keep track of the private keys and redeemscript yourself and save them somewhere like a thumb drive for example.

Here's a video tutorial that can guide you through creating and spending with your multisig address using bitcoin core.


It's for early adopters and those with a large percentage of their wealth in bitcoin. Since bitcoin isn't widely accepted at merchants these people use debit cards tied to bitcoin to spend their hoarded coins. It really doesn't make sense for a newcomer. In fact bitcoin rarely makes sense for newcomers as a payment method.


How to restore a backup made when using the big 20 Gigabyte Core Wallet to current MultiBit wallet?

First of all it is extremely dangerous to back-up your wallet to Dropbox or any other cloud based file service. You might find that if you do recover your wallet, it may have no more funds in it, but I'm hoping that you encrypted your wallet before backing it up to Dropbox and you can remember the passphrase.

Secondly, running vanilla bitcoind is not a mining version of bitcoin, by default, so I am assuming that you know what you are doing, although it might have cost you a considerable amount to run that on amazon.

Assuming that you haven't been unlucky or naive, you cannot directly recover your wallet to Multibit, the wallet file formats are not compatible but in any case this is not what you should be doing. The simplest way is to make a payment from your running bitcoind wallet to a new address in Multibit.

It actually surprises me just how many people don't understand this.


How can I have friend to send me money without possibility to see my balance?

You are correct that anyone can see the balance of bitcoins in any address at any time.

So a better way to keep your total balance private is to make a new address and ask your friend to send the coins to that address.  Then, don't transfer the money to another existing address of yours.  Any reasonable wallet software is capable of handling coins divided among many different addresses, and doesn't need them to be consolidated into a single address.

As you spend coins over time, eventually your wallet will use the coins in the address that your friend paid.  If those coins are combined with coins from another address of yours, your friend might be able to figure out that the coins in that address also belong to you.  But the more you keep your coins spread across multiple addresses, the less of a factor this will be.  If you use a wallet client such as Bitcoin Core which creates new addresses for change, they will spread out even more.

Of course, because of this, if you do send the coins from your friend to an existing address of yours, your friend cannot be sure whether the new destination address actually belongs to you, or to someone else whom you have decided to pay.  But if you don't do that, your friend has even less information.


The public key is the 2nd word in the scriptSig but you're looking at the first word.  That's the signature.  Signatures are 71 to 73 bytes (142 to 146 characters) long.  I think you must have miscounted when you wrote that the one you found had 140 characters.

In the example you're looking at, the public key (i.e. the 2nd word in the scriptSig) is:

04
73769dda763e1f3f0ff1ca65343ed27279d73a63eaf88ca93714f0605d5d06bd
6d57cc6c3097909c5e0947341201d4960e4e16598687aa29c7b6c4675b7d66b6

and is 65 bytes long, as expected.


What does the is_your_order field mean in a btc-e response?

The field indicates that the order is yours with a value of 1. With a 0, it indicates it is not an order made by you.

It's indeed nowhere documented, the only valid arguments for my explanation are the name of the variable and the fact that I can only find 0 or 1 values for it.

(I found this piece of code where they save the is_your_order field as a boolean, testing of the value ==1.)


Is there a way to identify number of wallets opened by an exchange

You won't be able to see the number of wallets, but you could get quite an idea by looking at the number of adresses an exchange generated.

( Exchanges such as poloniex only have 1 wallet for all their customers. )

See https://www.walletexplorer.com/wallet/Poloniex.com/addresses

I'm not entirely sure if walletexplorer also tracks coinbase adresses, but in the case it doesn't, you can use http://matbea.net

They currently track over (28.500.000+) coinbase adresses.

https://blockonomi.com/matbea-trace-bitcoin-address/

^^ (I wouldn't recommend using their webwallet though, and i'm also not saying that this is 100% indexing all adresses.)

For example, using matbea.net, i was able to identify 1DUiLkf34q7MVxtRkMAXVtP42UNGRrbftY  as a coinbase adress.

https://www.walletexplorer.com/wallet/000001e522b362b7?from_address=1DUiLkf34q7MVxtRkMAXVtP42UNGRrbftY


I upgraded bitcoind to 0.8 from 0.7, may I delete the old blocks?

Yes, if you don't plan on switching back to the old version you can delete the old blk*.dat files.

The final 0.8 release will include this little script to tidy your data directory:
https://github.com/bitcoin/bitcoin/blob/master/contrib/tidy_datadir.sh


Why do the price of bitcoins vary wildly between exchanges?

There are a variety of variables that affect Bitcoin pricing on the exchanges. Some are:

Market size
Exchange volume
Price of entry

Market size: Relatively speaking, the market for Bitcoins is small. In April of 2013 it was about 1.2 billion USD, and a few days later dropped to below 750 million USD. That's a small market cap, which means, among other things, that there's less consensus on the price to the BTC. This is the capitalization for all mined bitcoins and includes coins that have been lost, so the real value is something smaller. Each exchange is a subset of the total market, so those markets are even smaller, which allows for greater variation.

Exchange Volume: For all the coins that have been mined, the quotes are only from online exchanges, which are a small set of the total coins that have been mined. If only a quarter or less are in play, then the swings can be pretty dramatic. Since the volume is limited, and people don't take full advantage or arbitrage, different prices can and will exist on the different exchanges.

This happens with foreign currency exchanges too. However, with professional traders, billions of dollars, and serious automated trading the differences are in fractions of a percent.

Price of entry: It's relatively cheap to enter the BTC market and cheap to trade. Furthermore, if you mined BTC when it was trading for fractions of a dollar, or even $30/BTC, there's no issue unloading it. With a low price of entry people are less serious about how the trade their BTC.

Fundamentally, BTC is a small, highly speculative, irrational market. Each exchange is a small, highly speculative, irrational market. That's why the spread is so great.

As a crude example:
Consider two towns in the medieval period separated by twenty miles. They both have markets and people sell apples in both markets. In one market people really like apples. They pay 2 coins for the apples. In another market they aren't as enthusiastic, they only pay 1.5 coins for the apples. The economic thing to do would be to buy the apples in the second market and sell them at the first. But it's hard. It's a twenty mile walk, and all your friends are at the other market. Plus, the price could change by time you get there. It's just easier to stick with your current market, even if you're not maximizing your return.


Is the secret seed number also the private number?

I would start with looking at the alfanumeric number.
Is it in hexadecimal? If yes , is it 32 bytes long --> random number
Is it a code that begins with a 5 or L or K --> Private key
Never share any of these.
But you can calculate the Public key and the Bitcoin address from those.


The genesis block has height 0 (at least in the Bitcoin reference client source code).


How to setup a DNS Seeds node and a Seed Node (for Litecoin clone)

Seed nodes are important even for SCRYPT coins.  You need to edit the source code in particular the DNS seeds and IP address seeds in the net.cpp file.  You can run this on a VPS or any always on internet connection with a static IP address.

Litcoin Net.cpp

The DNS seed node resolves to multiple IP addresses that are all running their own *coind instance on the appropriate port.  To validate this perform an nslookup on one of the seed nodes.

C:\Windows\System32>nslookup dnsseed.litecointools.com.
Server:  dd-wrt
Address:  192.168.11.1

Non-authoritative answer:
Name:    dnsseed.litecointools.com
Addresses:  109.67.99.8
          108.52.232.25
          .... (insert more here)
          23.242.146.169
          114.216.241.119


Can an attacker steal a very recent tx and alter it, broadcasting a new tx with his address on the output?

In a typical transaction, every signature in the transaction is a signature over all the outputs. So you can't change any of the outputs without invalidating all the signatures.


What is the difference between BTC/LTC & LTC/BTC markets?

LTC/BTC and BTC/LTC are both ratios of purchasing one currency with another.

For example, with LTC/BTC, the price quoted is for 1 LTC (overlying) in BTC (underlying). If the price is 0.025, that is how many bitcoins are needed to purchase 1 LTC. At this price, 2 LTC would cost 0.05 BTC.

The opposite would be equivielnt to 1/x, using the example above the rate could also be expressed as 1/0.025, or 40 LTC per bitcoin.

The rate is the same. For some lower valued currency, it would indeed be much better to trade in a BTC/COIN format because it is more likely for an altcoin to go lower than 0.00000001 BTC than to go higher than 100,000,000 BTC per altcoin ;)

For the freshest data, I would recommend going to the source (e.g. a big exchange), such as https://btc-e.com/api/documentation


How was the dust limit of 546 satoshis was chosen? Why not 550 satoshis?

The dust limit is not actually fixed, technically - it varies based on the type of output. 546 satoshis is simply the most commonly known one, for a p2pkh output. Being the longest-lived output type, I suspect some wallets/blog posts/literature might treat it as a hard coded dust limit.

As to how to arrive at 546 satoshis, we must first know what "dust" means. A dust output is an output which costs more to spend, than it is worth. In other words, an X BTC output that costs >X to spend, is a dust output. This is directly proportional to the amount of data required to spend an output, since fees in bitcoin are commonly denoted "per-byte". The more bytes you must add to your tx to spend an output, the higher its dust threshold.

A very basic tx consisting of 1 p2pkh input (~148 bytes), and 1 p2pkh output (~34 bytes) comes out to 182 bytes. The dust limit is 3 times this number (assuming a relay fee of 1 satoshi), or 182*3 = 546 sats.

For more complex txs, such as p2sh, this number is larger. For less space-intensive ones such as the newer segwit options, this number would be lower.

The code used in Bitcoin core to determine the dust threshold can be found here.


Why can't I connect to bitcoind on localhost?

My "Intel(R) Core(TM)2 Duo CPU     T6600  @ 2.20GHz" laptop just took 80 seconds to create 1000 new addresses, so I'm surprised you're seeing over 2 hours for 10 times that.

One thing I noticed is that the address creation is noticeable faster now than I remember it - so perhaps upgrading to a recent version of the client will speed things up for you.

Run "tail -f ~/.bitcoin/debug.log" to see a log of which key number it's currently creating.

Either way, the start up should only be noticeably slower the first time, when the pool is initially created.

Edit: (in response to miernik's comment)

The debug.log output will end with lines like the following while it's populating the keypool:

keypool added key 41, size=41
keypool added key 42, size=42
keypool added key 43, size=43
keypool added key 44, size=44
keypool added key 45, size=45
keypool added key 46, size=46
keypool added key 47, size=47
keypool added key 48, size=48
keypool added key 49, size=49
keypool added key 50, size=50

The stuff you're seeing is what happens while bitcoin is running normally.  It's receiving and responding to messages on the P2P network.  I don't know what to suggest as to why it isn't accepting RPC connections.  Could it be a firewall issue, or some other configuration problem unrelated to the keypool argument?


Can a bitcoin transaction get confirmed unexpectedly?

Absolutely. There are cases of transactions remaining unconfirmed for several days and then getting confirmed.

If the transaction was ever broadcast and is still valid, it can be included in a block by any miner who wishes to include it.


How to get all addresses - including the "change" addresses - from bitcoind?

listaddressgroupings

I used the command listaddressgroupings from the bitcoin-qt console window and it listed all my addresses.  I then looked for one of my old send transactions here:

https://blockchain.info/

And found the change address.  It matches one of the addresses in the list.


What is the command to sign a message using a segwit private key using electrum 3?

Electrum provides signmessage and verifymessage commands that you can use to sign and verify messages.

For signing messages with a different private key, you will need to import it into the wallet.

Verifying a message does not require any additional work.


In manual raw tx creation, how do you specify the amount of the bitcoin to be sent?

99900000 in hex is 5F45A60. Padded out to be a 64-bit integer makes it 0000000005F45A60. But Bitcoin uses little endian for most things, so this will need to be converted to little endian by byteswapping. So the final value put into a transaction is 605AF40500000000.


Can I connect to Litecoin, Dash, BitcoinCash, Doge, etc. RPC with Bitcoin RPC client?

Yes, you should be able to use a Bitcoin JSON-RPC client to interact with JSON-RPC servers for other cryptocurrencies if they are using software that is based on Bitcoin Core (which most are). Such JSON-RPC clients and libraries don't really have anything in them that is Bitcoin specific; they just handle the connection to the RPC server for you and return you the JSON formatted result.


Try to subscribe by using prefix raw as topic . After this you will get both message on the one listener.

socket.subscribe('raw');

socket.on('message', (topicRaw: Buffer, bodyRaw: Buffer, ...tailRaw: Buffer[]) => {

    const sequenceRaw = tailRaw[tailRaw.length - 1];
    const sequence = sequenceRaw.readInt32LE(0);
    const topic = topicRaw.toString();

    if (topic == 'rawtx') {
        const rawTX = bodyRaw.toString('hex');
        console.log(topic, sequence, rawTX);

    } else if (topic == 'rawblock') {

        const rawBlock = bodyRaw.toString('hex', 0, 80);
        console.log(topic, sequence, rawBlock);
    }
});