text:
If using Bitcoin core client am I constantly going to be downloading data from the blockchain?
I understand you have to download the entire blockchain and sync in the beginning but don't you also have to constantly keep the software on if you want to buy/sell stuff, which means more data being downloaded to my personal comp every instant there is a transaction.
If this is true, what is the average amount of data per month being downloaded so that I can use bitcoin.
Also if this is true, why isn't this point highlighted on bitcoin.org, they say you have to initially download the blockchain but not that its constantly going to be downloading data on your comp, data is expensive!

Note that there are plenty of other, so called "thin" clients which are perfectly fine if you just want to use Bitcoin, e.g. to buy/sell stuff. Both mobile (all mobile clients are lightweight) as well as desktop clients (e.g. Multibit or Electrum). Furthermore you can also use web wallets, such as coinpunk.com or blockchain.info/wallet and others.

First: "data is not expensive" is not really true. Both harddisk and bandwidth are cheap and getting cheaper. But maybe you are in a situation where it's not cheap for you, so there are several solutions for that.

At the time of writing, the blockchain is 24 GB in size after 5 years. This is an expansion of 0.12 kilobytes per second. However, this does not represent all of the bandwidth used by the Bitcoin client:

The Bitcoin client also relays transactions and blocks it downloads.
The protocol has overhead.
Sometimes the Bitcoin client will download transactions that don't get into the blockchain.

I tested the amount of bandwidth that Bitcoin uses by measuring it using bwm-ng, over the course of six and a half hours. I found that it uses 2.1 kilobytes per second, combining upload and download. Over a month, that would add up to 5.5 GB.
Note that my Bitcoin client did not accept incoming connections, which would have changed the result significantly.
This can be an expensive amount of bandwidth. In that circumstance, you can use an alternative, like BlockChain.info, or MultiBit, both of which use almost no bandwidth.

The actual download usage of full Bitcoin nodes is somewhat higher because you need to download each transaction twice: once when it is first broadcast and again when it appears in a block. (This needless inefficiency will be fixed in the future.) Also, you download some transactions and other data that doesn't end up in the block chain. Upload bandwidth is much higher than that because you sometimes need to send a transaction or block to each of your peers, and you might even be asked by a peer to send them the entire block chain.

@theymos Thanks for the help improving my answer. Could you look at the edit?

Another solution (mostly for future readers of these answers) is getting your Bitcoin data from satellite or DVB broadcasts.
DVB project currently piloting in Finland: http://kryptoradio.koodilehto.fi/
BitSat project, under development: https://bitcointalk.org/index.php?topic=334701.0

You don't need to run the software 24/7, it just needs to be up-to-date in order to use it when you need to use it, to catch up with a few days worth of blockchain data doesn't take long and wont use much bandwidth.
Each block is 1Mb or less (at the moment) and occurs once every 10 minutes (roughly). So block data is fairly negligible in terms of bandwidth used.
However, as a full node you will also be peer-to-peer transmitting and receiving transactions and also supplying historical blocks to out-of-date peers. It's impossible to predict monthly data transfer because it depends on which peers you are connected to, but it's likely to be several gigabytes per month.
There are also other options instead of running a full node, bitcoin.org details these. e.g. blockchain.info, Hive, Xapo, MultiBit, GreenAddress, etc. You could also rent a cheap VPS server to run a full node on and configure your local node to only connect to that which would save a lot of bandwidth by removing the peer-to-peer data.

Note that the cheapest VPS servers may not have enough memory or disk to run a full node.  Also note that VPS providers often charge for bandwidth, at a rate that may be higher than the OP is paying for home Internet.


text:
How do I verify my privacy on Bitcoin Core
Based on my question, you can tell that I'm not experienced by any stretch of the imagination. However, I'm eager to learn.
I spent quite some time setting up a full node on a headless 2011 Mac Mini running Bitcoin Core full time. I also did my best to get everything running through Tor.
The point is I want to do my part to support the network, but at the same time I also want to avoid attracting any attention (from my provider, authorities, hackers, ...)
So here is my question: in what way(s) can I run checks to verify the privacy of my operation? Any tips are welcome.

Hi, one thing that may help for actual on chain privacy is looking at Blockstream explorer when you do a transaction, and looking at the bottom in the 'Privacy' section, heres an example of a tx with 'mixed script types' https://blockstream.info/tx/9d86441f0de05ca516e9a8ba0778c3c158ceba7756b7769d8ca351718f6acd5f . This gives you any privacy breaking heuristics they catch in your transaction, it can be helpful to discover privacy vulnerabilities in Bitcoin you were previously unaware of, as well as clue you in to how private the software you are using to transact really is trying to be.

@Poseidon i think he's talking about his node's privacy, not transaction privacy

If you set up everything over tor (and perhaps i2p), and don't keep poiting to it in other places (e.g post your onion service on social networks). It's unlikely you'll get in any trouble. There's no trivial test to do in this situation.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
Unable to use external SSD for Bitcoin datadir in Ubuntu
I'm learning about how to run a Bitcoin full node. I have started tinkering with it on Windows, and have put the data directory in an external SSD drive I got specifically for storing the entire blockchain data.
I am now looking into moving my setup into a dedicated Raspberry Pi 5 running Ubuntu. I managed to install Bitcoin Core via Snap, however, I'm struggling to point to the Bitcoin data dir in the external SSD.
Ubuntu recognizes it under /media/myUser/Elements and I can see the content via the GUI, but Bitcoin Core fails to start when I point to it in the bitcoin.conf file. I was expecting to see it under /mnt, but not sure why it's not showing up there.
Do I need to partition the external SSD for the Linux filesystem or something of the sort?
Would greatly appreciate any help!

I believe snaps have some security mechanism that prevents them from seeing external disk filesystems. I don't know the solution, so this isn't a full answer, but perhaps it's enough to help figure out what to look for.

This was actually it :) Thanks for pointing me in the right direction! This worked https://askubuntu.com/a/1345221

As @Pieter Wuille suggested, it had to do with the fact that snap doesn't allow packages to communicate with mounted devices by default.
This helped resolve my issue.
sudo snap connect packagename:removable-media

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
What is the point of solo mining pools?
I recently stumbled upon a solo mining pool. It's a pool for solo miners, but the rewards aren't shared, you only get the full reward if you mine a block. So... What's the difference between just mining solo?

The solo mining pool takes care of tracking unconfirmed transactions and supplying block templates for the solo miners. This allows the solo miners to run only mining hardware without a controller.

Seeing your follow up questions from the comments, let me go into a bit more detail:
Think of the Bitcoin miners as participating in a perpetual global lottery to be the author of the next block in the Bitcoin blockchain. Miners "enter the lottery" each time they hash the block header of a candidate block. About 1 in 5.22e23 of these hashed block headers yields a hash that is low enough to indicate that a valid block has been found. When a miner finds a valid block, they publish the corresponding candidate block and extend the Bitcoin block chain.
Miners create candidate blocks by first assembling a block template picking as many unconfirmed transactions from their mempool as they can fit in a block, then secondly using this template to derive numerous candidate blocks by changing either the nonce in the block header, parts of the coinbase transaction that can have arbitrary data, or other changeable parts of the block header. Changing any part of a transaction, the order of transactions, or the selection of transactions changes the Merkle root in the block header. Anytime even one bit changes in the header, hashing the header will result in a completely new hash, which miners use to quickly try many different candidate blocks.
In order to assemble block templates, a miner has to run a full node that keeps a mempool with the pool of unconfirmed transactions waiting to be included in blocks. Generally, the node software is used to create an initial block template. This block template is then provided to the mining hardware (ASICs), which will then generate and hash ~quadrillions of candidate blocks per second.
Setting up and maintaining a full node to serve as a controller for mining hardware takes more work than many miners are willing to invest, and mining by yourself yields extremely unreliable income. Therefore, many miners outsource the template creation to mining pools which generally share revenue among all the pool participants according to their contribution to the total hashrate of the pool.
Some miners either confident in their luck, or with sufficient hardware at their disposal choose to instead mine by themselves (not smoothing out revenue per a pool), but still outsourcing the block template creation by using so-called "solo mining pools".

I see. A couple of follow up questions: 1) you "connect" to a pool; what would you "connect" to if you mined solo, completely? 2) what are block templates? 3) what's a controller? 4) how did Bitcoin (solo) mining work in the early days?

I think I got most of these questions. "How did Bitcoin solo mining work in the early days?" sounds like a bit of a big new topic to open up, perhaps you could start another topic for that?

That's fair, thank you for the thorough answer!

A solo mining pool also takes care of communicating with the mining device, since Bitcoin Core does not speak the stratum protocol, can't control share difficulty, etc. It also constructs and adds the payout details to the coinbase transaction, which the getblocktemplate omits (though it provides ingredients for it).

So even in a Stratum v2 world where miners can make their own template the concept of a solo pool can make sense. Also note that you could run the pool software yourself. Nevertheless it's a strange term.


text:
bitcoind importaddress balance
I am trying to do some tests using multisig transactions without importing the private key in bitcoind (watch only addresses).
Bitcoind runs in regtest mode.
These are the steps I have done:

createmultisig 2, [three_public_keys] (address: 2MzNBD51VvSPU1w6vp2Z6zyRzVGwEHco5Wj)
importaddress multisig_address multisig_label true
sendtoaddress multisig_address 0.1. At this point I have a multisig address with 0.1 BTC
createrawtransaction from multisig address to a normal BTC address (miSXv45UamdKCBrb9DoWrzdQFzquqeVrhj) that is present in my wallet, amount 0.03
signrawtransaction with first key
signrawtransaction with third key -> the tx is "complete"
sendrawtransaction

I have omitted the confirmations steps.
As a result:

The listunspent command shows 0.03 BTC for the normal address and 0.07 BTC for the the multisig address
The normal address, which is in my wallet, is increased by 0.03 BTC (listaccounts)

At this point I would like to check the balance for the multisig address. I have some issues:

getbalance  always returns 0. I have the feeling that the provided label is not associated to an account, so, simply put, it does recognize it as an account and provides 0.
listaccounts does not show the multisig_account
EVERY single unspent block owned by the multisig address results to be "unspendable". I could not find any info about that field, but it does not seem to prevent that block from being used as an input. In fact, I use it as an input to send 0.03 BTC to the normal address. Is it normal?

