Hacking Question: Hiring a developer to run bitcoin core to process bitcoin payments on site

If you want to accept and hold bitcoins it is trivial to generate a large number of addresses offline and feed the public addresses (not the private keys) to the web developer.  He would not have any access to the funds.  Also as suggested in the comments you could use an HD wallet and provide the XPUB key to the developer.  This would allow him to generate only the addresses that you have private keys for.

For example the electrum wallet is an HD wallet that would provide the required capabilities.


Maybe you can arrange it such that a refund always uses the TxOut of the transaction with which it came into the cold storage? Basically giving the user the same bitcoins back.

If a fork causes the funds not to go into cold storage they will not be going out either.


Can pruned nodes perform fee estimation?

Yes, if it has a mempool (no -blocksonly).
No matter the number of blocks stored, what matters is how many blocks it has been watching (ie received at the time of generation, with transactions that were part of its mempool).


What would happen if 90% of the Bitcoin miners suddenly stopped mining?

The probability of 90% of miners suddenly stopping mining bitcoin is only slightly more probable than the chance of the sun going dark this afternoon.

Anyway, supposing that 90% of the active bitcoin miners were to suddenly vanish, the first effect would be that blocks would take much more time to be confirmed (10x longer, so 100 minutes per block instead of 10 on average). The next time the difficulty is adjusted (up to 2016 blocks later), the difficulty would be reduced such that blocks again take about 10 minutes to confirm depending on the new speed of the network as a whole. The difficulty is normally adjusted so that 2016 blocks is about two weeks, but if you just lost 90% of your hashing power then the next adjustment could be up to twenty weeks later.

The last time the difficulty was 10x less than it is now was around October 2013. You can see the difficulty history here .


Entry point hardware for profitable mining

Question is what kind of coin are you going to mine. If you are going to mine Bitcoin (SHA256) you will need special hardware (ASIC 28nm min) for it to be profitable. Here you have an excellent seller, I bought my mining equipment from them, but now they sold out their next generation devices. If you want to mine this coins you will have to risk buying ahead of time, I mean you will have to buy a device that is in development and wait like 6 months for the hardware to arrive, so you will need this calculator to make a preview of what your profits will be. Actually there are many other sellers (Butterfly Labs -which I do not recommend-, Cointerra, make your own search in google, but KNC for me is the most trusted one). Here you have a comparison of mining devices for Bitcoin.

If you plan to mine Litecoin (Scrypt) you will be able to do that with GPUs, you have a mining hardware comparison here.

You will first need to decide which coin are you going to mine and what kind of ecryption are you going to be solving (SHA256, Scrypt). You will need to consider what kind of risk you want to take, for instance, if you mine Bitcoins you know it is the safest bet with an actual price of 803$ and having reached 1150$ per coin it is cryptocoin that is being accepted in stores right now therefore it has a possible great future. On the other hand, mining this coin has become difficult and a considerable investment and risk is needed to aquire the hardware needed.

On the other hand, if you choose a coin which has recently started, it will be easier to mine those coins, but it won't be profitable (if you think that coin could gain value in the future then it may end being profitable, who knows).

Finally it is up to you to read and choose where you want to enter and what amount of money you want to risk.


How do I generate offline transactions in Java?

That depends on how the Overlay Network will be handling the transactions. It might follow the standard protocol, or develop its own. In any case, as the ON is still in proposal stage, everything can change still. Best advise is to follow the forum thread and the Google Doc and see where it settles at.


Bitcoin Core software on 2 hard drives with one Wallet

You should be able to download/install the software on your safe drive, and then specify as needed the locations of the wallet/data directory using the --datadir option (this should point to the repository containing the blocks directory as well as the wallet.dat file).


What is Blockchains 12 word recovery passphrase process

You secret key is a set of 256 random ones and zeros (bits). This is very difficult to remember. So, we need to represent those ones and zeros differently.

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

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


First of all, nothing is encrypted in Bitcoin, there is no "encryption" involved whatsoever. Cryptography: yes, but encryption: no.

The main aspect of private vs public key signing, is dat you can openly share your public key (that's what bitcoin balances are associated with), and then using your private key you can create a "digital signature" for a transaction spending coins from that public key. Other people can verify if this signature is correct, thus knowing that the transaction was signed by the one holding the private key. But here's the catch: this verification can be done without having the private key.

So essentially, the digital signature algorithm allows you to prove that you have the private key that corresponds to a certain public key, without sharing the actual private key.

And, obviously, neither is there a feasible way to reconstruct the private key from a given public key and a valid signature.

This is called ECDSA or "elliptic curve digital signature algorithm", because the inner workings are based on elliptic curves.

How this all works technically is somewhat complicated, there's some fancy maths involved. If you want to get into the dirty details, here's a good explanation: http://kakaroto.homelinux.net/2012/01/how-the-ecdsa-algorithm-works/


Is there any difference in pool mining with gash.io over slush?

Slush has a 2% fee, and GHash.IO has no fee. So that's a 2% difference for starters. There would be no difference in GH/s, because that solely depends on your hardware and tweaks. There is a difference of paying between the two, Slush uses Score, and GHash.IO uses PPLNS. An explanation from these two from here. You can choose whichever you like.

Score - Score based system: a proportional reward, but weighed by time submitted. Each submitted share is worth more in the function of time t since start of current round. For each share score is updated by: score += exp(t/C). This makes later shares worth much more than earlier shares, thus the miner's score quickly diminishes when they stop mining on the pool. Rewards are calculated proportionally to scores (and not to shares). (at slush's pool C=300 seconds, and every hour scores are normalized)
PPLNS - Pay Per Last N Shares. Similar to proportional, but instead of looking at the number of shares in the round, instead looks at the last N shares, regardless of round boundaries.

According to blockchain GHash.IO indeed has ±36% hashing power. But someone digged into the 'other' sources, and saw that some blocks came from IP-addresses owned by GHash.IO, but it doesn't mean that the block is indeed mined by GHash.IO. I think it is nothing to worry about for now, but GHash.IO shouldn't keep 51% of the hashrate for longer time. Then it indeed isn't decentralised, and the coin is vulnerable for a 51% attack.
I don't know how the CEX.IO works precisely, but you're right about the part the a certain amount of GH/s will return less BTC as the difficulty goes up. But as long as they upgrade the hardware, and get new equipment with a better GH/s/W ratio, it should still be profitable. If it isn't for a big company like them, it certainly isn't for individuals. They will stop, which makes the difficulty not increasing as much, and therefor new equipment will be more rewarding. If you mean that the GH/s you bought isn't worth it, you are right too. As the difficulty rises, the rewarded BTC is going down.


How to generate an output address from output scrips which start with 0x00?

It's a native segwit output. 0x00 signifies the segwit version (which is v0 in this case), 0x14 is the bytes to push and 2f82e61a98eb7027672760c691784d5fbccf7ce3 is the hash160 of the public key. Native segwit addresses uses bech32 encoding as defined in BIP 173 and begin with bc1. Use this for reference implementations in various programming languages. The address associated with the locking script is thus bc1q97pwvx5cadczwee8vrrfz7zdt77v7l8re20cz4


First: to get transactions from all accounts, use the "*" wildcard.

Second: Bitcoin version 0.5 includes a new listsinceblock RPC command that makes polling for new transactions more efficient.

I wrote a monitorreceived patch that does an HTTP POST whenever a new block or transaction-to-or-from-your-wallet was received, but I haven't pulled it into mainline bitcoin because it would make it VERY easy for websites to do the wrong thing and treat 0-confirmation transactions as "paid" and because it isn't clear what (if anything) to do when block chain re-organizations happen or transactions are orphaned (double-spent).


If I were to generate an address and it happens to collide, legally speaking, would a transfer constitute theft?

IANAL.

What you describe is the act of taking something that isn't yours in full knowledge that somebody else invested effort and money to accumulate it.

Just as with your Swiss bank example: The rightful owner would be losing the funds that you misappropriated. Taking someone's property without their consent is theft.

I feel that this is independent of the way by which you gained access to the property, but rather derived from the intent of your action.

Perhaps more ambiguous would be scenarios where somebody receives a transaction to a key that you also control, or when you stumble on a key that has a Bitcoin balance that hasn't been moved for decades and could reasonably assumed to have been lost by the rightful owner.


Can Large Bitcoin Collider break into the wallet which is created by new version of Electrum?

LBC exhaustively searches a relatively small area in the 256 bit private key space. It's not a general wallet cracker, broken or otherwise; rather, it will find a private key that is known to be in the vicinity of its searches. One example that sits in the blockchain is the so-called puzzle transaction, which was created to deliberately reward people who manage to crack successively more "difficult" keys. It may also discover some keys which were created in error - say, by a program (over)writing 32 random bits in the same memory location 8 times, instead of writing 32 random bits into 8 sequential locations - but it's not a general purpose wallet cracker.

I'm unsure if LBC is still in operation, but there have been subsequent keys in the puzzle transaction cracked, the most recent one (as I type this) in March 2019: https://www.blockchain.com/btc/tx/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15

You can read more about the puzzle transaction here, including posts by the person that created it: https://bitcointalk.org/index.php?topic=1306983.0


What do the mining workers do differently then if they would be mining
  solo?

A miner that is mining within a third-party pool doesn't need the entire block chain. In fact it doesn't need to be connected to any peers of the Bitcoin network. These miners work entirely outside of the network and could technically just need to communicate to the administrator of the pool in order to mine.

The admin of the pool, on the other hand, needs to be exposed to the Bitcoin network and needs to listen for new blocks and validate transactions. The admin of a pool is a full Bitcoin node as described in Satoshi's paper.

  How does it work under the hood? What does the mining pool server do
  in terms of computation?

What happens behind the hood is that the pool admin uses the combination of the miners computation, within her pool, as sort of an extension to her computational power. To do this there's specific software installed on the admin's server that takes care of making sure each miner is doing the work requested.

During a 10 minute block cycle, since most miners within a pool won't actually solve the block (only 1 miner on average will), the admin needs to make sure that miners are actually working on the problem.

To do this the miners solve a reduced difficulty hash, but one that could have also solved the actual hash, so it proves to the administrator they're actually working on the problem.


Curious about a network-based double-spending attack

That sort of attack sounds definitely doable. But it's important to take into consideration the cost of this type of attack versus the cost of the thing that you're actually stealing (double-spending):

