Will bitcoin core have to re-sync the whole block chain if I replace my wallet? I have an old wallet from 2013. After backing up and replacing my current wallet with the new one, will it require the client to re-sync and re-download the whole blockchain? Last time it took about a week so I'd like to avoid it.

No, it will not need to redownload the entire blockchain. It may need to rescan the blockchain, but that does not require downloading any of it and will not take as long.


Help sending bitcoin to bitcoincash wallet I've used an UPHOLD wallet to buy an AntMiner S9 from www.bitmain.com.

Bitmain provided a bitcoin cash address for payment.  However, by mistake, I sent bitcoin worth $1450 USD to their bitcoin cash wallet. Now, they have not confirmed the payment. And now I do not know what to do?  Where is my money?

Uphold gave me a BlockChain confirmation address and the transfer appears but as (not spent).  Neither bitmain.com nor Uphold has given me any reply.

I did this on Friday, November 17 and today, Monday, November 20, I have not received a response.

What should I do?  Can someone help me? I cannot afford to lose $1450 USD.

If you control both the sending (BTC) and receiving (BCC) wallets, you can recover the money by restoring the private key from the BCC wallet into a new wallet created on the BTC BlockChain.  Unfortunately, in this case it appears you have sent money to a BitCoin Cash wallet you do not control.

If you do not control the receiving address, sending a Bitcoin payment to a Bitcoin Cash address will almost certainly result in total loss of the money sent to the Bitcoin Cash address.  When you send Bitcoin, you are sending it to another address on the Bitcoin BlockChain.  There is no built-in method of sending Bitcoin to Bitcoin Cash directly; you should convert the Bitcoin into currency, then purchase Bitcoin Cash with that currency, typically through an exchange.

If you do not own the receiving wallet, the only way to get that money back would be in the highly unlikely event you sent it to an address that happens to exist in the Bitcoin BlockChain, and the person who owns that Bitcoin address decides to be nice, and send the money back to you.

As always, it pays to understand how a currency works by using a small amount of money at first.  You wouldn't give your 4 year old $1,500 to play with, would you?


Ripple - how to properly set flags? At the moment I'm trying to add flags to my custom Ripple transactions that I submit through JSON RPC. However, when I send my request:

{
   "id":1,
   "method":"sign",
   "params":[
      {
         "secret":"sxxxxxxxxxxxxxxxxxxxxx",
         "tx_json":{
            "Account":"rfESTMcbvbvCBqU1FTvGWiJP8cmUSu4GKg",
            "Amount":"31000000",
            "Destination":"rUD9V5kvnCpwN9HbZQqCwziMv3vtGgswZF",
            "Flags":2.147483648e+09,
            "LastLedgerSequence":7824714,
            "Sequence":63166,
            "TransactionType":"Payment"
         }
      }
   ]
}

I get such responses:

{
   "result":{
      "error":"invalidParams",
      "error_code":27,
      "error_message":"Field 'tx_json.Flags' has bad type.",
      "request":{
         "command":"sign",
         "secret":"sxxxxxxxxxxxxxxxxxxxxx",
         "tx_json":{
            "Account":"rfESTMcbvbvCBqU1FTvGWiJP8cmUSu4GKg",
            "Amount":"31000000",
            "Destination":"rUD9V5kvnCpwN9HbZQqCwziMv3vtGgswZF",
            "Flags":2147483648,
            "LastLedgerSequence":7824714,
            "Sequence":63166,
            "TransactionType":"Payment"
         }
      },
      "status":"error"
   }
}

Indicating that Flags is a bad type. Is it due to Flags in my request being sent in a float format (even though the response properly interprets it), or is it something else?

The error message explains the program. The Flags field has a bad type -- it must be a JSON integer.


My full node seems to be rejecting tor connections I'm running my full node with bitcoin core v0.18.1 with a mostly default configuration on debian 9.11. Port 8333 is forwarded through my router and I have 20+ node connections, so can safely assume others are able to connect, at least through ipv4. A friend was testing his tor node however, and received the following error when attempting to connect to my bitcoind's tor hidden service address: Socks5() connect to XXXXXX.onion:8333 failed: connection refused

When I run bitcoin-cli getpeerinfo I can see *.onion addresses in the list, so I presume others are able to connect through tor, is that correct? I'm using UFW and have 8333 open from all addresses, although tor connections are through localhost so UFW rules shouldn't matter. Why does my node reject the connection to my friend's node?

Here's my bitcoin.conf:

bind=0.0.0.0
onlynet=ipv4
txindex=1
listen=1
maxconnections=256
dbcache=400
upnp=0
discover=1

Turns out my node had auto-banned localhost (127.0.0.1) at some point. As a result bitcoind was rejecting all incoming connections from the tor service, including my friend's attempts. I removed the ban and he is able to connect.


if bitcoin plunges to $0 will altcoins be affected? If the value of bitcoin where to drop significantly to amost no value would altcoins be affected ?

i guess they would because usually we convert to BTC before cashing out into fiat but wanted other opinion.

Yes, for the reason you gave firstly (because most exchanges only have BTC/alt markets not alt/fiat markets), but also because Bitcoin is the first, most well known, and longest standing currency. If its value dropped to near 0, that would be a reflection of public loss of faith in cryptocurrencies in general, not just bitcoin, Bitcoin basically represents all cryptocurrencies to laypeople and its death would likely coincide with the death of all other currencies.


How to make the commission for withdrawal of Bitcoin on the exchange consistent with the miner’s fee viewed on the blockchain browser I transferred Bitcoin on the exchange and found that the fee charged for filling in is inconsistent with the miner’s fee viewed in the blockchain browser. How do I ensure consistency? Thank you!

The fee your exchange is charging you is the fee for their services, which includes the miner fee that they need to pay on your behalf.

It is normal that this number is higher than what you view on the block chain explorer.


When exactly an entry is removed or added to the UTXO's set in the Bitcoin core? I do have this implementation question and wanted to know how it's implemented specifically in the Bitcoin core.

1. When exactly an entry is added to the set of unspent transactions outputs?
Is it when a block is persisted (added to the bchain) after being validated and then all the utxo from its txs are added to the utxo set?

2. When exactly an entry is removed from the set of unspent transactions outputs?
Does the bitcoin core remove a spent utxo when validating a standalone transaction ? Or is it done on block persistence ?

3. Whats' the difference between validating  a transaction that is validated in block (case of a relayed block) and a transaction that is validated standalone (case of a relayed transaction).

When exactly an entry is added to the set of unspent transactions outputs?

  When exactly an entry is removed from the set of unspent transactions outputs?

The answer to these questions is that there is no singular set of unspent transaction outputs. There are multiple versions that are maintained and/or implied for different purposes.

1) There is the UTXO set defined by the on-disk LevelDB database. This only changes after a flush (see further).

2) There is the UTXO set defined by the in-memory cache (the pcoinsTip object). It represents the state of the network at the current best block, but does not include the effect of any unconfirmed transactions. Whenever the number of changes in this cache grows too big (see -dbcache) it gets flushed to disk.

3) There is the UTXO set defined by the memory pool. It consists of the UTXO set defined in 2, plus all outputs created by unconfirmed transactions, minus all outputs spent by unconfirmed transactions. This changes every time the mempool changes. Note that this UTXO set is nowhere materialized explicitly - it's just defined by what is in the cache (see 2) and unconfirmed transactions in the mempool.

  Whats' the difference between validating a transaction that is validated in block (case of a relayed block) and a transaction that is validated standalone (case of a relayed transaction).

From the top of my head:

Only consensus rules are validated, not policy/standardness rules
All scripts are validated in parallel (on multiple CPU cores)
The changes are flushed to pcoinsTip (and possibly to disk)


How does the miner efficiently check that an address has required amount of data? I've read this question.

As the answer said, the miner "looks up the outputs that a transaction is spending from and makes sure that no other transaction has spent those outputs already."

So the miner has to look up all the blocks form block 1 to the end, which has over 500,000 blocks (and will grow even bigger), for each transaction. And a block contains thousand of transactions. This sounds impossible to me.

"A node maintains a list of all unspent transaction outputs." This request each node to maintain billions of address and their unspent transaction outputs. Is this even possible? If yes, what about the future?

So the miner has to look up all the blocks form block 1 to the end, which has over 500,000 blocks (and will grow even bigger), for each transaction. And a block contains thousand of transactions. This sounds impossible to me.

No, it just maintains a set of all unspent outputs. For each output in each transaction in a block, an entry is added to that set. For every input, one is removed.

It doesn't need to go through the entirety of history for each input; it just looks it up in the database.

Also, this is not restricted to miners. Every node performs this operation. Miners are only kept honest by the rest of the ecosystem verifying that the blocks they produce are valid.

  "A node maintains a list of all unspent transaction outputs." This request each node to maintain billions of address and their unspent transaction outputs. Is this even possible

No, addresses aren't relevant here. The UTXO set is just a set of UTXOs. Each UTXO has an address (or more precisely a scriptPubKey or locking script), but they are identified by the transaction that created them and the position within that transaction.

Every transaction refers to actual UTXOs being spent (by listing the txid and index of the transaction that created them). They're not looked up by address.

The address (script) is only involved in determining whether a particular spend was authorized, by runni g the script with the signatures provided in the input, and checking it evaluates to True.

At the time of writing (July 2018) there are about 49 million entries in the UTXO set. For many systems the entire set easily fits in memory.

You are correct in being concerned about the future though. There are no real incentives in the system to keep this set small, and its growth is effectively unbounded.

There is research into moving to models where nodes don't actually maintain this set themselves anymore, but transactions instead contain proofs that the UTXOs being spent exist and aren't spent yet. Useful search keywords are Bram Cohen's bitset model or Peter Todd's Merkle mountain ranges.


Want to write my own solo cpu bitcoin miner I just want to understand how this mining process works (from the developers point of view from very start to end). Can someone guide me towards a doc or a open source code (I am newbie here so a VERY BASIC one)?
Thanks in advance

Tim S. pretty much covered it, but I wanted to 2 great resources which have been very helpful for myself and many others:

