How relevant is the Chinese Great Firewall in the blocksize debate? Mike Hearn said the following:

  The reason the true limit seems to be 700 kilobytes instead of the theoretical 1000 is that sometimes miners produce blocks smaller than allowed and even empty blocks, despite that there are lots of transactions waiting to confirm — this seems to be most frequently caused by interference from the Chinese “Great Firewall” censorship system.

Also, he mentioned on another occasion that the bandwidth through the GFW, is only about 50 KB/s, sometimes less. In the best scenario you can get 3 MB/s, according to Scaling Bitcoin Conference.

Mike put lots of accusations towards the Chinese regarding blockchain development, but how much of that is true and if there's some solution, what will be the solution?

Yes, data has shown, that GFW has effects on packet propagation, but not much. The major cause of delay is distance. As you can see here, the median propagation time is comparable for various locations.Complete details can be seen here.

Interestingly, this issue highlights that more than the effect of GFW, it is the effect of large blocks propagation delay & rather serves as a case for even smaller blocks, which Mike was against.

Possible solutions:

O(1) block propagation : "If memory pools were perfectly synchronized and all miners had exactly the same policy for choosing which transactions to include in their blocks and in what order to include them, then miners could just announce new blocks as the fixed 80-byte block header and the coinbase transaction; there would be no need to include any transaction data at all, it could be reconstructed from their peers' memory pools."
Blocktorrent : "a leech(node) will begin to upload chunks of data as soon as it gets them and confirms both PoW and hash/data integrity instead of waiting for a fully copy with full verification."
A miner backbone network : "a hub-and-spoke network, which consists of servers set up in eight well-connected Internet traffic hubs: New York, Seattle, Amsterdam, Beijing, Tokyo, Singapore, Hong Kong and Novosibirsk (located in central Russia). Additionally, the relay network uses a fairly basic compression algorithm. Any Bitcoin node can connect to the nearest hub on Corallo's relay network, and send and receive transactions and blocks to and from other connected nodes."
Cache transaction validation : memoization of transaction validation
Surprisingly enough, blocks smaller than 1 mb!

A duplex payment channel abstraction
Lightning Network

on top of bitcoin would enable off-chain transactions & be like the visa protocol over the fiat layer.

Stratum Mining : The miner in china delegates the block header creation to a server outside china. Probably, the best short-term solution.


Is there any tool to index ALL bitcoind UTXO? I've got a full bitcoind node with txindex=1.

listunspent command is useful only if node is in possession of a private key for address.
So, if I want to check UTXO for random address, it will not work until all of that UTXO is indexed properly.

So, are there any tools to do that simultaneously with bitcoind?

Of course there is an option to import that private key to bitcoind. But this question is larger - to get unspent for any address.

This is something that bitcoind doesn't do, but there are block explorer tools that work on top of it that will give you address-specific utxos:

https://github.com/bitpay/insight
https://github.com/coinbase/toshi
https://github.com/bitcoin-abe/bitcoin-abe


Given a Tx message, how does one calculate the fee paid for the transaction? Given a Tx message, how does one calculate how big a fee one paid for the transaction?

Use the following pseudocode:

TotalOutputValue = 0
For each Output in tx_out array
  TotalOutputValue += Output[value]
TotalInputValue = 0
For each Input in tx_in array
  PreviousOutput = Input[previous_output]
  PreviousTransaction = PreviousOutput[hash]
  OutputIndex = PreviousOutput[index]
  Look up the transaction with hash PreviousTransaction
  Output = The output with index OutputIndex in that transaction
  TotalInputValue += Output[value]
Fee = TotalInputValue - TotalOutputValue


How to migrate Lightning (LND) from local laptop to external myNodeBTC node I am in the process of migrating my LNP/BP stack from a Windows laptop to a dedicated myNodeBTC (RaspPi) device. My node on the Windows laptop was installed using Node Launcher.

I already have the new Bitcoin node running, but I haven't setup LND yet on the new device. I do have 3 Lightning channels open on the old device.

What's the current best practice for moving from the old node to the new node so that I don't lose any sats in the process?

I suppose I could just close all my channels and then move my sats to a different wallet, spin up the new node and re-establish my channels. But I'm not sure if that's the most network-friendly approach?

Thanks!

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

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

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

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

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

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


What if during transaction Ripple price drops, in this case the receiving bank will get less amount Suppose bank A wants to send 100 USD to bank B using ripple. As per other answers, time taken for this transaction ranges between 4-7 seconds. But, what if the price of ripple drops drastically during this time frame.

The market makers (which can be the banks themselves) price this slight risk into the rates they offer. Most of the time, this doesn't happen, and they make a slight profit. When it occasionally does happen, they may take a slight loss. Fortunately, the price can't move very much in so little time -- and, if necessary, the amount of time can be brought down to sub-second levels by using off-chain scaling schemes such as payment channels.


Send bitcoins using just a pub and private key If I install the bitcoin command line client for linux, can I use just a public and private key to send coins from an address? I don't want to add it to my wallet file, I just want to move coins out of an address.

Update: After reading some of the answers I realize that I should have been more clear about my purposes. This is for more of a computer controlled money system. I want to be able to create addresses, and move money between them, and be able to move money out of addresses to other public addresses. I wanted it to be super light weight and not have to download the whole block-chain to achieve anything, and I don't want it to use wallets because they don't conform very well to what I am doing.

I want to be able to be given a private key and public address of a source, and a public address of a destination, to be able to send coins from one to another, and do it by just sending a message to the network. I want to be able to do it with only 10-20 MB of storage, and be able to do it by only connecting to a few nodes. Confirmations & balances will just be handled by hitting up some public resource like blockchain explorer.

Note: if it is not possible to do without the blockchain handy, then that can be accommodated for (though it throws in the need for a server for me rather than being purely client based.).

EDIT: I recalled that Wiki: Sweepprivkey proposal, is actually exactly what you are asking for, bitcointalk.org: Proposed RPC command: sweepprivkey. The latest news about the work in progress from jarpiain, dated October 15.

  This is functional in the sense that I tested it succesfully on the
  real block chain. It's not yet robust enough for serious use. In
  particular, there are race conditions for accessing addrblock.dat.

  I'm going to implement some of the sweepprivkey options and copy the
  transaction fee logic from CWallet::CreateTransaction() this weekend
  (I think it's best to keep the fee setting in one place, the -paytxfee
  option).

MtGox has the option to fund account with private key, and it understands several different formats, not only the standart one, e.g. it accepts mini format used by Casascius physical coins, MtGox adds redeemer for private keys including Casascius Physical Bitcoins

But if you want to send the transaction from your own computer then you need a software that would create a proper transaction using the public and private key, bitcoin or bitcoind can't do that without importing keys into wallet first, importing could be done with Pywallet or hopefully soon-to-be-official wallet export/import bitcoin patch, but make sure to backup your wallet first.


Is there an address format for P2WPKH or P2WSH? Is there an address format for P2WPKH or P2WSH? If P2WPKH uses the same address format as P2PKH, how does a wallet know which one to use?

Is there an address format for P2WPKH or P2WSH?

No.  BIP142 would have provided an address format for these output scripts, but it is in "deferred" status and expected to remain that way.  Wallet developers are being encouraged to discuss a new address format on the bitcoin-dev mailing list, and it is my understanding that one proposal may be coming soon.

In the meantime, BIP70 supports paying to arbitrary outputs, so it can be used for the native segwit outputs, as can any other software that communicates using its own protocol (such as payment channel software like that being used for various Lightning Network implementations).

  If P2WPKH uses the same address format as P2PKH, how does a wallet know which one to use?

Although the new address proposal will probably not use base58check like the current address formats for P2PKH and P2SH, the now-deferred proposal in BIP142 explains how this could easily be done by changing the first byte of the address (which is a version number):

"For P2WPKH address, the address version is 6 (0x06) for a main-network address or 3 (0x03) for a testnet address.

"For P2WSH address, the address version is 10 (0x0A) for a main-network address or 40 (0x28) for a testnet address."


(Mastering Bitcoin) When sending a raw transaction, why is the receiver included in the details hash as a "send" transaction? I'm working my way through Mastering Bitcoin. The author made a transaction to send 0.05 BTC from one address to another (http://chainquery.com/bitcoin-api/getrawtransaction/ae74538baa914f3799081ba78429d5d84f36a0127438e9f721dff584ac17b346/1)

In the book, he runs the following command to get the transaction details:

bitcoin-cli gettransaction ae74538baa914f3799081ba78429d5d84f36a0127438e9f721dff584ac17b346

The JSONRPC returns the following object:

{
   "details":[
      {
         "account":"",
         "address":"1LnfTndy3qzXGN19Jwscj1T8LR3MVe3JDb",
         "category":"send",
         "amount":-0.02500000,
         "fee":-0.00050000
      },
      {
         "account":"",
         "address":"1hvzSofGwT8cjb8JU7nBsCSfEVQX5u9CL",
         "category":"send",
         "amount":-0.02450000,
         "fee":-0.00050000
      },
      {
         "account":"",
         "address":"1LnfTndy3qzXGN19Jwscj1T8LR3MVe3JDb",
         "category":"receive",
         "amount":0.02500000
      },
      {
         "account":"",
         "address":"1hvzSofGwT8cjb8JU7nBsCSfEVQX5u9CL",
         "category":"receive",
         "amount":0.02450000
      }
   ]
}

Why is there an object with the receiving address (1hvzSofGwT8cjb8JU7nBsCSfEVQX5u9CL) with the category "send"?

Shouldn't there only be 3 objects nested under "details" (i.e. 1 input and 2 outputs)?

Shouldn't there only be 3 objects nested under "details" (i.e. 1 input and 2 outputs)?

In the actual Bitcoin blockchain that transaction has one input and two outputs. One of the outputs appears to be change being returned to the input address. This is normal.

In an early version of the book, the same information (1 in, 2 out) is shown and the author says on page 52:

  That looks correct! Our new transaction “consumes” the unspent output from our confirmed transaction and then spends it in two outputs, one for 25 millibits to our new address and one for 24.5 millibits as change back to the original address.

The output you show is from page 55 and looks like an editing error to me. If the author has not issued an errata, you could report this to the author or to the publisher.

The example in the question is from Chapter 3 of Mastering Bitcoin. It exists in the previous edition but that chapter has been completely revised in chapter 3 of  the latest edition


