Is the bitcoin blockchain really non-corruptible? Some people say that proof of work is better than proof of stake, because it's not possible to rewrite the whole blockchain on-spot. One would need to "re-mine" everything.

But I think this is not true! A hypothetical attacker can rewrite the whole bitcoin blockchain and make the timestamps make the block-time exactly 10 minutes, and this way the difficulty of mining will remain at minimum, and no real mining is required. The mining effort is minimal.

The way I understand it, is that such a problem is practically solved by check-pointing the blockchain in the source code. The devs hard-code block-hashes in the source code so that no one could do that. Is my description of the situation correct?

In other words: Without check-pointing, the bitcoin blockchain is inherently corruptible and can be destroyed. What am I missing here?

PS: This is not about PoW vs PoS. This is basically about the claim that PoW is non-corruptible. If my conclusions are true, we can just do the same with PoS blockchains and use check-pointing to prevent corruptibility.

Your attack wouldn't work because nodes take the most-work chain as leading, the number of blocks is irrelevant. Any attacking chain needs to spend at least as much work as was done for the original. This actually used to be a bug in the whitepaper and the initial bitcoin software implementation: it checked for the longest chain instead of most-work. It was fixed very early on.

Checkpoints are centralizing as they give devs power. They're no longer done in Bitcoin.


What should you set as rpcpassword and rpcusername in BitCoin? Every example/tutorial looks the same:

rpcpassword=<somehashofsomesort> and rpcusername=rpcuser

They always use something like rpcuser, and some hash for the password. Why is it like this? Does it offer any advantage to break out of the shell and have your username and password be something you like?

In another place I found this:

#rpcuser=alice
#rpcpassword=DONT_USE_THIS_YOU_WILL_GET_ROBBED_8ak1gI25KFTvjovL3gAM967mies3E=

Does setting your username to alice cause you to no longer be anonymous, and that's why everyone has the same username?

Do I even need a username and password?

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

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

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

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


If a block chain is considered invalid, how about transactions in this block chain? Say if at current time there exist split of block chain, we call them A and B. A is "longer" then B, as the result B will be eventually forgotten, but what happened about the transactions in blocks on B? The block which is different between A will be unpacked, reconfirm the transaction then create new block, add new block on A?

Any transactions in a block that is no longer part of the longest chain will revert to unconfirmed (assuming they're not in the new longest chain) and return to the mempool. In most cases, assuming the transactions remain valid (i.e. the outputs they spend aren't already spent in the new longest chain), said transactions will simply be mined into a new block on the longest chain.


Does my client accept inbound connections? How can I verify that the Bitcoin client is well connected to the network and is able to receive incoming connections?

Get your ip from http://whatismyipaddress.com/ and put it in here http://www.subnetonline.com/pages/network-tools/online-port-scanner.php with port 8333. If you can accept incoming connections you should see a result similar to below:


how to find the block height from merkle root? I have the merkle root, using this value, how to get the block hash or its height?
There is this merkle root available in getblock RPC output:
./bitcoin-cli getblock 0320d6c1bd3c4cd2a08d6f76acb50b06a3ed766b058d247fbda3147aecfef388
{
  "tx": [
    "bccf4c873984245694f64263a3392c4d67c6a6f60efe4ed53aa4965f6d8b7dc0"
  ],
  "hash": "0320d6c1bd3c4cd2a08d6f76acb50b06a3ed766b058d247fbda3147aecfef388",
  "confirmations": 2,
  "size": 180,
  "height": 102,
  "version": 536870912,
  "versionHex": "20000000",
  "merkleroot": "bccf4c873984245694f64263a3392c4d67c6a6f60efe4ed53aa4965f6d8b7dc0",
  "num_tx": 1,
  "time": 1593523883,
  "mediantime": 1593467398,
  "nonce": 1,
  "bits": "207fffff",
  "difficulty": 4.656542373906925e-10,
  "chainwork": "00000000000000000000000000000000000000000000000000000000000000ce",
  "previousblockhash": "1664a604a6c8e603e311c6759f7693343ad77896c53de1bcef37de04dbcbbbc5",
  "nextblockhash": "1924c8db1b986f398a12d5481fcc293913a2dab2ee7fbcb0e131d7941e5201c2"
}

using different transaction hashes, I got the merkle root value, now I need to know which block has this merkle root as in getblock.