Ken Shirriff's blog has a few Bitcoin mining related posts which use Python code to great effectiveness; whilst Bitcoin Mining The Hard Way is probably the most useful, there's also some novel use cases where Ken tries Bitcoin mining by hand and using a 55 year old mainframe
Not specifically related to mining, but very useful in visualising related concepts is RoyalFork Blog


How should I invest $10,000 in crypto-currency? I have $10,000 which I have decided to invest in crypto-currency.

How should I go about investing this money for maximum profit? E.g. should I invest in a mining setup? Trade the currency? A combination of both?

A few investment parameters and some background on myself is provided below:

Risk sensitivity would be very high. Although I wouldn't want to be stupid with how I go about investing the money either.
I am a technically minded person (I am a mechanical and software engineer and I develop progressive web applications for a job and build computer hardware systems as a hobby).
I would be okay with constructing and maintaining rigs. Although I don't know what coins to mine but I have a basic idea on how to mine them using either ASIC hardware or graphics cards with off the shelf software.
I wouldn't say I have an investment style. I have never really invested in anything before beside putting my money in high interest bank accounts.

I'm going to assume Bitcoin since that is by far the most common cryptocurrency by mindshare for people who are new to the space.

Since you have $10k to invest, you could buy around 5 to 7 bitcoin mining rigs with a capacity of 13 to 16 tera-hashes per second each.  Investing in these mining rigs will give you about 1 year of mining time before the rigs cost more money to run than they can make.  You could make approximately $10,000 to $30,000 profit during that time assuming you have cheap electricity, and buy 5 x 15 TH/sec bitminers.  This path requires far more technical knowledge than a simple purchase of  bitcoin.  To get 5 mining rigs for $10k, you'll need to buy direct from a manufacturer.  Bitcoin mining rig manufacturers typically require a wait of 3 or 4 months until delivery.

If you buy bitcoin, you might lose the entire investment if bitcoin goes to zero; on the other hand you might make 10 times your investment if bitcoin repeats the past 12 months of performance.  If you stay invested for a longer timeframe that risk/return is extended.

There is no simple answer to your question since it depends on your technical knowledge, risk appetite, and timeline.


How to quickly get the target of the next block to be mined from bitcoin-core over RPC? The target for the next block is available in getblocktemplate but I can not figure out if there is a way to get the target without also getting all of the pending transactions, which can take a very long time and generate lots of data.
You could also use getbestblock to get the top block and then use getblockheader to get the previous 2016 blocks and then do the math based on the times, but again this is very slow and data heavy.
Is there a fast way to determine the target for the next block from bitcoin-core over RPC?

You can easly calculate that from the difficulty
So just with the RPC call getdifficulty calculate this:
target = targetmax / difficulty

Where targetmax = 26959535291011309493156476344723991336010898738574164086137773096960
target max is a fix number from the genesis block
If the hash value (Converted to decimal) is lower then this value, it's a valid Block


How to decode the block hash? I got the block hash from zmq.

00000000000000000045c639280aee532c5b12b03c80bfdec7aae674fd8246e0

I want to decode the above block hash. Could anyone tell me how to decode the above block hash?

What do you mean by "decode"?

A hash algorithm is a one-way function.

The hash-function takes some block header information (timestamp, nonce, a hash of all transactions) and returns such a hexadecimal value. There is no way to "decode" such a hash.

Its reason is just to identify a unique block (and deciding wheather someone gets the block reward or not). There are no other information stored in 00000000000000000045c639280aee532c5b12b03c80bfdec7aae674fd8246e0

But if you have the blockchain on your PC or if you enter the block hash at a block explorer, you can get information about that specific block: https://blockchain.info/block-index/1696955/00000000000000000045c639280aee532c5b12b03c80bfdec7aae674fd8246e0


Recover Wallet password (MultiBit Classic Version : 0.5.14) MAC Back in 2013 my parents bought 2 BTC, put a password on the wallet and haven't touched it sense. I am 80% sure I have the password correct, but no luck. But they were smart enough to back up all of their info, such as the wallet-backup, the key-backup, the Wallet Unenc-backup, and a rolling backup on to CDs.

I tried to move the wallet onto other platforms, but had no luck without the password. I managed to view it on blockchain, but it's labeled as "Watch Only". The only way I can get access to it is if I do QR code scan, but my private key I can get at is a string of numbers and digits in the backup files else I can somehow turn that into a QR code. So I was thinking perhaps the password can be hidden in the .key file or can be opened though the .wallet cipher in the Unenc-backup. This version of MultiBit is old so it does not have the 12 word recovery system please help.

The mbexport app will help with the wallet file in the unenc-backup folder - but that might not contain the main wallet key. If you try to open an encrypted wallet using mbexport, it will ask you for the password.

Sorry I can't be much more help. Without an unencrypted copy of the key, the password is the only way to get the key.

https://github.com/Multibit-Legacy/read-multibit-wallet-file
https://www.npmjs.com/package/mbexport


Is it possible to use the same BIP39 list of seed words to create addresses for different crypto assets? Currently, as a matter of convenience, I'm holding small about of crypto assets on various exchanges.

It's not ideal - I'd much rather store them locally, have access to the private keys, be in full control.

What worries me is that I treat any type of hardware as disposable and I'm worried I might mess up with creating 10+ different backups for each crypto asset.

(backups on Google Drive / Dropbox also don't seem attractive, although probably still better than me - these companies are in business of securely storing data and I generally trust them)

Is it possible to generate BIP39 compatible seed list and then generate private keys and addresses for each cryptocurrency out there?

In that way I'll only have to memorize 12 words and have addresses + private keys for each crypto.

Docs:

https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki

BIP 43/44 gives each coin a unique derivation root. Many wallets use this, including some multi-currency wallets.

Be careful when using multiple wallets with the same mnemonic though; the least secure wallet can cause you to lose all your coins, even coins that this wallet doesn't support.


Is there a reliable and accurate profitability calculator? I've looked at the various profitably calculator sites and honestly I'm not sure how up to date they are. They don't seem very accurate. Is there one that's better than the others?

All the calculators I have seen have been correct.

There are three typical sources of the confusion you are experiencing:

1. The calculator is NOT telling you what you will earn in the next 24 hours.

No, mining calculators cannot tell you exactly what you will earn from day to day. And they're not trying to.

If you had a dice calculator it would tell you that your average roll will be 3.5. You can roll a die 1 time, get a 6 and call bullshit because 6 is far from 3.5. But the calculator wasn't trying to tell you what your next roll will be. It cannot know the future. Neither can mining calculators.

What they are telling you is the average expected income with your hashrate mining at the given difficulty. Over the long term variance evens out, but something short like a single day has a lot of variance.

A common mistake among beginners is to try a few different mining pools for one day each and declare the one that paid the best as the most profitable pool. This is like buying one scratch ticket from three different lotteries and declaring one of the lotteries the best because you won on that ticket. This sort of thing makes absolutely no sense once you learn about variance.

2. Payouts lag behind mining work.

Another source of confusion is that pay from most pools lags behind the work you do. For example, many pools use PPLNS with shifts and pay for your work as long as your work is among the 10 latest shifts at the time when a block is found. If your work is eligible for pay (in the 10 latest shifts) for e.g. 48 hours, then it will take 48 hours before the work can no longer get paid more coins.

If you look at the pay after 2 of those 48 hours you are sure to be unhappy with how much you've been paid. This is like working a single day and then complaining to your boss that you didn't get paid, when your salary is being paid on a monthly basis. Note that 48 hours is just an example, this will vary from pool to pool.

3. Calculators don't include all the factors

This is a much smaller issue than the two others, but can still be useful to be aware of. There are many factors that affect your mining income, and most are ignored by calculators. I wrote about this here: BTC/hashes/second rates for various pools


If found a broken link on bitcoin.org - who manages the site? just a minor issue but yet:

MIT license link has moved from this:
https://opensource.org/licenses/mit-license.php

to this:
https://opensource.org/licenses/mit

Source page with the broken link:
https://bitcoin.org/en/download

Thanks!
Yosi

You can make a pull request on their official Github regarding line 400 and 963 from this file: https://github.com/bitcoin-dot-org/bitcoin.org/blob/master/_translations/en.yml

Line 400

  notelicense: "Bitcoin Core is a community-driven https://www.fsf.org/about/what-is-free-software\">free
  software project, released under the http://opensource.org/licenses/mit-license.php\">MIT
  license."

Line 963

  footer: "Released under the http://opensource.org/licenses/mit-license.php\"
  target=\"_blank\">MIT license"

Don't forget other translations as well ! :)

Otherwise, if your are not confortable with Git you can just open a new issue.


Is it possible to spend an output that hasn't yet been confirmed? From something I noticed in this thread: Unconfirmed BTC

MtGox will send a transaction to spend one of the outputs of a transaction that hasn't yet been confirmed.

Is it possible for both of the unconfirmed transactions to be in the same block (in the right order)?

Yes you can spend an unconfirmed output.
You can see this in MultiBit if you:

1) Send some bitcoin from one wallet to another.

2) In the wallet that received the bitcoin you can spend it. Because the bitcoin came from one of your previously confirmed transactions, you can trust it even though it is unconfirmed.

Of course, if you spend a transaction that is unconfirmed and it never confirms, then your child transaction will never confirm either.


What's a good way to "swipe" all funds into a secure wallet while hiding common ownership? I'd like to move all funds into a new, safe wallet. I could just send all funds to a new address in the destination wallet. That would disclose shared ownership of all source addresses, though.

How can I move all funds to new private keys while maintaining the ability to deny that those funds belong to a single owner?

I think you're looking for a "mixing" service (I've also heard it called "tumbling"). The idea is you mix your coins with those belonging to others, and send the output to new addresses in new configurations. This makes the "taint" (percentage of coins traceable back to a single address) pretty murky.

Take a look at Mixing Services on bitcoin.it. These require a level of trust, so there's a downside there.

I think the bigger question is, why do you want everything in a single address? I've found that using a deterministic wallet like Electrum makes it so that you can have lots of addresses floating around, and you spend from those as needed.

If it were me and I wanted to empty out a bunch of old addresses into a bunch of new addresses, I'd create a new Electrum deterministic wallet, and do one large transaction where the inputs are all your old addresses, and the outputs are 20 of your Electrum-generated addresses evenly distributed amounts (ie, each gets 1/20th of the amount), and then do a second large transaction with 20 new addresses each getting random amounts. The point here being to make it look like a you're mixing coins with other people, even though you're not.