How does a miner know which nonce to start with ? Pretty straightforward question :

When a miner is trying to find a 18-leading-zeros hash, does it always start with a nonce at zero ? I suppose it doesn't, because other miners in the world may have found out that the first 1000 nonces won't give a sufficient hash.

My question is then, how does a miner knows which nonce to start with ?

The entire block header enters as input in the hashing process.

Along with nonce and some other fixed fields there is a "Merkle root" field in the block header that each miner has different.

So each miner can search the nonce range from 0 to the last - in order; because of different Merkle root each miner will have different block header hash for the same nonce and other fixed fields.

NOTE: Why each miner has different Merkle root? That's because in the transactions miners include in the block (from which Merkle root is derived) there is one special transaction called "coinbase transaction" that each miner has unique. Therefore the Merkle root is also unique. "Coinbase transaction" is included by the miner himself along with regular transactions and is the transaction that gives mining reward to miner's own address.


How does the U.S. government view Bitcoin? Is it money? How does the U.S. government view Bitcoin?  Is it a currency, a commodity, or something else?

The U.S. government views Bitcoin as a commodity, kind of like gold.

If you buy Bitcoin at one price in dollars, and sell it at a higher price in dollars, you will have a gain (in dollars), that you will have to pay tax on.

If you buy some Bitcoin (using dollars), and then use the Bitcoin to buy a car, you have made a "two stage" purchase of a car. (If you then re-sell the car for dollars, you may have a taxable gain if the dollars you receive are more than the dollars you used to buy the Bitcoin that you used to buy the car.


How does ripple verify the signature? As I understand, the client send the following information to server
 1.the hash of the message,
 2. public key
 3. signature made by private key

And the server verified the signature with the public key and hash, to check if it belong to the certain private key, server also need to check if the public key correspond to the ripple address.

Am I right?

And I have seen that there is a public key recovery method for ECDSA signature.https://crypto.stackexchange.com/questions/18105/how-does-recovering-the-public-key-from-an-ecdsa-signature-work

If my previous judgement is right, then is it possible for client only send the signature and the hash to the server? I guess there is a problem because we can't derive the curve from both the signature and the hash.

You are correct about the first part.

Unfortunately, it's not quite possible to recover the public key from the signature. You can recover a public key that works for ECDSA purposes, but that doesn't guarantee it is byte-for-byte identical to the intended public key. That means it may not hash to the right address, which could cause the check whether the right public key was used to fail.


Where is the Merkle tree located? I am reading about the Merkle tree, I've read that in a block we store just the root of the tree. To check if a ttransaction is included in the Merkle tree we need to use the transaction's Merkle path. The question is where the Merkle tree is stored? How would a node given a path check if the leaf belongs to the Merkel tree?

The Merkle tree is not stored anywhere.

It is implicitly defined by the transactions in a block. Whenever needed, the portion of it that is needed is computed on the fly using the transaction identifiers.


How to report eth-harvest.com as a SCAM I originally suspected this website was to good to be true but now it has been officially confirmed. How can I begin the campaign to warn others that this site is a scam and work to get is shut down?

If there is a source online saying it is a scam, and with PROOF, then, there is not much you can do then try and get others over to the article/video for them to see it is a scam.

If the scam has a forum on it, make as many posts as possible detailing it as a scam, and putting links to a article that has proof of it being a scam. This will hopefully bring many users to their senses, and save them from using hard earned money

Hope this helped!


What are the advantages of sharing money in hosted e-wallet services? I was a little bit shocked to learn that many (if not all) hosted e-Wallet providers combine their customers money in the hosts account, instead of just providing a service for easy access and storing of the users wallet data. This carries over many of the well known and less well known problems with the traditional banking structures onto bitcoins, and defies the aim to avoid central services. So, what are the actual advantages of this, for both the user and the e-Wallet service?

For the e-Wallet it would allow fractional reserve banking in order to charge interest for loans. That makes the system susceptible to crashes like we are experiencing outside and supports an interest based economy, which has its own troubles. (See also this question.) And it makes it easier for the bank to run away with the users money, since the users give the actual ownership of their money away. Are there other points? What is the advantage for the users?

As Chris mentioned, this is the default behavior of bitcoind which the eWallet uses - disassociating addresses from accounts.
Users expect the funds to be immediately available. If everyone has their own address, it means all the deposited funds must be in a hot wallet, which is dangerous since it can be hacked and stolen. A prudent eWallet will keep most of the deposits in a cold wallet, and only move funds out of it as necessary to allow smooth transactions. For this it will need to move bitcoins to an address other than the original deposit address.
Some eWallets provide green address functionality - a sending address known to belong to the eWallet and assumed trusted. For this the eWallet will need to move funds to its green address in advance.

So the question really is why not to combine the funds. If it's to prove that it's not fractional reserve, that can be done in other ways.

eWallet such as blockchain.info's MyWallet provide the benefits of an eWallet without giving the provider control over the coins, and in the future there will be eWallets with more advanced features using multi-signature transactions.


How does solving math problems create bitcoins? If I understand correctly, Bitcoin mining software "creates" bitcoins by solving complex mathematical equations. Is there a need for these problems to be solved, is there a value to solving these equations? If not, where does the solving of the math problems fit into the whole Bitcoin scenario?

The problem that mining solves is the problem of providing secure transactions without a central authority. There is value to solving these problems because otherwise, there would be no way to securely exchange Bitcoins.

Bitcoin uses proof of work as its means of solving the double spend problem without a central authority. If I try to send the same Bitcoin to two different accounts, the miners choose one transaction or the other and use it as the basis of the computations they do. Because nobody else can outcompute all the Bitcoin miners, this makes it possible for others to determine which transaction "wins". Without this mechanism, there would be no way to resolve conflicting transactions.

Because this proof of work costs money to do, it's not likely that it could be accomplished without some incentive. Mining rewards provide this incentive.


Can't specify rpcport for testnet Was there a recent change where it is no longer possible to specify rpcport?

I noticed these two warnings:
Warning: Config setting for -addnode only applied on test network when in [test] section.
Warning: Config setting for -rpcport only applied on test network when in [test] section.

After trying adding a [test] section I got very mixed results as some times it disregarded all options and in general rpcport was still not set.

I could not find any documentation on how to do this.

For any of addnode, connect, port, bind, rpcport, rpcbind, and wallet you should move them into the [test] and/or [main] sections of your bitcoin.conf. You can also move any other setting that you want only applied to mainnet or testnet into the appropriate section.

Example:

server=1
daemon=1

[main]
prune=1000

[test]
rpcport=55555


How much transaction fees are taken by bitcore for API use? If I am using the API of bitcore.io and create transactions, how much transaction fees are taken by Bitcore?

I couldn't find any description in their documentation.

Bitcore is open source software provided at no charge, so there is no fee you have to pay to the BitCore software authors.

When creating a Bitcoin transaction, it is highly recommend that you pay a fee to Bitcoin miners to encourage them to include your transaction in a block.  How much fee you pay is optional, and there are a number of fee estimation services that will recommend a fee for you.  See also other questions on Bitcoin StackExchange for more information about transaction fees in general.


Why are P2WSH addresses larger than P2SH addresses? One would, perhaps naively, assume that both addresses are hashes of scripts and therefore ought to be the same size.

Because P2SH addresses are too short to provide typically desirable levels of security security level we expect from Bitcoin, against certain attacks. On top of that, they use bech32 encoding rather than base58, which means they're slightly longer for the same amount of data, but are case insensitive instead.
For any kind of "multi party" address (that is, an address constructed by multiple distinct and distrusting participants that each have their own key, such as multisig), a particular collision attack exists that has runtime O(2bits/2), where bits is the number of bits of entropy in the address.
P2PKH, P2WPKH, and P2SH addresses have 160-bit hashes in their addresses. For P2PKH and P2WPKH this is fine, as it only supports single-party construction. However, as P2SH supports multisig and other multi-party constructions, it means an ~280 attack is possible(*). Bitcoin typically has a 2128 security target for attacks, so this is insufficient. That doesn't mean such a collision attack is practical - it's just far weaker than what the rest of the system provides, and as computing performance increases it may become feasible for well-funded parties.
To address this, P2WSH introduced a multi-party-capable address that contains a 256-bit hash, so it has ~2128 collision security.
In the upcoming Taproot upgrade, a new P2TR address type is introduced. It has the same length as P2WSH addresses, and also contains ~256 bits of entropy. Due to the nature of Taproot, which merges P2PKH and P2SH style spending into one, this means even single-party addresses are 256 bits in it.
For details of the attack, see https://bitcoin.stackexchange.com/a/54847/208.
(*) There are ways to avoid the collision attack problem, even with short hashes. They significantly complicate address construction and spending however. So the choice to provide a 256-bit script hash mechanism is really just to make sure multi-party address construction isn't needlessly complicated.


How to tell bitcoind to use more memory and CPU I just updated my node to 0.12 and its going through its long verification process but I noticed that its not using very much memory/cpu

pi         602 10.5 19.4 352220 184312 ?       Ssl  21:57   1:28 /usr/local/bin/bitcoind -datadir=/home/pi/bitcoinData/.bitcoin -daemon

How can I configure it to optimise all available memory and cpu? I recall a option to bump up the cache from a default of 50 or 100mb but cannot find the option.

I have a 1GB PI 2. Any recommendations on maximum memory to use? I was thinking 900mb if possible.

Thank you for your tips, and any optimizations to make this run best would be great!

It will by default use all CPU cores available.

However, if the database cache is too small, your node will spend its time fetching and writing database entries from/to disk, rather than verification

You can set the size of the database cache using a bitcoin.conf setting dbcache=N, where N is the number of megabytes of RAM.


When are private Keys created on Wallets? I have just started mining and in another question of mine it came up, that there can be multiple private keys in a wallet because of defining a backup strategy.

I would like to understand when private keys are created in the wallet?
If it is specific of the coin / wallet, I am refering to dogecoin wallet application with currently 1 address created in it.

In the default Bitcoin client, and most clients based on it (including Dogecoin-QT), 100 private keys are pre-generated, so that the wallet you backup is useful both for existing and some future transactions (roughly 50 transactions, assuming you receive on a new address and send change to a new address each time). When you ask the client to generate an address for you, it pulls from a private key from this pool (and generates another to put the pool back up to 100 at some point), from which a public key and address can be calculated. This pool size is configurable in your .conf file:

 # Pre-generate this many public/private key pairs, so wallet backups will be valid for
 # both prior transactions and several dozen future transactions.
 #keypool=100


Constructing, signing, and pushing a Bitcoin transaction by using pybitcointools with Python I'm utilizing the pybitcointools module in python 3.4

I've went through time and time again in the examples listed on the github page, but it isn't documented very well nor is the code.

My situation is this: I have a list of private keys in a CSV and I want to generate a raw transaction for each address and spend their unspent_outputs to a single address by pushing the signed transaction to blockchain.info

I'm having a problem when it comes to the these functions: mktx, mksend, sign

If someone could create an example of the process while also documenting each step and explaining what each argument for each function is for and how it's used. This would be an amazing help if someone could give a hand here! I've searched far and low, but I just can't find a good documentation of this process. I'm sure this would help many others as well!

OK, so first off:

Use Python 2.7; there's numerous pieces of code which doesn't work with Python 3.4, namely make_request
Check out this pybitcointools fork, as there's a lot of added functionality (see the README.txt file)

The functions you've named work as so:

mktx(ins, outs) where ins is an array of "hexTxIdString:index" and outs is an array of {"value": 12345, "address": 1base58addressString}
mksend(ins, outs, txfee, 1changeAddress) where txfee is again in Satoshis

sign(unsignedtx, index to sign, privkey for utxo) where index is the input index to sign

We'll start by making the ins:

utxos = [(utxo_txid, utxo_index), (txid2, i2)....]
ins = ["%s:%d" % utxo for utxo in utxos]
change_addr = "1thisIsAChangeAddressYouOwn123"
txfee = int(0.45 * len(ins) * 10000) # you may want to check this 10000 value, it could be 100000
rawtx = mksend(ins, txfee, change_addr)

Right, so let's assume, you have the UTXOs' TxID and corresponding vout for each private key. Make an dict of privkeys ={ 'TxID:vout' : privkey, 'TxID2:vout2': privkey2 } Then finally, signall(rawtx, privkeys) to get your signed Tx. Then to broadcast it, use pushtx(signedTx, source="bci") or pushtx(signedTx, "testnet", source="blockr") for Testnet. Done!


Receive unconfirmed transactions using Insight API I am new to Insight API. I want to receive unconfirmed transaction that are being broadcast to confirm by a miner to add in a block.

I am using Insight API using RPC client.

How I can get unconfirmed transactions similar to the ones shown on blockchain.info.

It is relatively easy to build a simple program that connects to some peers in the network and receives transactions that are being broadcast. You do not need a third party service to do so.

Pycoin includes some simple examples that connect to the network and receive inv messages, all you'd have to do then is to send getdata to the peer announcing the transaction. Disclaimer: I am the author of pycoin.


Accepting cryptocurrency in Django app i was thinking of using a service like blockonomics linked to an offline store via Xpub.
When a user signals their intent to make a payment, the app would generate a new address (API call), display it, set a timer for blocking the address, then use its HTTP callback to wait for Confirmed before updating the user balance. Without knowing the TX id I would poll the address and see whether the amount had been received since the timer started.
All payments go to a single cold address pool.

Is this a sensible secure way of going about this? What are the potential risks?

I wrote a very basic webshop using Armory that does a lot of what you're talking about, though in Flask:

https://github.com/goatpig/BitcoinArmory/blob/master/webshop/server.py

The sensible way to go about doing this would be to run your own bitcoin node so you can be notified whenever payment is sent to the address. You can, of course, use an SPV server (like an Electrum server) or even a public block explorer (blockchain.info, blockcypher) to get notified of payment to an address, but then you start risking customer (and your) privacy.

As long as the private key(s) are held offline, there's no actual risk of losing bitcoins. The big risks are from a privacy perspective and the way to combat that is to run your own node so you don't leak information.


Are wallets compatible with different clients? If I create *.wallet file in MultiBit, encrypt it with password and transfer some coins to it - does it tie me to this particular client, or can I open *.wallet file in any client

Almost every client has the option to export your Private keys.

MultiBit also has this option.

You can think of a wallet file as a container for your Private Keys and a list of your transactions. This wallet may be in a different format for different clients, but you can always export your Private key, and that is what matters most.

Bitcoin-qt has a wallet with a key pool and addresses that does not show. The best way to move your coins is to send them to a new address in your new wallet. But if you have a favorite address you want to keep, you can export from the Console with "dumpprivkey".

Here is my answer, how to export from every client

But there are also services that keep the Private keys.  These services do not allow export.

Coinbase
Coinkite (You get your private keys - but encrypted)


Transaction confirmed for hours, not available in balance My bitcoin transaction has been confirmed for more than 24 hours and also on the block chain but it has not yet reflected on the receivers balance, all transaction details are correct,what could be the problem

Assuming you double checked that you sent the coins to the right BTC adddress:
The wallet of the receiver should be connected to a full Bitcoin-node, either his own node or another node. This node could be down or not updated to current block height.
So you might ask the receiver if (s)he used the same wallet already successfully for other transactions before and if the connected node is online and synchronized to the latest blocks already.
Another reason could be that the receiver looks up the balance in the wrong wallet. So you might ask if the receiver has more than one wallet and if it could be that he looked in the wrong one. The wallet probably allows to see associated addresses.


I ran out of space while synchronizing, how do I get my private keys & find my balance? OK, my most immediate concern is that I made three ~$500 bitcoin purchases this weekend and downloaded the Bitcoin-Qt client, but ran out of HDD space just before it finished synchronizing the BlockChain, and now I don't even know what my BTC balance is, if my value is lost, or what.

Now I don't know what to do.

I was at least bright enough to have made a screen print of the three bitcoin addresses from the client and also of my BitInstant orders (while they show the destination address and $ amounts paid/recieved, they don't list the amount of bitcoin I assume and hope that I received), but I can't find my private keys in the client, though it appears that I am able to Send Coins from the tab of that name.

I don't even know what my total amount of bitcoin is since Bitcoin-Qt hasn't finished synch-ing up, and I'm just sort of stuck without either bitcoin or fiat since my HDD is down to only ~200MB left with 1,746 blocks remaining.

What should I do?

I read that the Multibit and Electrum wallets seem to need less computer resources, so I was thinking/hoping that I could maybe transfer my bitcoin to one of those wallets, or maybe to the StrongCoin online wallet or other secure recommendation as an interim step, but I don't even know the precise quantity of bitcoin that I should have in my bitcoin addresses, or if I can even send them without knowing my private keys.

If you know what bitcoin address your bitcoins are coming to (and you should know if you expect to get your bitcoins), you can lookup balance on blockchain.info like this:

http://blockchain.info/address/your-address

replace your-address with your actual bitcoin address, for example here some random address i found:

http://blockchain.info/address/1LNx3azmdKyH43UsJ6DK9oUrTbkPUr6UJg


Electrum only offers online wallet, does it not? I am currently using Bitcoin-Qt and have just surfed to Electrum's website.

It seems that Electrum only offers an online wallet, not offline. Is that correct?

No, electrum only offers offline wallets.

I think your confusion comes from electrum being a thin client. But this only means that electrum does not download the blockchain, instead it uses a server to query for the the information it needs out of the blockchain. From the elextrum bitcoin.it Wiki page:

  Main features:

  ...
  Instant on: the client does not download the blockchain, it requests that information from a server. No delays, always up-to-date.
  Transactions are signed locally: Your private keys are not shared with the server. You do not have to trust the server with your money.
  ...


Best Way to Get Latest Transactions I'm trying to write a node that listens all the bitcoin transactions in real time. I'm considering two ways of doing this: The first one is to check mempools of other nodes periodically and the second one is to act like a relay so that other nodes can broadcast transactions to my node. I'm not keeping any blockchain data so it is out of question for me to verify the transactions. So my question is which one would be more reliable, secure and real time? I think the first one is more reliable because in the second case it's not certain that all transactions will be broadcasted to me but again it seems like there won't be any latency in the second case. What do you think? And also are there some better ways to achieve this?

ps: i don't want to use a third party api, it all should be handled from my node.

Without verifying the transactions themselves, there's no guarantee that the transactions you get from either method are valid. Nodes can lie about what transactions they have in their mempool, for example, and send you gibberish. On the flip side, nodes also don't have any obligation to send you transactions that they have. There are non-standard transactions, for example, that many nodes simply don't relay, so you have no way to find out about them, but they may still get mined in the next block.

In order to actually verify unconfirmed transactions, you're going to need to be a full node with the entire blockchain stored so you can validate them yourself. There are no guarantees about the behavior of any other node on unconfirmed transactions and assuming that they're valid is simply not a good thing to do from a security perspective.

That said, if you want the largest set of unconfirmed transactions possible, the easiest way is to connect to as many nodes as possible and get whatever transactions they have in their mempools. The bitcoin network protocol has a lot of very useful commands for this purpose that you can create. Of particular interest are the inv and getdata commands.

Of course, that's exactly what bitcoind already does and it verifies all the transactions to boot, so you'd really honestly be duplicating that exact same function. The big optimization opportunity here would be mostly on choosing the best peers that somehow are "most informed" about unconfirmed transactions.


Can a Bitcoin miner process their own transactions for free? Can I become a Bitcoin miner by setting up multiple nodes to give higher priority to my own transactions to process them for less fee or for no fee?

My understanding is that a confirmation is when a miner includes your transaction in a block he calculates and submits. So can you setup like six or more mining machines which gives higher priority to your own transaction if you know the transactions output addresses already? Or is it just an automatic process which you can't change?

If it's possible then how exactly I can achieve this?

A miner certainly can do that, and some miners do (well mining pools actually). Some mining pools like ViaBTC and BTC.com offer services where they will prioritize a transaction for you for a fee (paid out of band). There have also been many cases where a miner will make a transaction, pay a 0 fee, and mine the transaction themselves.

  So can you setup like 6 or more mining machines

The number of mining machines or nodes has nothing to do with this. You could do this with one machine and one node. However in order to actually profitably mine and have a chance of actually finding a block, you will need a large number of ASIC miners, much more than just 6 machines, more like something in the hundreds or even thousands of ASIC miners.


Transaction not found in Blockchain Trying to send a transaction via bitcoin-cli. It seems to be working on my end but if I look up the transaction ID 76f2b87d7fbd18a217626761cdea215b66d523a3471e446c4fb0147645647866 on any block explorers, it tells me not found.

I've tried to push it using https://blockchain.info/pushtx, but again I get a not found error. Doing the same on blockr.io gives me Did you sign your transaction? Is this double spend? Have you already sent this transaction?

I'm not sure how to debug this or fix it. Can someone point me in the right direction?

Hex representation:

  0100000003de8f7664d7f5d27681222e1b555d0e83fe33ad307083111cee4314c800186bbe000000006b483045022100d5678c645a1f939fddc01521ccbc983a7235bb3b6c9a58e07ee5303fe12b72080220489a4cb65f8466b8482e3d4fddd56c94c182397e0cb341ccaaa026716c00614201210216bb4c25989444f1688ef4b265f76a4c451e81392a0ad19637f77da01b55d03dfeffffffa37d8ae3985551635430f713c56c26295e77eed62a90b7b0a4cde4e77041ed03010000006b4830450221009307f571405ab3eff97bc299be7191a868de1fe291cc4edeb6f4e40750781c6202202275a9ffe4d70d9cfbe9cb9b94673aeffea4c65dbef1cf780ec122c74c78c8a80121025a150650d185dcf04b118c747cb3f48858f292fb35597ef1d6fcd0239d5834dbfeffffff725bfa3b94d4a737611df4977d92b1b3e5b9fb70ac3fcd388d6bae863e7ead1f010000006a47304402202694969e973220fa032b3609308a1e9eef2a8bee3049f9621167b499a78c86370220367552a5c6b3cd71dfcd1f4653cea65f9ff7b10c506ce020c7c9481c8204376701210371dd7ada759d1a808862c5c60dac7ecb39debab8bcd9fc5d336f65a21568feeefeffffff024d520100000000001976a914bf37c92070173662685e197b927449949a8092d688ac49480f00000000001976a914ace8b01ab9dc31091ebde277507f7d04d31518b388ac39e60600

Sending this transaction through my own Bitcoin Core 0.13.99 node:

error message:
64: too-long-mempool-chain

This means you're building a long chain of unconfirmed transactions that depend on each other. Wait until the first few of those have confirmed before creating more.


Why can't we make the Bitcoin software start the blockchain from the beginning? I"m really wondering: you see 13 gigabytes (current blockchain size) is big enough only because there are all of transactions.

Can Bitcoin developers create such a piece of code which will shrink the size of the blockchain by collecting information of all addresses and representing some kind of inputs without using a Merkle tree, but in "database" style (like 4.5 bitcoins belongs to Alice, 2.3 belongs to Bob, ... ,.. .. and so on)

If blockchain size could be shrinked once in a year, then that would be a great solution.

Why isn't such a model allowable or what is the probability that Bitcoin developers will adopt this kind of protocol?

My solution here implies that everything on Bitcoin goes on the same way, but except for the fact that there will be a blockchain limit like 250 gigabytes for the blockchain - once the network will reach that limit, the network will agree on the last included block of transactions, after which the whole network will switch to a new blockchain file which won't wipe out everybody's bitcoins, but which will just create the genesis blocks based on previous files with all previous inputs belonging to their owner's addresses.

Please don't just say "it won't work".

And how exactly would the network agree on the last included block in order to spawn your new blockchain? That would be kind of complicated.

In my opinion Merkle tree is already fixing the problem. Downloading the headers of each block is enough to verify payments.

Remember that only miners actually need all of the blockchain data. Clients don't.


Why is a short blocktime considered to be unsafe? I've heard a couple of times "a shorter blocktime is unsafe," (first about Litecoin and now Ethereum) but never understood why. Is it the higher probability of a fork? Why do some people consider a shorter blocktime less safe?

The shorter the blocktime the more time is lost by the relaying of blocks in relation to the average blocktime. A very short block interval therefore makes SPV mining (i.e. mining empty blocks without transactions) more attractive, and increases the advantage of large pools, because they can start mining on top of their own block the quickest.

Additionally, it increases the number of headers that need to be verified and stored by any client, even smartphone wallets.


Bitcoin unconfirmed transactions - what is the best solution to fast it up? I have couple of unconfirmed transactions that i want fast up.
How i do it quickly and easily ?
What do you do ?
the fees going insane (over $12 for the smallest transactions)
i want to send with low fees and acclerate it . which sites do you recommend ?

Edit: I tried this Free service and it works!

The simplest thing you can try is to rebroadcast the transaction and see if you get lucky. Here is one of the sites that offers this service http://www.speedupmybitcointransaction.com/

Failing that you can ask a mining pool for some help. For example ViaBTC offer a service described here https://www.cryptocompare.com/coins/guides/how-to-accelerate-your-bitcoin-transaction/

And failing that you can create a Child Pays For Parent (CPFP) transaction to increase the fee paid https://bitzuma.com/posts/how-to-clear-a-stuck-bitcoin-transaction/


what is the best mining intenisty to use for certain grahpichs cards? I use cgminer and I have a zotac nvidia geforce gtx 680 graphics card, what is the best intensity to use.

I would not bother using a nvidia graphic card but the choice is yours from experience they run way to hot and don't produce enough power especially at current difficulty. Anyway take a look at this list https://en.bitcoin.it/wiki/Mining_hardware_comparison it lists a lot of best settings as well as gives you an idea if your card is hitting the hashing rate that it should be.


What does "Safe mode: Warning: The network does not appear to fully agree! Some miners appear to be experiencing issues." mean? My bitcoind client that runs on testnet has started returning a lot of errors today. It has been doing so for a few of hours (as of 2014-08-29 9:50 UTC).

When I call it via RPC, I get the following response on ALL requests

{
  "result":null,
  "error": {
    "code":-2,
    "message":"Safe mode: Warning: The network does not appear to fully agree! Some miners appear to be experiencing issues."},
    "id":"1"
  }
}

It doesn't seem to be downloading any new blocks. It seems that I'm not the only one who's affected. As of now, http://tbtc.blockr.io/ is also stuck on blocks that are almost 5 hours old.

The version of bitcoind I use is 0.9.2.1, and the debug log says:

2014-08-29 05:11:59 ProcessBlock: ORPHAN BLOCK 0, prev=0000000000000e819b253066739275290fb4274b580bf62fbd279c518e6e2ebd
2014-08-29 05:11:59 ProcessBlock: ORPHAN BLOCK 1, prev=0000000000000e70d898fa12f328b9ee2d97912e9a495fc80eaeeb781096cadf
2014-08-29 05:11:59 ProcessBlock: ORPHAN BLOCK 2, prev=000000000000256194246bdabb62d3b50e2c309217258b17c543d13ec839367c
2014-08-29 05:12:00 CheckForkWarningConditions: Warning: Large valid fork found
  forking the chain at height 277766 (000000009cf297bc2a9610af823b49fc1d98e001239e99204c3c410e1ad3fe54)
  lasting to height 277767 (0000000000000e819b253066739275290fb4274b580bf62fbd279c518e6e2ebd).
Chain state database corruption likely.
2014-08-29 05:12:00 UpdateTip: new best=00000000735de11454d7de10a71a14e9695135f59b70a4eb906b1107df842270  height=277770  log2_work=61.959615  tx=2398741  date=2014-08-29 05:20:26 progress=1.000001
2014-08-29 05:12:00 UpdateTip: new best=00000000e9cc8d1bea3894d11cd4bacf4099dac3b644cb4f39b4ba3ad89ed2f8  height=277769  log2_work=61.959615  tx=2398732  date=2014-08-29 05:00:09 progress=0.999999
2014-08-29 05:12:00 UpdateTip: new best=00000000d553cd36cc43b3d1255ec395c05e1d4ad730178cd987e960931399ae  height=277768  log2_work=61.959615  tx=2398721  date=2014-08-29 04:39:40 progress=0.999997
2014-08-29 05:12:00 UpdateTip: new best=0000000000000f46520ca51be43443905945d2db5b513f35c2283c2d95a41077  height=277767  log2_work=61.959615  tx=2398683  date=2014-08-29 04:19:31 progress=0.999995
2014-08-29 05:12:00 UpdateTip: new best=000000009cf297bc2a9610af823b49fc1d98e001239e99204c3c410e1ad3fe54  height=277766  log2_work=61.959004  tx=2398667  date=2014-08-29 04:16:35 progress=0.999995
2014-08-29 05:12:00 UpdateTip: new best=0000000000000e819b253066739275290fb4274b580bf62fbd279c518e6e2ebd  height=277767  log2_work=61.959615  tx=2398670  date=2014-08-29 04:15:08 progress=0.999995
2014-08-29 05:12:00 UpdateTip: new best=0000000000000e70d898fa12f328b9ee2d97912e9a495fc80eaeeb781096cadf  height=277768  log2_work=61.960226  tx=2398674  date=2014-08-29 04:24:20 progress=0.999996
2014-08-29 05:12:00 CheckForkWarningConditions: Warning: Large valid fork found
  forking the chain at height 277766 (000000009cf297bc2a9610af823b49fc1d98e001239e99204c3c410e1ad3fe54)
  lasting to height 277767 (0000000000000e819b253066739275290fb4274b580bf62fbd279c518e6e2ebd).
Chain state database corruption likely.

What does this message mean? How is a fork of a single block a "large valid fork"? Why is this that this seems to completely freeze bitcoind? How can I fix it?

When Bitcoin detects that there is something seriously wrong with the network it gets into safe mode, disabling the majority of the methods exposed via its RPC API (only the okSafeMode methods will still work). It does that by filling up the error JSON node with an error code and the the generic error message you received so that the response will not be parseable:

The reasons that push it into safe mode can be a large valid/invalid fork, an invalid longest chain, etc.

Try adding these lines to your bitcoin.conf

checkblocks=10
checklevel=1

then restart bitcoind as well as your app and see if the issue is resolved. If not, try reindexing the blocks on your disk (via the -reindex param).

Also, consider using the -alertnotify hook to get custom notifications and/or to shut down your bitcoin apps every time this happens.


Need Help about Console in Bitcoin Core I would like to ask the following. I've downloaded Bitcoin Core and just start using their "Console". Before I can createrawtransaction, I need to first set up a node in Bitcoin Core, right? If yes, I did follow the instruction in https://developer.bitcoin.org/reference/rpc/index.html.
However, when I want to apply a node for myself that is using --> addnode "167.172.250.161:8333" "onetry"
but end up is Null although I have requested for "getnodeaddresses" as per the screenshot:

Please advise as I need to "importprivkey" in order to perform the createrawtransaction.
Also, my apology I would like to ask this as well. Why when I send createrawtransaction in the Bitcoin Core Console, the error it states here that the error - Method not found (code -32601). Anyone can advise or provide guidance to me? I'm no expert in this. Thanks in advance.

Running Bitcoin Core (bitcoind or bitcoin-qt) already means running a node.
You don't need to set it up.
The addnode function is used to manually add a connection to another node.
This is not something necessary, unless you have specific reasons to connect to a particular node (e.g. a node you trust).
This function does not return any object (although executed successfully), which is why get null in return.
getnodeaddresses returns a random subset of node addresses known to your node.
As for the RPC methods, generateprivkey does not exist, while the error for createrawtransaction is probably due to a wrong input format (you are missing the squared brackets in the second object)
The correct format is:
[{"txid":"id","vout":n},...] [{"address":amount},{"data":"hex"},...]

Also note that you won't be able to create a transaction without having the corresponding keys in your wallet.


bitcoin-0.9.3 won't syncup on TESTNET stuck at height 26859 Downloaded the latest bitcoin core tar ball 0.9.3.
New install for test and development. This thread relates only to the TESTNET, I haven't tried on the production network.
When launching the bitcoind everything works as expected until it reaches block at 26859 where it stops adding blocks. Nothing happens after no more blocks are requested.
After some debugging, it appears that the next block 26860 contains a transaction that fails verification, so it won't validate the block. These blocks (that are failing) are more than 2 years old, but I didn't expect to hit this hurdle so early in the game. Can anybody shed some light ? Am I doing something wrong here? DOwnloaded the bitcoin tar from the official web site and checked the signature.

Anyone can easily reproduce this on the testnet network.
Any help appreciated.

I'm not totally sure why it failed on height 26859, but I upgraded to 0.9.4 (from 0.9.3) using:

apt-get install --only-upgrade bitcoind

then I deleted the testnet3 folder and fired up bitcoind and now it's working and has passed height 26859.


coinb.in wallet balance does not match "confirmed balance"? Coinb.in wallet amount is different from "confirmed balance"? Is this because an earlier incoming transaction hasn't actually completed?

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

Current Blockheight: 476961,
Blockr Blockheight: 476808

This is likely why you are having issues.


How to reduce the amount of transactions with handling wallets? i'm working on a Web Application that will allow users to deposit Bitcoin into their own wallet, leading to a service that invests their funds in X(lets say alt-coins).i'm having issues on how to approach this.

So, if i'm not mistaken it will go like this:

Bob deposits BTC to wallet W => W sends to service S => Bob wins money => S sends funds back to W.

Until bob has funds again it takes 2 transactions

If the goal is to minimize fees by reducing the amount of transactions,
Would you create a private key for each of the users? or is there a way to create different public addresses that point to the same private key?
I Thought about initially giving Bob the option to deposit directly to the service S but the whole idea is giving funds to more than one service.

Thanks for any advice.

Since your service will control the wallet it is not necessary to do the actual transfer out of the wallet to the service, just show the user a lower balance and do not let them spend or withdraw more than this. This means that your service will have to maintain strict control of the private keys. Also, if you maintain a backend float BTC balance, you can show the user an increased balance immediately without waiting for a return transaction to process. To do this, effectively you will need to control all addresses used by your service. This amounts to virtual wallets.

A note on security, there have been previously several high profile services which hold a balance for users, which have been hacked so you will need to ensure your entire security regime is "A" Grade across your entire organisation.


Altcoin confirmations and safety - wait ~6 confirmations, or ~1 hour? The general consensus in the Bitcoin network is to wait for 6 confirmations or 1 hour on a transaction before it can be considered completely irreversible. However, when it comes to altcoins that use different block generation rate, some people go with ~6 confirmations, while others use ~1 hour worth of blocks as the standard confirmation model.

I am wondering if there is any consensus on which approach is more proper? Assuming the altcoin network in question is under no threat of a 51% attack, should companies under a risk of theft attempts (say, exchanges) wait for about 6 confirmations regardless of the block generation rate, about 1 hour worth of confirmations also disregarding the generation rate, or for the higher of 6 of 1 hour worth of confirmations if blocks are generated slower than 1 block per 10 minutes?

See https://bitcoil.co.il/Doublespend.pdf. What matters is the number of blocks, not time elapsed or average time for this many blocks.

Also, the idea of "wait for 6 confirmations or 1 hour" in Bitcoin is a myth. If 1 hour passes with 3 confirmations you're less secure than if 30 minutes passed with 3 confirmations, because the attacker would have had more time to build his competing branch.


Mining without using client Is there a way to mine bitcoins without installing a client, that is can I do it in PHP or Node.js by adding some libraries etc which replicate what the bitcoin client would do(more or less)?

You probably want this:

http://pastebin.com/ZYMNFAXt

It is a BTC miner that works in JS.  I took it from bitcoinplus.com

I don't think that this is economically feasible though - cpu mining is a total waste - unless you're looking to do something malicious with the code like having others use your tools that also happen to utilize CPU power to mine for btc underneath - which by the way is a sure fire way to get your software banned and shunned at large.  What you describe sounds like something deployed in a botnet or malware scheme - perhaps a bad android modded rom.


What if same transaction is added in more than one block of different miners? I know that miners have freedom to choose transactions from memory pool,

Let say there are 5 transactions Tx1 Tx2 Tx3 Tx4 and Tx5 in memory pool,

There are 3 miners M1 M2 and M3

M1 has created block with Tx1 Tx2 and Tx3

M2 has created block with Tx2 Tx3 and Tx4

M3 has created block with Tx2 and Tx5

==

M1 successfully solves the block and get reward in terms of bitcoin and transaction fee

at same time M2 and M3 successfully solves the block,
In this case, will M2 and M3 gets reward and transaction fee? as Tx2 was already part of M1's block which was already confirmed.

No, the blocks from M2 and M3 will most likely end up being discarded. The reason being that as soon as M1 broadcasts its block most miners will drop their current block and start trying to solve the next one.

There's nothing to stop M2 and M3 broadcasting their blocks after M1 in the hope that they will also be able to generate the next block and take over the longest chain. The problem is that these days the cost of generating a block is in the 10's of thousands of dollars in electricity so it's an expensive gamble to try and solve two blocks in a row.

And in answer to your main question if a transaction that's already included in a block appears in a subsequent block then the new block will be rejected as invalid by full nodes and other miners.


Size of Blockchain for huge smart contracts database Let's say I want to use smart contracts for huge collection of data. Since it will be distributed so downloading on every participant computers isn't this a huge problem ?

Yes. But smart use of smart contacts means you don't need to put all the data on the blockchain. You can keep the actual data offline or only shared between actual participants.

Lightning Network is a nice example of such a system.

Many other examples can be done using simply multisig and a bit of time locking if necessary. More op-codes and more flexible and more efficient scripting execution are in the works too.


Can collective mining pools refuse to recognize a mining block mined by a specific miner? This is a continuation to the question:
Can a bitcoin transaction from a specific bitcoin address be banned? (via mining pools).

Suppose Satoshi Nakamoto sends bitcoins from one address to another, and some mining pools would refuse to add that specific transaction to the mining block (Considering China has 81% total bitcoin hashrate with their pools combined).
However a miner/mining pool adds Satoshi's transaction to the block they mined.

But, other mining pools had a different idea. They would not accept the version of the blockchain where Satoshi's transaction is in that specific block.

Essentially the other mining pools are calling a "fork" where they don't recognize the block where Satoshi did a transaction. Would it be against bitcoin protocol? If they somehow get away with it, considering they have the hashing power, what would happen to the other miners?
Would they accept the fork or just go along with it?

What you are describing is essentially a majority attack. A miner (or group of colluding miners) with a majority of hashpower can censor arbitrary transactions, and blocks that include them. This question has more info about what an attacker can do.

Crucially: a majority of hashpower can create blocks at a faster rate (on average) than the minority. So if the majority decides to not build upon a block that the minority found, they can reliably outrun the minority, by simply mining their own chain, and ignoring blocks found by the minority.

  Essentially the other mining pools are calling a "fork" where they don't recognize the block where Satoshi did a transaction. Would it be against bitcoin protocol?

I wouldn't say it is "against the Bitcoin protocol", but it would be against the financial incentives which keep miners 'honest' (ie, not attacking the chain to censor transactions / blocks). Ultimately, the protocol does specify that the most-work chain is valid, so this becomes a tricky question about what the social understanding of the consensus rules really is.

  If they somehow get away with it, considering they have the hashing power, what would happen to the other miners? Would they accept the fork or just go along with it?

A majority-attacker can ignore any blocks created by the minority, and if they do so, there isn't anything the minority can really do about it. Enacting the attack is extremely costly though, the financial incentive to attack would have to be unbelievably large in order to outweigh the cost. So I think that simply censoring one of Satoshi's transactions would not be worth the cost of the attack.


Bitcoin cash to Bitcoin wallet Apparently I am not alone in feeling foolish regards this.
I think things are safe, but would so much appreciate advice.
When using Coinbase, I had some small change in my Bitcoin Cash wallet, don't know how it got there, as I always use standard Bitcoin.
Anyways I deposited into my Bitcoin CASH wallet.
I then sent the Bitcoin Cash to a standard Bitcoin address, of which I have access to.
So it has been sent to a one off address which is mine.
Can any of you kind folk tell me what will happen?

If you sent Bitcoin Cash to a standard Bitcoin address you can still get to it (maybe).

There is too little to give you a fully correct answer. If the address is a wallet you control (not an exchange) then you should have a recovery password. It is possible to restore your BTC wallet into a BCH wallet, then transfer the funds from there.

I'm assuming you didn't accidentally send the coins to a Segwit address.

What would help the most, if you provided the transaction ID and the name of the wallet you use. (provide the path: Eg, Coinbase BCH > Exodus BCH > Coinbase BTC)

I can look into it a bit, make sure the tokens were transacted etc. Beyond that, i'm far more familiar about how to deal with this if you were running a bitcoin core node.


I tried to run bitcoin core and it is gone. Has anyone experienced this? I tried to run bitcoin core and it is gone.The folder is still there, but the exe is not there. Does that mean the local wallet is gone as well?

Some antivirus programs can remove binaries, or move them away. If you have one running, look whether it has some kind of quarantine place where it puts suspected malware. False positives can happen.
That, or you deleted the file by mistake :)