The block hash is the output obtained when hashing the header of a bitcoin block. The header of a bitcoin block is comprised of several pieces of data, one of which is the merkle root.
So having the merkle root alone is not sufficient to calculate the block hash, you would need additional information (the rest of the block header).
You could write some code to query the block database for a specific merkle root, but otherwise I am not aware of any software that currently includes this functionality.
(this seems odd to me though: if you have calculated the merkle root, you assumedly have all the transaction data from the block in question. I'm not sure in what situation you would have all of this data, but not the rest of the block header data)


Javascript library to explore bitcoin blockchain data by connecting to a local running node I need to get data of a block using the block height.

Is there a javascript library to get block data from the Bitcoin blockchain, by connecting to local running node or a 3rd party blockchain provider?

bitcoin tools library
https://github.com/bitpay/bitcore-lib

Unofficial Node.js client for blockexplorer.com API
https://github.com/barto-/blockexplorer

or you can install bitcore full node and use bitcore-lib with that full node


Is there a source for historical LTC trades available? From bitcoincharts.com can download historical trade histories for BTC on various exchanges vs various currencies.

Where can I find something comparable for LTC?  I want to get historical trades for LTC vs USD & CNY.  1 year or more would be ideal.

These files contain every LTC trade from day 1 through about 2:20pm UTC on 31-3-2013.

LTCBTC @ BTCe Oct 2011 through March 2013
http://www.mediafire.com/view/?5cwjmviou15k32h

LTCUSD @ BTCe Oct 2011 through March 2013
http://www.mediafire.com/view/?cn5qxi44j6egrad

also Kraken LTCEUR charts are here:
http://api.bitcoincharts.com/v1/csv/

I'm looking for 2013 and 2014 BTCe LTCUSD and LTCBTC.

please help


clightning uses all my resources, ... till I have to shutdown! clightning runs for a while great. However, every second day the computer locks up,

I use docker-compose for that:

version: "3"
services:
  bitcoind:
    image: nicolasdorier/docker-bitcoin:0.16.3
    container_name: bitcoind
    environment:
      BITCOIN_EXTRA_ARGS: |
        testnet=0
        whitelist=0.0.0.0/0
        server=1
        rpcuser=*****
        rpcpassword=*****
    expose:
      - "8333"
    ports:
      - "0.0.0.0:8333:8333"
    volumes:
      - "/media/ronald/data/scratch/bitcoin/mainnet/bitcoind:/data"

  clightning_bitcoin:
    image: elementsproject/lightningd
    container_name: lightning
    command:
      - --bitcoin-rpcconnect=bitcoind
      - --bitcoin-rpcuser=****
      - --bitcoin-rpcpassword=****
      - --network=bitcoin
      - --alias=TWronald✅
      - --rgb=15C315
      - --log-level=debug
      - --announce-addr=220.133.223.206:9735
      - --bind-addr=0.0.0.0:9735
    environment:
      EXPOSE_TCP: "true"
    expose:
      - "9735"
    ports:
      - "0.0.0.0:9735:9735"
    volumes:
      - "/media/ronald/data/scratch/bitcoin/mainnet/clightning:/root/.lightning"
      - "/media/ronald/data/scratch/bitcoin/mainnet/bitcoind:/etc/bitcoin"
    links:
      - bitcoind

lightning-cli getinfo

{
  "id": "035aef5661e1a6e370db60dc0455796800afd5b51fbc12a0a8b34836b15f5d7ef6",
  "alias": "TWronald✅",
  "color": "15c315",
  "num_peers": 15,
  "num_pending_channels": 0,
  "num_active_channels": 15,
  "num_inactive_channels": 0,
  "address": [
    {
      "type": "ipv4",
      "address": "220.133.223.206",
      "port": 9735
    }
  ],
  "binding": [
    {
      "type": "ipv4",
      "address": "0.0.0.0",
      "port": 9735
    }
  ],
  "version": "",
  "blockheight": 560987,
  "network": "bitcoin",
  "msatoshi_fees_collected": 0
}

Why the version of lightning is "" ??? scratch/bitcoin/mainet/clightning/config is empty.

Currently it is running fine.
ps ax |grep lightn

 7278 ?        S      0:03 /usr/bin/lightning_channeld
 8524 pts/20   S+     0:00 grep --color=auto lightn
16579 ?        S      0:06 /usr/bin/lightning_channeld
31660 ?        S      1:19 lightningd --bitcoin-rpcconnect=bitcoind --bitcoin-rpcuser=**** --bitcoin-rpcpassword=**** --network=bitcoin --alias=TWronald✅ --rgb=15C315 --log-level=debug --announce-addr=220.133.223.206:9735 --bind-addr=0.0.0.0:9735
31665 ?        Z      0:00 [lightning_chann] <defunct>
31666 ?        Z      0:00 [lightning_closi] <defunct>
31667 ?        Z      0:00 [lightning_conne] <defunct>
31668 ?        Z      0:00 [lightning_gossi] <defunct>
31669 ?        Z      0:00 [lightning_hsmd] <defunct>
31670 ?        Z      0:00 [lightning_oncha] <defunct>
31671 ?        Z      0:00 [lightning_openi] <defunct>
31675 ?        S      0:00 /usr/bin/lightning_hsmd
31677 ?        S      0:00 /usr/bin/lightning_connectd
31678 ?        S      5:45 /usr/bin/lightning_gossipd
31862 ?        S      0:00 socat TCP4-listen:9835,fork,reuseaddr UNIX-CONNECT:/root/.lightning/lightning-rpc
31868 ?        S      0:06 /usr/bin/lightning_channeld
31869 ?        S      0:09 /usr/bin/lightning_channeld
31870 ?        S      0:06 /usr/bin/lightning_channeld
31871 ?        S      0:07 /usr/bin/lightning_channeld
31872 ?        S      0:07 /usr/bin/lightning_channeld
31874 ?        S      0:10 /usr/bin/lightning_channeld
31875 ?        S      0:10 /usr/bin/lightning_channeld
31876 ?        S      0:06 /usr/bin/lightning_channeld
31879 ?        S      0:10 /usr/bin/lightning_channeld
31988 ?        S      0:06 /usr/bin/lightning_channeld
31989 ?        S      0:06 /usr/bin/lightning_channeld
31992 ?        S      0:07 /usr/bin/lightning_channeld

... but still some Zombies.

When it grinds to a hold, it uses most with gossip.

Can you spot some changes I should make to improve my system?

This is most likely the gossipd bug that was causing a request from a peer to be processed very slowly. It was fixed in PR 2268. You don't have that fix in your installation yet, which can be seen by the 5 daemons that are not being reaped correctly (the <defunct> processes in the list). This was also fixed in PR 2224.

Both fixes are not yet part of a release, but we will release them soon.


Thin command line-capable client for Linux I need to set up linux server for web service that could generate bitcoin addresses and check the balance on them, etc (basically, receive payments in BTC). And I do not want to use third-party online wallets and services.

Original bitcoind client is too large now, you need almost 20 GB just to store blockchain files, and that'd be pretty expensive even for VPS.

Are there any thin command-line linux clients for this purpose? Electrum is GUI-based (it's command-line capable, but to set it up you need GUI anyway), Multibit too.

Electrum has a thin client.  Does not need a full block chain.

It is available as an RPM for Fedora which will run on Centos 7 =>  See https://www.rpmfind.net/linux/rpm2html/search.php?query=electrum  and the Rawhide version is the latest which will run on Centos 7 - you will need to source out and install dependencies one at a time as it complains they are missing and retry until it intalls.

See also http://docs.electrum.org/en/latest/merchant.html  It will run command line as a daemon or you can set up Remote X access with Qt but as stated by ThomasV it can be used completely command line who would know best of all.

You will need to open the ports needed 7777 and 9999 in the firewall and once you launch it issue a =>  netstat -anp | grep 7777 to make sure it is listening

Then do => electrum daemon load_wallet

Do =>  electrum -h - to see all the commands available from the command line of via a curl call.  See the link at the bottom for more on curl calls with software like PHP or website webstores

However if you leave it running as launched from the shell it is likely to die so . . . then set it up to start on boot and respawn if it fails

And the service file, in /etc/systemd/system/electrum.service:

[Unit]

Description=Electrum Bitcoin thin client

After=network.target

[Service]

Type=forking

User={USER}

Restart=on-failure

ExecStart=/usr/bin/electrum daemon start

[Install]

WantedBy=multi-user.target

Assuming above you change the "User" to  <= whoever you will run it as and assuming you installed the rpm - the path to electrum is then correct as the path.  Enabling that with => systemctl enable electrum <= (on Centos 7) will make sure Electrum always starts on boot.  You will need to load the wallet manually if it fails and restarts or you reboot however.

see also Checking/polling a balance of an address in Electrum via the command line/RPC


How do you install Bitcoin Daemon using Yum package manager? I have a Centos setup with the Yum package manager. How do you install Bitcoin Daemon using Yum? Or is it even possible right now?

This page has instruction on how to install Bitcoin using yum:

http://linux.ringingliberty.com/bitcoin/


What are the advantages of a 210,000-block subsidy halving interval that's out-of-sync with retargeting? The block subsidy halves every 210,000 blocks. Where could this number reasonably have come from? I'm not talking about the idea of a four year interval. 210,000 is quite close to four years given 10-minute blocks - let's just assume that's the ballpark Satoshi was after.

The most obvious problem is that 2,016 (the retargeting block interval) isn't a factor of 210,000. This puts the block subsidy halving and retargeting intervals out of sync.

For example, the subsidy halving interval might have been set at 209,664 blocks. At 10 minutes/block, this would have put the halving interval at very close to 4 years (~3.99).

Granted, retargeting and subsidy halving don't appear to be related. Nevertheless, it seems awkward to create unsynchronized adjustment events.

Was Satoshi just trying to keep things simple by choosing 210,000, or is there something I'm missing?
What attacks might be feasible under a synchronized halving schedule that wouldn't be possible under the existing one?

We do not know whether it was a deliberate choice or an oversight that the difficulty interval is not a factor of the halving interval. Instinctively, I'd suspect that both were chosen on their own to be round numbers in their context: 14 days worth of 10 minute intervals, and a 4 year intervals starting with 50 ₿ rounded to the next ten thousand. Choosing a halving interval of 209,664 blocks would have prevented either a nice round numbers for subsidies or the final supply. Today, we know that especially the supply has become an important meme in explaining Bitcoin. Generally, non-round numbers can mean an increase in complexity.
 via https://btc.com/stats/diff
Let's look at what happened at the third halving.
The halving in May at block 630,000 was exactly in the middle of the two difficulty adjustments at block 628,992 (+0.92%) and 631,008 (-6.00%). Assuming that the profitability drop of the halving led to miners turning off their hardware exactly then, one could suspect that the shift between the two periods could have smoothed out some of the congestion the slowdown: instead of one long period of extremely slow blocks, the difficulty adjusted across two periods with a shorter period of very slow blocks and a long period of less slower blocks. Since the blockspace supply is inelastic, this may have reduced the overall congestion. On the other hand, congestion can also significantly drive up transaction fees, which in turn could incentive miners bringing shutdown hardware back online.
Either way, the difference is very small.
If the halving would have coincided with a difficulty adjustment and the complete hashrate drop happened with the halving block, we would have expected the complete difficulty reduction of 6.00% and 9.29% in one period. Then, we would have expected the first difficulty period to have taken (14/(1*0.9400*0.9071)) = 16.38 days. If the second period would have then been balanced, and we would have reached 1.5 difficulty periods after the halving in:
16.38 days + 7 days = 23.38 days
Our record shows that the halving block is timestamped at 2020-05-11 19:23 UTC and the second adjustment after the halving at block 633,024 has a timestamp of 2020-06-04 12:30 UTC. This amounts to 23.7 days. Unsurprisingly, fully adjusting downward immediately would have led to a shorter time. However, as mentioned above it might have also caused more congestion due to the already slower blocks in the period directly after the halving, driving feerates even higher which in turn could have sped up blocks a bit.
In the end, it would likely not have made a huge difference if they had been aligned, and it will even less so in the following halvings under the assumption that the total transaction fees will remain at least at this absolute level, since the subsidy will then be a smaller relative part of the total reward.


I'm in the UK, how to fund my account at mtgox? It is getting ridiculously hard to get bitcoins in the U.K. International wires are to expensive, my bank doesn't support SEPA. I'm seriously thinking about converting ukash vouchers to cash u account, funding okpay with that. Then using that option at mtgox. There must be easier way.

I did a bank account thing with Blockchain.info. Assuming you have a UK bank account you shouldn't have a problem.


Can Ripple facilitate business-to-business barter transactions? Beverly Hills Hotel participates in the Ripple network and issues its USD-denominated IOUs which are redeemable for hotel stays.
Beverly Hills Performance Car Rentals participates in Ripple network and issues its USD-denominated IOUs redeemable for car rentals.
Both the hotel and the car rental shop have unrented inventory.
Daily room rental rate in USD is roughly the same as the daily rate to rent a Ferrari.

Question:

Can the hotel owner and the owner of the car rental business exchange their respective IOUs through either a mutually trusted gateway/nexus or directly (assuming they trust each other) or through a web of trust to allow a room to be rented out for a day of stay and a Ferrari rented out for a day of driving ?

Bonus question:

Is this the real purpose of the "issuer" field in the current Ripple user interface, i.e. to allow any participant to issue IOUs denominated in any currency of their choice ?

Currently currencies are limited to three-character codenames, so although this can be done and will work it will probably be useful to establish some convention(s) that will help people to not get too confused.

For example your examples seem to amount, in general, to "store credits", like airmiles or giftcards in a way. Thus it might be better to use a code for them that is different from the national cash they might happen to be useable on par with "at the store". So maybe instead of having lots of "different" IOUs labelled as USD most of which are not really someone owing an actual USD but, rather, someone owing in store credit, in other words goods or services, whose retail price happens to be in USD, it might be good to use USC or USX or whatever, the three letter code conventions only use two for the nation, deliberately leaving one for distinguishing between variants (such as day old dollars or tomorrow dollars or some such strangeness I think).

In general though, ripple docs already say that it is okay for a gateway to refuse to cash out people who are not actual members of that gateway, so that gateways can insist on knowing the customer and having anti money laundering data about that customer and so on. So we are told up front already that gateways are not under any obligation to actually make good on their IOUs to just any Tom Dick and Harry. Since that is already said, why not take it a step farther and say "oh yes I am a gateway, but only to people who buy my merchandise, and only up to the actual amount, per such person, that person spends at that moment on my merchandise".

I just think that would be a heading toward being kind of sleazy as compared to right up front setting your IOUs as not being USD but store credits, so people don't end up confusing them with actual fiat debt.

-MarkM-


Is there a Bitcoin ATM in London? Now I know there is one Bitcoin ATM in Vancouver, Canada. Is there a Bitcoin ATM in London? If yes, where is it located?

There will be Robocoin ATM's in London and Bristol this Spring. https://twitter.com/satoshipoint


Convert Electrum p2pkh wallet to p2wpkh one? Is it possible, in Electrum, to convert a p2pkh wallet to a p2wpkh one, so I can use the Lightning network?

You could theoretically export the wallet to a new type by seed (p2pkh to p2wpkh) but it would not recognize any utxo that came into it as the derivation for p2pkh and p2wpkh are different. It's not like with some altcoins who created new "address standards" that are just different way of hashing public keys, in bitcoin p2pkh and p2wpkh are different scripts.
There are wallets out there that allow for multiple types of scripts to be used, but I believe in electrum (desktop) the only way is to create a new wallet with a p2wpkh script type and transfer your funds there. I would still advise to do it (being security-conscious) as of now it will allow you to save on transaction fees as p2wpkh transactions are cheaper.
Also in the comment of One seed phrase created two wallets with two script types
@prayank has mentioned there is possibly a workaround to electrum having only one type of script available in the single wallet, but he hasn't gone into the details.


Does the BTC-e API have a method to transfer bitcoins? It seems crazy to me that one of the largest exchanges could forgo including a methed in their API to transfer bitcoins from one address to another, but this seems to be what BTC-e has done.

Does anyone know of a way to transfer bitcoins using BTC-e's API?

As of July, on the wiki entry about them, they do not seem to have an API endpoint for "withdraw".

Source:

https://en.bitcoin.it/wiki/BTC-E#Withdraw_options
https://btc-e.com/api/documentation

I'm sure it would be helpful for arbitrage reasons.


Where is merkle path of a transaction stored in a transaction? I understand every transaction can be verified if it belongs to a block by a merkle path which is basically a set of hashes that finally end up at the merkle root.

I know the merkle root is stored in the block header, but where is the merkle path (set of merkle hashes) of a transaction stored within the block?

The merkle path is not stored explicitly within the block. It is calculated from the transactions in the block when requested by a client.


Use of proof of work in bitcoin I am trying to understand what problem in bitcoin proof of work solves and came to this somewhat helpful quote:

  So, for instance, if a miner controls one percent of the computing
  power being used to validate Bitcoin transactions, then they have
  roughly a one percent chance of winning the competition. So provided a
  lot of computing power is being brought to bear on the competition, a
  dishonest miner is likely to have only a relatively small chance to
  corrupt the validation process, unless they expend a huge amount of
  computing resources.

Does this mean that proof of work prevents say double spending because of following reasons. Imagine attacker introduces 100000 rogue nodes in the network and their goal is to send false information about transaction validity - but since these nodes need to do proof of work, in total, when all 100000 nodes are doing proof of work this is too costly for attacker. Is that right? So because of this proof of work keeps attackers at bay.

Imagine attacker introduces 100000 rogue nodes in the network and their goal is to send false information about transaction validity ...

That's no possible. Every node validates blocks and transactions for itself. It doesn't matter what another node tries to represent - if the block is invalid, it's ignored by the receiving node.

Proof-of-work is unnecessary for determining block validity.

What proof-of-work does do is makes block generation expensive. Without it, nodes could generate blocks cheaply, rolling back transaction history by publishing replacements for previous blocks willy-nilly.

To rewrite a previous block, a node must not only rewrite the block its self, but all of its descendants. It must re-do all of the work that was previously done.

To re-iterate: nodes validate transactions and blocks for themselves. Proof-of-work doesn't convince nodes of block validity. It convinces them that a certain amount of work must have been performed to produce the block.

A node uses the cumulative proof-of-work when faced with a choice of two or more valid block chains. The one with the most proof-of-work is used to build the global transaction log.


How to get a full view of the lightning network with c-lightning? As I understand lightning a node should in principle have a complete view of the lightning network graph (i.e., all nodes and channels). However, I also understand that for practical reasons the view will not actually be fully complete (some update may not have reached the node, I suppose).
For example I am currently using c-lightning. After running a node for some hours, if I do lightning-cli listnodes I get a list of ~5k nodes. But if I look at 1ml.com they currently report that there are ~14k nodes (~7k with active channels). So there seems to be rather a large gap between what I see and what 1ml sees.
For a particular use case I would like to have a "as complete as possible" view, though. My question then is if there is some way to configure the node to more actively explore and learn the full network?

lightning-cli listchannels is what you are looking for to also see the channels and not only the nodes.
In general the lightning nodes learn the network view from the gossip protocol where closed channels may be discarded and not forwarded anymore. If you look proprietary tools like the one you mentioned they might have stored older nodes and channels this is one source how the different numbers can arise.
BTW you get the gossip information from your peers so you could also peer with as many nodes as you learn from your initial peers and hope that you get a larger view of gossip.


bitcoin core command line walletpassphrase incorrect but works for the main system? My command line won't accept my passphrase, but on the main system it says it's correct and I can change it. I want to dump private key but no matter what I try, it continues to say incorrect passphrase. What can I do?

If your passphrase contains spaces or special characters, you will need to wrap it with single quotes (') so that the debug console can properly parse your passphrase. For example, if your passphrase were This is my passphrase, then your command should be

walletpassphrase 'This is my passphrase'


How basecoin transaction is added to a block? I'm new to blockchain and bitcoin. In my understanding, miners are trying to find a nonce that is added to a block, and then the hash of the block will have some zeros at first and the first transaction in each block is a coinbase transaction.
Is coinbase transaction added to block before calculating the hash or after??? And what forces the miner, not to add 100 bitcoins as their basecoin transaction??
Also on btc.com I saw that different blocks have different amounts of bitcoins. Shouldn't it be a fixed amount of bitcoin, i.e 6.25??

It's called a "coinbase" transaction. It's added before the hashing work is done, just like all of the other transactions are.
If a miner tried to pay themselves any more than allowed in the coinbase transaction then the block they mine is considered invalid (since it contains an invalid coinbase transaction) and will not be accepted by the network, so they would have wasted any money spent mining it. This has happened before; for example, AntPool at block #584,802 submitted a block with too high of a coinbase transaction, and the block was rejected (see more).
Any amount above the block reward of 6.25 BTC paid in the coinbase is the sum of all of the transaction fees paid in that block, and this is how the miner claims their transaction fee reward.


Bitcoin core - creating transaction from UI without broadcasting it I would like to use Bitcoin core's wallet UI to create a transaction but instead of broadcasting it I would like to get the underlying raw transaction.

Is there a way to do that?

I assume that network sniffing tools might be able to help but I wonder if there is a direct way. I think it would be really useful to have such feature - view raw transaction & confirm before broadcast.

The motivation for this specific scenario is the following  - I would like to create a raw transaction on an offline machine running Bitcoin core (with synced blockhain) and broadcast the transaction from another machine.

I am aware that what I am asking for is easily achievable with the CLI but I'd like to use the convenience of a GUI (& fee calculations) and also avoid creating non-intended transactions.

1) First you can add connect=1.1.1.1 to your bitcoin.conf. Your node won't search for other nodes and just try to connect to 1.1.1.1. Since 1.1.1.1 is not a node, your node will have 0 peers.

2) Then you can make the transaction, open the debug console and enter: gettransaction YOURTXID. (or getrawtransaction to get the hex encoded transaction)

3) Then you can close Core, add zapwallettxes=1 to bitcoin.conf and start Core to remove unconfirmed wallet transaction you've made to cancel it.