If you're buying something expensive, the vendor will most likely
require you to wait at least 2-3 confirmations, defeating the
possibility for this type of attack.
If you're buying something inexpensive, the vendor could probably accept unconfirmed transactions, opening the possibility for a double-spending attack. But as an attacker, it'll probably cost you more to pull off this kind of stunt than actually buying the thing.

In conclusion, this type of attack can probably be successful, but the costs outweigh the benefits.


Backing up Bitcoin using only private keys?

It depends on what kind of wallet you have.

Traditionally each private key was generated randomly by your wallet software. In this case every private key needs to be backed up.

Recently deterministic wallets have become popular. Deterministic wallets randomly generate a seed, and then use that seed to deterministically derive the private keys in a cryptographically secure way.

To answer your questions specifically:

It depends on whether you use a deterministic wallet. Traditional method: If you make multiple transactions, new keys are periodically generated and these need to be backed up too. Deterministic wallet: backing up only the seed is sufficient.
Also depends on wallet. Traditional: back up every key. Deterministic: just backup the seed.
Yes. Private key ownership = ownership of the bitcoin held at the addresses derived from those keys. If you don't have the key, you can't spend the bitcoin.

In Bitcoin Core, both kinds of wallet can be sufficiently backed up by backing up your wallet.dat file. There is an HD (Hierarchical Deterministic) symbol in the bottom right that is greyed out and crossed out if you do not have a deterministic wallet.

Since you want to backup on paper, maybe Bitcoin Core is not the best solution for you. You could try using a wallet that implements BIP 39 (there is a list of them on the deterministic wallet article), which derives the seed from a human-readable list of words. In this case, writing down the seed words is a sufficient backup.


In the interests of keeping people's power bills low, I'd recommend not bothering to write anything that uses CPU mining as the bitcoins earned will not even come close to recovering the cost of the electricity.

If you can get it working with ATI graphics cards though, it would be quite a neat idea. It would also be a good way for charitable organisations to earn donations without people needing to put in their credit card details. Eg a donate-to-wikileaks screensaver.

However, there are also ethical issues to consider - not only does mining have a substantial electricity cost (where I live, it can be as high as $45 a month with my 5850 card), it also has a substantial effect of shortening the life of the hardware doing the processing. The average Joe Bloggs should really be made aware of those issues before they install & run mining software.


Is there a blockexplorer with a websocket API that includes relay IP address?

It looks like a blockchain.info API bug.

https://blockchain.info/rawtx/315d3cf722b73a2ad434dc3dba108bfb5ccdb13ea324bfa4d6e17ca3e741ad1f

"relayed_by":"0.0.0.0",

https://api.blockcypher.com/v1/btc/main/txs/315d3cf722b73a2ad434dc3dba108bfb5ccdb13ea324bfa4d6e17ca3e741ad1f?limit=50&includeHex=true

"relayed_by": "213.239.196.9:8333",

Note: I have no association with either API, but I have used Blockchain.info before, and know it can be buggy.

Also, relayed_by: 127.0.0.1 means that blockchain.info relayed it themselves.


Can I retrieve my bitcoins from years ago that I never received?

If you still have the wallet.dat file and your password you can access your bitcoins. You do not have to use Bitcoin-Qt 7 and it does not matter if your wallet ever synced before. If the sender sent the bitcoins to an address you control and the transaction was confirmed, the bitcoin are yours.

https://blockchain.info/wallet/import-wallet

If you want to use a new version of Bitcoin-Qt you can do that too: See Import wallet.dat into a new Bitcoin-Qt client


Litecoin has had SegWit for one month, what impact did that have?

Litecoin was not facing the same transaction volume pressure as Bitcoin (due to 4x faster confirmation times and lower relative volumes), so while the segwit lockin did raise the effective block size to 3.3~ MB, this didn't have much practical impact since the blocks weren't hitting that ceiling yet.

However, it did enable a lot of lightning network projects to start running on a realnet, and put a lot of concerns about the reliability of segwit to bed.


Why every node needs to validate a transaction in Bitcoin

I think your confusion comes from a slight misunderstanding of the reason a node validates all transactions/blocks.

This validation is done so that the user running the node can join the network and verify the current state without needing to trust anyone else in order to do so. Importantly, it allows sovereignty, you do not need someone else’s permission in order to join or participate in the network.

Each node doesn’t really care if other nodes validate transactions, it just does it’s own thing and provides the user with the ability to interact with the network trustlessly. Of course, the user is benefited by joining a widely utilized network (network effects, etc), but ultimately it is in the users interest to determine the network state themselves, so that someone else can not lie to them, disallow them participation, etc.

In some sense, if you need to trust someone, then why use a blockchain at all? There are much more efficient technologies and networks that could be built, that could take advantage of efficiency gains through centralization (though through a loss of sovereignty - and it is this trade-off that makes the inefficiencies of Bitcoin worthwhile).


Race Attack vs. Double-Spending Attack: are they same?

It's the other way around. The race attack is a specific type of doublespend attempt. It requires the recipient to accept unconfirmed transactions as payment.

The attacker supplies an unconfirmed transaction to the victim that pays the victim. Meanwhile, they broadcast a conflicting transaction to the network. As the merchant saw their own transaction first, they are under the illusion of getting paid, while the rest of the network predominantly saw the doublespend first and thus it's likely the merchant will in fact not get paid.

This attack is much easier to pull off, when the attacker has a direct connection to the victim's node, and perhaps deposits the conflicting transaction directly to miners.

It is therefore recommended to turn off incoming connections to nodes used to receive payments, so that your node will seek their own peers, and not to allow the payer to directly submit the payment to the payee.

The Sybil attack takes this information asymmetry even further as the attacker isolates the victim from the network and restricts their access to information while doublespending them. Other doublespend attacks rely on having premined a transaction to yourself in a block kept secret before paying a victim with a conflicting transaction (Finney attack), or on having overwhelming hashrate (majority attack).


How do I do a manual replace-by-fee in Bitcoin Core?

Simply send a new transaction with a higher fee. A miner will more likely include it in a block if the fee is higher.


How can I get the raw tx hex from bitcoind with the txid?

You can enable the transaction index by using setting txindex=1 in your bitcoin.conf file or starting bitcoind with the -txindex option. This option will allow you to use the getrawtransaction command on any transaction in the Bitcoin blockchain or in the node's mempool.

Note that setting this option will require you to reindex bitcoind if it was not already enabled.


In addition to what Mikko said, there have been some recent stress tests on the bitcoin network in which a flood of low-fee transactions have been pushed through the system. When the blocksize becomes full (currently 1MB per block, though that is configurable [can be smaller, but not larger] by each miner) it is likely that the miners will take the transactions with the highest fees. Since you are talking about a 0 fee transaction, yours would probably be left behind until the more expensive transactions are processed.

Think of it like a train in which you can pay what you want to ride (and can also pay 0). If there are a bunch of people waving dollar bills around when the train pulls up, the conductor will let them on first. Your cheapness will mean you wait for the next train... unless the same thing happens again (and it might!).

In the recent tests, some transactions took up to 8 hours to get their first confirmation. This may change in the future, assuming the blockchain max size gets adjusted (there is a big debate on what to do next going on right now in the bitcoin circles).


Where can I get bitcoin customer support? Is there a support number?

Bitcoin is not a business, it is a decentralized computer network, where no one person or organization is in charge. Thus there is no customer support number for bitcoin, like you may be used to with your bank, credit card, etc.

Note that even though bitcoin itself is not run by a business, there are businesses that operate within the bitcoin ecosystem. For customer support regarding those businesses, you'll need to contact them directly.

But for general bitcoin questions, you're in the right place to ask for support regarding your problems. Just like bitcoin is a decentralized cryptocurrency where no particular person is in charge, its 'support team' is also decentralized and scattered across the world. I put 'support team' in quotations because the participants of this Stack Exchange site are not employees of bitcoin or Stack Exchange, instead, they are here of their own accord, volunteering their time and knowledge to help others. There are many users here with a great knowledge regarding cryptocurrencies, so if you ask a good question, you will likely receive a great reply.

You could elaborate on your problem a bit for a better response.

Where did you do the transaction?
Did you pay the miner fees?
Did your wallet software give any response?
Were you trading/transacting on an exchange?
The transaction id (TXID)
Did your transaction make it to the memory pool (mempool)?

I see that you're new to StackExchange.

Please edit your question for some significant help.


How to get the addr from this transaction

482f0027662731277fdfa3b7f639c976a3bab11e is HASH160 (RIPEMD160(SHA256())) of the public key. The hash is the most important part of addresses (addres: network byte + hash + checksum).

You can look at how P2PKH script works step-by-step here.


LND Security best practices? Disaster recovery?

You can secure an LND node in the same way how you would secure any host on the internet. You can for example use ufw to set up a firewall. You could also have a physical firewall in front of you node. Also a big step towards security would be to run no other software on the node.

As for backups it is a little bit more tricky. The seedwords will not include the state of all of your channels. With the current channel design you cannot restore an old backup. As an old channel state would - following the protocol - allow your channel partners to claim all bitcoins in that channel. However you can use a distributed file system or a distributed data base to store your channel state. If configured properly writing to the file system or database will certainly be slower as all calls have to be synchronized and blocking.
Also you could at least have a raid system that helps if a disk crashes.

Generally you can shutdown your lightning node and migrate it to another computer by copying the database. As mentioned again it is tricky as you really have to make sure that you don't migrate old state. I have a video showing this for c-lightning. The process for lnd should be similar.


Can I remove the initial bitcoin folder after installing its binaries to /usr/local/bin?

Yes, after you've checked if bitcoin is properly "installed" by checking its version you can remove the ~/Downloads/bitcoin-0.20.1. Be sure to double-check the processes and be careful before putting funds in without backup.


What is "fed-peg" and "predefined functionaries" with sidechains?

I have no idea what that means. What is "fed-peg"? Why is that needed?

When you're creating a sidechain, you need a way to move Bitcoins from the main network to your sidechain. This is pretty straightforward. Counterparty, Ethereum, and NXT had various ways of doing this. (Admittedly, none of these allowed people to turn Bitcoin into the assets on these networks after they started, but I suspect that's due to economic reasons rather than technical ones.)