I could be wrong, so you should probably wait for a better answer on here before doing this :)


Running a bitcoind docker Thanks to the bitcoin.stack community I have successfully launched a bitcoind docker with an external volume which has the block data

Currently its in 100% sync but I am facing an issue to get information using bitcoin-cli I need to run bitcoind -reindex and then add txindex=1 into bitcoin.conf

As I pulled the docker image from docker hub I do not have any control over its docker file and I have 140GB+ blockchain data that I do not wanna discard and start over

How do I run --reindex on a bitcoin docker container ?

Well if you use volume you discard nothing. Next restart will reuse your volume.


How many txid gets added to mempool per second? I am trying to get the txid using json/rpc and trying to find out how many tx_id gets added to memory pool ?

i think it comes down to how many bitcoin transaction are possible per second ?

is there any fixed number ? or maximum number ?

On a long term average the number of transactions is limited to the number of transactions that can enter the blockchain-- so roughly 7tx/s before segwit and 14tx/s after segwit activates.

But on a short term basis while the mempool fills or with transactions being replaced the rate can be as fast as your node can process transactions.  On reasonably fast hardware this can easily hit a few thousand per second.

But you won't normally see rates like this in practice unless someone attacks you or someone does something strange, especially since most nodes limit their instantaneous relay rate to a small multiple of the long term average transaction rate.  When a new node starts up it only gets newly arrived transactions, though a misguided or malicious peer to could advertise every transaction they know to you as soon as you come online in order to hit that peak rate (at least until your mempool fills).


Import wallet.dat into a new Bitcoin-Qt client I had Bitcoin-Qt on my computer with several bitcoins in my wallet, using Vista. Then my computer crashed.  Finally I was able to get my computer fixed and download a new version of Bitcoin-Qt.  Now I would like to import my original wallet.dat from the old client which was encrypted into an new version of Bitcoin-Qt.  How do I do that?

First, close the Bitcoin-Qt client.
Then you have to locate your Bitcoin folder. For Windows, it should be here:
%APPDATA%\Bitcoin
and for Linux:
~/.bitcoin
In that folder, there should be a wallet.dat file.

If you currently have no bitcoins in your wallet, you can just delete that file and replace it with your backup.
If you have some bitcoins in this wallet as well, backup that wallet file as well, or send all the coins to an address from your backed up wallet.

When you placed the other wallet.dat file in place, you should run Bitcoin-Qt with the -rescan option. Here's how to do that in Windows:

Go to C:\Program Files (x86)\Bitcoin using Windows Explorer.

In that folder, hold shift and right-click and select Open command window here (picture).

In the command prompt, type bitcoin-qt.exe -rescan and hit enter (picture).

Now Bitcoin-Qt should start and rescan the blockchain to calculate the balances of the addresses in your wallet.dat file.
(Source for pictures: cant see bitcoin after restore of backup)


How to tell how many hashes/sec the bitcoin core app on osx is running? I'm curious how many hashes per sec my cpu is able to perform, is there some way to check this?

This is a follow-up to this question.

Yes Erik, the mining feature is still built-in and you can check how many hashes your CPU can perform. Although it's pointless and you cannot earn anything, it is still a fun experiment that people like to try. If you have a bitcoin core installed and synced with the network, you can just simply open the command console and type in and enter:

setgenerate true

This will initiate your CPU and will start mining.
You can then get your hashrate by typing in

getmininginfo

Your hashrate will be shown in integer format and you should see a number like 1-3 million hashes per second.
To turn off the mining, because you will just be wasting energy type in

setgenerate false


Since which version is the mining functionality removed from the wallet? As I'm starting to learn to create a new altcoin, I found there is a remarkable difference between old and new Bitcoin/Litecoin Core wallet: old versions (0.6.9 of Litecoin) have mining functionality integrated in the wallet with a tab and a button for it while new versions (from 0.7.0.1 of Bitcoin) don't.
So my question is from which version is the mining functionality removed from the wallet? Are there any change logs/release notes/statements that tell about this change? And can someone tell me why we should separate it from the wallet?
I really want to see if I can re-integrate this functionality back to the wallet as most of my clients are low-tech and a button "Mining" will be definitely much visually easier then running bunch of lines of command in the terminal.
I guess some of you may then start to tell me to stop creating new altcoins but my clients really want to have a new bitcoin-like currency for their private business so I think you will unlikely to see it public elsewhere if you're not part of the business so never mind. :)
Any reference links or articles or kinds of help will be highly appreciated. Thank you!

Bitcoin Core removed it in version 0.13.0.  You can see the change log at https://bitcoin.org/en/release/v0.13.0:

  Removal of internal miner

  As CPU mining has been useless for a long time, the internal miner has been removed in this release, and replaced with a simpler implementation for the test framework.

For future questions like this, all change logs can be found at https://bitcoin.org/en/version-history.


Is it possible to append new blocks to a block of arbitrary age? First of all, I'm aware of 51% attacks and how they work.
Though, I was wondering, if Bitcoin and other blockchains allow appending cryptographically valid, new blocks to blocks of arbitrary age (if no age restriction is in place).

For example, could I simply append a new block to the genesis block or are there any other restrictions than just the validity of the block itself?
And if this is the case, would the "Bitcoin network" really accept a completely new blockchain starting from the genesis block, if I really managed to make a blockchain with higher difficulty, than the current chain? (Like a 99,999% attack :) )

For example, could I simply append a new block to the genesis block

Yes, you can. You can actually do this if you start your node offline and begin mining.

  or are there any other restrictions than just the validity of the block itself?

There are, but only for legacy reasons. There are a set of checkpoints where, at a specified height, the block must have a specific hash. These were added to provide a performance boost, but have the side effect of locking in the blockchain to specific blocks. The most recent checkpoint is at block 295000. So unless you are able to find blocks that have the same hash at all of the checkpoints, you actually cannot produce an entirely different blockchain and have the Bitcoin network accept it.

  And if this is the case, would the "Bitcoin network" really accept a completely new blockchain starting from the genesis block, if I really managed to make a blockchain with higher difficulty, than the current chain? (Like a 99,999% attack :) )

If you were able to produce such a blockchain and produce blocks which have the correct checkpoint block hashes (or if you forked the blockchain after the most recent checkpoint), then yes, the Bitcoin network would accept your alternative blockchain as it has more work.


Why is a cyclic subgroup chosen in ECDSA? One thing which I am wondering for a long time and to which I did not find an answer after doing a web search and hope to find an answer here.

When we construct the elliptic curve over a prime field why do we actually select a cyclic subgroup instead of taking the entire group of the elliptic curve?

On a side note the thing that confuses me most about this choice: We know that the cyclic subgroup of prime order p is isomorphic to Z/pZ and finding the isomorphism would mean solving the discrete log.

Switching to a cyclic group seems actually rather like making the problem easier in comparison to staying with the full elliptic curve.

The security of the discrete logarithm problem in a group is only as hard as that of the largest prime subgroup.

Because of this, there is no security gain from working in the larger group. However; it's worse. If you're working in the larger group you must make sure to not accidentally ending up in a (much smaller) subgroup when multiplying.


Are bitcoins really immune to inflation? I see people everywhere saying that bitcoins are immune to inflation but nobody has explained it adequately to me. I understand why bitcoins would be more or less immune to inflation cause in increased money supply - because there's a fixed money supply forever. But what about hyper-inflation caused by confidence crisis?

Any currency have worth if people are willing to accept it. And how much would a bitcoin be worth is exactly how much goods would people accept to trade for one unit of bitcoin. If for any reason people start to think that bitcoins are worthless, its buying power will diminish and you will have inflation! I don't see how this can be avoided.

Is there something I'm not seeing? Where's the catch? Why are bitcoins  immune to inflation?