Proving two public keys are derived from the same seed, without revealing the xpub and the path? Let's think about the following scenario:

Key0 is derived from SEED at path m/44'/0'/0'/0/0
Key1 is derived from SEED at path m/44'/0'/0'/0/1

I am wondering if there's a way to prove that Key0 and Key1 share the same seed WITHOUT having to share the SEED or any Xpub along the way.
Basically I want to be able to prove two keys are somehow related without risking security (Where if you share an Xpub and one of its child private keys gets leaked, the entire sibling set is compromised).
It doesn't have to be exactly this, but my goal is to prove that two keys are related without sacrificing security, so if there are ways to do this, I would appreciate those solutions too.

This is possible with zero-knowledge proofs but not with the math used in BIP32 alone.
This is because Key0 and Key1 are not related to each other mathematically except that they were derived from the same parent key, using the same chain code (an extra 32 bytes of entropy described in BIP32). Therefore to prove they are derived from the same parent public key you must reveal that parent public key and the chain code -- and these are the two most important values contained in an xpub (there is some metadata as well).
Note that you do not have to reveal the MASTER public key of the seed, just the parent key which in your example is at path m/44'/0'/0'/0.
For details, read how child public keys are derived from their parent public key in BIP32.
(summarized):
let I = HASH512(<chain code> || <parent public key> || <index>).
let J = the first 256 bits of I
child public key = <J> * <G (generator point of curve)> + <parent public key>