The more complicated, and more important issue, is how you move Bitcoins that are on the sidechain back into the main network. I've heard multiple proposals on how to do this, but all of them are either

insecure,
centralized,
or require very complicated changes to the Bitcoin protocol.

This approach is centralized.

The idea with that you have several authorities, each of whom has a private key. Those private keys together control a multisignature account. When you move Bitcoins onto the sidechain, you deposit them into the multisignature account. When you want to move them back to the main chain, you do so on the sidechain; those federated authorities will independently validate that transaction. Then, all of them sign a withdrawal from the multisignature account to the main network address you specified in your sidechain transaction.

The blockstream paper suggests a 3 of 5 multisignature account. The issue with this is that if 3 of those keys are compromised (or if 3 of them collude) then they can take all of the money out of the multisignature account.

  Does it change in any way the security of the main chain?

No. It doesn't modify the main network. Future incarnations might, though. There's not enough detail about those possible future systems to answer that at present.

  How does it differ from decentralized PoW?

The federated authorities have two roles in this system: gating transactions into the system by producing timestamped blocks, (something normally done by miners) and the previously mentioned multisignature account.


As an example of how to build a block header, here's a short Python program that calculates this block header's hash:

#!/usr/bin/env python3
import urllib.request
import json
import binascii
import struct
import hashlib
ux = binascii.unhexlify
hx = lambda bin: binascii.hexlify(bin).decode('ascii')

# Load testing data in json format from blockchain.info
url = "https://blockchain.info/block-index/1114939/000000000000000003e6d3647001d1f455d585cdd3c298093902fe52ea4529ba?format=json"
block = json.loads(urllib.request.urlopen(url).read().decode('ascii'))
print("Original block hash: " + block["hash"])

version = block["ver"]
# 4 bytes, little endian
version = struct.pack("<I", version)

print("Version: " + hx(version))

prev_block = block["prev_block"]
# Reverse hash to go from display format to internal format
prev_block = ux(prev_block)[::-1]

print("prev_block: " + hx(prev_block))

merkle_root = block["mrkl_root"]
# Reverse hash to go from display format to internal format
merkle_root = ux(merkle_root)[::-1]

print("Merkle root: " + hx(merkle_root))

timestamp = block["time"]
# 4 bytes, little endian
timestamp = struct.pack("<I", timestamp)

print("Timestamp: " + hx(timestamp))

target = block["bits"]
# 4 bytes, little endian
target = struct.pack("<I", target)

print("Encoded target: ", hx(target))

nonce = block["nonce"]
# 4 bytes, little endian
nonce = struct.pack("<I", nonce)

print("Nonce: ", hx(nonce))

combined = version + prev_block + merkle_root + timestamp + target + nonce

print("Block header: " + hx(combined))

sha256 = lambda x: hashlib.sha256(x).digest()
sha256d = lambda x: sha256(sha256(x))
computed_hash = sha256d(combined)

# Reverse hash to go from internal format to display format
computed_hash = computed_hash[::-1]

print("computed_hash: " + hx(computed_hash))

Here's the output.

Original block hash: 000000000000000003e6d3647001d1f455d585cdd3c298093902fe52ea4529ba
Version: 01000030
prev_block: cd0594ebccfe15b205125165cc3b66986ed5b2a311cd88050000000000000000
Merkle root: 37022f7a3b9a2b199d53fbf1552be32c141892319966c3ef999d348d74cfb582
Timestamp: 7f476357
Encoded target:  a09b0518
Nonce:  ae5ae1c1
Block header: 01000030cd0594ebccfe15b205125165cc3b66986ed5b2a311cd8805000000000000000037022f7a3b9a2b199d53fbf1552be32c141892319966c3ef999d348d74cfb5827f476357a09b0518ae5ae1c1
computed_hash: 000000000000000003e6d3647001d1f455d585cdd3c298093902fe52ea4529ba


How do you load the Android bitcoin backup key onto Bitcoin Qt?

The backup file produced by the Android Bitcoin app is a text file containing lines of the form

5Jhvcnoi9LFxEcg68gTaDB3DiKEJ6TWJuMmyfjv89uEv3AbgdV 2013-01-01T12:34:56Z

The first field is the private key.  This can be imported into bitcoin-qt using the importprivkey command.  Choose "Help > Debug window", go to the "Console" tab, and enter:

importprivkey 5Jhvcnoi9LFxEcg68gTaDB3DiKEJ6TWJuMmyfjv89uEv3AbgdV

where you paste in the private key from the file.  bitcoin-qt will be unresponsive for several minutes while it searches the blockchain for existing transactions involving the new address; this is normal.


How can I brute force guess the passphrase for a Bitcoin Wallet (Andreas Schildbach) backup file?

the chance is very low. unless you have clues. brute force is not a way to get back your password. the time cost is very high. if you have many btc in the wallet. then you can try it. but the chance is too low.


Introduction

The key to finding out where a piece of code is without already knowing where it is is to start at the thing that will eventually lead to what you want to find. These can be logically thought through. For example, for relay and validation, these all occur after a node has received a block or transaction, so begin at the point where a block or transaction is received.

There are generally three kinds of actions that Bitcoin Core does: validation and relay of blocks and transactions, the wallet, and startup

Validation and relay

In order for Bitcoin Core to be able to validate and relay a block or transaction, it has to first receive it. So logically the place to begin looking is at the point where a block or transaction has been received and it is beginning to be processed. That is in ProcessMessages function in src/net_processing.cpp. Within this function, there are several if statements for each type of network message that can be received.

For transactions, you want to look at the if block for NetMsgType::TX. By reading through the code in this if block and following the functions that are called, you will eventually reach where a transaction is verified, added to the mempool, and relayed. The most important function within this block is AcceptToMemoryPool and that is where all of the validation for an unconfirmed transaction is done.

For blocks, you want to look at the if block for NetMsgType::BLOCK. Reading through this code will lead you to ProcessNewBlock and later ActivateBestChain and ConnectTip which are the functions that contain the validation of blocks.

The wallet

Almost all of the wallet's functionality is centered around the creation and receiving of transactions. These logically begin when the user wants to send Bitcoin. So a good starting place is the sendtoaddress RPC. Following this function will take you to CreateTransaction and later SelectCoins which are responsible for transaction creation and coin selection.

Some other things that are interesting in the wallet would include wallet creation and loading which occurs in CreateWalletFromFile and wallet encryption and unlocking which have good starting points of the encryptwallet RPC and walletpassphrase RPC

Startup and initialization

Lastly some interesting occur during startup such as DNS seeding, connecting to nodes, loading the blockchain from disk, etc. The obvious and actual starting point is the main function. The main function is the entry point for pretty much every C/C++ program so it's a good place to look at for startup. Following the main function will bring you to AppInitMain which is where the bulk of loading and initialization occurs.


What info do I need in a form where people can pay/donate with Bitcoin?

This model fundamentally won't work.

In the case of a credit card transaction, the funds are actually held by a third party: the customer's bank.  You collect information from the customer (their card number, etc) and present it to the bank (via the Visa network or similar), to convince them that their customer has authorized the transaction.  The bank then transfers the funds to you.

With Bitcoin, it is very different.  The funds are held by the customer herself.  There is nobody who can perform the transfer except her (that's what keeps her funds secure!).  You cannot do it unilaterally on her behalf, and there is no bank holding the funds who can do it.

Strictly speaking, the "necessary information" to execute a transfer is the customer's private key.  But the customer is the only one who has it, and she is not going to share it with you (don't even ask).  So she has to execute the transfer herself.

The only way to collect a payment via Bitcoin is to give an address to the customer and wait for her to make a transfer to that address, signed with her own private key via her own wallet software.  You can have a third-party processor like Coinbase handle that for you, but it doesn't change the fact that the customer actually has to do something besides giving you information.


Can i convert BAR ( Tidex ) to XRP ( Binance ) ?

So you want to;

Sell your BAR into another currency?
Send the new currency from Tidex to Binance?
Enter a new currency that is not BAR?

It will be easiest to sell BAR for ETH or BTC, since these make the biggest markets on Binance. Then send to Binance as you have the choice to buy many different coins from there.

What currency do you want to enter into after you have sold BAR?


Blockchain.info wallet payload strange format

there is an extra script in btcrecover that allows you to pull the wallet file but you will need to be able to authorize access through your email. I ran the extraction file with a test wallet and then used that wallet file with a token list which to discover the password successfully.

Since then I have extracted the another wallet where I actually lost the password but I am stuck at the brute force phase. my token lists are not finding the password.... :-/


I try to make it short (as this question spreads a wide range...): bitcoin or blockchain do not protect against malware. At the end, bitcoin can be considered as the software that runs a wallet on your computer/mobile. And blockchain is a public accessible data structure. We can forget about blockchain, cause this data structure doesn't help at all to protect against malware.
So for the wallet: this is a set of data on your harddrive, that contains (somehow) the priv key. As long as your operating system permits access to the storage area of your harddrive, it depends on the protection layer of the OS, how to secure this. Windows has a very long and very strong record of insecurities at all layers (any vulnerability you can think of), and the amount of "protection software" shows clearly, that this is not the optimal operating system for storing value(s). I am not strong enough an expert for mobile devices... When it comes to Unix type OS, the world looks far better, and there are less attack vectors, due to the segregation of duties in the system. Still there are possibilities to "steal" your data, e.g. when you install a (probably unverified) software as admin on your system.
Generally this OS protection topic should be further discussed in the information security area, not here. As long as you store only little value (like you would have Euros or Dollars or Pounds in your real wallet), any unix type OS would do, also mobile wallets. When you go above values of let's say 1000 Euros/Dollars/Pounds, start thinking about protecting your values (keywords: hardware wallet, cold storage). You find enough references here or in reddit.


Why has UTXO set stopped growing since 2017-06-03?

It's hard to know for sure what's been going on. My guess would be it's a mix of :

Better coin selection algorithms used by large wallets (exchanges)
Increase in fees pushed some inefficient services to stop creating uneconomical outputs (low values). Those services would be gambling/faucets/etc.. They might now be forcing withdrawals to be above a given amount
Some services consolidating their wallets since fees have lowered a bit from the last few weeks.


Is it a problem that miners participate in a pools?