Currently I am using listunspent to get all the unspent blocks, filter by multisig label and sum up all the amounts to get the balance. While it is true that it works (is it a correct way to get the balance?), it is also true that it might not scale.
This is my final transaction:
    bcli gettransaction 852ddf5c61a9f7bf2f16a9e0430eee738927cd9a8cd99cbab22ba55e0ac013bd
{
        "amount" : 0.10000000,
        "confirmations" : 10,
        "blockhash" : "000046caadc57b88f298e2409eff4370ad223d50c56631fae00d8fc4604e4039",
        "blockindex" : 1,
        "blocktime" : 1413096038,
        "txid" : "852ddf5c61a9f7bf2f16a9e0430eee738927cd9a8cd99cbab22ba55e0ac013bd",
        "walletconflicts" : [
        ],
        "time" : 1413096038,
        "timereceived" : 1413096038,
        "details" : [
            {
                "involvesWatchonly" : true,
                "account" : "mirko",
                "address" : "miSXv45UamdKCBrb9DoWrzdQFzquqeVrhj",
                "category" : "receive",
                "amount" : 0.03000000,
                "vout" : 0
            }
        ],
        "hex" : "010000000169b15f8599522a5f87d8edbeec3da95351b9bd5a1febb7eb3aa4498f5a9286fc01000000fdfe0000483045022100b77d6e54a3084587067ddbc08ddbb3bab5aac407f0d1dafbadf191cc8250954f022029503f2f32ae6d5513632a5e184ae3f8fcf09e49d392c39f70437651bef7a6a301483045022100fe41efff9176cfd6c108afcd5234cc4fa66cd5f0b652b5e9bb68a0b85c27e5d60220587c2045b9efab07abb17a652d500ffcb72c299194f84808a4d3bb820c69e174014c6952210286c7ae03f02252fa801e04db1df2f2f8e27878a1736480e4fc51e2ac4cba08e721039f682869cbbfb89aad9d0af1e10cf7d3f5ade3e6ad9546fde9a969a92abcf53f2103449784f470d86e75779d4faa9d98f4cd4aafa66332f9e4c824e9fc14a7dfb5c553aeffffffff02c0c62d00000000001976a91420125cd88147d3f1d16b453589f687500b0a606388acc0cf6a000000000017a9144e1978d2bed81a0af3d3e7759ab0bc8540717c548700000000"
    }

This is the decoded raw transaction:
{
    "txid" : "852ddf5c61a9f7bf2f16a9e0430eee738927cd9a8cd99cbab22ba55e0ac013bd",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "fc86925a8f49a43aebb7eb1f5abdb95153a93decbeedd8875f2a5299855fb169",
            "vout" : 1,
            "scriptSig" : {
                "asm" : "0 3045022100b77d6e54a3084587067ddbc08ddbb3bab5aac407f0d1dafbadf191cc8250954f022029503f2f32ae6d5513632a5e184ae3f8fcf09e49d392c39f70437651bef7a6a301 3045022100fe41efff9176cfd6c108afcd5234cc4fa66cd5f0b652b5e9bb68a0b85c27e5d60220587c2045b9efab07abb17a652d500ffcb72c299194f84808a4d3bb820c69e17401 52210286c7ae03f02252fa801e04db1df2f2f8e27878a1736480e4fc51e2ac4cba08e721039f682869cbbfb89aad9d0af1e10cf7d3f5ade3e6ad9546fde9a969a92abcf53f2103449784f470d86e75779d4faa9d98f4cd4aafa66332f9e4c824e9fc14a7dfb5c553ae",
                "hex" : "00483045022100b77d6e54a3084587067ddbc08ddbb3bab5aac407f0d1dafbadf191cc8250954f022029503f2f32ae6d5513632a5e184ae3f8fcf09e49d392c39f70437651bef7a6a301483045022100fe41efff9176cfd6c108afcd5234cc4fa66cd5f0b652b5e9bb68a0b85c27e5d60220587c2045b9efab07abb17a652d500ffcb72c299194f84808a4d3bb820c69e174014c6952210286c7ae03f02252fa801e04db1df2f2f8e27878a1736480e4fc51e2ac4cba08e721039f682869cbbfb89aad9d0af1e10cf7d3f5ade3e6ad9546fde9a969a92abcf53f2103449784f470d86e75779d4faa9d98f4cd4aafa66332f9e4c824e9fc14a7dfb5c553ae"
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 0.03000000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 20125cd88147d3f1d16b453589f687500b0a6063 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a91420125cd88147d3f1d16b453589f687500b0a606388ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "miSXv45UamdKCBrb9DoWrzdQFzquqeVrhj"
                ]
            }
        },
        {
            "value" : 0.07000000,
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "OP_HASH160 4e1978d2bed81a0af3d3e7759ab0bc8540717c54 OP_EQUAL",
                "hex" : "a9144e1978d2bed81a0af3d3e7759ab0bc8540717c5487",
                "reqSigs" : 1,
                "type" : "scripthash",
                "addresses" : [
                    "2MzNBD51VvSPU1w6vp2Z6zyRzVGwEHco5Wj"
                ]
            }
        }
    ]
}

This is the transaction that is the input for the previous one:
bcli gettransaction fc86925a8f49a43aebb7eb1f5abdb95153a93decbeedd8875f2a5299855fb169
{
    "amount" : 0.00000000,
    "fee" : 0.00000000,
    "confirmations" : 20,
    "blockhash" : "0000cf9fcd9b3dc7e08062284d84c184f76610c908cb96a5b19621d486c7ec0d",
    "blockindex" : 1,
    "blocktime" : 1413096031,
    "txid" : "fc86925a8f49a43aebb7eb1f5abdb95153a93decbeedd8875f2a5299855fb169",
    "walletconflicts" : [
    ],
    "time" : 1413096031,
    "timereceived" : 1413096031,
    "details" : [
        {
            "involvesWatchonly" : true,
            "account" : "",
            "address" : "2MzNBD51VvSPU1w6vp2Z6zyRzVGwEHco5Wj",
            "category" : "send",
            "amount" : -0.10000000,
            "vout" : 1,
            "fee" : 0.00000000
        }
    ],
    "hex" : "0100000001699191ffbe514553f4a9dcd02e3c7e351448d4e7c67f2e3ee3ec9a18a37a9a04010000006a4730440220359b170acf9650994549b6520bba440950c9904774eba4174bd7ada81a2702830220324f628c130bbcc5e54c3ee4702eb0e954dbd66f09944aa24a81992987d81e95012103080765b50062e774366f9be2f4adfeb28c27905e1dc48e41c3a54ca436f46ee2ffffffff0200c5d428010000001976a91452b3aef6dcab929528588f5a3fed742ac0f107e888ac809698000000000017a9144e1978d2bed81a0af3d3e7759ab0bc8540717c548700000000"
}

And this is the decoded transaction that is the input for the previous one:
 {
    "txid" : "fc86925a8f49a43aebb7eb1f5abdb95153a93decbeedd8875f2a5299855fb169",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "049a7aa3189aece33e2e7fc6e7d44814357e3c2ed0dca9f4534551beff919169",
            "vout" : 1,
            "scriptSig" : {
                "asm" : "30440220359b170acf9650994549b6520bba440950c9904774eba4174bd7ada81a2702830220324f628c130bbcc5e54c3ee4702eb0e954dbd66f09944aa24a81992987d81e9501 03080765b50062e774366f9be2f4adfeb28c27905e1dc48e41c3a54ca436f46ee2",
                "hex" : "4730440220359b170acf9650994549b6520bba440950c9904774eba4174bd7ada81a2702830220324f628c130bbcc5e54c3ee4702eb0e954dbd66f09944aa24a81992987d81e95012103080765b50062e774366f9be2f4adfeb28c27905e1dc48e41c3a54ca436f46ee2"
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 49.80000000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 52b3aef6dcab929528588f5a3fed742ac0f107e8 OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a91452b3aef6dcab929528588f5a3fed742ac0f107e888ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "mo4ExQhSqo4A1euJLK8FXDS2Qr9mbBLQXn"
                ]
            }
        },
        {
            "value" : 0.10000000,
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "OP_HASH160 4e1978d2bed81a0af3d3e7759ab0bc8540717c54 OP_EQUAL",
                "hex" : "a9144e1978d2bed81a0af3d3e7759ab0bc8540717c5487",
                "reqSigs" : 1,
                "type" : "scripthash",
                "addresses" : [
                    "2MzNBD51VvSPU1w6vp2Z6zyRzVGwEHco5Wj"
                ]
            }
        }
    ]
}

Finally, these are the unspent blocks:
{
        "txid" : "852ddf5c61a9f7bf2f16a9e0430eee738927cd9a8cd99cbab22ba55e0ac013bd",
        "vout" : 1,
        "address" : "2MzNBD51VvSPU1w6vp2Z6zyRzVGwEHco5Wj",
        "account" : "rpctest_1413096031008",
        "scriptPubKey" : "a9144e1978d2bed81a0af3d3e7759ab0bc8540717c5487",
        "amount" : 0.07000000,
        "confirmations" : 10,
        "spendable" : false
    }
{
        "txid" : "852ddf5c61a9f7bf2f16a9e0430eee738927cd9a8cd99cbab22ba55e0ac013bd",
        "vout" : 0,
        "address" : "miSXv45UamdKCBrb9DoWrzdQFzquqeVrhj",
        "account" : "mirko",
        "scriptPubKey" : "76a91420125cd88147d3f1d16b453589f687500b0a606388ac",
        "amount" : 0.03000000,
        "confirmations" : 10,
        "spendable" : true
    }

Notice the "unspendable" attribute. Unfortunately I have lost the 0.1 BTC unspendable block, that is, before the final transaction, but I am completely sure that it was "unspendable" as well.
Thank you very much for your help.
P.S. Sorry for the long post...

from the multisig example on bitcoin.org: "Neither the address nor the redeem script are stored in the wallet when you use createmultisig. To store them in the wallet, use the addmultisigaddress RPC instead." Maybe this is why you don't see results for the "2..." address.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
OP_RETURN transaction doesn't go to the blockchain
I created transaction with OP_RETURN adding some information. Even though transaction hash created successfully, the transaction doesn't go to blockchain properly. Could you please help me to do this transaction properly?
"scriptPubKey":
{
"asm": "OP_RETURN 726173656c6140676d61696c2e636f6d7e39383732363733383834",
"hex": "6a1b726173656c6140676d61696c2e636f6d7e39383732363733383834",
"type": "nonstandard"
}

Can you give the full transaction, and decode it?
The default client nodes will not broadcast your transaction because it is not standard. That may be the problem. If it is mined into a block, however, they would not refuse that block just because it had non-standard transactions, because the transaction would be valid even though it might not be standard. For more on this, you may find the below questions helpful.

Which scripts are currently considered standard and therefore actually propagated?.
What node implementations and mining pools relay and process 'non-standard' scripts?.