So the only relationship between Key0 and Key1 is that they were both derived this way, where <index> = 0 and <index> = 1.
Vitalik Buterin wrote a great article for Bitcoin Magazine in 2013 about this problem. If you reveal an extended parent public key (which includes the chain code) and any (unhardened) child private key, the parent private key can be computed. This is because the data needed to derive a child private key from a parent private key is available to the attacker (in the parent xpub). So the attacker can just subtract that value from the child private key to compute the parent private key.
As a final note, don't forget that if you need to prove that you control two keys, you can just sign the same message with each key :-)


Copay Log in Problem I bought a new phone and when I enter the account recovery phrase and password it tells me it is incorrect, is there any way I can contact someone at copay to help me log on?

Official BitPay/Copay support can be reached here:
https://help.bitpay.com/requestHelp

Below are a few tips you can try to make the 12 word recovery phrase work:

Are you sure that the recovery phrase was written in the correct order?
Did you use all lowercase letters and no punctuation?
Did you add a password to your recovery phrase?
Do you have the QR code or text/file backup?
Did you separate each word with a single space (no commas or any other punctuation)?

Please also ensure that your words are all contained in the following list of possible words:
https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt


how to get address from transaction with empty ScriptSig? look here https://blockchain.info/tx/d4223672c9043c17a2775abde858778fca38b53152e165757188ab747850770e