It can be.  The most widely-used mining protocol at present (and the historically popular protocols) give complete control over what gets mined to the pool operator.  Even if the pool operator has the best of intentions, they can be hacked and their hash rate abused for evil.  This is what allegedly happened when the mining pool GHash.io (with about 30% of hash rate) stole about $100,000 in BTC from the betting website BetCoin Dice.

But it doesn't have to be a problem.  One current mining protocol, GetBlockTemplate, theoretically allows pools to give individual miners the ability to select which transactions they include in their blocks, preventing the pool from centrally making important decisions.  Another system, Peer-to-Pool Pool (P2Pool), is a completely decentralized pool where there is no pool operator, just a bunch of independent miners collaborating without any one of them making decisions for the others.

Both of these protocols have problems. GetBlockTemplate (GBT) is bandwidth intensive, complicated, and not very flexible; P2Pool is complicated, less efficient than centralized pooling (it can't include as many fee-paying transactions in a block), and doesn't necessarily work well for very small miners.

A new alternative to both of these protocols is BetterHash which looks like it many work much like GBT was supposed to without the problems.

  I  think there are some possible ways to prevent miners from pooling. For example add miner signature to the block header, so pool will not be able to disclosure their private key to outsource calculations.

This solution has been proposed many times before and it certainly could be added to the Bitcoin Protocol.  However, several experts worry that it would make centralization worse by only providing the benefits of pooling to the biggest individual miners.  Smaller miners who now couldn't join pools would be subject to increased block-finding variance and so would either be more likely to go out of business, or would simply rent hash rate from a large miner who would operate the equipment and payout rewards---increasing centralization in either case.


A Bitcoin locking script to force a certain payment to the receiver?

No, that is not possible, and doing so can be problematic.
Such scripts would need the ability to inspect the spending transaction and this is currently not allowed or possible; the script interpreter does not have access to other parts of the transaction.
Furthermore, if implemented naively, this could allow for widespread censorship and centralized control of Bitcoin. In essence, such scripts could be written to require that transactions do not send money to some blacklisted addresses, and at the same time require that all receivers in that transaction also have this same requirement. This could lead to services blacklisting some addresses, and then forcing their users to also blacklist those addresses when they withdraw from the exchange. And the recursive nature of that means that all subsequent transactions also have the same blacklist.


Accidentally shutdown system while Bitcoin Core client was synchronizing

giving an error as ' fatal error please see error log' ... what is the solution to this problem.

Step one is to do as it suggests. The location of the error log depends on the platform (Windows probably %APPDATA%\bitcoin, Linux probably ~/.bitcoin)

If all else fails, just install some wallet software elsewhere and re-import the private key you carefully backed up for just this sort of situation.


It is hard to make out an early adopter advantage for users, except perhaps scoring a few Ripples to spend for free. After spending that money, there seems little advantage for users to stick around.

That's probably true for people who have no real urgent use case. But what about users who need to make international payments such as remittances? But largely I agree with you, pursuing users directly is not a good adoption strategy this early.

  There seems to be mostly a first mover advantage for businesses (see 1, 2). However, for most businesses this should be a chicken-egg problem, without customers there is no interest to implement, without usage opportunities there is no interest for customers.

The good thing about chicken-egg problems is that if you get one, you get the other for free. So when adoption is blocked by a chicken-egg problem, you pick the side of the problem that's easier to solve and work on that. Then the problem turns into something that drives adoption.

So what's the wedge into that problem? Well, businesses can accept payments through Ripple whether or not their customers send payments through Ripple directly, and customers can make payments through Ripple whether or not the businesses accept Ripple payments directly. The obvious example is the Bitcoin outbound bridge which lets Ripple users make payments to merchants that accept Bitcoins whether or not those merchants adopt Ripple. Similar bridges can be constructed in the inbound direction and from conventional payment systems.

There are numerous adoption strategies that don't require getting users directly but where Ripple is used as a "back end" payment rail and remains invisible to users.

  There is no strong incentive to do what is good for the network: While inactive users in the bitcoin network don't matter, should users in Ripple lose interest, their outstanding IOUs lose worth. So, not only do I have to trust that somebody is good for their money, but also that he will stay interested.

Community/social credit is not expected to be a realistic use case for Ripple for some time. It's reasonable to expect that the initial adoption will be driven primarily by assets issued by gateways, possibly even by business-to-business transactions using Ripple as a back end to provide irreversible, high-speed, cross-currency settlements.


Were all funds stolen from Mt. Gox finally returned to all users?

All the funds that were frozen have been returned. There are two types of funds that were not returned:

Some people claim funds of theirs were transferred out well before the freeze. They claim it must have been by the same person who got the account/password list, but before the big attack. They claim these funds have not been returned.
People who profited unfairly during the flash crash had their transactions undone. Some of them claim they are entitled to their profits. (Some people bought thousands of bitcoins at absurdly low rates.)

I think that people in the second category don't deserve to profit from the theft. As for the people in the first category, there are only two people that I know of who claim this and the amounts involved are quite small. So I think the true answer to your question is most probably "yes".


How can I sign a message with a multi signature address?

Signing message is proof of ownership of private key

Multisignature/P2SH address is hash of several (including zero) public keys

So, signing message with M private keys and disclosing the "contents" of msig address M-of-N is proof of control on address.

I do not know are there existing services to sign/verify p2sh addresses, but it is possible. Do not know about Armory/others.


How does bitcoin prevent someone from sending more money than he/she has?

This is called the "double-spending" problem. There's an excelent article on the Bitcoin Wiki that covers the entire mechanism.

https://en.bitcoin.it/wiki/Double-spending


How do I determine an optimal or above average fee to gain priority in the network during a transaction?

The amount you should pay is constantly changing, so you'll have to check at the time you send the transaction. 21 has an API that provides recommendations on mining prices.

They are only recommendations though, there isn't really a definitive answer. The network could get flooded with higher fee transactions at any time, and your fee would then appear relatively low to miners. If you need to be absolutely certain you may want to raise the fee even further, but I believe they've taken some amount of that into account.


I have bitcoins on my smart phone. How can I see and use my bitcoins on e.g. my pc?

In general, each wallet has its own set of addresses and private key chain. There is no way to log into your Bitcoin wallet, as there is no central service that is providing it to you, rather it is just locally stored on your device.

I would not recommend trying to share the same set of keys between different wallets, as it would increase the attack vectors on your money.

Rather, you might want to just send most of your bitcoins to whichever storage you expect to be most secure, and hold a spending amount on the other devices.

If you just want to see the coins on other devices, you may look up the specific address on a blockchain explorer such as blockchain.info, or read up on "watch only wallet".


No update on API when receiving payments from other Blockchain.info wallets

Can't see what would be different from a QR scan.  If the correct BTC address is getting paid, it shouldn't matter if the address was copied, QR'd or hand-pecked.

I have an example of the callback from Blockchain's Receive API here:

https://github.com/damonp/simplebtcpay/blob/master/www/callback.php


Building Signed Bitcoin Transaction in Java

Quickly decoding the tx:

 VERSION      01000000
 TX_IN COUNT  hex=01, decimal=1
 TX_IN[0]
  TX_IN[0]    OutPoint hash 22F389655A7916085318876070450A0BFCB0B5B762CCBC3B3F71CF70328368E4
  TX_IN[0]    OutPoint index hex=00000000, reversed=00000000, decimal=0
  TX_IN[0]    Script Length hex=8A, decimal=138
  TX_IN[0]    Script Sig  473044022051646B77924F6BB7C411C5AA890110AB55DB8812B8998FE24C8BDCE39795EBD602200BC4DE18FD5524AD8B946EE57604424E2B943EF2A14FC7199A7853DDA0743CBE014104B97C679207532E0F4EE2515AEDABA5F87700BBE0138F7457BAA58E89A53153823AB29632E6C3C804ECAAB5913656512339792479A1B898B7E5DC31F075FF8660
        47: OP_DATA_0x47:     push hex 47 (decimal 71) bytes as data
        30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript
        44: OP_LENGTH_0x44:   length of R + S
        02: OP_INT_0x02:      type tag indicating INTEGER
        20: OP_LENGTH_0x20:   this is SIG R
            51646B77924F6BB7:C411C5AA890110AB:55DB8812B8998FE2:4C8BDCE39795EBD6
        02: OP_S_INT_0x02
        20: OP_LENGTH_0x20:   this is SIG S
            0BC4DE18FD5524AD:8B946EE57604424E:2B943EF2A14FC719:9A7853DDA0743CBE
        01: OP_SIGHASHALL:    this terminates the ECDSA signature (ASN1-DER structure)
        Minimum and maximum size constraints                        - ok
        scriptsig always starts with 0x30                           - ok
        length 136 chars is less than actual sig length (140 chars) - ok
               (hex 0x44, decimal 68, 136 chars)
        length of R coordinate (64) >= 0                            - ok
        length of S coordinate (64) >= 0                            - ok
        S-Value is within scriptsig boundaries                      - ok
        Make sure the R & S length covers the entire signature      - ok
        S-value must be smaller than N/2                            - ok
        strictly check DER-encoded signature                        - ok
        41: OP_DATA_0x41:     push hex 41 (decimal 65) bytes as data
        04: OP_LENGTH_0X04
            B97C679207532E0F:4EE2515AEDABA5F8:7700BBE0138F7457:BAA58E89A5315382
            3AB29632E6C3C804:ECAAB59136565123:39792479A1B898B7:E5DC31F075FF8660
        * This terminates the Public Key, corresponding bitcoin address is:    mnAEswb3Aiz5YTsfCJc8vQETnSe19mc5Am
 TX_IN[0] Sequence FFFFFFFF

TX_OUT COUNT, hex=01, decimal=1
 TX_OUT[0] Value hex=76DF171000000000, rev_hex=000000001017DF76, dec=269999990
 TX_OUT[0] PK_Script Length hex=19, dec=25
 TX_OUT[0] pk_script 76A91448DDFD3891F3F422D5C3C9C25E35B382667FC6E688AC
        76: OP_DUP
        A9: OP_HASH160
        14: OP_Data14 (= decimal 20)
            48DDFD3891F3F422:D5C3C9C25E35B382
            667FC6E6
        88: OP_EQUALVERIFY
        AC: OP_CHECKSIG   This is a P2PKH script and translates base58 encoded into this bitcoin address:    mnAEswb3Aiz5YTsfCJc8vQETnSe19mc5Am
 LOCK_TIME 00000000

So the transaction is correct, and the signature is assembled correctly. It also follows the "strict sig check" rules. The tx is trying to  spend from mnAEswb3Aiz5YTsfCJc8vQETnSe19mc5Am to mnAEswb3Aiz5YTsfCJc8vQETnSe19mc5Am.
So I checked the signature against the double hash of the tx (see the famous pizza transaction run-through: How does the ECDSA verification algorithm work during transaction?):

The raw_tx.txt is:

0100000001e468833270cf713f3bbccc62b7b5b0fc0b0a4570608718530816795a6589f322000000008a473044022051646b77924f6bb7c411c5aa890110ab55db8812b8998fe24c8bdce39795ebd602200bc4de18fd5524ad8b946ee57604424e2b943ef2a14fc7199a7853dda0743cbe014104b97c679207532e0f4ee2515aedaba5f87700bbe0138f7457baa58e89a53153823ab29632e6c3c804ecaab5913656512339792479a1b898b7e5dc31f075ff8660ffffffff0176df1710000000001976a91448ddfd3891f3f422d5c3c9c25e35b382667fc6e688ac00000000

Removed sig, and entered your pubkey script into raw_tx_SIGHASH_ALL.txt:

0100000001e468833270cf713f3bbccc62b7b5b0fc0b0a4570608718530816795a6589f322000000001976a91448ddfd3891f3f422d5c3c9c25e35b382667fc6e688acffffffff0176df1710000000001976a91448ddfd3891f3f422d5c3c9c25e35b382667fc6e688ac0000000001000000

and double hash (the binary values, hence some conversion first!)

  result=$( cat raw_tx_SIGHASH_ALL.txt | sed 's/[[:xdigit:]]\{2\}/\\x&/g' )
  printf $result > raw_tx.hex
  hexdump -C raw_tx.hex
  openssl dgst -binary -sha256 <raw_tx.hex >ssha256.hex
  openssl dgst -binary -sha256 <ssha256.hex >dsha256.hex
  hexdump -C dsha256.hex

So the dsha256 is in readable form:
  6b37475a5388fb52f227817a0ddec00e7b69495b492cd7cdc6aff2afc44810e4

I use openssl to verify the double hash hex file (dsha256.hex), with the signature and a "pem" key (need to convert pubkey from hex to pem), I always get an error:

openssl pkeyutl -verify -pubin -inkey pubkey.pem -sigfile tmp_sig.hex -in dsha256.hex

whereas running through the pizza example, it returns a "Signature Verified Successfully".


Bitcoin-Qt frozen catching up/sync with Bitcoin in new wallet

If you still have the wallet.dat file from the bitcoin-qt installation at the time got the wallet address that you sent the money to you can use that with a new bitcoin-qt installation to try to make it work. If you don't have that wallet.dat file anymore the money is lost.

As for the problems downloading the blockchain, are you sure you have enough space? It's about 12 GB now. It sometimes take a very long time to download and may just look like it's sitting around for a while doing nothing, then pick up again a while later.


Why do some transactions have more than one input?

What might be confusing you, and which is a common misconception, is that the addresses themselves somehow "hold" the bitcoin balances, and gain and lose the coins via transactions. In fact all the blockchain does is link up previous outputs to new inputs, and the keys make sure only the correct person is allowed to send the coins.

Your balance is just the sum of the total unspent outputs and if you want to send a certain amount to someone, you end up creating a transaction which uses, as input, enough unspent outputs to give the right amount of coins. So if you have a few different smaller unspent outputs, and want to send a large amount, the transaction will end up using multiple of the smaller outputs as input. Because inputs and outputs are used as wholes - they can't be split up as such -
 you then usually receive a bit of change based on how much the total inputs sum up to, and how much you intended to send.

Of course, most of this is worked out by your wallet client or website which you use, so as an average user you wouldn't normally know in advance how many "addresses" are going to be involved with a specific transaction. The program will just select enough unspent outputs which you hold the keys to, and use them to create the transaction. Hopefully that answers your question to some degree.


Addresses are randomly generated starting from a private key. The private key is the only truly random value in a whole chain of interesting values. These values are then mathematically derived from the private key. On the other end of the chain of values is the address.

Now if you could simply pick an address and recover the private key that, when passing it through the address derivation mechanism, gives you that address we would be in a lot of trouble. People could simply listen to transactions on the network, extract the receiving address, reconstruct the private key and spend the funds, even if they were not the intended recipient. So at this point it should be clear that simply picking an address and go ahead from there is not possible, in other words some of the functions in the chain are non-reversible.

So starting from the private key, we construct a public key. Already this first step is non-reversible, otherwise public-key cryptosystems would stop working. It should be computationally unfeasible to recover the private key from the public key. Bitcoin further goes ahead and hashes the public key twice. This step is non-reversible as well.

The first character of the address depends on the address version and may not be freely chosen. Then there is the matter of the Base58 encoding, which unlike the other mechanisms is reversible.

Finally the last few characters in the address are a checksum which is again calculated as a double hash of the already hashed public key. So for these last characters there is simply no way of "choosing" them so that the address looks a certain way.

So to answer your question: no, you cannot simply pick an Address that looks nice and use it as yours. That's also the reason why tools like vanitygen exist: they simply pick a random private key, transform it until they get an address and then check whether it has the desired features, e.g., your name in it. The more restrictive you are with what you want your address to look like, the harder it gets to find one that does. This difficulty increases exponentially, hence the term computationally unfeasible above.


What will happen to mining after the 20 999 999th Bitcoin?

Assuming Bitcoin is still active at that point in time, mining will continue, because transaction fees will make it worthwhile to do so.

This topic has been discussed heavily in other answers, including:

What happens once the mining reward gets cut in half?
How many bitcoins will there eventually be?
How much will transaction fees eventually be?

The last link has suggestions that the fee mechanism of Bitcoin may need changing, though that's yet to be proven whether or not it will be a real problem.


You might want to try my website cryptodatasets.com It has free raw data and sampled data from Bitfinex and HitBtc (currently).


Environment for building Bitcoin core in Windows

In the past, the standard method of building for Windows has been to use MinGW. Either have MinGW on Windows and compile from within it (may be more difficult) or cross compile it from a Linux environment.

However, fairly recently, support for using MSVC has been added. Although the official binaries do not use MSVC, you can self compile using it. We even have CI that makes sure that everything builds under MSVC.

Instructions and the necessary project files can be found at https://github.com/bitcoin/bitcoin/tree/master/build_msvc


how to convert pubkey wif address to hex format with bitcoinjs-lib?

WIF pubkey

There is no such thing as a wallet import format pubkey. What you have shared is an address, which is HASH160(pubkey). There is no way to recover the original public key from an address. You could, however, recover the public key from an outgoing transaction from that address, as it would be revealed as part of the unlocking script.


The first confirmation is simply the fact that your transaction was included in a block. Any confirmations after that are simply new blocks that extend the chain on top of the history that includes the block with your tx.

To be notified about transaction confirmations, all one has to do is listen for the broadcasts of new blocks, and check if their tx is in it, or if the block extends the chain after their tx has been mined. If either of those hold true, the number of confirmations is incremented.

Due to this, it doesn't really matter who sent coins to whom. Every participant on the network is notified of which transactions are being confirmed, since they all receive new blocks.


Can I run bitcoind without BerkeleyDB 4.8 installed?

I feel stupid...

https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md#berkeley-db

I followed that to the T and I got it working. Now I'm struggling with OpenSSL issues :/


Does Coinbase have the ability to create a "Business" Account?

I'm with Coinbase (proof), better late than never with this answer.

We do have a way of doing this now, though it requires some extra verification steps to properly link your account to the business entity.

Email us at support@coinbase.com


What do these memory configurations in debug.log of BitCoin Core represent?

The block index and chain state databases are LevelDB databases. LevelDB has its own caching and cache management. So 2 MiB is being allocated for the block index's LevelDB database cache, and 8 MiB is being allocated for the chain state's LevelDB database cache.
However Bitcoin Core does additional caching by itself, particularly for the UTXO set, which is stored in the chain state database. So Bitcoin Core is also allocating 441 MiB for itself to manage a cache of UTXO set entries.
The difference is that LevelDB will organize its cache differently from Bitcoin Core's in-memory UTXO set because LevelDB is a database system. So it is optimized for data handling and has a strategy that is generalized to all kinds of database uses. However Bitcoin Core knows what data it is putting into the database and so it can cache that more effectively. It caches the data before it needs to be serialized and written to the database. Because Bitcoin Core knows how the data will be used, it's caching through the in-memory UTXO set can be optimized for the actual use cases.


What is the difference between time, blocktime and timereceived?

timereceived is when your client first learned of the transaction. If you sent the transaction, it's the time when you sent the transaction. If you received the transaction, it's when your client first saw the transaction on the network.

time can be different from timereceived if you first learned about the transaction by seeing it in a block. This usually happens when your client was offline for a while and you're getting caught up with the block chain. In this case, time will use the block's timestamp if it seems reasonable. Specifically:

If the block timestamp is in the future, time will be the same as timereceived.
If the block timestamp is before the latest transaction in the wallet, time will be equal to the time of the latest transaction in the wallet.
Otherwise, the block timestamp will be used.

Transaction times don't change, even after a reorg, and new transactions will never have a time earlier than an existing transaction. This was not always the case (old versions preferred to use the block timestamp, which is usually more accurate), but the current method makes it easier to deal with transaction timestamps safely.


Is this how to generate a bitcoin address with python?

If the public key were correct (see Mark's answer), the code is not complete (lacks signature) and contains a hash of an ASCII hexdigest which is not correct.
I'd like to contribute with this implementation of bitcoin address from public key.
It covers the case of both uncompressed and compressed bitcoin addresses (just changing compress_pubkey boolean value).

#!/usr/bin/env python2
# https://en.bitcoin.it/wiki/Protocol_documentation#Addresses

import hashlib
import base58

# ECDSA bitcoin Public Key
pubkey = '0450863ad64a87ae8a2fe83c1af1a8403cb53f53e486d8511dad8a04887e5b23522cd470243453a299fa9e77237716103abc11a1df38855ed6f2ee187e9c582ba6'
# See 'compressed form' at https://en.bitcoin.it/wiki/Protocol_documentation#Signatures
compress_pubkey = False

def hash160(hex_str):
    sha = hashlib.sha256()
    rip = hashlib.new('ripemd160')
    sha.update(hex_str)
    rip.update( sha.digest() )
    print ( "key_hash = \t" + rip.hexdigest() )
    return rip.hexdigest()  # .hexdigest() is hex ASCII

if (compress_pubkey):
    if (ord(pubkey[-2:].decode('hex')) % 2 == 0):
        pubkey_compressed = '02'
    else:
        pubkey_compressed = '03'
    pubkey_compressed += pubkey[2:66]
    hex_str = pubkey_compressed.decode('hex')
else:
    hex_str = pubkey.decode('hex')

# Obtain key:

key_hash = '00' + hash160(hex_str)

# Obtain signature:

sha = hashlib.sha256()
sha.update( key_hash.decode('hex') )
checksum = sha.digest()
sha = hashlib.sha256()
sha.update(checksum)
checksum = sha.hexdigest()[0:8]

print ( "checksum = \t" + sha.hexdigest() )
print ( "key_hash + checksum = \t" + key_hash + ' ' + checksum )
print ( "bitcoin address = \t" + base58.b58encode( (key_hash + checksum).decode('hex') ) )


libudev error while configuring cgminer on fedora 22

I was able to get cgminer to build the icarus extension on a fresh CentOS system like so:

yum install git
git clone https://github.com/bitmaintech/cgminer
cd cgminer/
yum install -y autoconf make automake gcc gcc-c++ kernel-devel libcurl libcurl-devel
yum install libudev-devel
./autogen.sh
./configure --enable-icarus
make
./cgminer

So I think you're missing the package libudev-devel. (It might be named something different on Fedora 22 - I don't know.)


Can a Lightning channel's initial BTC value be updated?

Currently the capacity of a channel stays the same. However on the Lightning Developer Summit in Australia in November 2018 it was agreed that Splicing should be added to lightning. With splicing you can increase or decrease the capacity of a channel (and your balance)

If you don't care about capacity but just about the balance and you want to refill the channel of your channel there are four things you can do:

You can receive a lightning payment by selling some good (:
If you just fund to fill up capacity you could use a submarine swap which works by sending bitcoin in order to pay for a lightning invoice.
You can also use exchange services like zigzag.io in order to send money from your channel to a bitcoin address.
You can route a payment to yourself in order to rebalance 2 of your channels.


Will Lightning Network still require a confirmation from the network?

Lightning Network (LN) payment channels are anchored on the blockchain by their owners cooperatively creating a 2-of-2 multisig address and sending funds to it. The funding usually comes from one party, but one channel owner can for example pay the other channel owner with the funding transaction by allocating the payment amount to them in the channel's initial balances. The channel anchor then remains unchanged on the blockchain until the payment channel is closed.
Payments on the LN are subsequently performed by the channel owners renegotiating their balance shares of the anchor's funds. Thus, as long as all payments are processed on LN, no on-chain action is required. When one of the two parties wants to use funds from the channel to send an on-chain transaction there are three possibilities:

Close: closing the channel and using the funds on-chain
Splice-out: cooperatively sending part of the funds out of the channel and re-committing the rest of the funds to a new channel with each other
Loop-out/submarine swap: paying a third party via LN to make an on-chain payment on their behalf


Every 100 transactions, counting both sending and receiving. For receiving, you can treat multiple transactions to the same address as a single transaction.

This ensures that you don't lose any bitcoins if, for example, your hard drive crashes.

The option keypool in Bitcoin-Qt client adjusts this.


Slides of my presentation: https://docs.google.com/presentation/d/1N6jT6SbBl3OxohbdEQj_f1su9nf9UqetAgLYu6RfeWQ/edit
Privacy: Things that a person doesn't want to share with everyone
Anonymity: Share things with everyone but not be associated with you IRL
When considering Bitcoin Protocol or Chain, these terms are confusing or used at lot of places without mentioning the difference. To achieve anonymity in bitcoin transactions (Real identity should not be linked with bitcoin transactions), users should follow best practices and still consider that no technology can help in 100% anonymity. Privacy is involved at different levels while using Bitcoin. If considering full node, lot of information is involved that you might not want to share with other nodes or not use others nodes and use your own node. Running node over Tor or i2p also helps in avoiding real IP being linked with any transaction. Once transaction is confirmed or even in the mempool, everyone can look at the address, amount and other details which may sound less private but this information is not really helpful for any spy until it is associated with real identity or any KYC exchange etc. Last but not least, never share information about your transaction on social media.
Things go wrong when you don't follow the best practices. Examples are many but one:
https://bitcoin.stackexchange.com/a/101959/
Basic things:

Use your full node

Do not re-use addresses

Use coinjoin and payjoin when required

Do not share information about transaction on social media

Use non-KYC exchanges like Bisq for trading

Bitcoin blockchain is like people sharing their nudes, everyone can see them, they are all blurred, few have information about real face etc.
Transactions being public doesn't make Bitcoin less anon or private. Privacy and Anonymity depends on the user, system and their interaction. There is always scope for improvement.


No, that text is not proof that there were transactions from your wallet. It just means the the software was running and those lines are normal. They just indicate that the received data from peers, but that data is not necessarily related to you.

To check if you have any Bitcoin, you can run the software and see what it tells you. It sounds like you are using an old version of Bitcoin Core, so you should probably upgrade to the latest Bitcoin Core first as it will sync much faster. Because that is Bitcoin Core, you will need to download the entire blockchain which is 180+ GB of data, but you can enable pruning to reduce the disk space used.


Is new cryptocurrency that runs only in raspberry pi possible?

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


Different address prefixes for different address types / network combinations

Different networks use different address prefixes.
In Bitcoin mainnet:

P2PKH addresses: 1...
P2SH addresses 3...
P2WSH and P2WPKH addresses: bc1q...
P2TR addresses: bc1p... (see BIP 341)

In Bitcoin testnet and signet (see BIP 325):

P2PKH addresses: m... or n...
P2SH addresses: 2...
P2WSH and P2WPKH addresses: tb1q...
P2TR addresses: tb1p...

Bitcoin Core's regtest network:

P2PKH addresses: m... or n...
P2SH addresses: 2...
P2WSH and P2WPKH addresses: bcrt1q...
P2TR addresses: bcrt1p...

See also https://en.bitcoin.it/wiki/List_of_address_prefixes


getrawmempool verbose returns ambiguous results

As easy as read an actual rpc call instead of bitcoin.org documentation:

"descendantsize" : n,   (numeric) virtual transaction size of in-mempool descendants (including this one)
"ancestorsize" : n,     (numeric) virtual transaction size of in-mempool ancestors (including this one)strong text


Why was the maximum target set to 0xffff0000000...?

I admit that I don't know for sure, but I have a guess.  Since Satoshi was mining by himself for the first blocks, he probably set the initial target to whatever would take approximately 10 minutes to mine a block on his CPU.  Had he set it to the maximum value for a 256 bit number, he would have mined the first 2,016 blocks almost instantly, and then immediately retargeted.

Because of the large number of blocks mined in such a short amount of time, this would likely have caused the retargeting calculation to produce a less-than-perfect result, meaning that the next 2016 blocks may be mined either far too quickly or far too slowly.

It was probably just better for him to initialize the target to a reasonable value, rather than force the algorithm to run its course in order to produce one.


How to calculate value of pair but in opposite direction

whether an exchange offers the Pair ABC/DEF or DEF/ABC depends on the readability of the values. so most exchanges have the same pair-orders. you can see that effect at https://coinmarketcap.com/currencies/ethereum/#markets if you search for "ETH/BTC" and if you search for "BTC/ETH". but you can always trade in both directions. back to your example "What if someone wants to buy BTC by selling XRP or ETC. Is it possible?" yes. let's say you are trading on the ETH/BTC market: the statement "i buy btc" is equal to "i sell eth". (and the opposite statements would be "i buy eth" and "i sell btc" which is also possible on every ETH/BTC-market).

"how do we calculate that value given the prices an exchange gives on ETH/BTC?" like Eliyahu pointed out the value is simply the reciprocal of the price but this value will rarely be displayed. look at BTC/USDT for example: current price is $8101. no one wants the pair USDT/BTC because the price would be 0.0001234415BTC (1/8101 BTC) which is probably very unfamiliar for the most users.


How to generate a native Segwit address and P2SH Segwit address from a standard WIF?

wif -> private key

Use base58-decode to convert the base58 string to bytes
Strip the first byte (network byte) and the last 4 bytes (checksum). The remainder is the key
Verify that the first 4 bytes of the sha256(sha256(network byte || key)) are equal to the checksum
If the key ends with 0x01 (compressed) remove the last byte. You are left with the private key

  private key -> public key

Cast the private key as an integer
Multiply with the secp256k1 generator point to get a Point(x,y) on the curve. This is your public key
Encode your public key in a compressed format. Byte 0x03 (if y is odd) or 0x02 (if y even) followed by x as 256-bit integer

  Public key -> P2WPKH address

Create the witness program = ripemd160(sha256(public key))
Encode into bech32 by providing the witness program, bc as the human readable part and 0 as witness version

  Public key -> P2SH-P2WPKH address

Create the witness program = ripemd160(sha256(public key))
Create the redeem script = 0x0014<witness program> = witness version + push20 + witness program
Calculate the hash160 = ripemd160(sha256(script))
Prepend the hash with the version byte 0x05
Calculate the checksum = sha256(sha256(version byte || scripthash ))
Base58-encode(version byte || scripthash || first 4 bytes of checksum)

  How do these two formats differ and why are there two? I've seen that
  the P2SH version is compatible with older clients, are native Segwit
  addresses not?

Old clients cannot send to segwit addresses but they can send to P2SH addresses and by extension to P2SH-P2WPKH


Using a wallet generated from an out of sync client with a synced client

Yes, but you will have to resync that wallet if it has pending transactions.


To sum up the mining process: miners have a potential future block and they need to solve a problem based on that block to prove that they worked on it (Proof of Work). They apply a hash function to the block and get back a hash. The hash needs to have some properties, e.g. start with 3 zeros. If it doesn't, the miners change a value in the block (called nonce) and apply the hash function again. The new hash will be different. If it still doesn't start with 3 zeros miners repeat the process until they find a hash that starts with 3 zeros. For more details, please read this to understand the mining process.

A hash function is in itself deterministic. However, the mining process is not. Thus, the answer in the link you provided is wrong. If everyone was trying to mine identical blocks with identical nonces of the same exact order then it might be, in a sense, deterministic but that is not the case.

Everyone has a chance to win (although it is so small that in practice doesn't occur). See here for some examples.


Getting bx to create a private key from known chain code and a private EC WIF key?

No need for an external program at all:

$ KEY=xprv9s21ZrQH143K2hYgcmBxsUfRw3Kbu3eEGXFJrM8Cqtewuqa6Y6nXbB7tv9HnrBajqjptPsRjL9FmnwLa317jHWJ5dpwTc99C2AiPztPRaxk
$ echo $KEY | bx hd-public -i 0 | bx hd-to-address
15jbcT7wE81s8n2dbEGRFGf65zp7PHrjxh

Or, because this is non-hardened, you can use the extended public key:

$ KEY=xpub661MyMwAqRbcFBd9iniyEccAV5A6JWN5dkAuejXpQEBvnduF5e6n8ySNmP8uWeqNbwFXLHEQkV1shXbNtBV8YCUJPMSuE7bGCvDaZJfUBuP
$ echo $KEY | bx hd-public -i 0 | bx hd-to-address
15jbcT7wE81s8n2dbEGRFGf65zp7PHrjxh


Can a blockchain from the future be synchronized today?

Extremely creative question. Most of UTF-8's answer is correct. I'd like to observe a few consequences:

If someone brought a future blockchain to current reality and even 11 blocks were immediately accepted, you would have some serious chaos. People that didn't spend bitcoins from their wallet would suddenly see money they were going to spend in the next two hours gone. Exchanges would see outputs of a lot of their money that they would have had to send out in the next two hours gone to people that were about to, but didn't yet ask for them. Same with merchants that deal with bitcoin, people would have paid money to addresses that may not have been generated yet!
The big thing about the future blockchain is that you have some serious replay attack vectors. Once future blocks are known, pretty much anyone can replay these transactions as long as they're valid and include them instead of transactions that try to spend the same UTXOs.
There would probably be a hard fork quite quickly to preserve the value of bitcoin that renders all blocks and transactions from the FBC invalid. The competing FBC chain wouldn't have any value since you can't create any transactions on there and some amount of hashing power has gone over to the new fork, making it extremely difficult to catch up to the FBC chain in any way.
From a world-building perspective, the most interesting consequences would be the potential future you got a glimpse of. You would know that you spent some amount of bitcoin 17 days from now, but for what purpose?
The evidence that FBC is actually from the future would be really compelling. First, the proof-of-work on a future blockchain, if it's more than a year in the future, for example, would be astronomically high and nearly impossible to fake. Second, people would see signatures to their own private keys on the chain that they never generated. Again, really convincing proof. It would certainly spawn research into time-travel =)


How to listen to an address or transaction_id continuously?

You can use Bitcoind's ZMQ integration. It lets you get notify instantly when a transaction is made (whatever the address), you can then do the filtering yourself if you want to pinpoint a specific address.

This setup requires a bit of work to do the transaction parsing and filtering, but lets you run without relying on third parties. You won't get the balances of each deposit address too, just the deposits (but you can get the balancet from elsewhere).

Another solution (that relies on a third party) would be to use blockchain.info's service.


What stops someone from faking a rating on OTC web of trust?

The global ratings are fairly easy to manipulate as you describe, and it has been done before. There is some minor protection provided by the requirement that you need a positive OTC rating to rate anyone else.

#bitcoin-otc also supports "trust rating" (example) which can't be easily manipulated.


How to convert fee_estimates.dat into a human-readable format?

You need to take a look at how fee_estimates.dat is written and interpreted. It is a binary file composed of:
MIN_VERSION
CURRENT_VERSION
CURRENT_TIP
TIP_AT_LAST_START
TIP_AT_LAST_STOP
[ESTIMATES]
[STATS]

With CURRENT being "when writing", i.e. when stopping bitcoind.
Here is the method writing the file, and here is the method reading this file (at startup). I think the latter can help you to parse it.


How do I change what wallet Coinbase deposits BTC into when buying?

Short answer: No.

Long answer: When you buy on Coinbase, no actual transaction occurs on the blockchain, instead Coinbase just updates their internal database, to show that your account now owns some amount of bitcoin.

When you make a request for Coinbase to send your bitcoin to an external wallet, then at that point an actual transaction is broadcast to the network.

So there is no way to 'shortcut around some fees' here. Even if your buy order paid straight to an external wallet, the same processes would happen in the backend (coinbase would update your account's balance on their internal ledger, and then broadcast a transaction to the bitcoin network).


How to debug a long "0/unconfirmed" status in the bitcoin client?

Try running bitcoind from the command line with the -rescan option. It may be that your transaction was erroneous or a double-spend attempt and it only exists in your client. You could double-check the receiving address in blockexplorer to see if the transaction ever came through from the rest of the network's perspective. If this is a zero transaction fee transaction (or is just otherwise unlucky) it might still be in-queue to be included in a block. Bitcoin Charts has a list of in-queue transactions you can check as well.

Assuming blockexplorer sees the transaction, your client probably isn't downloading blocks and may not even be connected at all. Check that the block number in your client matches the block number at blockexplorer (or any of a number of other sites), check if your client has 0 connections. If you have no connections, try the troubleshooting steps from this question. Worst case scenario delete everything from the Bitcoin data folder except for wallet.dat and re-launch the client. Several hours later when you've finished downloading a fresh copy of the block chain, your 0/unconfirmed transaction will probably be resolved.


One node accessible under several ip-addresses?

Yes, it is possible.

You simply need to listen on the different IP addresses. What is necessary to do that and the steps required depend on your network configuration and hardware capabilities.

The trick is then to get your node to advertise all of the different IP's, which on some node software I think (from practical experience but, without going back actually to confirm) that you can just specify multiple external IP's.

I am not sure that this accomplishes much, however. If you have the bandwidth you can just modify the node to allow a high number of incoming connections and use a single IP.

Also, I suspect, others may confirm, that the default connection rules have subnet spacing integrated so that the same node will not connect outgoing to all connections in the one subnet.

If you control traffic and DNS on your network it is trivial to ruin Bitcoin via a number of methods as you could the operation of any application.


Is it secure to collect common public addresses under a wallet using BlockCypher Wallet API

When using a third party, you will be trusting them to give you correct information. This is not just about being dishonest but also about not having bugs.

For instance consider the recent cve-2010-5141 vulnerability. If you are running a full node on your own, you can know what is going on and you can upgrade when you find out about it. But if you rely on a third party you have to trust that they upgrade and are aware of it.

As a matter of fact they apparently have not yet upgraded and on TestNet they are showing a block with exploiting transaction as valid. So theoretically you, as an exchange, can lose money if you were relying on them and if this was MainNet.


Why are pre-softfork blocks are not causing problems for post-softfork clients?

Your question is about deployment.

Softforking changing generally are not applied unconditionally to every block in history. Instead, an activation mechanism is used so that all clients know when they need to start being enforced. Before that activation point, new clients still enforce the old rules but not the new ones.

Activation mechanisms that have been used in the past:

Time-based (apply to every block whose timestamp is past a fixed point in time). Used in BIP16 and BIP30.
nVersion signalling (apply to every block after the first range of 1000 blocks in which at least 750 have a nVersion field that is higher than a specified value). Used in BIP34, BIP66, BIP65
Versionbits signalling (using signalling on individual bits of the nVersion field; see BIP9). Used in BIP141/143/144/147.


When I set up a lightning channel with a node, have I need to put some bitcoins in it?

Generally, yes. The person who initiates the channel creation process (i.e. the person that says "I want to open a channel with you") is the one who funds the channel.

  Then, if I wanted to buy something using lightning network (for example, a sticker from Blockstream), will I have to open another lightning channel with Blockcstream? Or the previously synced channel will be used to let me buy from Blockstream?

Not necessarily. If your channels are connected to other nodes who have channels with other nodes and eventually a channel with the merchant (which is likely the case), then you do not need to open any new channels. You can make your payment route through the Lightning Network and it will reach the merchant.


Is it possible to mine Peercoin and Litecoin simultaneously on the same machine?

OK, I have this set up now. BFGMiner is running the USB ASIC for Peercoin and cgminer is running the GPU for Litecoin. I also have cudaminer running my second GPU for Litecoin, which was necessary as cgminer didn't like running two different GPUs at once. All works nicely together now.


i have good pc can i mine on it, if i don't have to pay for electricity?

No, you can't. The days of GPU mining Bitcoins are long past.


Assumed, I hash the next bitcoin block. Whom do I tell if it's decentralized?

You don't tell a specific node on the network, but rather broadcast your block to the entire network.  You essentially scream it from the rooftop.

If it's valid, it will be in the best interest of everyone to recognize your block and start mining on top of it.


Are there any ways to sync mempool from another nodes faster?

I had a similar issue where I restarted my bitcoin node for changing some parameters and it took half a day to catch upto to all uncomfirmed tx. Bitcoin 0.14 has a feature that stores current mempool to disk and loads it back on startup https://github.com/bitcoin/bitcoin/pull/8448. It should be possible to copy mempool.dat files to your other nodes that are behind.


With recent versions of bitcoind, you can use sendtoaddress with the optional subtractfeefromamount argument.

sendtoaddress 123abc... 1.055 "" "" true

Creates a transaction with 1.055 BTC of inputs.  The destination address will receive a little less than 1.055 BTC, after an appropriate fee is subtracted.


0 hashes per second in Qt for new altcoin

i did same thing bro :) i am very happy when you saw your question :) firstly you have to connect another computer . and you have to see "connection=1" To do that, you have use command: ./testcoin -connect= # . and you have to add listen=1 to main pc and addnode for both pcs.However, hashespersec is also zero for me :(


Why did my transaction not include the fee?

I don't know why your wallet didn't include a fee, and it would probably require a fair amount of debugging to figure out what went wrong.  Here are my suggestions for following up on this problem:

Make sure your transaction really didn't include a fee.  Open your wallet, find the transaction is the list of outgoing transactions, and press-and-hold on it to get the extra menu, and open it in the block chain explorer (BitEasy in Bitcoin Wallet For Android).

In the block chain explorer, look at the details and make sure it didn't really include a transaction fee.  If there is a fee, Coinbase support got something wrong---so contact them again.  If there really is no fee, go to the next step.
See what wallet you use.  From your description, it sounds like you use Bitcoin Wallet For Android, developed by Andreas Schildbach and based on BitcoinJ by Mike Hearn.  I've worked with both of them, and they're both very responsive to user problems.

If that is in fact the wallet you use, open a new issue on their issue tracker.  Here is the information you should provide them:

A link to this question.
The link to the page on BitEasy that shows your transaction had no fee.  Note: this may reduce your privacy (but it won't put your bitcoins directly at risk); if you uncomfortable with that, ask them if you can send them that link by email---I'm sure they'll accept.
What version of Android you use (Settings→Device Information→Version) and whether you use the latest version of Bitcoin Wallet For Android from the Google Play store.
Whether or not you completely emptied the balance of your wallet.  I think there's some special code that gets run when that happens.
Anything else unusual that you noticed.
You may also want to provide a copy of the text from the email Coinbase support sent you after removing any personal information.

If you use a different wallet, you'll need to follow the same basic steps but at a different URL.  Let me know the full name of your wallet in a comment below, and I'll find the most appropriate link.
Read the response from the developers closely and respond as best you can.  Please note that Andreas, Mike, and everyone else who works on Bitcoin Wallet For Android are all volunteers, so it sometimes takes them a while to get to new issues---please be patient.

This may seem like a fair amount of work, but filing issues is one of the ways you can support great open source software like Bitcoin Wallet For Android.


What's the best strategy to send btc from one wallet to a address list with transaction id for each payment?

You can do this with sendmany.
It accepts a minconf parameter (which defaults to 1, for 1 confirmation) - it will spend outputs that have at least minconf number of confirmations.
Setting minconf=0 will allow you to spend unconfirmed coins, such as from the change output of a previous sendmany transaction.


Testnet transaction - OPCODE MISSING OR NOT UNDERSTOOD error

quickly verifying:

410404f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba

41 hex equals 65. So the following string should be 65 bytes, but it is 66 bytes. As arubi lined out, there is an error with the double "04" - it only needs one.

Quick proof: when I verify the pubkey, I get the right address:
    04f89c713f44615ad5fdc16f1ef8628351a1cce79ee96130a0e4a6eb09d05278cef28cb002a6ad2ad53181b01d03f931538488a7a689d83684e54822305205d5ba

SHA-256 hash of PUBKEY
EF14CA0F83CCDA08F81806AEFADF80BA58CCCD12B149E028EF86F7B00C04C293

RIPEMD-160 Hash
13AA97D12703B051D9B670097BBF07E2CD78DE60

Adding network bytes
6F13AA97D12703B051D9B670097BBF07E2CD78DE60

SHA-256
AD3575F9D5422C0BD5AE472DA035E54601085FA5F018F4F72EF2ED5E96602B0C

another SHA-256
02D633422E210032443A4F5595C443C311CD64A5C762A7E354CCB6E510F1196B

First four bytes
02D63342

Adding 4 Bytes at the end of the network bytes line
6F13AA97D12703B051D9B670097BBF07E2CD78DE6002D63342

Base58 encoding
mhJwViAyjAdKoEFNPcX96zN2HxZpv69avm

so the pub key is wrongly assembled into the sigscipt.
On the S-value: I can see, that it was extended with a double "0", but the value still remains "high":

checking S-value is less than N/2, no...
    --> S is not smaller than N/2, need new S-Value (new_s = N - s)
    new S=4ECBED0519B3649CBEF69530CA8726C4065E1AA8D9128939F120419D62B6313F

when changing the S-Value, the length fields might need to be adapted...
Just for curiosity: what tool are you using to assemble the tx?


Does bitcoin still concatenate the locking and unlocking script and execute?

Does bitcoin still concatenate the locking and unlocking scripts

No. This bug was fixed many years ago. ScriptSig and ScriptPubkey executed separately, not concatenated to each other


Specified data directory does not exist - but it does...

Do not use backslash and space symbols in folder name


Miners don't receive rewards from anyone else - they give the reward to themselves as the output of the coinbase transaction, which includes the block subsidy and any fees from the txs in that block.

They then broadcast this block to everyone else. Each node that receives the block independently validates it to ensure it meets consensus rules (has a valid proof of work, does not contain any invalid transactions, has the correct subsidy and fees charged, etc.).

If any node believes the block is incorrect, it will reject it and continue to mine or wait for another valid block at the same height.

If the block is considered valid, it is added by each node to its own copy of the blockchain. Once 100 blocks have been mined extending the block in question, the coins in the coinbase output are considered mature and may be spent by the miner of the block.


Is there a plausible future for the use of Bitcoin in the financial industry and corporate finance?

Generally, Bitcoin is a poor fit for the needs of most financial institutions. They want features which are incompatible with Bitcoin, or require unsupported workarounds:

Holding local currencies.
Reversing transactions.
Keeping transaction information secret from the public, but available to regulators.
The ability to kick others off of their platform if they give the platform a bad name.

What those articles talk about is Bitcoin technology (also called 'blockchain technology') which is much more broad.


Bitcoin sent to Bitcoin Cash address in blockchain

If you have the private key of the bitcoin cash address, you can import it into your bitcoin wallet and send it somewhere else.
If not, you have to ask the one, who has its private key, for example an exchange.


Forum user xorxor maintains a list:

http://bitcointalk.org/index.php?topic=134179.0

  A reason why the alternatives are better and/or worse?

The secret sauce for Bitcoin is how the proof of work approach allowed it to be a decentralized digital currency.  This approach allows "truth" to be determined by consensus of the network.  This also makes it vulnerable should the majority of the network not be honest.

Keep that in mind first and foremost when considering any alternatives.


but not the privacy problems? Did I overlook something here?

Yes, unfortunately.   When you later spend you often need to use coins originating from multiple transactions that previously paid you and these co-spends will link together your transactions.

For example.  Say Alice pays you 1 bitcoin to address A and then Bob pays you 1 bitcoin to addess B. You then spend 2 bitcoin and use those to coins, indicating to the world that the same party probably controls A and B.  Later Bob pays you 1 bitcoin again and Charlie pays you 1 bitcoin to address C.  You make another 2 BTC payment using the coins from Bob's second payment and Charlie's payment, now the world has reason to believe A, B, and C are all controlled by the same party.  Without the reuse people would know less.

This privacy loss doesn't just hurt you, but also A, B, and C and potentially the people they interact with so even if privacy isn't very important to you today it's still better to not gratuitously lose privacy.

Bitcoin Core has some logic to try to spend all payments to the same address at once (though in 0.17 it isn't enabled by default) but even that won't help you if the payments/spending are spread out over time. If you are forced to reuse addresses it's preferable to delay spending payments to a particular address until its unlikely to get any more and to then spend them all at once.

Using one address per paying party is the bare minimum needed to even know who paid you but doesn't provide particularly great privacy.


Generate QR code for multiple cryptocurrency addresses

You could use offline JS libraries either with your browser or in your console.
Command Prompt
Requires NodeJS & NPM to be installed
npm install -g qrcode-terminal
qrcode-terminal '1SomeCryptoCurrencyAddressOrPK'
Offline in Browser
Or in your browser with an offline library
Save a copy of the raw qrcode.js file to your computer as a javascript file. https://raw.githubusercontent.com/davidshimjs/qrcodejs/master/qrcode.js
Then simply use it within an html file


What is time warp attack and how does it work in general?

The Bitcoin Protocol (consensus rules) has two relevant rules for the timestamps in block headers:

A node will not accept a block whose timestamp is more than two hours in the future.
A node will not accept a block unless it has a timestamp greater than the median of the previous 11 blocks.  In Bitcoin, we call this Median-Time-Past (MTP).

As you mention in your question, difficulty changes are calculated based on the times of the first and last blocks in a 2,016-block difficulty period.  (Technically there's an off-by-one error there, but that's not important here.)

Given the above rules, if all miners agreed, they could simply increment the clock the minimum amount of one second MTP for the first 2,015 blocks and then set the time to two hours in the future.  That would basically give them just a small decrease in the difficulty, but think about what happens to the MTP when they add that last slightly-future datapoint: the actual median doesn't change much at all.  Actual time stamps are in seconds, but here's a set of 11 timestamps in days delta from present time:

[-13, -13, -13, -13, -13, -13, -13, -13, -13, -13, 0]

The median of the above is -13, meaning that after miners create the slightly-future-time block at the end of the difficulty period, they don't need to move their timestamps forward more than the minimum one second---so the next difficulty period starts out -13 days.

At the end of the next difficulty period, miners again move the timestamp forward as far as possible, so the protocol thinks it took 28 days to mine the blocks---half the expected speed---and so decreases the difficulty by about half.  Now the values used for MTP look like:

[-27, -27, -27, -27, -27, -27, -27, -27, -27, -27, 0]

So miners can continue keeping timestamps far in the past and repeat the attack, lowering difficulty every period until the point where it takes them less than 2,016 seconds to produce 2,016 blocks, at which point they can't lower difficulty any further because the MTP function requires time increase by a minimum of one second over the median every block.

Now, your main question was how can this attack work without collusion by a majority of miners.  Now that you've seen how the attack works with all miners participating, it should be clear than selecting the median time can allow an attacking miner who's lucky enough to find blocks reliably to prevent median time from jumping forward to an honest value.  For example, imagine these are the times of the previous 11 blocks, in block chain sequence:

[-27, 0, -27, 0, -27, 0, -27, 0, -27, 0, -27]

If you sort those numbers to find the median, it's -27 even though 5/11ths (45%) of the hashrate is mining accurately.  But wait, doesn't that mean the attacking miner has 55% of the hashrate?  Maybe not, for a large miner with about 30% or more of the hashrate could obtain an advantage over other miners using a selfish mining attack, or the miner could simply threaten to attempt to make stale ("orphan") other miners blocks who have accurate time stamps, causing those honest miners to earn less income.

I myself don't consider the attack particularly likely on Bitcoin because it's slow to execute and publicly obvious, but it's something protocol designers do need to keep in mind for when they change parameters, as those changes could make the attack easier to execute.