That might not even be the problem, though. It could be signed incorrectly. You should make sure that the OP_RETURN output was included before the transaction was signed. You can verify that the signature of the transaction is valid using the code in this question: How to verify ECDSA of a sample litecoin tx using pycoin?.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Decode blocks received and Store in another file for analyzing
I am working on a bitcoin research project. I want to decode receiving blocks from the block chain and store decoded data in a separate file for analyzing purposes.
For this purpose I digs the bitcoin c++ code and find the exact place, which use to write the blocks into blkXXX.dat file.
Could you please suggest a solution for this matter.
Thank you

#include <QTimer>
#include <QFile>

#include "BlockChain.h"

BlockChain::BlockChain ( const int start, QObject* parent ) : QFile ( parent ), blkFile ( start + 1 )
{
  QTimer::singleShot ( 0, this, SLOT ( start ( ) ) );
}
//--------------------------------------------------------------
void BlockChain::start ( )
{
  setFileName ( blkFileName ( blkFile++ ) );
  if ( !open ( QIODevice::ReadOnly ) )
  {
    _trace ( QString ( "cant open [%1]" ).arg ( fileName ( ) ) );
    getParent ( ).block ( QByteArray ( ) ); // finish signal
    deleteLater ( );
  }
  else
  {
    _trace ( QString ( "processing [%1]" ).arg ( fileName ( ) ) );
    QTimer::singleShot ( 0, this, SLOT ( next ( ) ) );
  }
}
//--------------------------------------------------------------
void BlockChain::next ( )
{
  bool lock ( true );
  if ( pos ( ) < size ( ) )
  {
    quint32 magic;
    quint32 size ( read ( (char*)&magic, 4 ) );
    xassert ( ( ( magic == MAGIC_ID ) || !magic ) && ( size == 4 ) );
    if ( magic )
    {
      read ( (char*)&size, 4 );
      xassert ( size > HEADER_SIZE && size <= MAX_BLOCK_SIZE );
      getParent ( ).block ( read ( size ) ); // process data
      QTimer::singleShot ( 0, this, SLOT ( next ( ) ) );
      return;
    }
    else
      lock = false;
  }
  close ( );
  getParent ( ).doneFile ( lock, blkFile - 1 );
  QTimer::singleShot ( 0, this, SLOT ( start ( ) ) );
}
//--------------------------------------------------------------
const QString BlockChain::blkFileName ( const int i )
{
  return
    ( i < 10 ) ? QString ( DATA_ROOT "\\blk0000%1.dat" ).arg ( i ) :
    ( i < 100 ) ? QString ( DATA_ROOT "\\blk000%1.dat" ).arg ( i ) :
    QString ( DATA_ROOT "\\blk00%1.dat" ).arg ( i );
}

Thank you very much for take your time to reply me. Actually I am trying to find a way to do the enhancement in C++ core, not the qt-client. Because we dont use qt environment for development.

This is just a working example which shows how to parse existing blk-files and store data somewhere else


text:
Bitcoin disappeared after resetting the blockchain and transactions
I'm looking for some advice on trying to recover bitcoins.
I transferred some bitcoin to my multibit wallet, it came through but still didn't confirm after 20 hours. So I tried resetting the blockchain and transactions, and now my wallet is empty! I got the message
com.google.bitcoin.store.BlockStoreException: Corrupted block store: could not find chain head

I searched for this and found advice about deleting the.spvchain file, but I don't appear to have this file!
Edit: Ok, so I just downloaded the newest version of multibit and the bitcoins appeared. All is good! Thanks for the info.


text:
Account verification
I have BTC in a exchange account, it states that it's unlocked, but when I try to transfer or withdraw my BTC it tells me that I need to deposit BTC to verify my account, why and how do I do this


text:
Stratum connection example
I'm trying to figure out what each parameter does in stratum. I've looked through the internet, but haven't found an agreement on what each parameter does. I have a wireshark dump of CCminer connecting to the pool, subscribing and authorizing, getting mining.set_target and mining.notify and submitting a share, but I can't figure out what exactly is each parameter in the packets. What are the parameters inside the methods? (for example I know mining.authorize uses username and password)

Is it possible that your question is "Where can I find documentation for Stratum V1?"


text:
Backward and forward compatibility
Can we consider these statements to be true?

Hard forks and soft forks are both backward compatible, but only soft forks are forward compatible.

However, backward compatibility in soft forks can be fragile if relatively low hash power supports the new software. For example, if a modified pre-taproot node mines a segwit-v1 input transaction.

This question is similar to: What is a soft fork? What is a hard fork? What are their differences?. If you believe it’s different, please [edit] the question, make it clear how it’s different and/or how the answers on that question are not helpful for your problem.

@RedGrittyBrick, Thanks for the link. I had read that previously. However, my main question is about backward compatibility. Can hard forks be backward compatible? I've seen various sources, including a tweet by murch, stating that hard forks are also backward compatible.

Can we provide an example of how BCH can demonstrate backward incompatibility? For instance, would the mandatory segwit sighash algorithm or the ForkID flag serve as such an example?

Can this be considered: If a hard fork is backward compatible, there is a possibility of a wipeout?


text:
Theta old token and Theta Mainnet token
My Ethereum address shows me two versions of the Theta old token (with a different value) and Theta with the current market price.
Theta old token is only visible in Rabby wallet.
While Theta with the current Market Price is only visible when I scan with Etherscan.
What‘s strange is that I can‘t access Theta on the Theta Mainnet, and it doesn’t Show any information on the Theta Explorer.
Any ideas why I see the Theta old token only on Rabby wallet, Theta, supposedly, current token on Etherscan, but nothing on Theta Mainnet, not even the Explorer?
Thank you.

Hey MWohks, we only deal with questions about Bitcoin on this Stack Exchange. I’ve migrated your question to the Ethereum Stack Exchange, which might be able to provide more insights: https://ethereum.stackexchange.com/questions/167228


text:
OP_Return in transactions at json_rpc_api at blockchain.info
I am writing a project in Ruby using JSON-RPC to communicate with blockchain.info. The API is available here: https://blockchain.info/api/json_rpc_api
Is it possible to create a op_return txout using the given JSON-RPC API ?

Since they don't support signtransaction or createrawtransaction, I don't think so.

Well, in that case I will need to run my own node to broadcast a message with OP_RETURN, the only way will to be run my own node?

Blockchain.info and bitoind/qt out of the box doesn't support pushing transaction out with the OP_RETURN op code. They will mark the transaction as invalid and refuse to broadcast it.
I have an open source project with a program that will push out transactions to the network directly at https://github.com/kaykurokawa/pushtx.  It doesn't do any error checking on the transaction so transactions with OP_RETURN will get relayed.
I've successfully used this in combination with pybitcointools for crafting a transaction with OP_RETURN in it.


text:
Time to send bitcoins?
I was investing bitcoins in Coin Controller but I need the time to send it because they only give you 10 minutes. So I want to know how to calculate the time to send bitcoin with for an example 0.00005 transaction fee. I know that you can't calculate it but do you know how long it would take if I send 0.00015 and the transaction fee is 0.00005 (the half of a normal transaction fee).

I'm not sure I would call that an investment - I'd call it more of a pyramid scheme.


text:
Consolidate to one wallet service
I've used a few different apps to create wallets and have decided to narrow down to a single web-based wallet software.  Is there some way that I can take the addresses from my other apps and import them to my new favorite service?
I'm not concerned about moving currently "owned" value, but rather leaving an orphaned address out there.  I'd hate for someone to send coins to an address that I can no longer access because I've uninstalled a particular app from a particular computer.

Never delete a wallet. At least keep backups!

I don't want all that block chain taking up valuable space on my multiple devices.  I really need to clean up my phone specifically!

@NickSentowski: You can keep the wallet files without keeping the blockchain. Also, There is no mobile app that stores the entire blockchain.