why does address start with bc1q... ? Is it some standart?
How can I derive this value from witness?

witness script here:

2 0375E00EB72E29DA82B89367947F29EF34AFB75E8654F6EA368E0ACDFD92976B7C 03A1B26313F430C4B15BB1FDCE663207659D8CAC749A0E53D70EFF01874496FEFF 03C96D495BFDD5BA4145E3E046FEE45E84A8A48AD05BD8DBB395C011A32CF9F880 3 OP_CHECKMULTISIG

why does address start with bc1q... ? Is it some standard?

Yes, it's a Bech32 address, specified in BIP173.

  How can I derive this value from witness?

In general, you can't.

The address defines under what conditions an output is spendable. The scriptSig or script witness gives the proof that those conditions are satisfied. If you know that a particular output is a V0 witness, then you can determine what that output was based on the input spending it (the last witness stack element is the public key). However, without knowing exactly what type of output was being spent you can't generally do so.


When does a transaction end up in the transaction pool? I have been reading about the validation of transactions. And I understand the actual method in which a transaction is composed (by inputs and outputs). And I know a transaction ends up in a transaction pool before being put in a block.

However, I want to know what happens in between. How many nodes need to validate my transaction before it ends up in the transaction pool?

The transaction pool (or mempool, as it's usually called) is not a network-wide pool. Each node maintains its own mempool.

When a node receives your tx, it will validate and add it to its own mempool, and possibly broadcast it further on. In some cases, such as a lot of unconfirmed txs, a node's mempool may be full, in which case it will not be added.

There is no network-wide consensus required to add your transaction to the mempool, each node does so individually, regardless of how many other nodes have validated that transaction.


How do I disable automatic address generation for the official bitcoin client? This question was asked before over at bitcointalk.org over here way back in June '11. The answer back then was a resounding no. Is this still the case?

My wallet.dat keeps growing bigger after every transaction since the client keeps generating and adding new bitcoin addresses I never intend to use. I want to stop that from happening.

The satoshi client still uses a previously unused address each time it needs to send itself change, and there's no option to prevent this.

Obviously since the client is open source you could change it to do whatever you like, or pay somebody with the appropriate skills to do it for you.


How can I run a light (SPV) node on Linux? I tried to sync the blockchain and, though I have ample free disk space (>500 GB on my computer, the chain is ~265) I've been having a hard time. So, how can I use an SPV node to send transactions and/or view the blockchain?

NOTE: don't do this if you don't have to because the blockchain needs nodes to ensure adequate distribution.

Try Electrum. Exact details on how to install depend on Linux distribution used.

Also Wasabi Wallet could be good choice, easy to setup.


Significance of the "hash" field reported by the 'bitcoin-cli getblock' command It is stated that the header of a block does not contain a 'hash' field ( see https://en.bitcoin.it/wiki/Block_hashing_algorithm or Antonopolous' Mastering Bitcoin 2nd Ed. )
This makes sense since inlcuding such a field would be self-referential.

However, when interrogating the blockchain for info on a specific block for example via 'bitcoin-cli getblock' a 'hash' field is reported:

{
  "hash":  "00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048",
  "confirmations": 534047,
  "strippedsize": 215,
         .
         .
         .

Is the "hash" field something that the 'bitcoin-cli' calculates and inserts in situ into the json for informational purpouses

OR

is it that the "hash" field  >is<  actually part of the header and my understanding of this aspect is flawed?

Is the "hash" field something that the 'bitcoin-cli' calculates and inserts in situ into the json for informational purpouses

This is correct. The block contains all of the info necessary to compute the hash, so as you mentioned, including it would be unnecessary and self-referential.

As one of the steps taken to confirm the block as being valid, bitcoind will calculate the hash and check it against the network difficulty. Using the getblock command returns this hash, among other info (not all of which is explicitly included in the block, but can be calculated locally with the available info).


How do I trade at BTC-e? I want to sell 1 LTC via BTC-e.

How does selling LTC for USD takes place at BTC-e? Most probably I'll firstly deposit 1 LTC in the BTC-e wallet and then go to LTC/USD and then enter 1 LTC under the 'Sell LTC' section and click on 'Sell LTC.' What happens after that?

I want to know because I don't want to waste any bit of my hard earned Litecoins!

When you place an order to sell LTC in btc-e it checks if there is an order to buy LTC at the same rate as you specified. If there is order to buy LTC at the same rate as you specified in your sell order it will fill your sell order up to the amount of the buy order. If the buy order amount is bigger than your sell order your sell order will be filled instantly and you will receive BTC and the buyer will receive your LTC. If there is no buy order at the rate you specified the system will wait for someone to buy LTC at the same rate. You can always cancel these orders before they are completely filled, but remember the 0.20% trading fee is taken when you place an order and not when you complete the order.


Why wipe all BTC from an imported address? I've read a couple blog entries and tutorials on how to spend BTC that are "stored" on a piece of paper.
They all suggested importing the private key into e.g. blockchain.info's wallet (or any equivalent)
and wipe ALL coins from that address. But why should I not continue using it?

Once your import the key, the key now exists in two places: your paper and your wallet.  Because of this, you've lost the advantage that a paper wallet has for cold storage.  What you now have is a paper backup of one of the keys stored in your hot wallet.  Any risks of a hot wallet now also apply to your paper wallet.

In addition, there is the inherent privacy issues with re-using a Bitcoin address, regardless of how that wallet is stored.  There aren't many advantages to re-using addresses, and this case is no exception.  If you still need a paper wallet after importing one, you should really create a new one.


Why are balances not in the blockchain? Currently one needs to traverse the full blockchain to determine the balance of a certain address. Wouldn't it be much more efficient to include the new balance along with each transaction? That way clients wouldn't need the whole blockchain to verify a transaction, since miners already verified the balance.

That would not work because the way the system is designed, accounts do not have a pile of coins to spend. Spendable coins exist in the form of transaction outputs that have not yet been used as the input of a subsequent transaction. To form a valid transaction, you must pull in coins from specific transaction outputs, not from specific accounts.

One could imagine a Bitcoin-like system where accounts have balances. In such a system, you could simply report the new balance of an account in any block that modified that account's balance. Then a transaction could pull in from accounts rather than specific transaction outputs. But that system would not be Bitcoin.

Essentially, Bitcoin was not designed around accounts. Accounts are just a convenient way for human beings using Bitcoin to think about the set of transaction outputs that can be claimed with the same key. (Or to form transactions that we know can only be claimed by a particular person.)


how do i backup private keys of user address which are generated by getnewaddress? i am working on website which receives and store bitcoins
each user will credited with newaddress for deposit BTC how would i take backup of their privatekeys with bitcoind
i think bitcoind generate address from key pool which is limited to 100 after that it will generate new key pool
what are the best practices to maintain backups

The addresses that you get from getnewaddress are part of your wallet. To back them up, use the backupwallet RPC command. This will create a copy of your wallet file at the location that you specify.

Bitcoin Core by default has a keypool of 1000 keys. However because Bitcoin Core uses BIP 32 Hierarchical Deterministic wallets, one backup is sufficient for you to be able to generate all of the private keys your wallet will ever have.

Although you will have access to all private keys, it is still recommended  that you backup regularly in order to preserve transactional data and other metadata stored in the wallet, as well as have all of the keys and not need to regenerate them upon restore (restoring may not necessarily get all of the transactions associated with keys that were not in the keypool at the time of backup). Thus you should backup the wallet every 1000 keys so that the latest unused keypool is always part of your most recent backup.

Also, if your wallet is encrypted (it should be), then you will need to unlock your wallet every 1000 keys so that the keypool can be refilled. You can do that with the walletpassphrase RPC command.


Is there an alternative to identify a lightning node without their IP or onion address? In the country where I live, only dynamic IPs are assigned to most customers unless you are willing to pay a lot more for a business service.
I guess not everyone in the world can get a static IP without paying a lot extra or doing something like running a VPS.
Also, a node operator with a static IP address doesn't have total control of the IP assigned to them.
I learned that lightning uses the IP or onion address of the node to identify it, so if a node changes their IP - I guess - it assumes the node is not online anymore. Which, I understand, is a problem if you open a channel with a node.
So, my question is: is there an alternative method, implemented or not, to identify a lightning node without knowing their IP or onion address?

Lightning network nodes are identified by their node_id which is a ECDSA pubkey. This key will not change if the network Adress (IP Adress or onion Adress) changes.
If you issue invoices you will see that neither IP nor onion Adresse are part of the invoice and necessary for routing. Only your node ID (which can be derived from yours signature) is part of the invoice. This means as long as your node is online, has open channels and is connected to its peers it will be able to send and receive money.
So the question is what happens to your node and its connections if the node changes its IP Adress? Well it will in the background open a new connection to its peers and channel partners so that they can talk to you again.
Of course for other peers to be able to connect to your node your node has to send out a new node announcment message via the gossip protocol in order to update its network adress. As gossip messages in lightning are not relayed in real time to protect against spam it can be tricky for other nodes to connect to you if your network address changes too often. However this will not be an issue for end users as their node can reestablish its necessary connections to its channel partners.
If course if all channel partners have the same problem peers could not find each other and conduct the reestablishing in real time. Thus for the routing part of the network somewhat stable network addresses are useful. In general toronions are considered more stable than dynamic IP addresses.
Of course lightning network could have relied on DNS as an alternative to solve that issue. While it does rely on DNS for node discovery as described in BOLT10 it does not use dns for your described problem. So to answer your question fully: no there is currently no alternative but that is most likely never a problem.


Funding channels In Lightning Network I was attempting to learn more about LN and came across the post below.

https://medium.com/tokensoft/tokensoft-lightning-node-how-to-connect-for-free-62b9aaec18b8

I also made a picture of my interpretation of the instructions.

In it, the suggestion is made that Nodes 1, 2 and3 connect to the his own (main) Lighning Node.

The purpose of this exercise is for Nodes 1, 2, and 3 to "gain access to the Lightning Network" altogether.

I was wondering if this would not be an exercise of futility (since the channels are funded with such small amounts).

TIA

Channel balances on the Lightning Network are denominated in millisatoshis. $5 correspond today to roughly 0.001 BTC or 100,000 satoshis, so even a channel funded with only $5 could facilitate a number of small payments back and forth.


Bitcoin core "bad-txns-in-belowout" Using bitcoin-cli decoderawtransaction, i got the txid of the only one vin, and the value of two vout are set at 0.015 BTC. Then, using bitcoin-cli gettransaction, i got negative value of amount and fee. How could the transaction have negative value of amount and fee ? Could this be the reason of that error "bad-txns-in-belowout"?

./bitcoin-cli -regtest decoderawtransaction "hexvalue"
{
  "txid": "35d2e765217d71db34fd0cd1cf52f419fc525069ac87ed9f413b194851c70849",
  "hash": "35d2e765217d71db34fd0cd1cf52f419fc525069ac87ed9f413b194851c70849",
  "version": 1,
  "size": 338,
  "vsize": 338,
  "locktime": 0,
  "vin": [
    {
      "txid": "2146415931a60db99ebf60849e2874dd67d37f870249a1ff06adcc6b8244155b",
      "vout": 0,
'''
    }
  "vout": [
    {
      "value": 0.01500000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 dd100be7d9aea5721158ebde6d6a1fd8fff93bb1 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914dd100be7d9aea5721158ebde6d6a1fd8fff93bb188ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "n1fprNxRhWrpkJ34A4cNsSZbHsnzhob2KL"
        ]
      }
    },
    {
      "value": 0.01500000,
      "n": 1,
...
    }
}

./bitcoin-cli -regtest gettransaction 2146415931a60db99ebf60849e2874dd67d37f870249a1ff06adcc6b8244155b
{
  "amount": -0.08000000,
  "fee": -0.00100000,
  "confirmations": 0,
  "trusted": true,
  "txid": "2146415931a60db99ebf60849e2874dd67d37f870249a1ff06adcc6b8244155b",
...
}

How could the transaction have negative value of amount and fee ? Could this be the reason of that error "bad-txns-in-belowout"?

No, it is not. The negatives you see are normal; the values are actually positive, but because you are sending money away from your wallet, they will display as negative relative to your wallet.

That error means that the value of the inputs is less than the value of the outputs. You need to check that output 0 of 2146415931a60db99ebf60849e2874dd67d37f870249a1ff06adcc6b8244155b actually has the value that you want to spend.


Where can one find the listing of the 3-call letters for all of the altcoins? There's BTC, and everything else.  But how are the call letters registered and is there a comprehensive list of them all?

As said above, there's no real, official "standard" everybody follows. Now then, you can go have a look at different exchanges and see what the call them. Cryptsy is famous for allowing you to deal with dozens of crypto-currencies, and they're constantly adding new ones (as well as taking out those deemed defunct) - you could go to their home-page and download

Be warned, though, that not all call-signs are 3 letters-long, though. Dogecoin appears as "DOGE" in most of the exchanges it appears at, and forty-two-coin is usually represented as just "42".

Some call-signs, off Cryptsy's page - notice the 4-lettered ones, the non-obvious (as eMark being "DEM" or Primecoin being "XPM") and the potentially confuse (as "LK7" and "LKY")

42   42Coin
ALF  AlphaCoin
AMC  AmericanCoin
ANC  AnonCoin
ASC  AsicCoin
BET  Betacoin
BQC  BBQCoin
BTC  Bitcoin
BTE  ByteCoin
BTG  BitGem
BUK  CryptoBuck
CAP  BottleCaps
CAT  CatCoin
CENT Pennies
CGB  CryptogenicBullion
CMC  Cosmoscoin
CNC  CHNCoin
COL  ColossusCoin
CSC  CasinoCoin
DBL  Doubloons
DEM  eMark
DGC  DigitalCoin
DOGE Dogecoin
DVC  DevCoin
EAC  EarthCoin
ELC  ElaCoin
ELP  ElephantCoin
EMD  Emerald
EZC  EZCoin
FFC  FireflyCoin
FLO  FlorinCoin
FRC  FreiCoin
FRK  Franko
FST  FastCoin
FTC  FeatherCoin
GDC  GrandCoin
GLC  Globalcoin
GLD  GoldCoin
GLX  Galaxycoin
GME  GameCoin
IFC  InfiniteCoin
IXC  IXCoin
KGC  KrugerCoin
LK7  Lucky7Coin
LKY  LuckyCoin
LOT  LottoCoin
LTC  LiteCoin
MEC  MegaCoin
MEM  MemeCoin
MNC  MinCoin
NAN  NanoToken
NBL  Nibble
NEC  NeoCoin
NET  Netcoin
NMC  NameCoin
NRB  NoirBits
NVC  NovaCoin
PHS  PhilosopherStone
PPC  Peercoin
PTS  ProtoShares
PXC  PhoenixCoin
QRK  Quark
RED  RedCoin
RYC  RoyalCoin
SBC  StableCoin
SXC  SexCoin
TGC  TigerCoin
TRC  TerraCoin
UNO  Unobtanium
WDC  WorldCoin
XNC  XenCoin
XPM  PrimeCoin
YBC  YBCoin
ZET  ZetaCoin


how does GHOST protocol really work? I am trying to wrap my head around GHOST protocol... I know it's too much to read, but not my fault. It's GHOST that's complicated (i guess)
As I read, it's said that:

instead of a longest chain consensus rule, GHOST follows the path of
the subtree with the combined hardest proof of work/difficulty.

OK, SO Let me explain how I understand it. Every node started at 0 block. Then other nodes mined 1B block, attacker mind 1A block.. and attacker solves his block(belowest one) secretly.He doesn't broadcast it.  Other nodes are at 1B and now there happened to be a fork (2D,2C,2B) since blocks got mined at the same time. then some nodes went ahead and got the longest chain ending at 5B(the most top chain). Remaining nodes(L1) are at 2C and 2B. some nodes(L2) from these remaining nodes(L1) are at 3E,3D,3C. and one of the nodes from L2 is at 4B now. Now, let's take a moment and say that everyone on the network broadcasted their blockchains. Attacker's chain won't be accepted because there's only 1 subtree(one path only).. Also, the most top chain is only one. As we can see on the image, The biggest subtree is 3E, 3D,3C. So what happens is some nodes share 0->1B->2C->3E, some share 0->1B->2C->3D->4B, some share 0->1B->2C->3C. Let's say I am nodeA and I receive all the broadcasted chains. When I get all of those, I have to choose from them. Since I found that different chains are derived from 2C, I should follow that path. I follow it and try to find the longest one in them which results in 0->1B->2C->3d->4B and that's the one i am gonna accept.
In this case, attacker's chain is doomed. so i think one of the problem's chance which is having 51% hash rate power and broadcasting the longest chain has been decreased(which is great). But I still see a couple of issues.

If blocks don't get mined at the same time, we won't have subtrees as shown on the image, Hence GHOST protocol is powerless here. and we still have 51% attack possibility and in this case, attacker's secret chain will succeed.
So, if blocks get mined at the same time, that's when GHOST protocol will help us. I guess GHOST protocol is a little bit of extra safety added on top of proof of work.
but as soon as nodes followed GHOST protocol(which means, they accepted the chain - from the image it's 0->1B->2C->3D->4B), we are back to where we were(longest chain wins). until blocks start to get mined at the same time again..
Let's say attacker broadcasted his chain, and my node received it. And let's also say that i've not received other node's chain due to network propagation delay. How will my node know that it shouldn't accept attacker's chain ? if my node had received all other node's chains, it would figure out that subtree in 0->1B->2C is bigger and would reject attacker's chain. Any idea ?

I think the main thing you've missed is the problem GHOST set out to solve.
It's first and foremost intended as a scalability/speed upgrade. We want to increase the size of each block and/or decrease the interval between blocks. Either of these would increase the ratio between propagation time and block interval.
The higher the ratio is, the more we get that blocks are mined at the same time. And then lots of honest hashrate is wasted on blocks that get orphaned.
This makes it easier for an attacker to attack, because he doesn't need to have more hashrate than the honest network - he only needs to have more hashrate than the unwasted hashrate of the honest network.
This isn't much of a problem now, when blocks are 10 minutes apart and are about 3MB. But if we were to try to, say, reduce the interval between blocks to 1 second, the time to propagate blocks will be a multiple of the average time to find a block, leading to huge waste and an easy attack.
GHOST (and the more recent SPECTRE) is designed to allow us to increase block size or speed without this waste.
Contrary to what you said, simply adopting GHOST will not cause less branching in the block tree. It will just mean that we won't waste hashrate due to this branching.
Re question 3 - I think you've got things backwards. The way a double-spending attack works is:

Attacker pays merchant, tx is included in the honest chain.
Merchant gives product.
Attacker releases secret chain, where the tx is replaced by one that credits the attacker.
Attacker has both the product and his money.

If you are not up-to-date on the network state, and think the attacker's chain is winning even if it's not, you're actually better off - you will see that the attacker intends to not pay, and you will know not to send the product.
After I send the product, I want the whole chain to recognize the tx that pays me. Even if there are nodes which are not up to date, and briefly believe the attacker's chain is valid - that will resolve quickly after they receive the blocks they've been missing (and see that the honest chain has more weight).


Somebody sells at 4k instead of 40k. Who gets it? If somebody sells x amount of BTC (or any other crypto) mistakenly at 4k instead of the current 40k (assumption), who will get it and for how much? Will somebody just be the happy one?

AFAIK, if it is the same as stocks, then it is "The person who entered it first", meaning:
If somebody put in the limit order to Buy At $33,000, before you, then your $4000 will be matched to his limit order, but because he entered it first, then the transaction between you and him will be $33,000.  That's the rule.
There are tons of buy orders to buy at $33,000 or $32,999, so the $4000 will be matched by those numbers first. (and it will be sold at $33,000 or whatever the highest bidder is).


How could you differentiate if the bitcoin address is from master node or derived nodes? Given that I have these two random generated bitcoin testnet addresses, could you tell if it is the bitcoin testnet, master node or derived nodes, if we discuss bip-0032 spec (Master key generation)?

**master node (m)**
mn6tBTqAigmknKMkpT82VYLy272mfXYdqF

**derived node (m/0/999999'/0)**
myt7MRuUpXRDL3ht5E1oiP3yrKkekCzc4S

I assume this question is about whether other people can tell whether there is a relationship between these two addresses:
Just from the addresses, third parties cannot tell that the two addresses are related.

Third parties may be able to guess that they are associated by analysing the transaction graph, though.


Compiling bitcoin-qt error: ld.exe: cannot find -lsecp256k1 I have followed the guide "Building headless Bitcoin and Bitcoin-qt on Windows" but with a more recent altcoin source code to test.

The compilation stop on ld.exe: cannot find -lsecp256k1

Is one step missing to generate this missing dll ?

My qt-pro includes:

  win32:BOOST_LIB_SUFFIX=-mgw49-mt-s-1_57
  win32:BOOST_INCLUDE_PATH=C:/Deps/boost_1_57_0
  win32:BOOST_LIB_PATH=C:/Deps/boost_1_57_0/stage/lib
  win32:BDB_INCLUDE_PATH=c:/deps/db-4.8.30.NC/build_unix/
  win32:BDB_LIB_PATH=c:/deps/db-4.8.30.NC/build_unix
  win32:OPENSSL_INCLUDE_PATH=C:/Deps/openssl-1.0.2k/include/
  win32:OPENSSL_LIB_PATH=C:/Deps/openssl-1.0.2k
  win32:MINIUPNPC_INCLUDE_PATH=C:/Deps/
  win32:MINIUPNPC_LIB_PATH=C:/Deps/miniupnpc/
  win32:LIBPNG_INCLUDE_PATH=C:/Deps/libpng-1.6.1/
  win32:LIBPNG_LIB_PATH=C:/Deps/libpng-1.6.18
  win32:QRENCODE_INCLUDE_PATH=C:/Deps/qrencode-3.4.4
  win32:QRENCODE_LIB_PATH=C:/Deps/qrencode-3.4.4/.libs
  win32:SECP256K1_LIB_PATH = C:/Crypto/mycrypto/src/secp256k1/
  win32:SECP256K1_INCLUDE_PATH = C:/Crypto/mycrypto/src/secp256k1/include

Problem resolved !
There was an error during the secp256k1 compilation process (MINGW32 under windows), adding:

  LT_INIT([win32-dll])

into the secp256k1/configure.ac has resolved the compilation error.


Calculate mnemonic code from terminal I want to replicate mnemonic code with terminal.
the steps are:

Create a random sequence (entropy) of 128 to 256 bits.
Create a checksum of the random sequence by taking the first (entropy- length/32) bits of its SHA256 hash.
Add the checksum to the end of the random sequence.
Divide the sequence into sections of 11 bits.
Map each 11-bit value to a word from the predefined dictionary of 2048 words.
The mnemonic code is the sequence of words.

I can see this image

And I take this entropy

0c1e24e5917779d297e14d45f14e1a1a

If I follow the image, I create the checksum

printf 0c1e24e5917779d297e14d45f14e1a1a | xxd -r -p | sha256sum -b

result

76e57a90f93135e97ce700a9e79196ba46315d65e696d0a4518270a8de3e80e4

Then take 4 bits (0,5 byte => 1 char ) and append to my entropy with this result:

0c1e24e5917779d297e14d45f14e1a1a7

Now I have 132 bits And I have to split in 12 segments of 11 bits each

I try to convert in base 2

 echo "ibase=16; obase=2; 0C1E24E5917779D297E14D45F14E1A1A7" | bc

11000001111000100100111001011001000101110111011110011101001010010111111000010100110101000101111100010100111000011010000110100111

But the result is not correct, If I put that entropy in https://iancoleman.io/bip39/#entropy-notes I can see that result

00001100000 11110001001 00111001011 00100010111 01110111100 11101001010 01011111100 00101001101 01000101111 10001010011 10000110100 0011010

But I don't understand How can I obtain that

00001100000 = 96 = army


How to model randomness in validators selection in PoS? I searched a lot here and on the Internet to figure how how randomness selection of validators in PoS works? I understand it is a random selection based on fraction of stake a validator has, similar to PoW.

In PoW, we can model block arrival as a possion process. E.g., if block interval is 10 seconds,, we expect on average a block to be created each 10 seconds. You can get two blocks where the time between them less than a second (hence memoryless process). The chance each miner has for each block depends on its hash power fraction, but random in terms of assigning miners to blocks.

Now, how block arrival and assignment differs in PoS? from what i think is the same as in PoW. From other sources, i read time is divided into slots, where each slot is assigned to a validator (say deterministic). But not really understand how this differs from PoW. Any plain English explannation is appreciated (without too much technical details).

I understand it is a random selection based on fraction of stake a validator has, similar to PoW.

Not correct. In PoW, any miner can mine the next block. In PoS, a specific validator is chosen by the protocol that has the right to form/propose the next block.

  The chance each miner has for each block depends on its hash power fraction, but random in terms of assigning miners to blocks.

The first part is correct that the chance a miner has depends on the hash power fraction. However, no miner is 'assigned.' Any miner can form the next block in the blockchain provided the block is valid and its header hash meets the target requirements.

  How block arrival and assignment differs in PoS?

There is no one protocol set in stone that determines how the next block validator is chosen. (1) Peercoin (the first coin to implement PoS consensus along with PoW) used coin age (no. of coins x no of days the coins are in the wallet) to determine the next validator. (2) Then there is a hash selector (Ouroboros Praos protocol) wherein you take the current date and time, sign it with your private key and then check if it is less than the difficulty target. If yes, you are selected as the next validator. (3) There was one method where the randomness of the next block will depend on the signature of the current block (this method is now defunct due to potential vulnerabilities.)


Who pays for the computational cost when validating a transaction Suppose Alice wants to validate a transaction (check this transaction does exist, not make a new transaction),
and suppose her has not downloaded all transaction history.

My understanding is,

1) Alice will send a request to all her peer computer nodes and ask for the root the Merkel tree and hashes required to validate the transaction.

2) Some miners among her peer nodes will locate the block that includes the transaction

3) As block only stores Merkle tree root, not internal nodes, these miners will have to construct a Merkle tree from all transactions

4) The miners send block header and hashes (Merkle tree root and hashes on the authentication path) back to Alice.

Since the step 3 requires computational resources, my questions is why some nodes want to perform these computations for Alice?
It seems that these nodes will not get paid for validating an old transaction.

You have a few things wrong.

  1) Alice will send a request to all her peer computer nodes and ask for the root the Merkel tree and hashes required to validate the transaction.

Alice probably already has the Merkle root, since it is part of the block header.  The first step in validating a transaction is making sure that block that contains it is real.  Even SPV clients store all the block headers of the entire chain, so they already have every Merkle root.

  2) Some miners among her peer nodes will locate the block that includes the transaction

This is more or less correct, except that the nodes do not have to be miners.  There are plenty of full nodes with full copies of the blockchain on the network that can be queried for these hashes.

  3) As block only stores Merkle tree root, not internal nodes, these miners will have to construct a Merkle tree from all transactions

Full nodes store all transactions, and returning the hashes of the Merkle tree is not too computationally intensive.  You can read more about this in the Transaction Data section of the Developer Guide.

  4) The miners send block header and hashes (Merkle tree root and hashes on the authentication path) back to Alice.

Again, it is not necessarily (or even usually) miners who will send the hashes of the Merkle path that are needed.  It will usually be non-mining full nodes.  And as mentioned before, the block header and Merkle root do not need to be requested.

In the end, Alice is the one validating her transaction, but doing so by using additional information provided by full nodes on the network.  The work that the full nodes do to supply this data is important, yet not too computationally intensive.  For example, my Raspberry Pi 2 works just fine as a full node.  As for who pays the full nodes for their service...well...nobody.  This has been a topic of much debate.

In the end, however, people operate full nodes for several reasons.  Off the top of my head:

so they can operate trustlessly
as a service to the overall health of the network (which, in turn, protects their own investments)
for research or business purposes

So even though supplying the required data for thin clients to do transaction verification can be viewed as charity, in reality there are incentives for participating...even if not directly financial.