how to make own coin with soft fork? What I am looking to do is soft fork on litecoin and create my own coin! I know that I need to make a node but I can't find any process that shows me how to create my own coin.

Soft forks are generally used to upgrade an existing protocol in a backward compatible way. If you were to create a new coin you would need to hard fork the Litecoin protocol. How you do that depends on your motivation. If you just want to create a new coin to make money I would strongly advise against it. There are thousands of altcoins that have no unique selling proposition. It sounds like any coin you would make would also have no unique selling proposition.
If you want to experiment with your own network I would recommend looking into Signet.


Is it possible to get the public key from a transaction input that is a 'pay to public key' output? I am looking to be able to calculate the public key from the transaction input.  The input is from a 'pay to public key' output.
Can the public key of the input be generated from just the signature and the transaction that the input is in?

I can't understand your question but I will try to clarify the things for you.

A Pay-to-Pub-Key transaction is a type of transaction which is generated basically from a miner in order to send back to his own address the reward(now is 25 BT) after a suceessful creation of a Block. This transaction is called coinbase transaction and is the first located transaction of the Block which is going to be mined by him.

The structure of the script which satisfies this kind of transaction is:

•   Locking Script or scriptPubKey (which located in the Output of a transaction)

< Public Key of Miner> OP_CHECKSIG

•   Unlocking Script or scriptSig (which located in the Input of a transaction)

<Signature from Private Key of Miner>

•   Validation Script

<Signature from Private Key of Miner> < Public Key of Miner> OP_CHECKSIG

In order the miner to redeem the 25BT value :

His signature located in Locking script have to be created by his private key.
In order to check that condition, his public key is used, which corresponds to this private key.

As a result the public Key can't create a signature. A signature is created by the private key and a message (or transaction) which is going to be signed with this private key.
You can't calculate the public key from the input, because the public key is located in the output or better in the Locking Script.


Hash of backed up wallet file not the same as hash of wallet currently in use A couple of months ago I had backed up the wallet.dat (I use bitcoin-qt) file and saved it some place else.

Lately I've opened the data folder for the current running node (also bitcoin-qt) and I compared the md5 hashes of both files and they are different.

What caused this? Surely my private keys have not changed so why is the wallet.dat file not exactly the same as the backed up version?

Thank you

The wallet file contains the hash (and more) information about the tip of the chain it has been synchronized to. This means that generally when loading a wallet into a running node, it will be modified every time a new block comes in.

Furthermore the wallet file also contains all transactions affecting the wallet balance. If you sent or received any transactions, that too will inevitably modify the wallet file.


Cheapest way to move money from MultiBit to Coinbase After the launch of MultiBit HD, I decided to move from MultiBit to Coinbase. What is the cheapest way to transfer all my money from one wallet to another? Can I somehow export/import my key/wallet (if yes, how) or the only way would be to send money and pay transaction fees (if yes, should I transfer them all at once or in smaller chunks)?

You should reconsider your wallet switch. Mind that Coinbase can fully control your funds and it could lead to a similar fiasco we have seen in the past (Mt.Gox, etc.). Check out the web wallet section of bitcoin.org.

Export and import (if even possible) would expose your private keys or mnemonic seed and should therefore be avoided.

A better option would be to send your coins from Multibit HD to Coinbase. It would be one transaction and the required fee would be not very hight (~0.0003 BTC).


How can I setup Bitcoin to be anonymous with Tor? Bitcoin is billed as many things, among them its anonymity is highly regarded. While it is true that a transaction does not identify a user or wallet, recent news shows that there is the potential for privacy to be partially undermined, by an 'educated guess' method that may identify the IP address of a transaction originator.

How do I setup to use Bitcoin completely anonymously using Tor?

This is not a thorough schooling on Tor and only shows how to configure it to work together with Bitcoin Core.

Bitcoin Core includes Tor integration

When Tor is correctly setup on your system, Bitcoin Core automatically identifies Tor and creates an anonymous service. Little configuration is required to be 'off the grid' and, just a tiny bit more to be completely anonymous if that is important to you, with none of your Bitcoin traffic reaching out onto the public internet.

Using these steps you can be anonymous in only five minutes.

With the full privacy setup, transactions will of course still be broadcast but will only be broadcast actually onto the public internet by other Bitcoin nodes. With the standard 'off-the-grid' Tor setup, your Bitcoin traffic will be routed through the anonymous Tor network before reaching the public internet and other Bitcoin nodes on and off the Tor network to be effectively untraceable.

Setting Up Bitcoin Core and Tor

These instructions work on Fedora 23>29 and assume a default setup of Bitcoin Core v0.15.1 and Tor v0.2.7.1 or newer (and have been tested to work with Bitcoin Core v0.16.0 on Fedora 27 with Tor v0.3.1.9). Fedora is a modern operating system that will run on most standard modern hardware. The configuration is the same on Windows, but the instructions are different. There are some instructions for setting up Tor on Windows here.