I will prefix this answer with the statement "Don't use a web wallet", but since your question explicitly states you want to use one, i'll leave my ideals at the door.
(Side note: Coinbase lets you use their "vault" in multisig mode, where you control the private keys yourself. Withdrawals take 48 hours to confirm, so perhaps it isn't ideal for you, but consider solutions where you retain control of your keys. I am in no way affiliated with Coinbase, other than using their service myself.)
Usually most wallets have an "Export private keys" feature, and  an "import" feature included. Which wallets in particular are you using?
This question indicates the following steps for Bitcoin QT:

To export a private key from your Satoshi bitcoin-qt client:

launch your bitcoin client as usual and wait for it to load the blockchain and start up
click on 'help' in the menu bar (top right)
click on 'debug window'
select the 'console' tab
type: walletpassphrase "your walletpassphrase here" 600
type: dumpprivkey [your public key here]
this will return the private key, you can copy it now; ensure you clear your clipboard/history afterwards
type: walletlock

For MultiBit, This page describes the steps to export:

In the 'Wallets' side panel choose the wallet you want to export the private keys for.
Select the menu option 'Tools | Export Private Keys'. The 'Export Private Keys' screen appears.
By default, the private keys file is called the same as your wallet file, only with an extension 'key' rather than wallet. You can see this in the following screenshot: [redacted]
If you want to output the private key file to a different directory or filename click on the 'Export to. . .' button. A file chooser opens and you can select the file to save to.
It is strongly recommended that you password protect your private key export files. To do this, click on the 'Password protect export file' radio button.
Enter the password you want to use in the 'Password' field and then repeat the same password in the 'Repeat password' field. If they match you get a little green tick on the right hand side.
To output the private keys to the output file specified, click on the button 'Export private keys'. The private key file is written and a success message appears. If the export of the private key file fails for any reason the error message is given on screen.
After the export file is written, it is then verified by reading the file back in again and checking the keys in the file match the keys in the wallet. A verification message is given if this is successful.

If you can indicate which wallet you're using, I can add the steps for exporting to this post. Additionally, if you want to import into a new service, you will first need to determine whether your wallets are hierarchical deterministic (HD). If so, the "private keys" are in reality a single key, which is used (in effect) as a seed for the entire set of keys in your wallet (theoretically infinite). If your web wallet supports HD key imports, you're all set, otherwise you're going to need to figure out how to extract the private keys for each public key you used, and export those.


text:
How Do I create a Mining Pool for an Altcoin?
I made an altcoin using coincreator.net , but I can only mine it on an underpowered windows computer. I was wanting to make a pool so that my friends and I could mine it together from a Windows or a Mac computer. If no one knows how to do this, then could anyone tell me how to solo mine on a computer that does not have the altcoin wallet? Thanks in advance!

You'll need to clarify details. Ie is it POW or POS? SHA256 or Scrypt or something else? Re I can only mine it on an underpowered windows computer, I'm not following you here. Why do you need to mine your own coin faster? Just so you know, the reason you don't find this information online is because there is no copy/paste method of starting an altcoin, it's extremely complicated even if you can code C++.

Check out MPOS, here is a guide to setting up an MPOS pool:
https://github.com/MPOS/php-mpos/wiki/Quick-Start-Guide
And, to answer your last question, it is impossible to solo mine standard coins on a single computer that does not have the alt coin wallet in question installed.

and if the target altcoin wallet doesn’t provide a mining port ? and the altcoin wallet doesn’t release it’s source code ? Is there a way to go ahead straight from databases ? I’m thinking about https://gmdcoin.co.


text:
How to increase fee of existing transaction with bitcoin-cli
I have broadcast a trasnaction from my bitcoincli wallet using this command:
./bitcoin-cli sendtoaddress ADDRESSGOESHERE 0.1
The problem is, it has set the fee to a very low amount by default.
After doing some more research, i found "bumpfee" but when i run this command:
./bitcoin-cli bumpfee TXID
i get this error?
error code: -4
error message:
Transaction is not BIP 125 replaceable
I also found another way was to run this:
./bitcoin-cli -conf=/mnt/blockchains/bitcoin/bitcoin.conf bumpfee TXIDGOESHERE
But that returns:
error: Could not locate RPC credentials. No authentication cookie could be found, and RPC password is not set.  See -rpcpassword and -stdinrpcpass.  Configuration file: (/mnt/blockchains/bitcoin/bitcoin.conf)
Is there a way for me to increase the fee of a transaction of someone else? That way, I can use my Electrum wallet to increase the fee of this transacton, but it doesn't seem to give me that option inside Electrum either.
I am using an old version of bitcoin-cli, perhaps I need to update it to the latest version?

related: https://bitcoin.stackexchange.com/q/115360/5406

You created a transaction that signaled finality. Your wallet will therefore not allow replacing it per the opt-in RBF rules specified in BIP125.
You have multiple options:

Use child-pays-for-parent
If your stuck transaction has a change output, you
can spend the change output with a high-feerate transaction. Miners will then include the stuck parent transaction in order to collect the fee of the
child.
Abandon the stuck transaction

Shut down Bitcoin Core
Delete the mempool.dat to remove knowledge of the stuck transaction from the mempool because abandontransaction only works when the tx is not in the mempool
Start Bitcoin Core with walletbroadcast=0, so your wallet doesn’t put it immediately back into the mempool
Call abandontransaction "txid"
Create a new transaction to replace the stuck transaction with a higher feerate that uses at least one of the inputs of the previous transactions to create a conflict
Restart Bitcoin Core without the walletbroadcast=0 to return to the default behavior regarding submitting of transactions

You may want to consider upgrading to v24, since that version started marking all transactions built from the commandline as replaceable by default. Alternatively, you can use the replaceable parameter on the sendtoaddress RPC to explicitly mark future transactions as replaceable.

A transaction whose input sequences are all 0xFFFFFFFE or greater is not eligible for RBF. If at least one input sequence is less than 0xFFFFFFFE, the transaction may be replaced by fee.
Seems your transaction is before BIP 125.

I tried running this as well:
./bitcoin-cli bumpfee TXID
but it returns this error:
Transaction is not BIP 125 replaceable
Does this mean, there is absolutely no way for me to increase the fee on this transaction?


text:
Is a smart card more than an non-updatable/inacessible and tamper resistant software?
This question is asked in light of the latest Ledger Recover debacle, and an earlier question.
I'm trying to understand whether devices such as smart cards or YubiKeys are anything more than than a chip (= Secure Element) with non-updatable firmware that is tamper proof? I.e since everything is implementable in a (Turing complete) CPU then how does it matter whether a Secure Element has support for Bitcoin's cryptographic primitives - other than making signing and decryption faster. Would a device with a generic CPU where the software can't be changed (without losing the secrets as well) with protection against physical attacks already be "the dream hardware wallet" which doesn't support key export no matter what?

I.e since everything is implementable in a (Turing complete) CPU then how does it matter whether a Secure Element has support for Bitcoin's cryptographic primitives - other than making signing and decryption faster.

Firstly I think this is slightly a misconception, it is important to be able to do ECC operations efficiently which is why a theoretical Secure Element (SE) with these capabilities would need to be efficient. However the point of them is not to compete with the efficiency of say a desktop processor, the point is to have a verifiably correct and discrete processor that is efficient enough do do the operations on a small device.

Would a device with a generic CPU where the software can't be changed (without losing the secrets as well) with protection against physical attacks already be "the dream hardware wallet" which doesn't support key export no matter what?

I am not sure that smart cards fit this description perfectly, they store information and require physical interaction to release secrets but are not made for generic CPU processing if that is what you are suggesting.
I want to clarify I am certainly not an expert on this topic but from what I have researched the reason a smart card (SC) is not more secure than a SE is because you are inable to secure private key operations on the SC, you can only use it to store the private data. The SE having the capability for secp256k1 (which apparently none do atm) would allow you to do signing completely airgapped from your potentially vulnerable or already exploited personal computer system or local computer network. That being said there are non-secp256k1 related private operations that can be done on the SE, which in the case of an SC would need to be performed on your personal computer system which is an increased attack surface.
Ledger for instance claims that they use the SE to generate private keys:

Secure Element Chip Protects Your Ledger From Attacks
A Secure Element is a highly advanced chip that mitigates a lot of different types of attacks. This cutting-edge chip, which is used in high-level security solutions, really sets Ledger apart as a top-end security solution for crypto assets. All of our devices use a Secure Element, which greatly enhances their security. Ledger uses them to generate and store private keys for your crypto assets.

https://www.ledger.com/academy/security/the-secure-element-whistanding-security-attacks#secure-element-prepared-for-anything
I do not recommend using ledger in light of their recent press releases however this is an example of how a SE might be used.
Blockstream Jade adopts a different security model not based on SE which you may find to be relevant:

Instead of a secure element, Blockstream Jade uses a unique security model that allows it to remain fully open-source while also being protected from physical attacks and achieving similar (if not better) security from this potential threat - by acting as a "virtual" secure element.

The blind oracle model that Jade uses is fully open source, and is truly blind. It knows nothing about Jade wallet data, and doesn't even know the user's actual PIN. Users may use Blockstream's blind oracle to protect their wallet, or they may run their own.

https://help.blockstream.com/hc/en-us/articles/13745404122265-Does-Blockstream-Jade-have-a-secure-element-
From what I can surmise, an SE can be useful for certain private operations such as generating a key however it does not close the attack surface completely. An SC because it cannot do any private operations is a more open attack surface because it delegates private operations to any computer system you plug it into. An open source blind oracle model may be an effective way to decrease the attack surface when using a SC or hardware with a similar security model such as I believe Jade might fall into. However since all SEs so far are closed source it may not be a viable option for SE based wallets to implement blind oracles to protect private key operations yet.


text:
Is new cryptocurrency that runs only in raspberry pi possible?
Is it possible to create a cryptocurrency software that can run efficiently on a raspberryPi and has a mechanism to detect (based on maximum coin production?) if a node is using a better computer so the swarm rejects it's coins?

possible duplicate of Is there an altcoin that is only feasible to mine by CPU?

@GregHewgill: Not a duplicate.  This question wants a mining algorithm that not only can only run on a CPU, but only on the CPU of a Raspberry Pi.

How would you be able to tell the difference between a thousand people with their own Raspberry Pis and one person with a very fast computer? You can solve a block with a different address every time, so there's not really a way to know.

It possible to inject hardware detecting code into code of your mining software, but to protect the mechanism you cannot publish it as an open-source. That will make your currency not so popular as others. Even if you will be succesful there are people that will change the Raspberry Pi CPU and pass-by your mechanism.

authors: Вася Васильчиков


text:
How would one go about generating a BIP-38 encrypted vanity address for cold storage?
I want to generate a vanity address with BIP-38 encryption for a cold storage paper wallet, how would I go about securely making one? From what I've found, generating a vanity address with Vanitygen does not allow me to encrypt the key. Or is a vanity address advisable at all for long-term cold storage?

Take a look at http://bippy.org.
The main potential issue I see with using a vanity address for cold storage is in spending from the address multiple times. If the wallet software you use isn't properly crafted (i.e., by using RFC 6979) there's a possibility that it will use the same k value during ECDSA on the transaction, which will make it possible to recover your private key (see this). Note that this potential issue applies to any address for which there is more than one spend, not just vanity addresses. But I bring it up in particular here since the nature of a vanity address implies a reasonable likelihood of multiple spends from the address.

Would there be a possibility of Bippy causing this? I'd more than likely only be using it for very few spends, and more long-term storage and many deposits.

Or could I just hypothetically use Vanitygen offline, and then encrypt it with Bippy? Vanitygen is tried and true, I'd assume it wouldn't have any glaring issues.

This specific issue I mentioned is relevant at the time of spending, or that is to say, after the private key has been imported into wallet software in order to retrieve funds. It is not related to how the private key or address are generated.

In summary -- when spending, know your wallet software.  :-)


text:
Is there an easy-to-use tool for creating and signing offline transactions?
From what I understand, signing a transaction offline means I don't have to ever expose my private keys to a web-connected computer. From what I've found, the only program that allows something like this with WIF keys is sx, are there any other tools that perform something like this? Or is sx the only way do accomplish this?

Armory is a popular solution for dealing with offline wallets. It is GUI based so is more user friendly than command-line / programming based solutions.
https://bitcoinarmory.com/

Would Armory be appropriate if I had one paper wallet that I wanted to reuse many times, without exposing my private keys?

You can do this using Bitcoin Core, and it'll be even easier with Bitcoin Core 0.10's watch-only wallet support.
With the current Bitcoin Core, you create a wallet on your offline machine.  Using it, you get one or more addresses (saving them, for example, to a text file).  You copy those addresses to your online computer and give them to people to pay you.  When you want to spend those payments, you create the transaction on the online computer in an unsigned form, copy it to your offline computer, verify it, sign it, copy the signed transaction back to the online computer, and send it.
Core dev Greg Maxwell has instructions for all this on his site: Offline Signing Demo.  There's another example aimed at developers on Bitcoin.org: Offline Signing Example.
The problem with both methods is that you need to know the TXID of any payments made to the addresses corresponding to your offline keys, and current (December 2014) versions of Bitcoin Core don't make that easy.  However, the next version of Bitcoin Core (0.10.0) will include watch-only address support.  So you'll take that list of addresses you generated and use the new importadddress RPC command to add them to your wallet.  The private keys will still be offline, but your online Bitcoin Core will track those addresses as if they were regular parts of the wallet.  Then you'll be able to use the listunspent RPC to get the TXIDs and vouts for incoming payments without any extra work.

Just discovered the android apk : bitcoin paper wallet from fireedge.
I use it on an old phone which I had reset, without Google account and transfered only the 2 apk manually : bitcoin paper wallet and qrdroid for copy pasting the json utxo and transaction to sign. Wifi disabled of course.
Before sending the tx, I use coinb. In on the online phone/computer to verify the target and amount.
https://github.com/ValleZ/Paper-Wallet