Specifically, bitcoins are immune to M0/MB inflation, meaning that the money supply itself does not inflate, except at the very beginning (which we're still in) while the original 21 million BTC get distributed via the mining process. Once 21 million coins exist, they become deflationary since no new coins are issued and, as naturally occurs, money falls out of circulation as wallets are lost.

Bitcoin could still suffer the kinds of inflation most currencies see in M1/M2/M3/MZM such as fractional-reserve banking, but the idea of a publicly published block chain is that at any moment it should be trivial to audit a bank and ensure their deposits are correctly recorded. Essentially, any institution practicing fractional reserve banking should be much easier to spot and those who dislike such practices can more easily walk away from them. There are complications to this model, but that's the ideal anyway.


I sent my bitcoins from LocalBTC to a unsynced bitcoin wallet program, the bitcoins are not showing up. How do i get them back? I sent bitcoins from localbtc wallet to a unsynced program, it says 0 in the balance of the program and I really want them back.

You have two options: Either wait until your wallet has sychronized with the network – your bitcoin will show up when the block was processed that validated the transaction with which it was sent to you. The other option is that you can export the corresponding private keys to a client that doesn't store the blockchain and access it that way.


Can a blockchain be created that forgets transactions whose outputs have been spent? Is it possible for a blockchain based currency to say, after all outputs have been spent from a transaction to "delete" it from the blockchain, or at least require the nodes not to download it, what methods are there for achieving such a goal ?

The problem I see with pruning is that you still have to first download the entire blockchain from a node and then prune it. I am looking for a method which doesn't require the whole chain ever to be downloaded.

This is not possible with current blocks and transactions, although future improvements may allow us to prune some space from future blocks and transactions.

Let's think through the idea of deleting a transaction for a moment.  Let's say we have two particular transaction in the blockchain:

  Alice mines 50 bitcoins
  Alice pays Bob 50 bitcoins

Now we delete Alice's coinbase (mining) transaction:

  [PURGED]
  Alice pays Bob 50 bitcoins

Wow!  That looks like 50 bitcoins appeared out of nowhere!

What if that transaction has lots of proof of work?

Could you trust the Alice-pays-Bob transaction if it had 50,000 confirmations even though you can't see where those bitcoins came from?  Sure, that like that might be a reasonable trade off of reduced security for increased convenience.

But in order to validate future transactions, nodes don't just need to know who has bitcoins—they also need to know who doesn't have bitcoins.  For example, imagine Bob hasn't spent his 50 bitcoins, so that transaction should be part of the blockchain; yet, when you download the blockchain from Mallory's node, this is what you get:

  [PURGED]
  [PURGED]

At some point in the future, Bob goes to spend his 50 bitcoins.  Other nodes who didn't sync from Mallory know Bob has 50 bitcoins, so they accept blocks with that transaction. Your node rejects blocks with that transaction because it doesn't think Bob has 50 bitcoins, permanently forking you off of the consensus blockchain.  This is called consensus failure and it's one of the things we try really hard to avoid in Bitcoin.

Why not just keep track of amounts and purge the rest?

One way around this dilemma would be if we could split transactions into different parts:

The parts we needed to build the Unspent Transaction Output (UTXO) set that full nodes use to prove whether or not Bob has 50 bitcoins.
Everything else, such as the large public keys and signatures we use to prove Alice was authorized to spend those 50 bitcoins.

Here we encounter an additional problem with transaction pruning, a limitation of the way Nakamoto designed Transaction Identifiers (txids).  Nakamoto's design simply hashes the entire transaction and uses that to form the leaf nodes of the merkle tree whose root node gets included in the block header and secured with proof of work.

(Image from 21.co, CC-By-SA license)

Because of this design, in order to verify the UTXO-required data, you also need to download the entire transaction, including its public keys and signatures which constitute about 1/3 to 2/3 of a transaction.

This makes Nakamoto's whitepaper-style pruning in Bitcoin right now pretty much impossible.  Happily, some smart people have been working on improving the situation.

Segregated Witness

...which sounds like some weird law-enforcement term...

Blockstream's testnet sidechain, Elements Alpha, includes a nifty feature called segregated witness.  First, some background on witnesses in cryptography:

A witness is the data needed to prove some other data's validity.  This probably derives from contract law, where you often get other people to witness your signature on important documents.  In the case of Bitcoin, the witness to a particular spend being valid is the scriptPubKey of the output being spent and scriptSig of the input that references it in the spending transaction.

In Elements Alpha and the new Liquid mainnet Sidechain, the witness is "segregated" into a different part of the block and is not covered by the txid hash.  That means that nodes who want to reduce their download requirements can skip downloading witnesses for transactions with more than (say) 50,000 confirmations. However, now they can still use the block header merkle root to verify that all of the non-witness data (including the amounts transferred) are correct, and use that to build a correct UTXO set.

I can't find a source right now, but I think I've heard Wuille and Maxwell say that for typical Bitcoin mainnet transactions, this would mean about 1/3 of the transaction data doesn't have to be downloaded by nodes that don't want to validate old signatures.  On Elements Alpha where the witness is larger for transactions that use value blinding, this would mean 2/3 of the data doesn't have to be downloaded.

As a bonus, segregated witness also "completely eliminates all known forms of transaction malleability" (Wuille's description).

When will this appear in Bitcoin?

You're in luck: just a few days ago, Luke Dashjr presented an idea for how segregated witness can be soft forked onto Bitcoin mainnet.  (Previously, it had been thought that a hard fork would be necessary.)

The payer pays to a scriptPubKey that always returns true but which contains the hash of a redeem script like P2SH does:

<hash_of_redeem_script> OP_TRUE

(I just made that up; I don't know what the real construction will look like.)

When the person paid later goes to spend, they provide an empty scriptSig in the transaction itself.  This is valid to old nodes, but upgraded nodes know to look somewhere else in the block for the actual scriptSig.  The witness has been segregated.

For both old nodes and new nodes, they calculate the txid using the empty scriptSig, so the data covered by the merkle root still covers the important value amounts and references.

I don't know exactly how well this compares to the segregated witness in Elements Alpha (does that cover the scriptPubKey as well?), but it does most of the work in a convenient soft forkable construction.

Since this is week-old engineering, it may change a lot or even be found to be unworkable in the coming months, so don't expect to see it in the immediate future—but, long term, do expect to start seeing some new pre-download pruning options appear.


What is the difference between the two types of Blockchain.com wallet? Really new to cryptocurency so bear with me.
I am currently using Bockchain to store the Bitcoin. But, what is the difference between "My Bitcoin Trading wallet" and "My Bitcoin Wallet"?
Also, what software do I use to start mining coins like Bitcoin or Ether?

"Bitcoin Wallet" wallet on Blockchain.com is a "non-custodial" wallet -- this is probably what you want, and it'll let you send and receive Bitcoin to and from a wallet with a key that you own. You can import this key into other wallet software if you ever need to.
"Bitcoin Trading" wallet on Blockchain.com is a "custodial" wallet -- meaning it's a balance held on Blockchain.com, similar to a balance you might hold on any other exchange. If you want to buy or sell Bitcoin using Blockchain.com then you'll need to sign up for this, and it'll require you to upload identity verification documents.
To start mining Bitcoin you will need to purchase an ASIC. To mine Ethereum you'll need at least a recent high-end GPU, software such as Ethminer (https://github.com/ethereum-mining/ethminer/releases), and to join a mining pool.


How to do tx.addInput without tx_hash if sending from address for the first time? Iam using the bitcoinjs-lib library and trying to do a transaction. Iam doing the tx.addInput method before building but running into a build issue. I assume an error is thrown if blockchainScripthash_listunspent cannot retrieve the previous tx_hash.

If not a coinbase transaction, you have to spend from an existing output. Thus the input must reference an existing transaction.

  cannot retrieve the previous tx_hash

Maybe the library you are using is the following common semantic:

txid for the transaction id (hash without the witness data)
tx_hash for the transaction hash (hash with the witness data)

You want the txid to reference a previous transaction in an input.


Transaction history with bitcoinj I am new to bitcoinj. I want to print out the list of transactions like as follow for a wallet:

1- Sent 1 BTC to Adress1 on 'A' Time
2- Received 5 BTC from Adress2 on 'B' time
3- Sent 2 BTC to Address 3 on 'C' time

How can I do this?

Create an object of wallet app kit like:

WalletAppKit kit = new WalletAppKit(params, new File("."), "filename");
kit.startAsync();
kit.awaitRunning();
Iterable<WalletTransaction> walletTransactions = kit.wallet().getWalletTransactions();

this walletTransactions will give you all transactions related to the wallet.


How do I read the time field from the json-rpc calls from bitcoind? The JSON-RPC would return the time in this format "time": 1346289025. How exactly do I read it? I don't know what  kind of format it is. So what time is 1346289025?

It's unix time, the number of seconds since January 1, 1970. Your programming language probably has an easy standard way of converting it to a date.


Did Bitcoin founders know Bitcoin is not scalable at Base Layer? Given Bitcoin takes 45 min per Transaction, and consumes lot of energy (around 1 million Visa transactions),  https://digiconomist.net/bitcoin-energy-consumption/
This is more of a history question,
Did Bitcoin founders (Satoshi Nakamoto) know that Bitcoin would not be Scaleable?
Did they only create a Base Layer on purpose, and expect other people to create second derivative layers like Lightning Network?
Currently Bitcoin is not economic, without the key Lightning network, and certain provinces in China and other countries are attempting to shut down nodes. Lightning network has taken 10 years to release, since Bitcoin creation, and environmental politicians are starting to complain about power consumption. Just wondering if the founders, had foresight about this, and if they noted future goals for Bitcoin to work. I did not see it in their whitepaper. https://bitcoin.org/bitcoin.pdf

If you look at the announcement of bitcoin and the very first response to it, you can read James A. Donald pointing out that bitcoin (which we today call the base layer) "does not seem to scale to the required size".
Partial quote of James A. Donald's response:

We very, very much need such a system, but the way I understand your
proposal, it does not seem to scale to the required size. [...] hundreds of millions of people are doing transactions, that is a lot of
bandwidth - each must know all, or a substantial part thereof.

This response was sent more than two months before the genesis block was mined. Thus, it is fair to assume that Satoshi was well aware of the scalability concerns.


node-bitcoin express rpc I can't get the node-bitcoin rpc module running correctly in my express app... Either I get a connection refused error or I get a invalid params -32602

Here's a little code snipped from my app.js file.  Can somebody help me out on what I'm doing wrong here.  FYI, I do have port 8332 and 8333 open on nginx

/******* THIS GIVES ME INVALID PARAMS from -32602 ******/
var net = require('net');
var server = net.createServer(function(c) { //'connection' listener
console.log('server connected');
});
server.listen(8332, function() { //'listening' listener
console.log('server bound');
});

var bitcoinClient = new bitcoin.Client({
host: 'localhost',
port: 8332,
user: 'username',
pass: 'password'
});

bitcoinClient.getInfo(function(e, info){
if(e){ return console.log(e);}
});
/****************************************************************/

/******* THIS GIVES ME CONNECTION REFUSED ******/

var bitcoinClient = new bitcoin.Client({
host: 'localhost',
port: 8332,
user: 'username',
pass: 'password'
});

bitcoinClient.getInfo(function(e, info){
if(e){ return console.log(e);}
});
/****

As Murch suggested in comments, I better leave this as an answer.

What I think your problem is that you haven't configured your bitcoin.conf file. You can see all the parameters and explanation of em' thoughtfully provided by the Bitcoin wiki here. See that example bitcoin.conf? It has all the parameters commented out with the # sign. Just uncomment them by removing the hash and fill in your configuration.

To use the api you are going to need server=1 to enable api commands, rpcuser=<username> and rpcpassword=<your secure password to be able to actually connect.

Now test it

It's easy to test your Bitcoind configuration settings with a browser, just load up the address of your Bitcoind in a browser like so: http://127.0.0.1:8332. It should throw a username and password dialog if everything is correct.

Note: You will need to enable rpcallowip=<ip> to allow connections from other than your own machine. This is also really dangerous and I advise against this.


How does the Kimoto Gravity Well regulate difficulty? Maxcoin will use the Kimoto Gravity Well (KGW) to regulate the difficulty. From what I could find about the KGW, it retargets after every block and adjusts very quickly, e.g. when multipools add and retract mining power to a smaller coin's network.

Apparently, KGW = 1 + (0.7084 * (PastBlocksMass/144)^(-1.228)) (-> Introductory post by Kimoto) describes how to calculate the Kimoto Gravity Well. On another source, it was stated that "KGW is applied if the hash rate is high, and 1/KGW when the hash rate is low" (-> Post on Catcoin's adoption of KGW).

This leaves me with three questions:

What does PastBlocksMass refer to?
Does KGW only rely on the time required to find the previous block?
Why/How does the above formula produce the described fast adaptation of the difficulty?

The explanations on the web are all very vague and mystical, on purpose maybe. Here is my take in simple words, just reading the megacoin source code from the above comment.

The goal is to have a more adaptive way of adjusting the difficulty instead of just averaging the last 2016 blocks like bitcoin. This is needed because of multipools which might switch the coin they are mining, and a sudden change in hashrate  can occur (both increasing or decreasing). Especially when a multipool switches away you get stuck too long with a too high difficulty.

The algo loops backwards through the blocks, starting from the current one. The PastBlocksMass is just the number of blocks, so it starts at one and increases in each loop.

In each loop an adjustment factor is computed, which is the target block time divided by the actual block time, in a cumulative fashion, so at loop 10 we would have the 25 minutes target time divided by the time it actually took to compute the last ten blocks. When the hashrate increases, we get shorter times and an adjustment factor greater than one and vice versa.

The loop ends whenever the average adjustment factor is larger than the kimoto-value, or smaller than 1/kimoto-value. To understand this look at this python script and an example plot:

from pylab import *

one_day = 1440 / 2.5   # how many 2.5 min blocks per day

nmin = one_day / 4     # PastBlocksMin
nmax = one_day * 7     # PastBlocksMax
x = arange(nmin, nmax)   # PastBlocksMass

# start with 2.5 minute blocktime + some noise
t0 = 2.5 + randn(nmax) / 4
t1 = 2.5 + randn(nmax) / 4

# t0 has 20% more hashrate, so shorter blocktime in the beginning
t0[:one_day] = 2.5 / 1.2 + randn(one_day) / 4
# t1 has higher blocktime in the beginning
t1[:one_day] = 2.5 / 0.9 + randn(one_day) / 4

s = arange(nmax)

adjust0 = (arange(1, nmax + 1) * 2.5 ) / cumsum(t0)
adjust1 = (arange(1, nmax + 1) * 2.5 ) / cumsum(t1)

# the magic function
def kimoto(x):
    return  1 + (0.7084 * pow((double(x)/double(144)), -1.228));

plot(x/one_day, kimoto(x))
plot(x/one_day, 1/kimoto(x))
plot(s/one_day, adjust0)
plot(s/one_day, adjust1)
legend(["kimoto","1/kimoto", "20% increase in hashrate", "10% drop in hashrate"])
xlabel("days")
ylabel("adjustment factor (target/actual blocktime)")
show()

The script produces a figure like this .

It shows two constructed examples when the hashrate increases and when it drops for one day. Best is to play with different settings for a while to get a feel for what is going on.

You see that the lines cross through the Kimoto formula at some point. This is when the algo exits and uses this adjustment factor to compute a new target/difficulty. For large adjustment factors this happens earlier than for the ones closer to one. This is to have a quick adaptation if the hashrate changes a lot, and a slower one if not - then we want a longer period to get a better average. The parameters of the Kimoto formula are adjusted in such a way that one roughly adjusts in one day to a 10% change and in seven days to a 1.2% change. A minimum of 144 blocks determine the new difficulty and at most 4032 (0.25 days or 7 days for a 2.5 minute blocktime).

Summary: the Kimoto gravity well algo has a fancy name and determines the number of blocks which contribute to the evaluation of the new difficulty. It gives fewer blocks for high hashrate changes and is therefore more adaptive.


How to get Bitcoins without having a bank account? I'm an 18-year-old guy who wants to get some bitcoins but I don't have a Bank account yet.

I've been looking at some websites, such as bitstamp.net or blockchain.info but they seem like they are having problems (each one with its own problems).

What would be a fast way of converting cash into Bitcoins or cash into PayPal into bitcoins? (I don't know wich method can be used to get bitcoins, I'm really new to this.)

Read up about chargeback, this is unfortunately a huge problem when you exchange from bitcoins to 'PayPal dollars' and other online currency.

However, you can buy bitcoins with cash: https://localbitcoins.com/


SegWit. Redeem script I'm experimenting with Segwit transactions.

Is it possible to restore redeem script, if I know
1. Address (Segwit)
2. Public key
3. Private key

Thank you.

The redeem script for a P2SH-P2WPKH address is relatively simple. You take the RIPEMD160 hash of the SHA256 hash of the public key (same as P2PKH), this is known as the keyhash. The public key must be in compressed form. Then the P2SH redeem script is just OP_0 followed by a push of the keyhash. The keyhash is 20 bytes so the redeem script will always be 22 bytes long: 0014{keyhash}.


What is the difference between kH/s, MH/s, and GH/s? I started mining on a friend's computer and it shows 300 kH/s. But when I research other peoples' hash rates I usually see MH/s. Are these speeds the same as kilobytes and megabytes?

Also, when I say 300 kH/s does that mean 300,000 Hashes generated per second?

Sure:

1 kH/s is 1,000 hashes per second (sometimes mistakenly written KH/s).
1 MH/s is 1,000,000 hashes per second.
1 GH/s is 1,000,000,000 hashes per second.
1 TH/s is 1,000,000,000,000 hashes per second.
1 PH/s is 1,000,000,000,000,000 hashes per second.


Coinhive for bitcoin/ethereum I know that CPU mining wouldn't pay for electricity bill, but what if some sort of CPU miner was deployed to a website? Similarly to CoinHive with Monero. Would such mining make sense?
I started mining Monero with CoinHive on my website today.

I did a little research on slushpool's mining proxy. I wanted to deploy it on a server to be able to mine on non-supported mining tools. I had no luck with that - my shares were always REJECTED.

I'm planning to do the same research with ETH. Would such approach make sense on any other currency than Monero?

I did this, actually! In terms of disclosure, @eric allam is absolutely correct, above; you should let your users know that's going on, at a minimum, and ideally have some sort of "Start mining" button they can click to have an explicit opt-in type procedure. That said, it's wildly unlikely to generate a profit unless you have a huge base of users and are providing some sort of content (a game, streaming music, etc.) that they would want to stick around for.

I started (Let's) All Mine as a sort of experiment (to raise money for grad school) inspired by The Million Dollar Homepage, thinking that a site that is only about mining would be a curious thing users might want to be engaged with, similar to how that site was only a site of ads. I also thought it was a low bar for users to engage with, considering they can run it in the background on their browser while they're doing other stuff. The reality, though, is that I'm asking users to give up some fraction of their CPU, which, even though most users aren't using nearly all of it, is an ask. Also, it is very hard to get users to stay on a particular web page; given short attention spans and the habit of closing pages when we're done, it takes a special kind of user to stick around and mine for a while. And that's really what it takes: Coinhive's own site says with 10-20 "active users" (which I interpret to mean "users who are consistently mining 24 hours/day"), you can expect $30-40 per month. Maybe that covers your hosting and domain costs, maybe it doesn't, but you're not walking away with a whole lot. Finally, there are dedicated mining pools that reward users with some amount of currency depending on their contributions; what I'm asking for is a donation of time + resources, so it's not as palatable.

In any case, for my project in particular, it was exciting to make something in a weekend that was functional and get it out there. I've had a bunch of people stop by and mine for a minute or two, and the rare few miners that stay for a while, but I chalk it up to a learning experience. You have to get the incentives right to get users to come, and stay.


Is there a maximum size of a scriptSig/scriptPubKey? Previous research:

Transaction's maximum size
What is the maximum size of a transaction?
The maximum size of a standard transaction is 100k bytes.

Are there any consensus rules that prohibit scripts from being too large? I know each individual element of a script has to be less than 520 bytes, as shown here, but a script could still have many many individual elements and create an extremely large block.

For example, a malicious miner wants to make the blockchain as big as possible and creates a coinbase transaction with a particular output that has the OP_RETURN opcode followed by enough data to make their block just less than the 1 MB limit. Will the malicious miner's block, in which 99% of the block data is encoded into a dummy OP_RETURN output, be accepted or rejected?

10,000 bytes.  See Bitcoin Core source code: https://github.com/bitcoin/bitcoin/blob/v0.17.0/src/script/script.h#L31-L32
https://github.com/bitcoin/bitcoin/blob/v0.17.0/src/script/interpreter.cpp#L299-L300
Note that the EvalScript function only runs when someone tries to spend a script, so it doesn't apply to unspendable outputs like OP_RETURN.  In that case, the consensus rules allow you to include as much data as you want in the output up to the maximum block weight limit.  Bitcoin Core has long placed much more restrictive limits on what transactions it'll relay and mine when they contain OP_RETURN outputs, so we rarely see transactions exceeding those limits.


How can users have confidence that there are no backdoors in paper wallet generators? I'm thinking of issues like the randomization not being truly random. I appreciate that some users could examine the code themselves, but what assurances do less technically skilled users have?

There's really no way for a nontechnical user to know. In fact, most technical users do not have the specific technical knowledge required to evaluate cryptographic code (including the random number generator). Therefore, it comes down to a matter of trust. If the user does not directly trust the software author, they may sufficiently trust somebody else who has evaluated the technical aspects of the software.


Do bitcoind and bitcoin-qt resume blockchain downloading from the same place? This is a multi-part question.

I downloaded source code of bitcoin core from github and compiled it on my Windows 10. Then I got bitcoind and bitcoin-qt among other commands. I first run bitcoin-qt and choose a directory(D:\bitcoin) for blockchain data storing. However because I need to use bitcoin-cli tool and bitcoin-qt doesn't expose an RPC service by default, I close bitcoin-qt and start bitcoind.

But then I found that bitcoind didn't download blockchain from where bitcoin-qt stopped(by run bitcoin-cli -getinfo). How can I make bitcoind download that way? (I use bitcoind -datadir=D:\bitcoin to do that, is it right?)

Another question is where should I put my configure file. In my home directory(C:\Users\MyName) or just in the same data directory(D:\bitcoin)? Does bitcoind and bitcoin-qt use the same configure file?

bitcoin-qt and bitcoind are built from the same source code. They largely use the same settings, data directory, and configuration file.

However, bitcoin-qt has a set of options that are specific to it. These settings are stored in a separate Qt defined location (on Windows, it's stored in the registry). bitcoind cannot read these settings. If you set your data directory by choosing the location in the dialog box that appears the first time you started, the data directory location is stored in the Qt specific settings so bitcoind cannot read it.

You can set the data directory for bitcoind by creating a bitcoin.conf file in the default data directory location (on Windows, that's %APPDATA%/Bitcoin) and adding the line

datadir=<path>

where <path> is the path to where you want the data directory to be.

Or by adding -datadir=<path> to the command you are using to start bitcoind.

  I use bitcoind -datadir=D:\bitcoin to do that, is it right?

Yes, that is correct.

  In my home directory (C:\Users\MyName) or just in the same data directory (D:\bitcoin)?

You should put the config file in the data directory that the software will open initially. If you are setting -datadir in your startup command or the datadir is specified in your Qt settings, then you should put the config file in the data directory.

If not, you should put it in the default data directory location which is C:\Users\<username>\AppData\Roaming\Bitcoin.

  Does bitcoind and bitcoin-qt use the same configure file?

Yes.


Can Bitcoin help charitable organisations ensure payments go to the right people? One common problem when organisations, such as charities or governments, donate money to good causes is that it becomes very hard to track where the money went.

For example, there are accusations of money unintentionally being used to purchase weapons instead of providing food. Naturally, the organisations handing out the money do their best to keep track of it, mainly relying on accounting and reporting procedures, but these chains become complex and there are many ways to obfuscate the money trail.

Is there a way, even if it is not yet implemented, that Bitcoin would be able to provide a better solution than existing in this scenario?

By itself Bitcoin doesn't provide a complete solution however it could be used in conjunction with a trusted non-governmental entity to track charitable flows.  The issue is that while Bitcoin provides public and irrefutable evidence of monetary transfers it doesn't (and shouldn't) provide information on who owns those accounts.  It would require some mechanism of registering ownership of accounts similar to how an SSL cert is used to not just encrypt traffic but to also validate ownership of the site.

Using a system of cert authorities and public key encryption one could create "public and verified" addresses.  This has potential uses beyond just Charities.  The Bitcoin network itself should always remain psuedo anonymous.  It was designed to have properties of digital cash and trying to force verified identities into the network would be a mistake.

A better solution would be building a framrwork that allows entities to volentarily have their identitiy validated.  They could then be issued a digital cert which would enable them to sign an address making it public & verified.

Many businesses would benefit by linking an anonymous Bitcoin address to their real world identity to improve the trust and confidence of customers and suppliers. Remember Bitcoin is irrevocable so this present unique challenges if it were ever to become mainstream.  If a major store (Amazon for example) decided to accept bitcoin and was hacked, the attacker could replace Amazon payment address(es) with their own. Unsuspecting customers would be paying the wrong entity and would have method of reversing those fraudulent transactions. The larger the sales volume the more tempting the target.  In the Amazon example even if the attack was detected within minutes a sizeable amount of funds could be diverted.

To protect against this thread an entity could use a "public & verified" payment address.  Wallets & browsers could implement changes to warn users that an address in unverified, similar to how browsers use SSL today to provide warnings or assurances to users.


how do mining pools expose their stats? Webistes like https://miningpoolstats.stream/ must communicate with the pools somehow. What protocol do they use to retrieve information such as the pool's hashrate and what blocks have been mined by that pool? If I make my own pool what is the necessary API to expose this information?

Mining pools export this functionality via API's.

For example, poolin's API docs are here: https://btc.com/api-doc

Here's F2Pool's : https://www.f2pool.com/developer/api

And so forth.

The way aggregators add value is by compiling all this data from different pools into a neat user interface.


Where's the bug in this unsigned transaction? When I apply the JSON-RPC method decoderawtransaction to this unsigned transaction it returns {"result":null,"error":{"code":-22,"message":"TX decode failed"},"id":"t0"}:

01000000
02
0f7404441d85118286dbb8e2937fad174d76b834b91705e7fb6b42d57cbe54d3 01000000
14 23376070c7b24da64b435c71613053800494ab1c ffffffff
d6d62745bb4d15d3ef8ff1aaecef5bc7a794e77f3257516edd3ebe5ada659ae4 01000000
14 23376070c7b24da64b435c71613053800494ab1c ffffffff
02
40420f0000000000
1a 76 a9 c8a73488183dd49f63a11dea0a3b242ae70942d2 88 ac
10ae220100000000
1a 76 a9 23376070c7b24da64b435c71613053800494ab1c 88 ac
00000000
01000000

I removed the whitespace characters before sending it.

Here's the transaction in a more friendly format:

{
 :version=>1,
 :in_counter=>2,
 :inputs=>
  [
   {:previousTx=>
     "0f7404441d85118286dbb8e2937fad174d76b834b91705e7fb6b42d57cbe54d3",
    :index=>1,
    :scriptLength=>20,
    :scriptSig=>"23376070c7b24da64b435c71613053800494ab1c",
    :sequence_no=>"ffffffff"},
   {:previousTx=>
     "d6d62745bb4d15d3ef8ff1aaecef5bc7a794e77f3257516edd3ebe5ada659ae4",
    :index=>1,
    :scriptLength=>20,
    :scriptSig=>"23376070c7b24da64b435c71613053800494ab1c",
    :sequence_no=>"ffffffff"}
   ],
 :out_counter=>2,
 :outputs=>
  [
    {:value=>0.01,
    :scriptPubKey=>
     "OP_DUP OP_HASH160 c8a73488183dd49f63a11dea0a3b242ae70942d2 OP_EQUALVERIFY OP_CHECKSIG "},
   {:value=>0.1905,
    :scriptPubKey=>
     "OP_DUP OP_HASH160 23376070c7b24da64b435c71613053800494ab1c OP_EQUALVERIFY OP_CHECKSIG "}
 ],
 :lock_time=>0,
 :hash_code_type=>"01000000"}

Here is the Blockchain.info page for the sender address.

Are there any obvious errors in the friendly format? Or did I make a mistake converting it to hex?

Is there any way to make BitcoinQT provide more informative error messages?

Update: I was able successfully verify another unsigned transaction that I found here:

01000000
01
eccf7e3034189b851985d871f91384b8ee357cd47c3024736e5676eb2debb3f2
01000000
19
76a914010966776006953d5567439e5e39f86a0d273bee88ac
ffffffff
01
605af40500000000
19
76a914097072524438d003d23a2f23edb65aae1bb3e46988ac
00000000
01000000

The four bytes at the end as well as the script-sigs for the inputs are temporary data required for signing. In the working example above they are also present.

I found several bugs and now it works.

For the incoming transaction I used the public key, but I had to use the full scriptPubKey for the output I was trying to redeem. The clue for that was that my inputs were 0x14 long instead of 0x19 in the correct example.

In the output I forgot to add the length of the public key 0x14 after OP_DUP OP_HASH160 (0x76a9).

At this point BitcoinQT was able to parse the transaction and detect a newly introduced mistake I made in calculating the output size.

Later on I tried to sign and manually send the transaction using blockchain.info. This is where I uncovered another error, namely that the transaction hash needs to be little endian. In other words 0f7404...be54d3 needs to be written as d354be..04740f.

Here's the correct version (with slightly improved line breaks):

01000000
02
d354be7cd5426bfbe70517b934b8764d17ad7f93e2b8db868211851d4404740f 01000000
19
76 a9 14 23376070c7b24da64b435c71613053800494ab1c 88 ac  ffffffff
e49a65da5abe3edd6e5157327fe794a7c75befecaaf18fefd3154dbb4527d6d6 01000000
19
76 a9 14 23376070c7b24da64b435c71613053800494ab1c 88 ac  ffffffff
02
40420f0000000000
19
76 a9 14 c8a73488183dd49f63a11dea0a3b242ae70942d2 88 ac
10ae220100000000
19
76 a9 14 23376070c7b24da64b435c71613053800494ab1c 88 ac
00000000
01000000


Error in blockchain.info wallet My problem is that I can not do any transactions at all because of an error.

BitcoindException(super=com.neemre.btcdcli4j.core.BitcoindException: Error #-26: 66: mempool min fee not met, code=-26).

I set the standard (not customized) transaction fee to about $12 now, but the error still appears. What is the way out of the situation?

I'm pretty sure the problem of blockchain.info.

I'm facing the same issue and even though i've tried to set too high fee.

but it seems to be they have some issue and they will fix it soon (as usual).

They're service isn't stable at all. they get this type of issues from time to time and they fix it.


Do the channel balances get publicly announced in real-time on Lightning Network? In Lightning Network, is the balance publicly announced in real-time?

On the one hand, it should be public as it is crucial to the routing mechanism.

But, in case that the balance might reveal some private information to the network..

I didn't find the answer in the BOLT documentation.

Thanks.

Channels do not publicly announce their balance for several obvious reasons

It would be a huge privacy concern if balances could be viewed
live on the network. People could monitor large parts of the network and
aggregate data about how balances change over time, which could then
be used to trace payments through the network and deanonymize users.
If every transaction by every node required a broadcast of the new
channel balance, then bandwidth usage would become extremely large.
The network would not scale for the same reasons Bitcoin can't have
massive blocks. It would make running a node impossible on a
commodity computer and internet connection.
Broadcasting channel balance would really be quite useless because
the concept of "real-time" does not exist in a distributed network. A
node could advertize its channel balances to its peers, but before
any peer has chance to act on that data, those balances could have
changed if they route a payment for another peer. The system is in
constant change, and there is no way to atomically check a channel
balance and then send a payment over that channel. It would be a bad
idea to attempt to add such locks because there is no central
coordinator of them, and it would result in all kinds of race
conditions happening, like livelocks and deadlocks.

Channels only advertize their capacities, features, fees, minimum and maximum (optional) transaction values. There is no guarantee that a payment will route successfully even if you've provided a valid amount between the minimum and maximum with the correct fees.


Why are there regulations when buying/selling with USD I'm looking to learn about bitcoin regulations by studying the history of bitcoin. Bitcoin went from being an unknown thing to buy and sell to being heavily regulated. If I back track and look at it historically I think I'll better understand. So I have two simple questions up for open ended answer;

A. Who places and enforces the regulations between BTC and USD?

B. Compared to the gold market is bitcoin less or more regulated and why?

Every country (or other jurisdiction) can make its own laws and regulations about how Bitcoin can be exchanged for dollars (or anything else) in their jurisdiction, just like they can make their own laws about taxes, traffic, etc.  So your question as stated maybe has  hundreds of answers.

Since you mention US dollars: in the United States, my understanding is that most regulations on businesses that exchange Bitcoins come from the fact that they are considered money services businesses (MSBs).  The US Department of Treasury, through its FinCEN agency, makes and enforces regulations on MSBs, as authorized by laws created to fight money laundering.  These regulations require MSBs to do various things, such as gather personal information on their customers, report suspicious transactions to the government, and so on.

I don't know much about gold markets, so I can't really address that part of your question.  I would think that in the US, large-scale gold market participants would fall under the purview of the US Commodity Futures Trading Commission and be subject to regulations roughly analogous to those which the Securities and Exchange Commission enforces on stock traders and brokers.  My impression is that these regulations are substantially more complex than those for MSBs.  I don't think this would apply to small-scale operators like jewelry stores, but they may have other regulations to obey, perhaps imposed at the state or local level.


Understanding a Bitcoin Double Spending Transaction by Performing one on yourself Everyone talks about preventing a double spend transaction, but how does one do one to yourself in order to better understand the steps involved by the attacker?

What is required to do a double spend? Two phones running the same btc wallet?
Do you send at the same exact time?
Is it random a double spend happens when sending to multiple addresses?
How do certain online services that don't wait for the 1st confirmation stay in business? Wouldn't every attacker want to scam that no-confirmation service?
What are some preventive measures a business can use to prevent a double spend aside from waiting for 1-confirmation.

How to Double Spend

You can double spend using Electrum quite easily. Even without duplicating your wallet, be it on the same or on 2 different machines. Btw.: Duplicating wallets is super easy with Electrum.

Just go to Tools → Preferences → Transactions and check View transaction before signing.

Close the settings, go to the "Send" tab, and enter the first address you want to pay to and the amount to want to send. Click "Send ...".

A window titled "Transaction" opens. Click the button "Sign". This will require you to enter your password to sign the transaction but doesn't already send it.

Note that on my screenshots, it says that the amount sent is 0. This is because Electrum noticed that I used addresses of that same wallet. It will still actually send the transactions out and one of them will (probably) happen but it tells you that you're not sending money to someone else. If you want this to be different, create a second Electrum wallet to send the money to. Don't double spend when paying others.

After pressing the button, the transaction ID is generated, the button "Sign" disappears, and the button "Broadcast" appears. Don't already click that button.

Instead, go back to the main window and enter the second address you want to send to. Leave the amount to send the same.

Because the coin selection (if you didn't change it in the mean time, of course ;-) ) and the amount remained the same, the same UTXOs are selected when you press "Send". You can verify this by making sure the inputs are the same. Sign this transaction, too.

You now have 2 transactions spending the same UTXOs:

Then, broadcast both transactions quickly after each other.

It doesn't matter whether the addresses you send to belong to the same or a different wallet.

Alternatively, you can duplicate your wallet by simply copying your wallet file (which by default is stored in ~/.electrum/wallets or restoring the wallet (even though you still have it) with your seed. Of course, using the same wallet on a different device is possible, too.

Do Double Spends Happen by Accident?

Wallets usually try to not spend the same UTXOs twice because when you're not playing with it, it only causes trouble.

If you're using the same wallet on your PC and your smartphone, of course, it can happen that you're spending the same UTXOs twice accidentally because the device you made the first transaction on didn't broadcast it immediately or the device you made the second transaction on didn't know about the first transaction when you made the second one.

How do Online Services Accepting Unconfirmed Transactions Stay in Business?

How do restaurants which serve food without the customers having paid that food first, stay in business would be a much better question.

If you buy something online, it's usually something that's delivered to your home or at least connected to an account of yours you plan on using. You have an interest of not defrauding the people or companies providing the services you use because you don't want to be sued for not paying for what you ordered or having an account of yours closed.

In the case of restaurants, it's merely that people usually feel a moral obligation to pay for what they consumed much more than fearing to get caught because the chance of the latter happening as rather small. Restaurants can't sue you because they don't know your name or your address and they can't close an account containing stuff that's valuable to you, either.

And besides, what's with all the online services accepting payments via direct debit? How do they know that you're even the owner of that account? They don't, they just hope for it. If there is an unconfirmed transactions to the address they asked you to pay to, they at least know that the payment was authorized by the person owning the funds it uses and can't get in trouble with other people and their banks.

Detecting Double Spending

Businesses can't avoid it because they don't have power over it happening. But they can detect it. They can simply not process an order if, within relatively short period of time, a second transaction spending the same funds as the one they received first appears, and only process the order when the transaction sending sufficient funds to them has 3 confirmations. If someone tried to defraud a business, letting them wait a bit more than they usually would is only fair. If it the double spending happened by accident, the consequences aren't bad anyways so no one is really harmed significantly.


Why no other company is producing Bitcoin ASIC except bitmain? Except bitfury and 1-2 Chinese companies that looks fake or just a copy of Antminer.

Nobody in Western produces miners?

Why?

This is merely a hypothesis.

The difficulty of mining difficulty was going up so quickly that any miner you bought quickly lost its value but if the value of bitcoin also went up, you could barely come out ahead in some situations before it wasn't worth mining anymore.  Some companies started charging for their miners before they had even built them or finished designing them yet, but as they were trying to stay ahead of the increase in bitcoin difficulty, they fell behind and eventually had to give money back, got sued, etc as they didn't give people what they were ordering.

Now its easier for companies who can do that to simply mine the coins for themselves.  Why sell it to customers who will just complain they didn't come out ahead when you can just use your hardware yourself and come out way ahead since you're doing it at cost.  Now it seems that the average person who wants to take part in such things need only purchase cloud mining contracts as it works out better for the hardware makers.


How to verify if a transaction is signed correctly? Given an arbitrary signed raw transaction, how can we easily verify if all inputs are correctly signed (assuming all inputs are existent/unspent and the fee is higher than zero)? Bitcoin core's RPC command testmempoolaccept will check if all inputs are available to be spent in the mempool/blockchain so it's impossible to test transactions that have parents not yet broadcasted.
I am aware that for this kind of check, the scriptPubKeys of all inputs needs to be known and therefore only the signed raw transaction by itself is not enough for this kind of check. Still, the scriptPubKeys could be passed to the transaction instance or verify method. I was looking for some nice way to do this in python/javascript but was surprised how difficult this task is:

Peter Todd's python-bitcoinlib requires each input to be validated manually with some flags indicating the type of ScriptPubKey.
1200wd bitcoinlib, has a transaction.verify() method but it seems to only verify the basic transaction types: coinbase, P2PKH, P2SH(P2PKH), P2SH(multisig), ...
BitcoinJS has a method for this, psbt.validateSignaturesOfAllInputs() but converting a raw transaction to PSBT is not possible/easy.
Bitcore's transaction.verify() does mostly some basic sanity checks and doesn't verify the signatures.
BitcoinJ's transaction.verify() does also basic verification and the script execution, as python-bitcoinlib, has also to be done manually with verification flags.

Pubkey script alone is not enough to verify a transaction, you'll need:

Pubkey script, to evaluate the scripts
Amount, in order to check if the sum of inputs is bigger than or equal to sum of outputs
Index (in TxOut list) and tx hash of the transaction being spent
Block height so that you can set the consensus rules

After gathering all the above (should be found in the node's UTXO database) you can start evaluating if the provided script is valid which isn't limited to signature verification but running/evaluating the script that includes checking correctness of the script, OP codes, OP count, script size,...
A lot of the verification can be found in validation.cpp file.
This is also how I do it in Bitcoin.Net library.


How do nodes contribute to security when the power comes from mining and what is the chain of transaction validation? Blockchain security comes from the decentralisation of hashing power by miners. They append transactions to a block, perform PoW and add them to the blockchain when that validate blocks. How do nodes contribute to this? Doesn't all the validation power come from the longest chain, which is decided by miners. And how do miners detect an invalid block that has been added to the blockchain?
When transactions are broadcasted, I though that public key cryptography is used to verify the transaction. At what level does this happen? Do nodes do this, and if so, is it every single node? When a block is added, do miners perform steps on the block to make sure they are legit. And what does an illegitimate transaction look like?
Thanks

Miners offer up blocks to the network hoping that their offerings will be accepted. Other nodes may accept or reject such blocks. A node that accepts a block adds that block to their copy of the blockchain. Nodes that don't accept a particular block don't add it to their copy of the blockchain and don't pass on that block to anyone else. Any miner that is consistently a source of bad blocks is likely to be ignored thereafter.
Miners can't spend income from a block until a further 100 blocks have been added on top of their block. So miners have a great incentive to only offer up blocks that are acceptable to everyone.
All nodes validate blocks and the transactions in them. This consists of checking that the blocks and transactions conform to a set of common rules. These rules are often called the consensus rules. The rules protect the interests of the buyers and sellers in transactions.
Nodes will eventually be ostracized if they consistently apply different rules and attempt to pass on blocks that meet their different rules but don't meet the mainstream rules.
All nodes called "full nodes" do check hashes and perform cryptographic checks on signatures. Some nodes (Simplified Payment Verification or SPV nodes) rely on other nodes to do much of this work, but they will still perform some checking themselves.
The classic example of an illegitimate transaction is one that attempts to spend money that has already been spent in a prior transaction. A trivially illegitimate block would be one whose independently calculated hash is greater than the current target value (inverse of difficulty)


Security for bitcoin businesses with Employees Have been investigating some of the gateway apps and offline systems that are being developed. I was wondering what is the most secure way for a business to conduct itself. Let's use a bar as an example.

I would assume a strategy like this would be a start.

Owner creates a cold storage wallet with some read only addresses. I am thinking as this being the safe. (maybe even print some out so employees can easily cash out)
The bar then has an online accessible wallet.
He outfits his mobile devices running one of the online gateways or maybe even the electrum wallets.
Patron is ready to pay, the employee rings up the bill and says $xx.xx
The employee and the patron do their transactions.

Here is the question...

How often should the employee dump the coin into the cold storage safe? I would think they would need some in case they needed to reimburse a customer.

What do you guys think is the optimal way for a business of anytime, customers or not should handle their coin?

Why would you need to reimburse a customer? They should give you exact change and there's really no reason for them not to. I would recommend creating a daily cold storage wallet to receive bitcoins and then using some kind of online wallet service with a watch-only address so your employees can see the new deposits but they can't actually withdraw any of the coins.


Mining Bitcoin at 1000x Efficiency Bitcoin secures its network by forcing miners to solve a cryptographic puzzle who's difficulty increases based on the total hashing power of the network. If someone were to develop an algorithm that enables them to solve this puzzle say 1,000 times more efficiently (faster) than anyone else on the network they would be able to mine most (or a good portion) of new Bitcoin for pennies on the dollar. Assuming the person only uses his knowledge to mine Bitcoin at a much greater speed/efficiency compared to other miners (and does not hack anything or attempt to double spend etc) would the network be able to detect that something like this is happening?
I suppose not, because the hashing power of the network is not something that is known explicitly. It is something that is implicitly calculated based on the assumption that there is no possible way for a single individual to solve the cryptographic puzzle more efficiently than anyone else.
Is my assessment accurate?
Thanks

Market laws suggest that if said person would use his 1000x more efficient miner in any non-trivial scale, he would push other miners out of the market. The difficulty would steadily increase and other miners would be operating at a loss.
So I guess the answer is yes, other people would notice if such thing happened.


where do unspent outputs come from? This post asks the same question: What is an "unspent output"? but the answers for me are completely incomprehensible, probably because I lack a key piece of knowledge.

I have read every article I can find on "unspent outputs" and with each I get more confused.  e.g. these:

https://www.r3.com/blog/2017/07/18/what-is-a-utxo/

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

Lets say I have 1 BTC in a coinbase wallet or similar.

Do I have any unspent outputs yet?

If yes, who created it?

If no, how does one create an unspent output (or in what circumstance/use case are they created?

Can a single address have more than one unspent output?  If so in which circumstance?

Is there some article which explains these fundamentals in layman terms?

This one is on the general subject but doesnt mention unclaimed outputs:

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

It says this:

  An output contains instructions for sending bitcoins. Value is the
  number of Satoshi (1 BTC = 100,000,000 Satoshi) that this output will
  be worth when claimed.

What is the relationship between claimed and unspent?

Is unspent unclaimed?

How does one claim unclaimed outputs, and in what circumstance would they end up unclaimed?

You are just puzzling your self. We will start step by step.

What is Bitcoin output?

An output is an amount that was sent (via a standard transaction) to a Bitcoin address.
So when I send some bitcoins the recipient address is output address and if the recipient didn't spend the input I sent, it will be unspent output.

What is the relationship between claimed and unspent?

it's just the status of the output.

Do I have any unspent outputs yet?

No, You have one input. and the sender has "unspent output" which belongs to you.

If no, how does one create an unspent output (or in what circumstance/use case are they created?

When you make a transaction, you are creating outputs.
Unspent or claimed is whether the recipient spent the bitcoins or not.

Can a single address have more than one unspent output? If so in which circumstance?

outputs do not belong to addresses, but transactions. and a single transaction can have more than one output (e.g.) if you were sending for more than one address in same time.

Is there some article which explains these fundamentals in layman terms?

Mastering Bitcoin book.


sometimes my miners aren't detected by pools? from bitminter, and bigltc, both will often report my miners as not mining and inactive, although they are running and even generate work. the work is acknowledged by both sites but it lists the number of active workers as 0. why does this happen?

Mining pool servers and websites don't actually know your real hashrate. They try to estimate it based on how often you send in proofs of work (aka "shares"). If your hashrate is very low it won't be possible to make a good short-term estimate and it looks to the website as if you have stopped mining. That's what causes this issue.


P2PUBKEY in witness program (P2WPUBKEY) Old standard transactions format included 3 types: P2PUBKEY, P2PKH, P2SH. After Segwit soft fork, we have got 2 additional types: P2WPKH and P2WSH.

If we compare the cost of spending inputs (in bytes we write on HDD) for   P2PUBKEY, P2PKH, and P2WPKH and  we got next values:

P2PUBKEY  33 bytes public key(we do not consider uncompressed keys)  + signature 72 bytes = 105 bytes
P2PKH        20 bytes public key hash + 33 bytes public key + 72 bytes signature = 125 bytes
P2WPKH     20 bytes public key hash + 33 bytes public key + 72 bytes signature = 125 bytes

From this comparison, we can conclude that P2PUBKEY the best for reducing blockchain size. We can save about 19% of spending input size. I understand that P2PKH give more
security in case we do not reuse the address. If we reuse address, there are no advantages to use P2PKH. We can observe the quite frequent use of addresses repeatedly. For a specific range of tasks, we do not need extra security like P2PKH. Why in Segwit transaction types we don't have the ability to use P2WPUBKEY as standard transaction?  This type of transaction help to reduce blockchain size in case a user does not need/want use "no address reuse" security model? 20 bytes for each input this is a good opportunity to save the size of the blockchain.

Also, I read this thread https://bitcointalk.org/index.php?topic=6430.0, what is the reason why bitcoin core developers do not want to use public key recovery and save 33 bytes for each input?  If the concerns are related to performance, we can observe how the ethereum works and reaches about 1M tx per day (this is like 1M inputs per day in Bitcoin).

If the concerns are related to performance, we can observe how the ethereum works and reaches about 1M tx per day (this is like 1M inputs per day in Bitcoin).

Ethereum is really not a good comparison considering that it is impossible to sync a fully validating archival Ethereum node.

Regardless, the concern isn't just "performance" but rather Denial of Service attack risk. Performing pubkey recovery is much more computationally expensive than computing a hash of something. Thus there is potentially a DoS attack where an attacker creates many transactions with invalid signatures which a node then has to perform pubkey recovery on only to discard the transaction because it is invalid. By requiring a node to do a lot of computations on invalid transactions, it can be prevented from doing any verification of actual transactions thus preventing the node from actually doing its job.

With key hashes, this is less of a risk because the attacker needs to know the pubkey in order to get a node to break on the invalid signature step. Thus an attacker could not just use any output that has the same format (as you could with any output using key recovery) but has to use specific outputs which he knows the pubkeys for which limits how many of these transactions can be created.


51% attack clarification Im just reading a book on the basics of blockchain and I encountered a confusion regarding the 51% attack. If I'm right, it says that an attacker holding 51% or more of the network's computing power can rewrite the blockchain to his own favor.

What confuses me is the following: Blocks in the mainchain can only be added sequentially, hence the growth speed of the blockchain is at most the speed of the fastest miner in the network. So if a attacker is faster than the fastest miner of the rest of the network can start at some lower block (maybe even the genesis block) and add his own blocks on a new branch one after the other. Since he is faster than the official main-chain, his branch will eventually be longer than the latter and consequently become the new main-chain.

So the attacker does not need 51% of the whole computing power, only more than any other node, which is usually much less than 51%. What is wrong here?

Yes, the attacker needs to be faster than the rest of the network combined.  Being faster than the second-fastest miner is not enough.

I think this is where you are mistaken:

  Blocks in the mainchain can only be added sequentially, hence the growth speed of the blockchain is at most the speed of the fastest miner in the network

Yes, blocks are added sequentially, but I can't follow your logic as to why that means block growth only happens at the rate of the fastest miner.  If you are the fastest miner on the network, that in no way means that you are producing 100% of the blocks.  It means that you are producing the highest proportion of the total, which is still likely a minority.  Block growth still happens at a rate of the entire network collectively, regardless of who is fastest.

With that in mind, you can see why an attacker needs to produce blocks faster than the rest of the network combined.


What is a stub from the lightning grpc documentation? For example, very often in the lightning documentation for their grpc api, you will see the following boilerplate python code:

>>> import codecs, grpc, os
>>> import rpc_pb2 as ln, rpc_pb2_grpc as lnrpc
>>> macaroon = codecs.encode(open('LND_DIR/data/chain/bitcoin/simnet/admin.macaroon', 'rb').read(), 'hex')
>>> os.environ['GRPC_SSL_CIPHER_SUITES'] = 'HIGH+ECDSA'
>>> cert = open('LND_DIR/tls.cert', 'rb').read()
>>> ssl_creds = grpc.ssl_channel_credentials(cert)
>>> channel = grpc.secure_channel('localhost:10009', ssl_creds)
>>> stub = lnrpc.LightningStub(channel)

I am curious, what is an LightningStub? Looking a bit deeper into rpc_pb2_grpc, which seems to be a generated file you'll find the following ( lacking ) bit of documentation:

class LightningStub(object):
  # missing associated documentation comment in .proto file
  pass

It turns out, it is grpc nomenclature. According to the documentation at grpc.io:

  gRPC users typically call these APIs on the client side and implement
  the corresponding API on the server side.

  ...

  On the client side, the client has a local object known as stub (for
  some languages, the preferred term is client) that implements the same
  methods as the service.

Which pretty much means using grpc on the client side looks like you're interacting with an object that performs the operations locally - when in reality that object ( known as a stub ) is making calls to the server asking it to perform certain actions.


What are the parts of and how is a raw coin generation transaction made? Referencing: https://blockchain.info/tx/9b0fc92260312ce44e74ef369f5c66bbb85848f2eddd5a7a1cde251e54ccfdd5

With raw data:

  01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0704ffff001d010bffffffff0100f2052a010000004341047211a824f55b505228e4c3d5194c1fcfaa15a456abdf37f9b9d97a4040afc073dee6c89064984f03385237d92167c13e236446b417ab79a0fcae412ae3316b77ac00000000

This appears to differ greatly from a regular transaction and appears to have different parts.  What are those parts broken up and how does one acquire them?  Which part is hashed? etc..