Further instructions for other *nix based systems are available here. NOTE: You do not need to configure your Tor client as a relay or exit node for Tor to operate, so you can skip the step for 'Put the configuration file /etc/tor/torrc place:' in that guide. You will still need to use all of the following steps in this guide.

Setup Tor

Install the tor package:

sudo dnf install tor

Start the tor daemon and make sure it starts at boot:

sudo systemctl enable tor
sudo systemctl start tor

Figure out where your torrc file is (/etc/tor/torrc is one possibility).
Open the torrc file to edit:

xhost +local: ## skip if earlier than v29 only needed for Wayland
sudo gedit /etc/tor/torrc

or

sudo nano /etc/tor/torrc

Add these lines to your torrc (or ensure that they are uncommented):

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

You need to figure out what group tor is using. On Fedora 23 it is toranon. Run the following command:

ps -eo user,group,comm |egrep 'tor' |awk '{print "tor group: " $2}'

You need to figure out what user bitcoind or bitcoin-qt is running as. Run the following command while Bitcoin is running:

ps -eo user,group,comm |egrep 'bitcoind|bitcoin-qt' |awk '{print "Bitcoin user: " $1}'

Run the following command as root, which adds your Bitcoin user to the tor group. Replace TOR_GROUP and BITCOIN_USER with the actual information found above:

sudo usermod -a -G TOR_GROUP BITCOIN_USER

If you don't modify any other settings, Bitcoin Core will usually connect over the regular Internet, but will also allow connections to and from the hidden Tor service.

So that Bitcoin Core wil only connect via Tor (for standard 'off-the-grid' setup), add these lines to bitcoin.conf. In Bitcoin Core, go to Settings -> Options -> Open Configuration File. Bitcoin Core uses Tor stream isolation by default:

proxy=127.0.0.1:9050 #If you use Windows, this could possibly be 127.0.0.1:9150 in some cases.
listen=1
bind=127.0.0.1

(optional) If you like, you can add some onion service peer nodes to connect to. This will help especially if you do all of the following optional configurations. Add the following lines to your bitcoin.conf file. Bitcoin Core will only connect to a maximum of eight of these at any one time randomly, depending which ones are online:

#Add seed nodes
seednode=wxvp2d4rspn7tqyu.onion
seednode=bk5ejfe56xakvtkk.onion
seednode=bpdlwholl7rnkrkw.onion
seednode=hhiv5pnxenvbf4am.onion
seednode=4iuf2zac6aq3ndrb.onion
seednode=nkf5e6b7pl4jfd4a.onion
seednode=xqzfakpeuvrobvpj.onion
seednode=tsyvzsqwa2kkf6b2.onion

#And/or add some nodes
addnode=gyn2vguc35viks2b.onion
addnode=kvd44sw7skb5folw.onion
addnode=nkf5e6b7pl4jfd4a.onion
addnode=yu7sezmixhmyljn4.onion
addnode=3ffk7iumtx3cegbi.onion
addnode=3nmbbakinewlgdln.onion
addnode=4j77gihpokxu2kj4.onion
addnode=546esc6botbjfbxb.onion
addnode=5at7sq5nm76xijkd.onion
addnode=77mx2jsxaoyesz2p.onion
addnode=7g7j54btiaxhtsiy.onion
addnode=a6obdgzn67l7exu3.onion
addnode=ab64h7olpl7qpxci.onion
addnode=am2a4rahltfuxz6l.onion
addnode=azuxls4ihrr2mep7.onion
addnode=bitcoin7bi4op7wb.onion
addnode=bitcoinostk4e4re.onion
addnode=bk7yp6epnmcllq72.onion
addnode=bmutjfrj5btseddb.onion
addnode=ceeji4qpfs3ms3zc.onion
addnode=clexmzqio7yhdao4.onion
addnode=gb5ypqt63du3wfhn.onion
addnode=h2vlpudzphzqxutd.onion
addnode=n42h7r6oumcfsbrs.onion:4176
addnode=ncwk3lutemffcpc4.onion
addnode=okdzjarwekbshnof.onion
addnode=pjghcivzkoersesd.onion
addnode=rw7ocjltix26mefn.onion
addnode=uws7itep7o3yinxo.onion
addnode=vk3qjdehyy4dwcxw.onion
addnode=vqpye2k5rcqvj5mq.onion
addnode=wpi7rpvhnndl52ee.onion

If you additionally want Bitcoin Core to only connect out to Tor hidden services and not even to connect to IPv4/IPv6 nodes on the public internet via the Tor network proxy:

(optional) Also add this to bitcoin.conf for full anonymity (not particularly recommended)*:

onlynet=onion

*Note: Bitcoin Core will still query for peer addresses via DNS lookup if low on addresses. This also can be disabled using the next option. However, it is possible your node may not be able to find any other nodes to connect to.

*Note: Bitcoin Core v0.15.1 currently seems to make some outbound IPv4 connections at node startup even when onlynet=onion, none have been observed after initial startup. These connections should be made via your onion proxy, however, using the next option has been observed to prevent them.

(optional) (advanced) If you also want to disable DNS lookup to query for peer addresses then also add the following to bitcoin.conf (not particularly recommended) note: if you use this option your node may be unable to find peers until you add some good peers with the addnode= parameter.:

dnsseed=0
dns=0

Restart tor:

sudo systemctl stop tor
sudo systemctl start tor

Log out of your user, log back in (this is so that your new user group permissions are effective, I do not know what user you are running Bitcoin Core on).
Restart Bitcoin Core. Since Tor version 0.2.7.1 and newer the Bitcoin Core GUI version called bitcoin-qt automatically registers your Tor hidden service and makes it reachable on the onion network. For the command line version of Bitcoin Core, bitcoind, add the following parameter to your command line:

>bitcoind -listenonion

No port forwarding is necessary for everything to work with Tor including incoming connections via the Tor hidden service, you do not need to forward any ports for Bitcoin Core or Tor for this.

If you want your Bitcoin node still publicly reachable via the public internet for incoming connections you will still need to forward port 8333 for Bitcoin Core.

Checking everything is working

There are only two things to check that all is working. Checking peer info in the debug window of bitcoin-qt, you should see that connections to IPv4/IPv6 peers now have some extra connected 'via' info along with the peer address when you click on a peer. Onion addresses only route via Tor.

Checking the same thing via console or CLI for getnetworkinfo, you should see for each network type the proxy info and, checking with getpeerinfo you should see that the addrlocal info is a remote address for each peer. Onion peers do not have addrlocal and just have their onion service name for addr.

The second thing to check is that your onion service for inbound Tor connections is up and all configuration is in place. Have a look in your debug.log file, you should see a few entries after the most recent node restart that match the following:

2018-02-10 06:31:48 InitParameterInteraction: parameter interaction: -proxy set -> setting -upnp=0
2018-02-10 06:31:48 InitParameterInteraction: parameter interaction: -proxy set -> setting -discover=0
...
2018-02-10 06:32:13 Bound to 127.0.0.1:8333
...
2018-02-10 06:32:13 torcontrol thread start
2018-02-10 06:32:13 tor: Got service ID {onion}, advertising service {onion}.onion:8333
2018-02-10 06:32:13 AddLocal({onion}.onion:8333,4)

The advertising service information is your onion service address.

In the debug.log, connections to onion peers will only look like the following but still show up in the peers tab of the debug window on bitcoin-qt:

2018-02-10 06:34:07 receive version message: /Satoshi:0.15.1/: version 70015, blocks=508469, us=[::]:0, peer=7

It is not necessary to configure port forwarding on your modem/router for Tor to operate. If you are behind a restrictive firewall it may be necessary to configure outbound connections to allow Tor to connect out to other Tor nodes. Tor can be configured to only connect out using port 80/443 if that helps. See Appendix 1 - Monitoring Tor for nyx and access to full Tor configuration options.

It is difficult to be completely anonymous since the sender and the receiver know, however, you can obfuscate your transaction origin so that your data cannot be traced by IP address without breaching the Tor network. Do some research, onlynet=onion is more secure.

Additionally, there has been research[1][2] done on graphing the blockchain in an attempt to trace all BTC to their origin, potentially identifying source<-wallet<-purchase and depending on the combination of UTXOs potentially identifying wallet balances or wallet balance subsets. Data linkage is a privacy issue we may all be concerned about, this article discusses the use of bitcoin mixers, and this series of tweets.

Done! Enjoy being anonymous!

Appendix 1 - Monitoring Tor

You can monitor (and further tweak/break) Tor using nyx.

There are several installation methods available. On Fedora 27:

sudo dnf install nyx

To start nyx simply type nyx in the console and it will connect to Tor if it is running.

Footnotes

Once correctly configured, most synchronisation issues are to do with your hardware. See this answer for more information.

There are more configuration options available, and additional ways you can support the Tor network. Please see the several pages available here for information.

Thanks to en.bitcoin.it for your excellent guide that got me started on this.

Additional information is available from the bitcoin project here.

For an even higher level of anonymity, it is possible to configure Tor as a DNS resolver and, configure your system network configuration to use Tor to resolve DNS queries.

*by default, Tor will participate in the Tor network.


What does the debug output look like when a new block is found? In the Bitcoin-QT client, what does the debug.log look like when a new block is found?

I got the following output when I set gen=1 on test net:

BitcoinMiner:
proof-of-work found
  hash: 00000000502cfb2fe549f1d672ff60cab179b8c91c95fe6d4d9dce490a8e00e8
target: 00000000ffff0000000000000000000000000000000000000000000000000000
CBlock(hash=00000000502cfb2fe549, ver=2, hashPrevBlock=000000008efd2a2075c9, hashMerkleRoot=cae3a8d5d1, nTime=1355478291, nBits=1d00ffff, nNonce=119890730, vtx=1)
  CTransaction(hash=cae3a8d5d1, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000, 4294967295), coinbase 03b39b00010e062f503253482f)
    CTxOut(nValue=50.00000000, scriptPubKey=031e72826fe94305e81a34e34ea316)
  vMerkleTree: cae3a8d5d1
generated 50.00
keypool keep 6
AddToWallet cae3a8d5d1  new
NotifyTransactionChanged cae3a8d5d1feb8e058ddf4a30d021a9f1f85775b474456f4d6b595ffd832b7f3 status=0
updateWallet cae3a8d5d1feb8e058ddf4a30d021a9f1f85775b474456f4d6b595ffd832b7f3 0
   inWallet=1 inModel=0 Index=0-0 showTransaction=0 derivedStatus=0