text:
How exactly is Multibit HD more secure than Multibit Classic?
In what ways is Multibit HD more secure than the old, no longer supported, Classic version? What are the differences in threat models, wallet recovery, and other areas a Bitcoin user would care about?
I haven't found anything about this on multibit.org.


text:
How can I use a vanity address as my main address
I obtained a vanity bitcoin address (1MonkeyQWbMzny7BNTA66W9wv6KaCFFAB7) along with its private key. I would like to be able to use this as my main address.
Sites like BlockChain.info allow you to import the bitcoins with a private key, but is there something where I can enter the address and private key and be able to view how many bitcoins I have, and send them from THAT address (not import them to another one, like BlockChain.info does)?

Pure technically, there are many wallets that enable you to import single private key. I personally like Electrum, which can be both desktop and mobile app. You can have multiple wallets inside Electrum, i. e. single-address wallet (which is your case), Legacy-HD, Segwit-HD, or even all of them if you like. If you work with one, it will not mix addresses with others. What you're trying to avoid is 'sweeping' the private key, which resends all funds from your vanity address into existing wallet and never reuses your (vanity) address again. I don't recommend using bitcoin-core to accomplish this. Creating raw transactions manually is very inconvenient.
Apart from this, I have several other recommendations regarding your question. Don't use addresses/keys you obtained - generate vanity address by yourself - e. g. with this app.
Don't use online web wallets unless you have no other option. Blockchain.info may seem to be nice and good choice at first sight, but it's not necessary to give keys of your money to some internet company to look after it.
Vanity address may be cool, but use it only as a bitcoin contact card. For everyday transactions and payments resend the funds into Segwit HD wallet. It will significantly reduce fees and improve your privacy.
To check your balance, don't enter private key anywhere, just use blockchain explorer like blockchain.info   or blocktrail and your bitcoin address.


text:
How can I solo mine using Bitcoin Core?
I want to mine Bitcoin using the Bitcoin Core client.
I have followed the steps on https://www.youtube.com/watch?v=Xd4Opw0Upok, but when I type "setgenerate true" in the console, it replies with "Method not found (code -32601)"
How can I mine Bitcoin with Bitcoin Core?

You cannot.  The mining functionality was removed in version 0.13.0 since it was hopelessly inefficient.  See Since which version the mining functionality removed from wallet?
It is not practical to mine Bitcoin without recent specialized ASIC hardware.  See In the ASIC-age, is it worth starting mining Bitcoin at home?


text:
What's the fastest websocket bitcoin provider to access mempool data?
I'm looking for a free or paid (reasonably) way to access the bitcoin mempool data by subscribing to the mempool. I'd like to get info in real-time, or anyway in the fastest way possible. Can anyone recommend how to do it? Thank you!

mempool.space have a API-WebSocket.
You can obtain data of:

blocks: last 15 block info, you can specify a particular block to obatian itself and 14 before blocks data.
mempool-blocks
live-2h-chart
stats

It's not the best, but it works.
It depends on what you want, but the API-Rest is much better, has MORE data.


text:
How can a replace occur with a tx with lower fee and feerate?
I have seen a tx A get replaced by a tx B, where B had a lower fee and feerate than A and it was broadcasted later. How is it possible?
These are the txs details:

Tx A: segwit,  ̶t̶a̶p̶r̶o̶o̶t̶,  ̶R̶B̶F̶
Tx B: segwit,  ̶t̶a̶p̶r̶o̶o̶t̶,  ̶R̶B̶F̶, Full RBF

Can anyone help me understand it, please?

Could you share the transactions you're talking about?

Generally, the replacement rules employed by Bitcoin Core specify that a replacement must both exceed the original transaction in feerate as well as in absolute fees.
A likely explanation could be that while your node saw the higher feerate transaction first, the miner that found the block had seen the original, lower feerate transaction first and when they authored a block, you learned about the lower feerate transaction from the block. Another reason could be that the winning transaction was accompanied by a child transaction which overall made parent and child more attractive than what you considered the better transaction.
These are only guesses, and there are a number of other scenarios in which a partial view of the overall situation could look like what you describe. If you want a more specific answer, please share the transactions in question.


text:
What happens to bitcoin if math is found that makes reversing PQ multiplication, modular math, etc, easy to reverse in a few steps?
What happens to bitcoin if math is found that makes reversing multiplication, modular math, etc, easy to reverse in a few steps? What if DH exhanges can be decoded almost as fast as they can happen?  Would bitcoin pay to keep this out of public? (In real money, of course)

What happens to bitcoin if math is found that makes reversing multiplication, modular math, etc, easy to reverse in a few steps?

All of these are already easy.
Reversing elliptic curve point multiplication, is however considered hard. This is the cryptographic hardness assumption that underlies Bitcoin's signature algorithms, ECDSA and Schnorr. If that changes, new cryptography will need to be adopted. If these breakthroughs happen quickly and unexpectedly before migrations can happen, Bitcoin users may be affected.

What if DH exhanges can be decoded almost as fast as they can happen?

Bitcoin doesn't currently use Diffie-Hellman anywhere in the protocol, though BIP324 proposes it for transport encryption. This would be very easy to upgrade, and low impact if broken.

Would bitcoin pay to keep this out of public? (In real money, of course)

Bitcoin is a currency, not an entity that can choose to pay anything, in whatever currency. Hypothetically, some bitcoin users may be incentivized to prevent cryptographic breaks that would affect the system becoming public, but I cannot speak for them.

The reverse of multiplication is division, which is easy, yes, even in a modulo setting (look up modular inverse). Factoring is not easy in general, but this is not relevant for any of the cryptographic protocols used in Bitcoin.


text:
How to connect to Terraminer via USB?
Does anybody know how exactly to connect to Terraminer machine via USB?

I found out that it's a simple serial connection.
On Linux or Mac this does work for me:
screen /dev/tty.usbserial-XXXXXX 9600.cs8

Or you can you any other program for serial communication, e.g. minicom
Serial settings are: 9600 8-N-1
Or after firmware upgrade baud rate is 115200

First of all, did you read the manual?
http://cointerra.com/wp-content/uploads/2014/02/TerraMiner-User-Guide-1.pdf
This is a miner with a mining controller on board, specifically the beaglebone black. This allows the miner to do 'standalone mining', meaning it does not need a computer to control it, it has it's own microcontroller to connect to a pool and get the necessary information to start hashing away.
If you do want to connect the miner to a computer:
Accessing the TerraMiner via Serial Port
You can access the TerraMiner by connecting a USB cable between a computer and the TerraMiner’s
serial port and using a terminal program. The login is root and the password is cointerra.

But the manufacturer does say:
NOTE: Accessing the TerraMiner through the serial port is unsupported by
CoinTerra. The Technical Support team will not be able to answer any inquiries
regarding serial port access. Accessing the TerraMiner via the serial port and
modifying the software will invalidate the product warranty.

Edit after comment:
I do not own this machine myself, so I can't say this out of experience. But from what I can read, the miner has a Beaglebone board inside of it, as the miner controller. A beagle bone has a micro USB connection, so plugging in a USB cable into the Beaglebone would allow you to connect to it.

Yes, I've read the manual. And the manual says you can connect via USB, thus the question created above HOW EXACTLY?

@Daveel I have edited my answer to hopefully answer your question.


text:
How light can an input be?
In the bitcoin-core reference client, CFeeRate::GetFee is a function of num_bytes.  What is the smallest amount of num_bytes that a TxIn can be in practice as it pertains to calculating that inputs effective value?  The reason I ask is that there are some test cases in the core wallet that use 150 bytes which seems unrealistic.  The transaction calculator shows taproot as the most compact at 57.5 vB or 230 bytes I believe.  The reason why 150 bytes is problematic is that it's difficult to faithfully  reproduce that calculation using the rust-bitcoin framework for example, since the effective_value calculation implies at least inputs of 160 bytes due to the output and sequence size implicit in all effective_value calculations.  Of course, a test could be made for 160 bytes instead which would probably have identical results, although I'm mostly curious why 150 bytes was selected here and if there's some practical oversight in the rust-bitcoin effective-value calculation.

In the rust-bitcoin code, the 160 is a minimum weight, denominated in weight units, not size. 160 weight units corresponds to 40 (virtual) bytes.
In the Bitcoin Core coin selection unit test, the 150 is a virtual size, denominated in virtual bytes. In weight units, it would be 600.
The smallest an input could be is 41 vbytes. This happens to be 41 actual bytes as well, and is 164 weight units. This input would be composed of the 32 byte txid, 4 byte output index, 1 byte scriptSig, and 4 byte sequence. As there is no witness data, each physical byte translates to 4 weight units.
The rust-bitcoin code is specifically excluding all script and witness data, so the 1 byte scriptSig is excluded from their calculation, hence 160 weight units.

I see thanks.  It wasn't clear to me if the 150 in the tests was bytes or Vb.  If it's Vb then that resolves the other problems I had with calculations.  And yes, I am aware that in rust-bitcoin, the computation starts at 40 vB. I guess I should have started there instead of using 160 bytes.

Bytes are irrelevant for feerate. Only weight or vbytes matter.

I think you meant fee not feerate?

In rust-bitcoin, the FeeRate module implicitly converts to the units sat/kwu where in bitcoin-core, it looks like the units are sat/vB.  I was able to make a unit test with the same results as bitcoin core using FeeRate::from_sat_per_vb(5) and Weight::from_vb_unwrap(110) which gives the same results as in core fee_rate = 5000 and weight = 150

@yancy I meant that feerates are always expressed per vbyte, weight units, or multiples thereof. Bytes (as in total serialized size) is just conceptually irrelevant for fee-related reasoning.

@PieterWuille in rust-bitcoin, functions either return usize (u32 or u64) or Weight, so this is what I mean when I say bytes or Weight.  For example base_size of an input: https://github.com/rust-bitcoin/rust-bitcoin/blob/dbedac1bffa9f35c9c6b1a818d6a195ebb06cf46/bitcoin/src/blockdata/transaction.rs#L137.  Conceptually bytes or usize here is vbytes not weight.

Yes, but I still don't understand what you mean with "fee not feerate". I'm not talking about code at all. Just the concept of feerate isn't applicable to bytes.

fee_rate is a ratio of either sats divided by Weight Units or sats divided by vbytes (which I am confusing the issue by calling bytes).  I don't think we disagree.

and yes, fee is not applicable to bytes, sorry for the confusion


text:
What is the difference between X11 and X11 Ghost (Gost)
I'm looking at SIBCOIN. Its algo is X11 Gost. I've been trying to see what differentiates that algo from "plain, vanilla" X11.