SetBestChain: new best=00000000502cfb2fe549  height=39859  work=4384611213659391  date=12/14/2012 09:44:51

ProcessBlock: ACCEPTED
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
keypool added key 110, size=101
connection timeout
keypool reserve 10
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
CreateNewBlock(): total size 1000
Running BitcoinMiner with 1 transactions in block (189 bytes)
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549
received getdata for: block 00000000502cfb2fe549


1 block only allow about 2000 transactions. Does it mean every 10 minutes, bitcoin can allow 2000 transactions? Hi I very new to bitcoin and don't understand this. Isn't this 2000 too small? I thought there would be more than 10,000 transactions going around every 10 minutes. Especially when there is an ICO going on.

2-3000 transactions can be included in each block. But that does not mean that only that many transactions can be made every 10 minutes. There can be, and has been, several thousands more transactions made than can fit into the next block. That just means that several thousand transactions won't be confirmed in the next block and will have to wait for blocks that come later.

There are many proposals that are in their activation stages that will increase the Bitcoin's capacity so that much more transactions can be included in each block. However these are all not yet deployed; they either require miner signalling or community consensus (everyone, including miners) to activate, and none of those have happened for any of the proposals yet.

  Especially when there is a ICO going on

ICOs don't use Bitcoin.


Is it possible to transfer blockchain data from one machine to another? I want to run a bitcoin full node at home but the initial sync-up is taking days because of my slow internet connection. Can I download the blockchain data from a machine with faster connection and transfer over to my home machine? Is this possible and if yes, how?

You can simply copy the entire data directory from an existing bitcoin-core installation on another machine over to your machine, then start the bitcoind daemon.

Be aware you'll want to create a backup of the wallet.dat file from the destination machine so you don't inadvertently overwrite it.  You may also want to confirm the bitcoin.conf settings work for the destination machine.  Specifically, you may want to modify the rpcpassword, memory configuration, etc.

On Windows, the data folder is installed by default into %AppData%\Bitcoin


Does bitcoind ERROR "Disk space is too low!" refer to RAM or actual harddrive? After having finished the "Initial Block Download" I needed to reindex:

[BTC_Core_Expmnt]# bitcoind -reindex -datadir=/mnt/BTC_Core_Expmnt

The debug.log showed everything starting up ok; and the process beginning:

[2020-01-20T07:43:41Z Loaded 119369 blocks from external file in 6005ms\
2020-01-20T07:43:41Z Reindexing block file blk00001.dat...]

Then a while later this:

[2020-01-20T09:05:59Z Reindexing finished]

But bitcoind continued grinding on... Well then what is all this? ::