text:
How to get BTCChina full Orderbook (FIX or alt API)
I have worked through BTCChina's FIX APi (using their java example).  Creating a subscription request message such as:
public static Message marketDataIncrementalRequest(String symbol) {
    quickfix.fix44.MarketDataRequest tickerRequest = new quickfix.fix44.MarketDataRequest();

    quickfix.fix44.MarketDataRequest.NoRelatedSym noRelatedSym = new quickfix.fix44.MarketDataRequest.NoRelatedSym();
    noRelatedSym.set(new Symbol(symbol));
    tickerRequest.addGroup(noRelatedSym);

    tickerRequest.set(new MDReqID("123"));
    tickerRequest.set(new SubscriptionRequestType('1'));
    tickerRequest.set(new MarketDepth(0));

    addMDType(tickerRequest, '0');
    addMDType(tickerRequest, '1');
    addMDType(tickerRequest, '2');

    return tickerRequest;
}

The above message request is documented to provide full orderbook + trades snapshot + incremental refresh.  Unfortunately it just provides top-of-book with no sizes + trades with no size.   I suspect their FIX server implementation is not complete.  The same standard FIX message on OKCoin, works fine, providing full book.
The alternative API via websockets provides a call to get depth of book, however, according to documentation only provides 5 levels.
Various real-time OB viewers are showing deeper-than-5 depth, so assume there is an API for this.   Can anyone point me in the right direction?

Have you got this to work using FIX? I have the same problem.

No, unfortunately not.  BTC China seems to be ignoring it.  Their web socket API may provide a reasonable alternative.  I have not looked at it yet.

Ended up using their REST API and polling periodically (why do bitcoin exchanges use something so inefficient, very poor design).


text:
Why can't we switch private and public keys?
If private and public keys are performing the same task (although asymmetrically), but I mean each one can encrypt something that only the other one can decrypt, can I create a paper wallet and share my "private key" and just keep my "public key" private?

Some public key cryptosystems have this kind of symmetry (RSA does), but it's not a general property of digital signature algorithms.   Signing and verifying are not symmetric at all for ECDSA.

@NateEldredge That's short, but it's an answer. Please rather post it as such. :)

The ECDSA signature algorithm used by Bitcoin doesn't have symmetry between its private and public keys.  If you read about how the algorithm works, they aren't even the same type of mathematical object: a private key is an integer, while a public key is a point on an elliptic curve.  They do not, in your words, "perform the same task."  So you can't do that.  (It's not at all clear why you would want to, in the first place.)
In fact, ECDSA is an algorithm for digital signatures, not encryption; ECDSA can't be used to encrypt or decrypt secret data at all.
The property that "each one can encrypt something the other can decrypt" is a special feature of the  RSA algorithm.  In this particular cryptosystem, signing and verifying (and encryption/decryption) use the same process; people sometimes say that signing in RSA consists of "encrypting using the private key". One could interchange the roles of the private and public keys, and the algorithm would still work mathematically.   But this isn't a general feature of all asymmetric cryptosystems.
(Even for RSA, although mathematically you could switch the private and public keys, this would totally blow its security: as typically implemented, the public exponent is an arbitrary integer that doesn't have to be secret, and people usually just use 65537.  But the private exponent is hard to compute without knowing the primes used to generate the key. So if you released what was intended to be the "private" key as your public key, people would have no trouble guessing the other key as well, and then you have no security.)

Your answer is correct. I'd like to add that in RSA, mathematically speaking the public key and private key behave the same way, but in practice we tweak them. The public exponent is one of those tweaks. Another tweak is that the private key contains the factorization of n, which allows faster arithmetic via the Chinese remainder theorem.

No.
Your private key can be decoded/reversed to reveal your public key. Public keys can not be reversed to reveal the private key. If you share your private key they have EVERYTHING.


text:
Is there a difference between "In" and "Out" peer connections?
On bitcoin-qt, some peers are called "Out" and some are "In". Is there any difference besides who initiated the connection?

No, connection directionality doesn't affect peer behavior in Bitcoin P2P at all. The same rules for relaying inventory, and punishments for misbehavior apply to both. The software will avoid making outgoing connections to peers in close proximity in the IP address space to one another, but this does not apply to incoming connections where many connections from even the same IP address are allowed.

There is a small difference: Bitcoin Core tries to avoid synchronizing from incoming peers, in order to retain the "if you don't listen, you won't have huge transfer volumes" invariant.


text:
Why can I only see the balance of my wallet and not the one of each of my receiving addresses? (Multibit)
I have some troubles to understand the logic behing addresses and wallets. I use Multibit to manage my BTC. I have one wallet with 5 receiving addresses. I have transfered from an exchange website 0.1BTC to each of my receiving address. So Multibit indicates that my wallet balance is 0.5BTC (to simplify, I don't include the transaction fees).
So far so good.
What I don't get is why I can't see  in multibit the balance of each of my receiving addresses seperatly, like:
A1 = 0.1
A2 = 0.1
A3 = 0.1
A4 = 0.1
A5 = 0.1

If I got it right, it's because now the 0.5BTC aren't anylonger tied up to the receiving address I sent them to but only to my wallet. This would mean that it is useless for me to send money from my wallet to a A1 for example to get this new balance...
A1 = 0.3
A2 = 0.1
A3 = 0.1
A4 = 0
A5 = 0

...because it would be exactly the same as the total balance of my wallet would still be 0.5BTC. But this doesn't seems right because blockchain track the amount of transaction per addresses.
But then why can't I choose from which "receiving" address out of the 5 I have, I want to take the money of when I sent BTC? Multibit only ask me the receiving address where I want to send the money to not the address where it takes the money of. Who get to choose which  sender address will be kept in the blockchain?
This is really confusing! Thanks for your help!

There are multiple reasons why you do not see individual address balances or get to choose the sender address:

For privacy reasons your client will generate a new address for every change output in your transactions. Soon, you'd have many more addresses; and choosing from a long list of addresses is not user-friendly.
"Addresses are not wallets nor accounts, and do not carry balances. They only receive funds, and you do not send "from" an address at any time." (see Address Misconceptions)
There is no "from" address (see From address)

Thanks Malte! You wrote "For privacy reasons your client will generate a new address for every change output in your transactions.". Does this mean that each time I spend some of my bitcoins, Multibit will generate a new address to receive bitcoins? I have never spent bitcoin, so I have no experience here, but this sounds rather strange. Thanks a lot for the two links, they help me get rid of some of my misconceptions!

I'm not 100% sure about Multibit's implementation, but if it follows best practices it should. This way nobody can figure out how much bitcoins you transferred because it is difficult to determine which output contains the real transacted value and which the change back to you. It's also discussed in more detail here: http://bitcoin.stackexchange.com/questions/1629/why-does-bitcoin-send-the-change-to-a-different-address


text:
I raised my bitcoin to 0.02 but it should be 0.05 when I withdraw, why?
I raised my bitcoin to 0.02, but when I withdraw, it shows the withdrawal amount as 0.05, I can't withdraw?

Hi Yazdan, it sounds like you are experiencing some issues with a specific company. We are just some random Bitcoin enthusiasts on the internet that don’t have insight into the inner workings of specific companies. However, that 0.05 ₿ is a pretty big chunk of money, and way more than usual for minimum withdrawals. Have you acquired those bitcoins suspiciously affordable and they are trying to get you to deposit more money with them so you can withdraw?

I reached the value of 0.02 bitcoins from the btcfree.win site, which previously said that this range can be withdrawn, but today the value of 0.05 bitcoins is the permitted withdrawal range.

That’s about 600 USD. That sounds like a lot of winnings for a presumably free website. I would suspect that it’s an advance fee scam: they’ll probably keep raising the minimum withdrawal until you deposit money to reach the minimum withdrawal amount and then abscond with it.

A brief websearch into the legitimacy of that site has a bunch of “is this a scam” hits.

There is no place to deposit money on the site, if it is a scam, they will probably hack the wallet

What is your overall opinion? Does it seem like a scam?

I count four red flags: 1) Changing withdrawal conditions, 2) Promises money for free, 3) Lots of people asking all over the internet whether it’s a scam, 4) Four other websites with very similar names pop up on the first page of the search engine,… Basically whenever it’s not obvious how a service is supposed to make money, it’s very likely a scam. And it’s not clear to me at all how they’d turn a profit on this.

Thank you very much for the advice

If it’s not an advance fee scam, they may simply be farming ad revenue by having people come back over and over again without ever paying anything out.


text:
How do cryptocurrency exchange services generate disposable / sub-addresses?
I am developing my cryptocurrency exchange service. The first problem - how to distinguish clients from each other? It seems to me that other services have solved this problem by generating something like a one-time address for each client - and then this problem is 100% solved. I found an article about generating disposable addresses for monero. But what about bitcoin? Tell me please where I can read about it? Or about other the top 10 cryptocurrencies. Interested in automatic generation, or api integration with some services. Thank you!

See BIP-32 for one way to deterministically create multiple addresses in a hierarchy that could provide for multiple customers. The diagram there shows accounts at depth 1.

Does one of these answer your question? https://bitcoin.stackexchange.com/q/42763/5406, https://bitcoin.stackexchange.com/q/113551/5406

I don't know if there is much more to be said than yes, generate a new address for each customer. Generating new addresses is a very cheap operation, and one that literally every Bitcoin related wallet service, software, or API can easily do for you.


text:
spending P2TR script path output using python bitcoinutils library
I am currently trying to spend a P2TR output using one of the scripts used to create the address. Below is the python code I tried to construct raw transaction in order to spend the UTXO. The address I am trying to move testnet coins from is tb1pnnr3jysdew9gma9ac9k3pzdy5xp69fka3jh9vkga5ak28yjak0ws3hw834.
from bitcoinlib import transactions
from bitcoinutils.setup import setup
from bitcoinutils.script import Script
from bitcoinutils.utils import *
from bitcoinutils.transactions import Transaction, TxInput, TxOutput, TxWitnessInput
from bitcoinutils.keys import *

utxos = [{'txid': "4390635a95c7e3538dda7c4690f38fbfaa5d93eaf04e1f4f63fb811a884428e2", "vout": 0}]

priv1 = PrivateKey(wif="secret for obvious reason 1")
priv2 = PrivateKey(wif="secret for obvious reason 2")
priv3 = PrivateKey(wif="secret for obvious reason 3")
priv4 = PrivateKey(wif="secret for obvious reason 4")

pub1 = priv1.get_public_key()
pub2 = priv2.get_public_key()
pub3 = priv3.get_public_key()
pub4 = priv4.get_public_key()

def main():
    setup("testnet")

    input_amounts = [79800]
    output_amounts = [79650]

    # taproot script 2 is a simple P2PK with key 2
    tr_script_p2pk2 = Script([pub2.to_x_only_hex(), "OP_CHECKSIG"])

    # taproot script 3 is a simple P2PK with key 3
    tr_script_p2pk3 = Script([pub3.to_x_only_hex(), "OP_CHECKSIG"])

    # taproot script 4 is a simple P2PK with key 4
    tr_script_p2pk4 = Script([pub4.to_x_only_hex(), "OP_CHECKSIG"])

    all_leafs = [[tr_script_p2pk2, tr_script_p2pk3], tr_script_p2pk4]
    input_address = pub1.get_taproot_address(all_leafs)

    input_1 = TxInput(txid=utxos[4]['txid'], txout_index=utxos[4]['vout'])

    output_address = P2pkhAddress(address="moHfMJHAP3LE2aYTp4Q6g5GxnnfTK9muAJ")
    output_1 = TxOutput(amount=output_amounts[0], script_pubkey=output_address.to_script_pub_key())

    tx1 = Transaction(inputs=[input_1], outputs=[output_1], has_segwit=True)
    sig1 = priv3.sign_taproot_input(tx=tx1, txin_index=0, utxo_scripts=[input_address.to_script_pub_key()],
                                    amounts=input_amounts, script_path=True,
                                    tapleaf_script=tr_script_p2pk3, tweak=False)

    # tagged hashes of leafs
    leaf2 = tapleaf_tagged_hash(tr_script_p2pk2)
    leaf3 = tapleaf_tagged_hash(tr_script_p2pk3)
    leaf4 = tapleaf_tagged_hash(tr_script_p2pk4)

    # If using get_tag_hashed_merkle_root
    merkleroot1 = get_tag_hashed_merkle_root(scripts=all_leafs)

    # If manually constructing the tree
    branch_23 = tapbranch_tagged_hash(leaf2, leaf3)
    merkleroot2 = tapbranch_tagged_hash(branch_23, leaf4)
    assert(merkleroot1.hex() == merkleroot2.hex())

    control_block = ControlBlock(pubkey=pub1, script_to_spend=tr_script_p2pk3, scripts=leaf2+leaf4)
    tx1.witnesses.append(TxWitnessInput([sig1, tr_script_p2pk3.to_hex(), control_block.to_hex()]))
    print("\nRaw signed transaction:\n" + tx1.serialize())

Among the three scripts used to create the address, I am trying to spend the UTXO using the tr_script_p2pk3. The raw transaction I got from executing this code is the following.
02000000 => version
0001 => marker and flag
01 => input count
e22844881a81fb634f1f4ef0ea935daabf8ff390467cda8d53e3c7955a639043 => input txid
00000000 => input vout
00 => scriptSig
ffffffff => nSequence
01 => output count
2237010000000000 => output amount
1976a914553d745f650e2faba231590931c3561e3ab7cb7888ac => scriptPubKey
03 => witness stack count
4060f3d6d5e5782977b53d6f7025ff8c7f70e1cb6a1b1de96117aa499713fcd701fed99f27d0922e58a8a8d731af9f3f9b36d5389e694b23513dd0b0eea6264fa7 => schnorr signature
222030a1dfffabb677eb2d8aa45bc7e24cbc31d67731680fe5be4b524e3359445f37ac => tr_script_p2pk3
61 => control block length
c0 => default leaf version tapscript
cded16e0e749cb161694b20f5bd7737ebc22b40805a415941b3fcc26df30dbb1 => internal key (in this example, pub1)
dff122122208c96d11efdd99a987150f7c422eeb2f9076f40804382dbc95c7b78cbca50495d9c133a60cf93e502e84b421b5640258f549c2bdb6e538eae16e7d => Merkle path (in this case, leaf2 + leaf4)
00000000 => nLocktime

The transaction failed and I received the following message: <sendrawtransaction RPC error: {"code":-26,"message":"non-mandatory-script-verify-flag (Witness program hash mismatch)"}> I tried the same code but with an address with two taproot script paths and the transaction was successfully broadcasted. In that case, the Merkle path just have to be the tapleaf tagged hash of the other script that wasn't being used to unlock the UTXO. I believe the error has something to do with the control block part but I don't know exactly where my code went wrong. Can somebody point out the problem?

Problem resolved. The problem was related to the leaf version of the script that I was trying to use when unlocking the UTXO script. The version was supposed to be c1 but instead, it was c0 according to my code.


text:
Multiple bitcoin transactions between addresses in the same wallet
I have two wallets: one in coinbase and one in blockchain.info. I imported several outside addresses(created in bitaddress.org) in my blockchain.info wallet. However, sometimes when I transfer bitcoins from my coinbase wallet to my blockchain.info wallet, the transaction is followed by several (usually two) transactions within my blockchain.info addreses (in the same wallet). As if the money is being bounced off within the addresses inside the wallet. Is there any reason for this?

Can you post an example? It's hard to know what you're asking without context.

Did you happen to import any private keys, using the "sweep" option? If so, it might try to keep re-sweeping any new inputs, though I am just speculating.

Coinbase sometimes creates an address to move your bitcoin from cold storage. Any movement ie downloading to offline storage. will require a hash for the block chain/transaction  to "track" the bitcoin. Hence the appearance of transactions in the wallet.


text:
Why can't we expire two year old transactions?
I understand any output in blockchain can be left un-redeemed forever. But If we expire all transactions that are more than two years old (specifically after some number of blocks), there are some benefits

Recycle lost/destroyed bitcoins by giving them back to miners
Miners will continue to get more transactions and thus more fees
Number of unspend transactions may become less speeding up verification
Size of blockchain to keep downloaded can be minimized
Broken cryptographic hahes/signatures can be made obsolute
New features can be easily introduced

Are there any alt coins that consider these? What are the advantages of keeping all transactions valid since genesis block?

Also see: Why doesn't Bitcoin return lost coins back into the block reward?

One big reason against this sort of thing is that it creates a huge incentive for bad people to try to prevent you to do transactions (censor you).

If miners get the "lost" bitcoins they might simply refuse transactions with coins that are almost expired hoping to get a bigger reward later.
If miners don't get them but they are truly lost forever, then there is an incentive for big stakeholders to try to do the same thing: less coins means the value of everyone else's coins goes up.
It gives governments and other mafia huge power: don't want to comply? We'll just lock you up for 2 years and make your coins expire. Or more "humanely" use other censorship tricks (hacking/digital censoring) to prevent you from spending your coins before they expire.

Another reason is that people will en mass set up automated scripts to move all their coins regularly, which is a big security (and privacy) risk. It's much easier to keep private keys safe (on a piece of paper in a vault) than it is to keep an internet connected system powered up and safe 24/7.

When I mean give it back to miners. not directly. But extend the block reward. For e.g. current block reward is 25 BTC. Make it 25.1 BTC and next one as 12.505 BTC the number calculated according to number of bitcoins that are lost forever. I doubt it will be beneficial for miner to censor one person and loose the transaction fee as other miners will be willing to include the transaction

Two years might be very small. May be it can be 5 years. Agree people will need automated scripts or have to just remember to reuse bitcoins atleast once in 5 years.

I know you didn't mean directly but it's still a dangerous incentive.  And there are other people that would love to be able to make someone else's bitcoins worthless even if they can't take them. 2 years or 5 years is only a parameter, i was discussing the concept. Either way it's a big unnecessary security and privacy reduction.

Recycle lost/destroyed bitcoins by giving them back to miners
Miners will continue to get more transactions and thus more fees

If you already own bitcoin, this isn't a good thing as it increases the supply. That said, there is an altcoin called Freicoin that uses demurrage rather than an abrupt 2-year expiration that's got some of the property you're looking for.

Number of unspend transactions may become less speeding up verification
Size of blockchain to keep downloaded can be minimized

This may or may not be true as expiring coins gives people incentive to transfer them in order to not lose them. I would guess that given this fairly major economic incentive, the number of unspent transactions wouldn't actually go down that much.

Broken cryptographic hahes/signatures can be made obsolute
New features can be easily introduced

You seem to be of the opinion that what's keeping bitcoin from innovating is that there's all these obsolete transactions. That's simply not true. What's keeping bitcoin from innovating is the possibility of a hard fork. New features like lifting the 1MB block limit has nothing to do with old transactions being in the blockchain. It has everything to do with miners achieving concensus.

Why would this increase the supply? Maximum limit of bit coins that can exist will still be the same.

Your question said you'd take coins that haven't been used in 2 years and give them to miners. These formerly dead/unused coins are now alive/being used again. So yes, that would increase the amount of bitcoins on offer, or the supply.

@balki Think of it like this - if Bitcoin changed so that there were an extra million Bitcoins that nobody could spend, would that change the amount of available Bitcoins significantly?


text:
Can same private key generate multiple addresses?
Is this possible using some clever bitcoin script? The intention is to get more privacy. I can give different addresses to different people still no one can guess how much I make in total. I can do this by generating several key pairs but I will have to save all the private keys somewhere. If I can come up with a way to generate multiple addresses, I will have to save guard only one private key.

One private key maps onto two addresses - one that uses an uncompressed public key, and one that uses a compressed public key.
What you might also be interested in is a deterministic wallet - a Bitcoin wallet holding multiple addresses generated from one private key / secret. This will let you secure multiple addresses and store only one key.

Can you please explain how they work?

@balki Deterministic wallets? Generally, you start with one private key / secret, and produce the next ones according to some algorithm - whether it's adding 1 to the private key each time, hashing the key over and over, or whatever else you want. The linked wiki page provides some description, and you can check out BIP0032 as well.

What you are looking for are Hierarchical Deterministic Wallets. You can create one for example with the Electrum wallet.
Also see the tags deterministic and electrum here on Bitcoin.StackExchange.

Besides the HD wallet technology, you might want to investigate "stealth addresses" that are new to Bitcoin.  Not aware of any easy to use wallets supporting stealth addresses yet, unless you are into the Darkwallet.
The libbitcoin framework currently supports stealth address capability for Bitcoin, in particular see the bx command which incidentally is deprecating the sx command also mentioned Andreas Antonopoulos's book - available at O'Reilly. bx is pure C++ code while sx was a combination of C++ and Python.
I suspect the airBitz wallet, currently HD-enabled will be one of the first mainstream mobile wallet applications to support stealth addresses because it is built up the libbitcoin foundation.
I believe the one major issue with stealth addresses is both the sender's wallet and the recipient's wallet must support it because the address formant is very different from the typical Bitcoin address. (Have not yet experimented with BX enough to say if this is true for certain.) Stealth addresses are effectively performing Diffie-Hellman-Merkle key exchanges behind the scene. More information must be conveyed to make this happen.
In a nutshell, Peter Todd's stealth address invention will be great to print on business cards to share while still maintaining your financial privacy. Only waiting for the stealth address BIP63 to be posted at https://github.com/bitcoin/bips. Not sure what the politics are...