[2020-01-20T09:05:59Z Pre-allocating up to position 0x100000 in\
[rev00000.dat 2020-01-20T09:05:59Z UpdateTip: new best=\
[00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048\
[height=1 version=0x00000001 log2_work=33.000022 tx=2\
[date='2009-01-09T02:54:25Z' progress=0.000000 cache=0.0MiB(1txo)]

In any case it got to this point ::

[2020-01-20T09:59:00Z UpdateTip: new best=\
[00000000000000001088ed0c0989828504a41d4b5b974c8c081b708cfdd3b7b0\
[height=359645 version=0x00000003 log2_work=82.893764 tx=71128141\
[date='2015-06-06T07:25:10Z' progress=0.143166\
[cache=669.7MiB(4972713txo)]

Then it fell over ::

[2020-01-20T09:59:00Z *** Disk space is too low!
[2020-01-20T09:59:00Z Error: Disk space is too low!\
[Error: Disk space is too low!
[2020-01-20T09:59:00Z Failed to connect best block\
[ (Disk space is too low! (code 0)) ]

Which is odd, because there should still be 20GB free since the size of
BTC_Core_Expmnt is supposed to be 300GB.

[BTC_Core_Expmnt]# du -h
102M    ./blocks/index
275G    ./blocks
56K     ./bitcoin-0.19.0.1/share/man/man1
60K     ./bitcoin-0.19.0.1/share/man
64K     ./bitcoin-0.19.0.1/share
73M     ./bitcoin-0.19.0.1/bin
8.0K    ./bitcoin-0.19.0.1/include
440K    ./bitcoin-0.19.0.1/lib
74M     ./bitcoin-0.19.0.1
16K     ./lost+found
3.4G    ./indexes/txindex
3.4G    ./indexes
914M    ./chainstate
280G    .
[BTC_Core_Expmnt]#

Is 300GB not enough in 2020 to run a full node?  I thought it'd do.  But, asking for any helpful tips because I cannot see anything else amiss from debug.log.

It refers to actual disk space. RAM is memory, not storage. The term "disk space" is very specific.

  Then a while later this:

[2020-01-20T09:05:59Z Reindexing finished]

  But bitcoind continued grinding on... Well then what is all this? ::

Your node was not fully synced, so after it finished reindexing the blocks on disk, it continued to download blocks from its peers and finish syncing.


Litecoin Historical Trade Data Is there anywhere I can find detailed LTC historical trade data? BTC-E's API is not well documented and I can only find a live tick API from them. I found historical data on Cryptocoin Charts but the data they output is not very detailed.

If you search through your BTC-e's profile, you will find that they have MetaTrader which shows all trades.

This site shows data for MTGox which is very good for like how you want though I don't know if they have one for BTC-e

http://www.quandl.com/BITCOIN-Bitcoin-Charts/MTGOXUSD-Bitcoin-Markets-mtgoxUSD


How long has it taken for BIP-Taproot to go from draft specification to activation? It seems BIP-Taproot has been discussed for years now. How long has it taken to go from draft specification to potential activation?

The idea of using the leaves of a Merkle tree to store alternative Bitcoin scripts dates back to Russell O'Connor in 2012. The idea of using Schnorr signatures instead of ECDSA has been discussed for at least as long. So you could say that what we will collectively call BIP-Taproot (BIP 340, BIP 341 and BIP 342) has been in the making for over eight years at this point.
However, there have been different iterations of how to apply these ideas and what we now consider BIP-Taproot was first proposed on the Bitcoin dev mailing list by Greg Maxwell in January 2018.
The draft of the Schnorr BIP (what became BIP 340) was first sent to the Bitcoin dev mailing list in July 2018.
The draft of the Taproot BIP and the Tapscript BIP (what became BIP 341 and BIP 342) were sent to the Bitcoin dev mailing list in May 2019. The BIPs were all allocated BIP numbers in January 2020.
Jonas Nick laid out the full timeline of BIP-Taproot progress here.
Greg Maxwell compared how long it took SegWit to go from draft specification to merged into Bitcoin Core in this Reddit post.

Segwit went from early public discussions to merged in six months. So in spite being more complex and subject to more debate due to splashback from blocksize drama, segwit was still done in significantly less time already.
Taproot has also been exceptionally widely discussed by the wider bitcoin community for a couple years now. It's application is narrow, users who don't care to use it are ultimately unaffected by it (it should decrease resource consumption by nodes, rather than increase it) and no one is forced to use it for their own coins. It also introduces new tools to make other future improvements simpler, safer (particularly, taproot leaf versions), and more private... so there is a good reason that other future improvements are waiting on tapoot.


Why is my bitcoind daemon not listening on RPC port at 8332? I have read a similar post which had no answer at this location. I am trying to use bitcoin-cli from a host that different from the host that runs bitcoind.  I also would be happy with being able to use curl to issue rpc requests.  I have had much success with getting bitcoind and bitcoin-cli to communicate within the same host, but activating the rpc port for external communication has proven to be beyond difficult if not impossible, and I am seeking your help.

I have started bitcoind with the following configuration file:

server=1
rpcuser=jared
rpcpassword=1234
rpcport=8332
rpcallow=192.168.*.*
gen=0
prune=600

(Note, the password will be changed after the system is working)

I have confirmed that the system is functioning on the local machine using bitcoin-cli to get the following:

{
    "version" : 110200,
    "protocolversion" : 70002,
    "blocks" : 183745,
    "timeoffset" : -1,
    "connections" : 8,
    "proxy" : "",
    "difficulty" : 1583177.84744401,
    "testnet" : false,
    "paytxfee" : 0.00000000,
    "relayfee" : 0.00005000,
    "errors" : ""
}

And from another host on the network, I have used nmap to scan the ports to display:

Starting Nmap 6.47 ( http://nmap.org ) at 2015-12-19 15:20 PST
Nmap scan report for c161.attlocal.net (192.168.1.68)
Host is up (0.0014s latency).
Not shown: 997 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
8333/tcp open  unknown

In the question referenced above, the user was able to cause the rpc port to open by removing the rpcallow lines from his configuration file. He commented them out, and the problem fixed itself. I have also tried this and not had any luck.

I also have tried using rpcallow of '192.168.1.*', '192.168.0.0/16', '192.168.1.0/24' and once tried using rpcbind, which appears to be related to an older version of bitcoind as it is no longer listed in the man pages for bitcoin.conf.

My system is running the following OS:

Distributor ID: Ubuntu
Description:    Ubuntu 15.10
Release:    15.10
Codename:   wily

Any and all help is appreciated!  Kind regards, and thank you.

Two thoughts:

The wildcard syntax is not supported anymore. Instead of 192.168.*.*, use 192.168.0.0/16. Instead of 192.168.1.*, use 192.168.1.0/24.
As an additional debugging step, try running netstat -antlp | grep 8332. If that produces output like the following, that means that it is bound to the port.

tcp        0      0 0.0.0.0:8332             0.0.0.0:*               LISTEN


How to get full Block information like blockchain? How to get these values?

Output Total
Estimated Transaction Volume
Transaction Fees
Relayed by

Raw blocks are available at datafolder/block/blkXXXXX.dat in serialized in network format or can be downloaded from the p2p network.

As you can see in the format, each block has a list of transactions which in turn has a list of outputs. If you sum each output value, you get the output total.

The estimated transaction volume is calculated like the output total, but not counting the change outputs. There's no reliable way to know which output is being sent and which one is change, so you'll have to guess, take the mean or something like that.

One of these transactions must be coinbase. A coinbase transaction has a single input with txid = 0000000000000000000000000000000000000000000000000000000000000000. If you sum all input values (not including coinbase) and subtract all output values (again, not including coinbase) you get the total fees. Inputs don't have a value, so you have to find the transaction they're referring to (txid) in a previous block and the referenced output in that transaction (vout). There's a cheap (but not reliable) way to calculate the total fees. Just sum the coinbase outputs and subtract the block reward. The value is only accurate if the miner claimed the whole reward and fees (which is not enforced anywhere).

You might have noticed the relayed by is nowhere to be found. This is different for everyone, and is only the client which sent you the block for the first time. To know who relayed the block to you, you have to set a client listening for block broadcasts and just record whoever did broadcast the block to you.


Why does the Genesis block coinbase input script push bits and the value 0x04 before the famous "Chancellor" message? According to the Wiki, the input script of the Genesis block consists of these bytes:

  04FFFF001D0104455468652054696D65732030332F4A616E2F32303039204368616E63656C6C6F72206F6E206272696E6B206F66207365636F6E64206261696C6F757420666F722062616E6B73

We can break this down as follows:

0x04: push 4 bytes
0xffff001d: the same value as the "bits" field of the Genesis block header
0x01: push 1 byte
0x04: push the value 4
remainder: ASCII encoding of the famous message "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"

As far as I know, the first two values pushed to the stack (0xffff001d and 0x04) are unnecessary. Of course, so is the chancellor message, but at least its meaning is a bit more clear.

However, the push bits/0x04 pattern also appears in other blocks. For example, the same pattern shows up in the next block (0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098).

I found this question, with an answer that speculates:

  So 010445 are in fact part of 2 operations - 01 pushes 04 to the stack, 45 pushes the message to the stack. As to why push 04, beats me, maybe it was just testing to make sure something works? Some internal counter used by Satoshi during Genesis block creation? Since the script of a coin generation transaction is really meaningless, we might never know.

My questions:

Are these initial push data operations necessary?
If not, why do these items (bits and 0x04) appear in more than one block?
Was adding this prefix to the coinbase transaction input script part of the default behavior of the original Bitcoin client?
If not, wouldn't this be a signature for blocks that Satoshi mined?

I found some more information on the Wiki:

  Generations have a single input, and this input has a "coinbase" parameter instead of a scriptSig. The data in "coinbase" can be anything; it isn't used. Bitcoin puts the current compact-format target and the arbitrary-precision "extraNonce" number there, which increments every time the Nonce field in the block header overflows. Outputs can be anything, but Bitcoin creates one exactly like an IP address transaction. The extranonce contributes to enlarge the domain for the proof of work function. Miners can easily modify nonce (4byte), timestamp and extranonce (2 to 100bytes).

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

In other words, the first Bitcoin client copied the "bits" field (compact-format target) from the block header and used it in a push data operation for the coinbase input script. But I'm still not sure why this was considered to be a good idea.

Next, a second pushdata operation pushed the "extranonce" field. This field incremented whenever the nonce field overflowed. The privacy implications of this system are discussed here:

https://bitslog.wordpress.com/2013/04/17/the-well-deserved-fortune-of-satoshi-nakamoto/

I believe I can now answer my own questions:

No.
Bits is there because that's just what Bitcoin did. 0x04 is the extranonce field.
Yes.
Yes, in part.


One pub address to many cryptocurrency I've found this in the code on Github:

  This pubkey can accept any type of coin, please leave this in
             your config to help support development.

  22851477d63a085dbc2398c8430af1c09e7343f6

How do I create a similar address?

It appears to be a hash160 of a public key. Generate an address, then either take the RIPEMD-160(SHA256(key)), or paste the address into this calculator: http://bitcoinvalued.com/tools.php


BlockCypher MicroTX transaction fee? does anyone know how much is the BlockCypher fee when doing Micro TX? I read here (https://www.blockcypher.com/dev/bitcoin/#microtx) and it says it is generated automatically (deducted from source). I need specifics, like is it in % or a fixed value,  but cannot find any.

The Microtransaction API documentation it describes a BlockCypher MicroTX as a normal transaction. BlockCypher just checks that the transaction has reached 98% on their confidence-factor and is therefore included in the next block.

However the documentation (and the whole concept) seems to be outdated.

  The Microtransaction API will accept values between 7,000 satoshis (~$0.04) and 4,000,000 satoshis (~$20). Anything below or above these thresholds will return an error.

At the time of writing (BTC @ ~$7000) the 7000 satoshi would be worth ~$0.49. In the Microtransaction API they alert that MircoTX are not feasible anymore and the API is therefore discontinued on bitcoin.

  Due to congestion on the Bitcoin network and the drastic increase in miner fees, microtransactions have become uneconomical. As a result, our microtransaction API isn’t supported on bitcoin anymore.


How to do refunds and internal transfers on bitcoind? I would like to ask regarding refunds and internal transfers. It wouldn't be difficult if not for the network fee.

How can one do internal transfers without network fees and another is refunds in bitcoind or bitcoindxt?

:)

Unfortunately, there's no distinction between "external" and "internal" transfers in bitcoin. If you want coins to be in another address, you have to pay the transaction fee. That said, you can create a single transaction that does everything you want and only pay the fee once (though, obviously, that transaction will be relatively big, you should still save some fees because you'll not have as much overhead in terms of tx size)


1 MB Block Size as a Anti-DoS Attack Measure Wikipedia explains the rationale behind the 1 MB block size limit as follows:

The one megabyte block size limit was added in 2010 by Satoshi
Nakamoto as a temporary anti-DoS measure

A SE post expounds on this:

Usually Denial Of Service(DoS) attack may take place on larger sized
blocks. So to avoid this condition initially block size Bitcoin was
chosen to be 1Mb. Because attacker sends a lot of data in the network
to make it busy so that the actual transactions are not able to take
place

What I don't understand is:
1) What stops an attacker from sending illegitimate transactions to quickly filling up the 1 Mb block size in order to perform a DoS attack? What is it about bigger block size that makes this attack more likely?
2) Is there a way to empirically demonstrate that a block size of 1 Mb is less likely to suffer a DoS attack compared to a block size of say 1 GB?
Considering the block size is one of the biggest bottle necks to BTC scalability it seems like a no-brainer that something like has to be proven. A block size of 1 GB would be able to process 1,000 x more transactions per sec compared to a block size of 1 mb.
Thanks

The DoS the block size limitation is trying to prevent is a miner creating a huge block of garbage data that now every single Bitcoin miner must download, validate, and store the entirety of. Imagine if some miner decided to create block after block of 1GB of garbage, and now every single Bitcoin node in the world must store and validate all of this garbage. If it were possible, this would be in the best interests of larger miners to do: smaller miners, who don't have the ability to download and validate these giant blocks of garbage as efficiently, will not be able to keep up with mining.
Also, people do attempt to submit spam to the blockchain. Trying to do so to the point of blocking out legitimate transactions will be quite expensive, considering you would have to pay transaction fees for every "spam" transaction you want to send.


Why is utxo time a priority for miners? I've understood (maybe mistakenly) that once free transactions arrived to be collected into new block the miner will prioritize them by fee, then by maturity, meaning will take the transaction with the oldest inputs. Why?
What kind of incentive does the miner have to do so?

First of all, this is a slight oversimplification: after taking transactions with fees, the standard policy is that priorities of remaining transactions are weighted by age and amount transacted.  For each input to the transaction, the age of the input being spent (counted by number of confirmations) is multiplied by the bitcoin amount of the input, and the result is summed over all inputs to get the priority of the transaction.  So a large-value transaction spending a fairly recent input might get higher priority than a very small-value transaction spending an old input.

There's certainly no requirement for any given miner to follow this policy (miners have complete freedom as to which valid transactions they include in their blocks), nor is there any direct financial incentive for them to do so.  However, there are a few indirect incentives.

The policy described above is the default behavior of Bitcoin Core.  A miner who is willing to use this policy can use Bitcoin Core for their transaction processing, rather than having to spend time and money to find or develop some other software.
Since miners are out to earn bitcoins, they have an incentive to behave in ways that help make the currency convenient and desirable for people to use, since that should increase adoption of the currency and ultimately increase the value of a bitcoin.  So if they believe this policy is helpful to the community as a whole, it is in their interest to use it.  Even if they are not sure this policy is inherently the best, there is some benefit in using it simply because it is standard; it is good for the currency's transaction processing to behave consistently, so that users know what to expect.


Pool getwork "target"? In a getwork request, bitcoind sends a target corresponding to the current block's bits value. Do the major pools send the same target as one would expect from bitcoind, difficulty of "1" target, or perhaps something else?

Most pools define their target value (minimum value required to earn a "share"), as:

T = 2 ** (256 - 32) - 1
= 0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff

The Bitcoin protocol defines a difficulty of 1 as a target of:

D = 0xffff * 2**208
= 0x00000000ffff0000000000000000000000000000000000000000000000000000

They are nearly equal:

T/D = 1.0000152590218967

The precise target used for earning shares could be set to a larger number, but that would increase the number of getwork requests sent to the server as shares would be easier to find.  Note that if you decrease the size of target, you would reduce the probability of finding ANY valid shares for a given block header (unless you allow changing the timestamp as well as the nonce).  As it stands, the expected number of shares found per getwork request is approximately 1 (when the target has 32 leading zero bits).


Which method is preferable: sender to send Bitcoins to eWallet/mixer first or to wallet on the PC? Suppose a friend wishes to send some Bitcoins to me.

In terms of anonymity, which of the following would be preferable?

Have the Bitcoins sent to an eWallet/mixer first and then I withdraw them to my Wallet on my PC; or
Have the Bitcoins sent to my Wallet on my PC first. As and when I need to spend them, I will send a portion of them to the eWallet/mixer from where it will be spent.

Depends on which link you want to hide. If you do not want observers to be able to tell that you and your friend traded then take option 1. If you want to later hide what you are doing with the coins, but do not care whether people find out that you and your friend traded then go for option 2.

You could of course do both but then you'd pay the mixer twice or at least pay the transaction fees twice.


Getting error when starting bitcoind in regtest mode I tried starting bitcoind in regtest mode but got the following error.
Command :    bitcoind  -regtest  -daemon
Output :

Bitcoin server starting
Error: Invalid amount for -paytxfee=: '0.00' (must be at least 0.00001000 BTC/kB)

Since paytxfee is not passed as an argument you need to alter the value of paytxfee in your bitcoin.conf.


How long does it take for a transaction to be included in a block? If I understand it correctly, a transaction must be included in a block and broadcasted to other nodes before the transaction is accepted as valid. But it takes time to create such a block which only miners create.

How much time does it take before the transaction is registered as valid?

Time between mining the blocks is around 10 minutes. Bitcoin protocol adjusts itself to keep that 10 minutes target.

But the transaction is not necessarily included in the next block. It depends on the number of transactions and fee you provide to incentivize the inclusion of your transaction. If the fee is too low transaction will never be mined (put in the block and added on blockchain). If the fee is reasonably high it will be included in the next block (so less than 10 minutes time).

The party receiving the money should not consider transaction valid up until it is "buried" under a number of other blocks (let's say 6 - so another 60 minutes after your transaction is added on the blockchain).


Running a store through Tor - what are the setup options available? I am required to setup a store that will operate through Tor and accept Bitcoin payments only. I know I can run the standard client on the server and make it connect to peers only through Tor. However, are there any other options available for handling Bitcoin side of things - hosting the wallet, creating accounts, receiving money and so forth? Do any eWallets or other services allow access through Tor?

Try using bitwasp. It seems to provide a lot of features you need. Try it and let us know if it works.

https://github.com/Bit-Wasp/BitWasp

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


Do miners participating in pools pay a transaction fee? So I understand that an individual miner in a pool gets paid based on their hashrate. But my question is, what about the Bitcoin transaction fee? When the pool pays the miner, who is paying that fee to transfer the funds from the pool to the individual person?

The sender always pays the transaction fee, so it is the mining pool operators that pay the transaction fee. Of course since they control a mining pool, the mining pool operator can just have their pool mine the transaction and thus not have to pay any transaction fees. This is a fairly common occurrence.


What is the current computing speed of performing an elliptic curve multiplication? Hi I was just looking for some information on how long it would take to crack a private key in bitcoin using a brute force approach and I couldn't find a very good answer for how long it takes to check whether one specific key (or every key) would work.

So essentially what I am asking is how long would the elliptic curve multiplication process take to check whether a single private key would work for a given public key (on average), thanks :)

The only way to determine the private key associated with a given public key is by a brute force method, spanning the entire 2^256 key space. More specifically, any number from 0x1 to 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364140 (order of G) is a valid private key.

According to an article on wikipedia on brute force cryptography, it would take 50 supercomputers that could check 10^18 keys per second about 3x10^51 years to exhaust the 256 bit key space. However, this number fails to account for theoretical limits of energy consumption and computation from Landauer's principle. I decided to put in some work to show the theoretical limits.

  Landauer's Principle

Laundauer's principle basically provides us with the lower limit of energy consumption needed to flip a bit as a function of temperature (it is much more complex, but we can leave that aside for now.) That lower limit is given by the formula: kT * ln(2) (where k is the Boltzmann constant (1.38*10^-23) and T is temperature in Kelvin scale.) So, for a 2^256 key space, that energy is 2^256*kT*ln(2). The energy that I'm calculating below, is only to generate keys in the 2^256 key space, and does not involve the energy to generate public keys from them and check the result.

Since I'm in Mumbai, I will take the liberty to use temperature of 25 degree celsius or 298 Kelvin. Using the above formula, E = 2^256*kT*ln(2), we get energy as 3.3x10^56. According to this article, the global electricity consumption was 21,700 TWh in 2017. That's equivalent to 7.8*10^19 Joules. So, even assuming that world's entire electricity supply is diverted to generation of the keys in 256-bit key space, we would still need electricity that is 5*10^36 times more than that is generated today.


Cryptocurrency with addresses that cannot collide? I had originally posted the following question here:

Is it possible to have a cryptocurrency based on email address?

And now I have come across The Large Bitcoin Collider

I have read on Bitcoin Stackexchange and other places people writing how improbably it is to collide with an existing address with a balance. Some even wrote its astronomically improbable.

But if you look here you'll see that the LBC in a matter of few months has already found over 15 addresses with balance, of which one contained 0.54 BTC: LBC Trophies

Imagine once it starts harnessing more power from users?

Clearly this is a big problem. Right now a Bitcoin address with some balance is akin to a cabin in some woods with no door and a small pouch of gold waiting to be discovered.

My question is, what is the solution to this going to be?

I have a few comments which I'll consider unacceptable. I am listing them and their reasons.

Comment: Even bank account passwords can be cracked and your amount could be stolen.
Invalid: I am not talking about someone trying to specifically attack your bank account with number 123456789 with bank ABC with password wtHMcQ^KB;i9UA6ZPI,VE!r<:3xLkzDlXg.[N0{~214o*/h+(W>O@me?-J_#&|`8. I am talking about attackers randomly going through private keys and checking if they have a balance.

That's it for now.

I am going to look forward to some good solutions.

"My question is, what is the solution to this going to be?" there is no solution. it is by design that collisions can be found. i really think that people who are searching for collisions are using their computing power quite inefficient because the gains are probably very small. so mining would be more profitable.


What is the best way to monitor non-wallet addresses for new transactions The main purpose is to have "payment done" confirmation as fast as possible, within  some seconds.

First option is to implement it myself. Now I have the following implementation based on querying Bitoin-qt from .NET API:
I receive all new transaction IDs using getrawmempool and then iterate through each of them to get details using getrawtransaction to find transactions with addresses I want to monitor.

2 years ago it used to work well, but now I see it performs slower and slower.
So, I think bitcoin-qt + .NET API is not the approach which can increase monitor time.

Another option is to use third-party services, like blockchain.info, which can be used in my (commercial) application.

You can use the importaddress functionality to make the Bitcoin Core wallet (bitcoind or bitcoin-qt) treat certain addresses as its own, even though it does not have the key for them.

This will make them appear in the outputs of RPCs like listtransactions, getreceivedbyaddress, listunspent and getbalance. It will also trigger notifications through -walletnotify and the recently added ZMQ mechanism.


Unable to sendcoins using bitgo express apis Trying to access API URL: https://test.bitgo.com/api/v2/tbtc/wallet/walletid38u5348t9yj958jtv985j89g5/sendcoins

But every time getting same response:

{
    "error": "You have called a BitGo Express endpoint but this is the BitGo server. Please have a look at the BitGo Express documentation: https://www.bitgo.com/api/v2/#bitgo-express-rest-api",
    "name": "ApiError",
    "requestId": "irfo34r5541k06grtyy4j6n33",
    "context": {}
}

Is there any correction in API route? Or how can I successfully send coins using this api?

sendcoins is an endpoint that is only available on BitGo Express. BitGo Express is a proxy that runs on your own infrastructure, typically on port 3080.

Instead of calling test.bitgo.com, if you're running BitGo Express locally, try calling localhost:3080.


What miner can I use to mine litecoin with the scrypt hash function? When I run cgminer for run it to mine ltc the parameter --scrypt, cgminer says that is not recognized option. So, cgminer does not work.

What miner can I use to mine litecoin with the scrypt hash function?

You can look at this table of software scrypt miners.

You don't mention whether you intend to try to use a CPU or GPU to mine. Towards the top of the list is sgminer (for GPU mining) and Pooler's cpuminer (for CPU mining). There are other choices listed there, but a number of them are just graphical frontends or are listed as no longer maintained.


How can I trade cryptocurrency the way it meant to be fees-free, unidentified, and secure? My first post here and my first time to look for cryptocurrencies
My understanding of cryptocurrency that it is uncontrolled and no mediators and no fees for exchange
Today I registered at coinbase and it asked for my ID and veridication
and when i wanted to purchase coins I got 10% going for fees !!
How can I trade cryptocurrency the way it meant to be fees-free, unidentified, and secure?

My understanding of cryptocurrency that it is uncontrolled and no mediators and no fees for exchange

Bitcoin is a protocol for peer to peer decentralized network. BTC is the symbol for bitcoin, currency used by this network. Every bitcoin transaction involves a fee which is decided by users. Check https://mempool.observer to see what fee rate is used by others for unconfirmed transactions. This fee is an incentive for miners to include transactions in blocks and they normally prioritize transactions with higher fee rates.

Today I registered at coinbase and it asked for my ID and veridication

Coinbase is a KYC exchange.

and when i wanted to purchase coins I got 10% going for fees !!

This fees is decided by exchange and has nothing to do with Bitcoin protocol.

How can I trade cryptocurrency the way it meant to be fees-free, unidentified, and secure?

Check other exchanges that don't require KYC and allow P2P trades and use the one that works better for you:

Bisq: https://bisq.network (This may require some security deposit)
HodlHodl: https://hodlhodl.com


What is the approach to calculate an Ethereum address from a 256 bit private key? For a given private key generated by MyEtherWallet, I would like to see I have the tools to independently arrive at similar results.

Wrote a wrapper around Keccak to accept both hexadecimal and ASCII inputs to be sha3-224 or sha3-256 or  sha3-384 or sha3-512 hashed. Hashes are consistent with Test Vectors. Would like to apply it with bitcoin-explorer (bx) version3 commands to see if I can synthesize ETH addresses. If successful at synthesizing addresses for ETH, XMR, and MAX altcoins, I go through the effort of submitting a pull request to add sha3 hashing capabilities to bx version3, and update this Wiki concerning the application of bx to altcoins.

Start with the public key bytes (a bytestring of length 64)
Of that public key, take the Keccak-256 hash used ubiquitously by Ethereum (make sure you get that right, as the ultimately standardized SHA3-256 hash differs). You should now have a bytestring of length 32.
Drop the first 12 bytes. You should now have a bytestring of length 20, the Ethereum address associated with your public key.

Update: Oops! I see you want it from the private key, not the public key. That's harder. You have to first derive the public key from the private key, which is best with the help of an EC crypto library. I can show you some example code in Scala, but the EC math is mostly a black box to me. First, interpret the 256 bit private key as an unsigned big integer. Then, see e.g. here. Curve represents the named eliptic curve secp256k1. The details of the math are, alas, beyond me, but hopefully in whatever environment you are coding you have access to a high quality crypto library.

Update 2: In the comment thread, I speculated about where Ethereum's hash function diverged from the SHA3 standard. My speculation was mistaken, the version I thought was the incompatible change is the version Ethereum in fact uses. Thanks to work by Eric McCarthy, who chased this down in great detail. Please see this comment below for more details.


Get balance for an array of addresses with bitcoin core I am searching for a command to get balance for imported addresses in bitcoin (not my wallet addresses) and I don't wanna do this with blockchain explorer API's. Is it possible to do this through bitcoin core? if not, is there any alternative option like bitcore?

You can use the scantxoutset command. This will scan the utxo set and return the utxos and the total balance for the addreses that you specify. Because it scans the utxo set, you won't have the transaction history for those addresses. But it does get you the balance and a list of utxos that can be used in a new transaction.


Donation wallet address I read that wallet/account is not the same as bitcoin address. The address can be used only for single transaction. How do you receive donations on your address? Are wallet addresses unique for the network so that I can generate my wallet in one service, eg. blockchain.info, and used it in different service? How do you call the address of the wallet if not address?

I read that wallet/account is not the same as bitcoin address.

A bitcoin-wallet is only a way to store multiple private keys (corresponding to multiple bitcoin-address).

  The address can be used only for single transaction. How do you receive donations on your address?

Addresses can be used for an infinite number of transactions. If you put a donation button somewhere referring to an bitcoin-address of yours, all those donations will get paid to this one.

  Are wallet addresses unique for the network so that I can generate my wallet in one service,
  eg. blockchain.info, and used it in different service?

With a wallet (like the bitcoin-core client) you can generate new bitcoin-addresses as well as using other services like blockchain.info. Those addresses are unique and by exporting/importing the private key you can use those addresses in other services as well.


Why aren't block hashes used directly as scores for difficulty purposes? Why does Bitcoin apply a difficulty function to block hashes and then use the output of this function to add up and determine the "longest" chain?

Why not just e.g. add together all block hashes (as bigints) and consider the longest chain to be the one with the biggest or smallest sum?

Is there some mathematical reason for this or is it just a performance optimization or a way of avoiding excessive dependence on big integer arithmetic?

Background info:

The block hash must be less than a certain value (as defined by the difficulty function) in order for the block to be valid.

Generally, as time has progressed, network difficulty has increased. So as the blockheight has increased, the cutoff value for a valid blockhash has decreased.

—————

  Why not just e.g. add together all block hashes (as bigints) and consider the longest chain to be the one with the biggest or smallest sum?

I think it may be easiest to explain why this sort of implementation is broken by giving an example. Let’s consider a system following the ‘smallest sum for a given blockheight’ rule:

—————

For simplicity, let’s imagine a pow function that has an output value range of 1-100. Let’s say the network difficulty is currently set so that any output of 10 or less is valid.

Now, miner A finds a block at height X, with blockhash 10. This is valid, and so it is added to the chain.

Miner B sees this, but continues to mine blockheight X, because if they can find a block with hash 9 or less, then their new chain will replace the previously accepted one. By forcing a reorganization this way, they may be able to successfully commit a double spend attack, etc.

—————

This example shows how a miner could game the algorithm to rewrite the blockchain. The same is true for a ‘largest sum for a given blockheight’ rule: if a miner finds a small blockhash (eg. Blockhash = 5 in the example above), another miner could profit by continuing to mine on the older block, forcing a reorganization if they find a block with a larger, but still valid, blockhash.

For the bitcoin network to function properly, the game theory needs to incentivize miners to always mine at the chain tip. Using a difficulty function instead of the explicit blockhash value helps ‘level the playing field’, so to speak. This is because any valid blockhash is no better or worse than any other valid blockhash.


If i reset my block chain do i lose my btc that is unconfirmed for 2 days? Just as the title says i chose economic but it is not working. It doesnt give me the option to reselect an old wallet either

no. if you have stored your private key anywhere (where it is safe), no one can steel your bitcoin in practice.

theoretically you can write down your private key on a piece of paper. then you can loose your entire py and you can not create a transaction quickly (however your address can still receive bitcoin). but you will not loose any bitcoin if you backup your private key. because: you can (whenever you want in future on any pc/mobile phone with internet access) start to use a bitcoin-wallet-software which allows to import private keys and then you have full access to your fund again.

the fact that a transaction is not confirmed does not affect that either the sender or the receiver of funds of a transaction has access to the funds. (depending on whether the transaction is confirmed or not.)


P2SH-P2WPKH - has always segwit UTXOs? I've been reading a lot of docs on BTC transaction structure, and find it really confusing when it comes to SegWit story.
So, the very first thing is, if I've P2SH-P2WPKH address, does it mean that all outputs to this address (UTXOs) are by definition segwit UTXOs ?
In the docs (https://bitcoincore.org/en/segwit_wallet_dev/) it says:

Signature Generation and Verification for P2SH-P2WPKH
For spending of non-segwit UTXO, the signature generation algorithm is  unchanged.
For spending of P2SH-P2WPKH:

The scriptSig MUST ONLY contain a push of the redeemScript

...

So, either all UTXOs for P2SH-P2WPKH address are segwit ones, or they are SegWit if SegWit transaction was made to this address (which does little sense actually for me, as then arises chicken-egg problem).
Why they wrote this "For spending of non-segwit UTXO, the signature generation algorithm is  unchanged" part, what case it covers? If you've P2SH-P2WPKH address but you are taking some foreign UTXOs to spend(that were directed not to your address)?
Another not clear part are scripts for P2SH-P2WPKH address.
So here is my example address:
3MxYPuvEcKDdaEG1xoGyddqir6C4b66MJi
And here is transaction that was made to it:
https://blockchain.info/rawtx/6c2806587d5cdb3f0363e43f60b4a84baf37b3012fbde02f108f4eb1bdcede42
Based on it pubKeyScript of output is a914de523116b281c96ff1e204ea2ff435b75d48f0de87 which translates to:
OP_HASH160 de523116b281c96ff1e204ea2ff435b75d48f0de OP_EQUAL

So, de523116b281c96ff1e204ea2ff435b75d48f0de is hash160 of redeem script.
The only redeem script that matches this hash I've found is following:
0 389f26d8d616cb96df1cfd6d9989248a30b933b9

Which is witness v0 program script(0 sha160sha256(pubkey), so it means I've to create SegWit transactions, right?
I tried making P2SH ones and it says that I've non-nominal pushes in the redeem script, that's cause of "0" push there I believe.
I feel that doing something wrong in this part, and as a result signing either wrong thing or in a wrong way...
Very appreciate any explanations.

if I've P2SH-P2WPKH address, does it mean that all outputs to this
  address (UTXOs) are by definition segwit UTXOs ?

Yes, Bitcoin sent to a P2SH-P2WPKH address will produce a segwit UTXO.

  Why they wrote this "For spending of non-segwit UTXO, the signature
  generation algorithm is unchanged" part, what case it covers? If
  you've P2SH-P2WPKH address but you are taking some foreign UTXOs to
  spend(that were directed not to your address)?

I think you're right, it sounds like it's just saying if you want to send to a segwit address, you don't need to sign a non-segwit input any differently than before.

Spending P2SH(P2WPKH)

Here is a good reference example: BIP 141: P2SH(P2WPKH). In order to spend Bitcoin sent to your address 3MxYPuvEcKDdaEG1xoGyddqir6C4b66MJi, you have to provide the following:

witness:      <signature> <pubkey>
scriptSig:    <0 <20-byte-key-hash>>
              (0x160014{389f26d8d616cb96df1cfd6d9989248a30b933b9})

Perhaps you are forgetting the push ops 0x16 and/or 0x14 in scriptSig?


Compiling litecoin on Macosx: llvm-g++ not found I'm trying to compile litecoin on macosx 10.8.5, I have Xcode installed along with command line tools and have built all recommended dependencies (boost db48 qt4-mac openssl miniupnpc).

When I run sudo make -f makefile.osx USE_UPNP=- I get the following error:

make[1]: llvm-g++: No such file or directory
make[1]: *** [db/builder.o] Error 1
make: *** [leveldb/libleveldb.a] Error 2

Any help in this matter would be greatly appreciated, all my google searches have been in vain.

For anyone who runs into this problem, the newest version of Xcode 5.0.2 and Oct 23 version of command line tools did not install the llvm-g++ file. I rolled back to Xcode 4.5 and installed the first mountain lion command line tool release and this fixed the problem.


Difference between blockchain.info and cold storage I have a wallet on Blockchain.info, but I don't really understand how it works.

They say that they don't store my password nor have access to my funds. Does it mean that it's somehow a cold storage? I have had my coins for quite a while, so I was wondering if I could get Bitcoin Cash. However, I see that I should export my private key, but this is only possible from imported addresses.

So what is the difference between having my coins at Blockchain.info compared to having the stored on my own computer? Will it be possible to export a private key from Blockchain.info if I simply have a normal wallet at their website?

Does it mean that it's somehow a cold storage?

No. Cold storage means that the private keys for your Bitcoin are held in an offline machine and are never online. Using blockchain.info means that you are online, and the private keys are held in your browser. Furthermore, cold storage means that you have sole control of your private keys; with blockchain.info, you don't. Blockchain.info (or a malicious man-in-the-middle) can control your private keys by giving you bad javascript on the web page which steals your private keys.

  So what is the difference between having my coins at Blockchain.info compared to having the stored on my own computer?

When you store your private keys on your own devices, that means that you have full control of the private keys. That means that if you need the private keys for something like cashing out your BCH, then you are able to do so. It also means that your coins are less likely to be stolen by someone.


what is the use of OP_PUSHBYTES what is the meaning of this SCRIPTPUBKEY:

OP_DUP OP_HASH160 OP_PUSHBYTES_20 xxxxx....xxxxxxxx OP_EQUALVERIFY OP_CHECKSIG

in particular I searched for some documentation on OP_PUSHBYTES_X which only explains what exactly that instruction does but now why it is used or why it interesting.

Thanks for pointing me to any "more divulgative" resource than the bare code:)

Inside scripts sometimes you need to push an arbitrary length of bytes on top of the stack. Example: pushing public key after signature inside scriptsig. In these cases you use special operators called OP_PushDataX or OP_PushBytesX telling the interpreter that X number of bytes should be pushed to the stack. You won't find these names in any library because there isn't any. Basically we interpret any value from 0x01 to 0x4b as a OP_PushDataX operator. Remember that every operator is just a single byte starting from 0 to 255 each performing a different operation.

So in your example which is a scriptPubkey for P2PKH outputs you want to push the result of Hash160 hash of public key (which is 20 bytes) on top of the stack so you include 0x14 (=2010) before the actual bytes. And the script becomes:

OP_DUP OP_HASH160 OP_PUSHBYTES_20 [20_bytes_here] OP_EQUALVERIFY OP_CHECKSIG


QR to pay more than one address? I know that I can generate syntax for a payment qr code like so:

bitcoin:xxxaddressxxx?lable=reason&amount=0.051

this pays (to) 1 address! I however, would like to know if I can scan a QR that will construct a tx that pays to two addresses

(can I add more than one address?)

eg:

bitcoin:[xxxaddressxxx1,xxxaddressxxx2]?lable=reason&amount=[0.05,0.001]

so the addresses receive amounts relative to the array positions

As per BIP 21, Bitcoin URIs are only allowed to contain a single address.

You are free to develop your own format that supports multiple outputs, but it won't get very far unless you can convince other wallets to adopt it.