text:
Hybrid e-wallets
I am quite confused regarding working of hybrid e-wallets..If private keys are stored on user's browser, then what is the purpose of involving a hosted web service... Can someone please answer my query ?

What site are you referring to?

Generally web wallets have you store the keys on your computer, because otherwise they would have control of your Bitcoins and could run off with them.
The reason you need a site is because you can't broadcast transactions to the network without a full node, something that is running on the site's servers.
Web wallets of this type allow you the best of both worlds, you do not need to run software on your computer, and you retain control of your coins as the server never knows your private key.

Web wallets can generally still steal your coins, even if the keys are stored on your system. They can serve you different javascript that sends the keys back to them once you unlock them to sign a transaction. In fact, this has actually happened in the past. A web wallet trades security for convenience.


text:
How do I see what version of bitcoin core my wallet uses
I use the multibit wallet which I understand doesn't download the whole bitcoin core i.e. the entire block chain, but it must use the bitcoin core protocol right? So how do I see which version of the protocol my wallet is using?

In the Multibit data directory, there is a file called log/multibit.log. When you connect to a peer, it will write something like this to the log:
20:01:26.124 [bitcoinj user thread] DEBUG o.m.c.b.BitcoinPeerEventListener - Connected to peer:
client version: 70002
local services: 1
time:           1424228484
my addr:        [xx.xx.xx.xx]:51127
their addr:     [xx.xx.xx.xx]:8333
sub version:    /Satoshi:0.10.0/
best height:    343977
delay tx relay: true

The 'sub version' field contains the version in a human readable format. The 'client version' field contains a machine-readable protocol version.

Perfect thanks Nick! I appreciate the link to finding the Multibit data directory as well.  So bounus question, I see my wallet last used Satoshi:0.9.2.1, but I see it skips around, what determines which version it uses?

@JonathanChadFaling It connects to nodes owned by other people, so it's whatever they decide to run.

This is not entirely true. Looking at https://blockchain.info/connected-nodes, lots of nodes have same 'client version' but vastly differently 'sub versions'.

@Jus12 It's because the protocol version and the client version are different.

On Bitcoin Core go to Windows > Console (CTRL+T).
Then, type:
getwalletinfo

Should show you a json with the wallet version.
Not sure if multibit software has that option thought.

You can find this out on the command line with:
$ bitcoin-cli getinfo

This will give you an output like this:
{
    "version" : 90400,
    "protocolversion" : 70002,
    "walletversion" : 60000,
    "balance" : 0.62950000,
    "blocks" : 323377,
    "timeoffset" : -5,
    "connections" : 9,
    "proxy" : "",
    "difficulty" : 1.00000000,
    "testnet" : true,
    "keypoololdest" : 1412131069,
    "keypoolsize" : 101,
    "paytxfee" : 0.00000000,
    "relayfee" : 0.00001000,
    "errors" : ""
}

Version is the actual bitcoin core version and probably what you're looking for.

This appears to get the version of a local bitcoind instance. I don't think that's what the asker is asking about.

Gah, you're right


text:
Do I need to keep updating Armory version and more?
Do I need to keep updating version of Armory when it notifies me of new version. Just wondering if these are security patches or just some new bells and whistles in new armory versions. Seems like it took me forever to DL Armory and to install a new version every few months seems like a huge pain I run linux so that makes it even more difficult because I have manually uninstall and re-install and my newbie self doesnt' even know how to on linux as there is no automated uninstall or install like windows.
What gives?

If you take a look at the Patch Notes, it will tell you the content of the patch. Then you can make an informed choice.

It really boils down to fixes and any upcoming security issue which are announced with the releases, but in general it's a good idea to upgrade every once in a while (at least it will likely make any mandatory update less painful). The updates should usually be less painful than initial install - sometimes no database rebuilds are even needed, and v0.93 rebuild is very fast too.
Note that sooner or later you will eventually need to upgrade Bitcoin core too. It may be running seamlessly from within Armory but you can also choose to run it yourself as a standalone application - either way updates will be required eventually to pick up the latest changes in the network. Armory updates often comes along with Bitcoin core updates as it need to support any Bitcoin core database changes.
Also if you use an offline wallet, there are some limitations in the version delta you can have between online and offline wallets - Armory will normally warn you loud and clear about them.


text:
Pairing pattern of txids in merkle tree
For constructing the merkle tree txids are paired and hashed. ¹
But how are these txids paired? Does it happen chronologically or is there a certain pattern of pairing?

Transaction order in the block
Currently, there are only two requirements for the order of transactions:

The coinbase transaction is always first.
Intra block dependencies must preceed, i.e. if Transaction A and Transaction B are both in the same block, and Transaction B spends outputs of Transaction A, A must be listed before B.

It is likely that in the future a correct order for transaction will be introduced, as this will allow proving the absence of a transaction in a block with logarithmic effort, and will allow more efficient block data propagation through IBLT. Right now, transactions are propagated in the network before confirmation, and then again as the content of a block. With a deterministic transaction order and IBLT set reconciliation, each transaction would only have to be received once instead of twice.
Building the Merkle Tree

The transactions are inserted into the Merkle Tree in the same order they are listed in the block. If a block only contains the Coinbase Transaction, the Coinbase's transaction ID is used as the Merkle Root.
Otherwise, a binary tree is created from the transactions by pairing transaction hashes on the first level, then pairing resulting hashes on each next level until only one hash results, which is then used as the Merkle Root. If there is an odd number of hashes to be paired, the last hash is paired with itself.
Further Reading
The Developer Reference has additional details. The image is from the Developer Reference as well, and hence licensed MIT.
Antonopoulos covers Merkle trees in detail in his book, also providing examples of how it is used to prove transaction presence in blocks.

Also of relevance: https://bitcoin.org/en/developer-reference#merkle-trees

@ChristopherGurnee: Thanks that had the information that I was looking for. :)

Excellent updated answer IMO!

Does this relate to the so-called CTOR vs TTOR comparison?


text:
bitcoin full node huge upload bandwidth
Have been running a full node for a couple of months now, using bitcoin core 25.0
Last time I was running a node was many years ago, so I a bit outdated...
I am wondering if upload stats are not a bit huge.
I am around 90 GB uploaded per day!
I have a good connection (arond 500 Mbps Upload), not complaining, still this means a lot of usage of it, disk, and so on.
I am wondering where all the traffic comes from , probably not from transactions, but mostly from new nodes downloading big chunks of the full blockchain from me?
Do you have similar stats on full nodes?

Does this answer your question? Bitcoin Core uploads much more than it downloads

Partly...indeed my node is correctly listening and joinable.  Still it seems to me 90 GB a day is huge, considering number of daily blocks....   I also heard about erlay protocol which should have partly solved the traffic generated by flooding, but I am not sure if it's already implemented in bt-core.

If you're seeing that much traffic, it is very likely almost entirely due to people downloading historical blocks from you. Bitcoin Core has a feature to limit how much you're willing to upload per day, if this is an issue.


text:
Stopping Hash field in GetBlocks Message
Reading Bitcoin Developer Guide, I couldn't fully answer following question:  What is the exact purpose of the Stopping Hash field inside a GetBlocks Message?

Node1 announces block B3, using an 'inv' message with B3's gash.
Node2 does not know about B3, or its parent B2, but does know the grandparent B1. It sends a getblocks message, starting from B1, but stopping at B3.
Node1 replies with an inv for B2, but not with B3 or any potential successor B4 thay may have appeared.
The purpose is just avoiding sending too many hashes in case the sender already knows some successor.
Note that since Bitcoin Core 0.10.0, getblocks is no longer used. getheaders has similar logic though.

By "[...], but stopping at B3" you mean that Node2 requests only 1 block saying "give me B2's hash but not B3's hash"? So can we say Stopping Hash defines how many block header hashes are requested, unlike the default 00000..00000 Stopping Hash?

No, not how many. Just the one after which the sender can stop.


text:
Avarage block size

Has someone calculated the avarage block size (e.g., for a day)?
On blockchain.info there are a few blocks listed with their size, on the top of the page :/

Here's your answer!
Blockchain.info provides the average block size.

Take http://webbtc.com/ , copy-paste it to excel and calculate average for last 20 blocks.


text:
"Array& params": How to understand "&" after "Array" - type modifer?
I'm trying to understand how "invalidateblock"-function works, literally line by line.
Since I'm at basic level in C++, I couldn't explain to myself what's the "&" after "Array" there to achieve though I know of references and pointers and though I've found out that it's a so called "type modifier". Still I'm wondering "Array" is a type just like "int", "char" etc.
Where can I find more information on where Array is defined/explained?What are member functions?
Thanks in advance!

I'm voting to close this question as off-topic because this question is not related to Bitcoin specifically and would be better suited for http://stackoverflow.com

Ok, but I asked it here in order to hear developer's answers or comments who have written the code and are represented in Bitcoi.SE.

Can you provide a link to the particular software your question is about?

@DavidSchwartz: I've been looking at rpcblockchain.cpp of bitcoin-0.10.0

It's part of the JSON code. An Array is a JSON entity that contains an ordered list of zero or more JSON entities. As its name, "params", suggests, this one contains the parameters to the command. So when you see:
std::string strHash = params[0].get_str();

That gets the first parameter into a string called strHash. This makes sense since the first (and only) parameter to invalidateblock is a hash, as this help text indicates:
        "invalidateblock \"hash\"\n"
        "\nPermanently marks a block as invalid, as if it violated a consensus rule.\n"
        "\nArguments:\n"
        "1. hash   (string, required) the hash of the block to mark as invalid\n"
        "\nResult:\n"
        "\nExamples:\n"

Thanks! But what's the purpose of "&" after "Array"? I think type modifiers, such as "&", are used in programming to convert a data type into another and obviously Array is being converted into a reference type while it's defined in the "invalidateblock"-function so can I assume that this conversion makes references out of Array's params? And if yes, what variables are they references to? What do they have to do with get_str()?

@AliakbarAhmadi It sounds like you need to learn C++ and then come back and look at this code.

I know I'm not using the best technical terms but would you give me a hint to understand: why I need to put a "&" after "Array" though - to my limited knowledge - you could leave it away and simply write Value invalidateblock(const Array params, bool fHelp) {...}? - I found this but it's not really helping to understand this problem. But I think get_str() is just putting the hash value as a string to params[0]!?

@AliakbarAhmadi Why do you think you need to do that? In this case, the parameter could be passed by value or by reference, but passing by reference is cheaper. Competent C++ coders reflexively pass "complex" classes by reference when that is possible because it avoids copying the value.

David Schwartz, thanks! Finally you gave the answer and I can sleep well :D +1