What is the wallet "word seed" that is commonly used in popular wallets clients and what does it do? I've been using a pretty old version of Multibit classic and recently decided to upgrade. I tried out Multibit HD and Electrum and noticed that both have me set up a wallet with a "word seed". It's just a string of random words that is apparently used in an algorithm. The question is, what does it do exactly? Someone told me that it generates private keys for you, and all you need is that word seed and you will be able to restore/generate all your private keys. How does this work exactly? What algorithm is being use on the seed to generate the keys?
These words are apparently very important, as Multibit warns on their site:

To restore your wallet and recover your bitcoin, you must have your wallet words.
With your wallet words, you can recover your bitcoin. You must keep your wallet words safe, because anyone who knows your wallet words can steal your bitcoin.

The seed words seem to be a replacement for the private keys, based on what Multibit says about them. I'm personally quite attached to the idea of having my private keys, so why should I be content with this word seed instead? Some apparently think it's safe enough: Is 12-word seed phrase safe enough?, but is it usable enough?
These questions: Does a wallet containing multiple addresses have a single private key? and Why can the same 12 words produce different seeds in an Electrum wallet file? hint on what is happening here, but is lacking details. It seems the phrase is "hierarchical deterministic" wallets, hence the "HD" in "Multibit HD".
This question exactly articulates my concerns: Is it important to have an unencrypted backup of the private key?

With HD wallets, a single key can be used to generate an entire tree of key pairs.  This single key serves as the "root" of the tree.  The word seed is simply a more human-readable way of expressing the key used as the root, as it can be algorithmically converted into the root private key.  Those words, in that order, will always generate the exact same key.

That single key is not replacing all other private keys, but rather is being used to generate them.  All your addresses still have different private keys...but they can all be restored by a single key.

Compare this to non-deterministic wallets.  In a non-deterministic wallet, each key is randomly generated on its own accord, and they are not seeded from a common key.  Therefore, any backups of the wallet must store each and every single private key used as an address...as well as a buffer of 100 or so future keys that may have already been given out as addresses but not recieved payments yet.

A hierarchical deterministic wallet doesn't need to back up so much data.  The private keys to every address it has ever given out can be recalculated given the root key.  That root key, in turn, can be recalculated by feeding in the word seed.

Relevant BIPS:

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


deleted Bitcoin Wallet before transaction processed I requested bitcoin through Bitcoin wallet before fully syncing.  Bitcoin wallet would not sync on the original laptop that I had installed it on, so I removed the program and reinstalled it on another computer.  Now, I can't use the old address to receive my transaction. I can see it on blockchain, but I have no idea how to receive it as Bitcoin core will not allow to type in the old address.  Please help!

Whenever you create a new wallet, a number of private keys are generated for you. These private keys are used to authenticate yourself as the owner of bitcoins sent to the keys' corresponding addresses. Therefore, you must keep these private keys safe. For Bitcoin Core, these private keys are in a file called wallet.dat in the Bitcoin directory. If you've deleted this file there will be no way to recover your coins, as private keys cannot be regenerated.

However, I think that the wallet file may remain even when Bitcoin gets uninstalled, so if you didn't delete the whole directory, but just uninstalled it, you might want to check if you can still find the wallet.dat.


How can size of a block be significantly small? As we all know bitcoin block size should be sth about 1MiB. (Some blocks about 2MB). And this is because miners put all transactions to the block every 10 minutes.

So what happens technically that causes some tiny blocks to be relayed to the network occasionally?! For example: Block #593577

Let me add that its mined at same time with a couple of other blocks:

#593576
#593575

So maybe its gonna become an orphaned one.

But my question is about the reason behind mining & relaying such a tiny block with as small number of transactions as 46?! Is it because of sth like low number of connected peers? or weak network connection? Or what?!

Since the time between those blocks is so small (from 593576 to 593577 was only 16 seconds) a miner wouldn't have many transactions to add to the block they are mining (there just haven't been many transactions on the network within that period of time). Also, mining is random, if you happened to mine a block, wouldn't you want to get the block reward even if the block is small? The reward is much higher than the transaction fees. It wouldn't make sense to wait to try to mine a block until there are more transactions. In fact, you can mine a block with only the block reward and no other transactions, if you wanted.

So as more transactions come in, miners would presumably add them to their block in order to maximize the transaction fees they might get if they happen to mine the block.


Can an output be spent in the block in which it is contained? Is a Bitcoin block containing both a transaction that funds an output, and another transaction that immediately spends the same output, allowed by the protocol?

Does such behavior occur "in the wild", e.g. do any of the common clients allow spending unconfirmed Bitcoins? Would miners include such transactions?

allowed by the protocol?

Yes. It is possible to spend an output immediately. And two (three-four-etc) chaining transactions will be included in the same block. There are a lot of examples in blockchain. Note, that the their order in block is fixed.

  do any of the common clients allow spending unconfirmed Bitcoins

Bitcoin-core client allows to send "raw transaction" to spend unconfirmed bitcoins. Also the "change" output can be spent without confirmations. Holding incoming bitcoins for several confirmations is an interface option only, not a protocol rule.


Is it possible to reach same address in HD wallets? Is it possible to reach same address (same private key) with different mnemonics and different derivation paths in an implant based on BIP32,BIP39 & BIP44 combination?

In theory it is possible to have a collision in this way. However in practice, doing so is basically the same as randomly generating new private keys and hoping for a collision.


Can someone with an unlimited amount of money compromize the network? I was reading this interesting discussion in the comments section on ZH where this guy was talking about how a single entity (think corrupt government and banksters) can throw money and processing power at will at the network to successfully manage a 51% attack or just cause havoc in the system by sending incorrect network messages, such as denying valid transactions or allowing invalid transactions.

The initial part of the discussion quoted here

  Assume I'm a completely unscrupulous and ammoral person, for example,
  and I want to shut down bitcoin.  Here are the ways I would attempt to
  do it.

  Write a virus to mine bit coins and spread it across the internet.
  Write a virus to steal bit coins, and spread it across the internet.
  Write a virus to act as part of the bitcoin network, and deny
  transactions that are valid
  Write a virus to act as part of the bitcoin network to approve
  transactions that are invalid.
  Dump the bit coins I mined as part of step #1 and #2 on the market
  Create a mania in bitcoins by dumping billions into buying bitcoins
  after doing step #5
  Associate it with terrorism
  Associate it with drugs
  Claim that people like me are manipulating it

  And that's just off the top of my head.

  I gots unlimited money.  I am working in a market that is unregulated.
  I run the government or own it.  Try to stop me.

Here is a link to that discussion.
http://www.zerohedge.com/news/2013-03-25/bitcoin-mania-accelerates?page=2#comment-3373165

Can someone please comment on whether this is possible and if not, how does the bitcoin algorithm/ecosystem counter such an attack

With unlimited money, you could destroy almost anything. I don't really see why it matters. If someone with unlimited money spends a few billion dollars to destroy Bitcoin, we'll just create Bitcoin2 and maybe he'll spend another few billion destroying that. We can keep creating new crypto-currencies indefinitely. If each one gets a few billion dollars out of the hands of some evil entity, that's a win in my book.


How public key is calculated from a base58 encoded private key? I followed this post and created a private key for bitcoin wallet. The post says after finding the random 256 bit(32 bytes) integer the version number should be prepended and the checksum should be appended to it. This produces a 37 bytes hex.
Now I am trying to find the public key associated with this private key.I learnt that the PUBLIC key is calculated by applying ECDSA secp256k1 curve on the private key. But only 32 bytes is accepted as input by the ECDSA algorithm.
So what am I doing wrong?
Thanks in advance.

The private key is just the 32B entropy you generated. Between wallets this private key can be encoded in a format, which provides further information such as the network(main/test/alt) and whether a compressed or uncompressed public key was used. This encoding is called the Wallet Import Format.

version (1B) (0x80 mainnet/0xEF testnet)
privatekey (32B)
0x01 compressionmarker (1B)
checksum (4B)

https://teachbitcoin.io/wallets.html#/2

Checksum is of everything which precedes it. The data is finally encoded in base58.

To take this WIF data and produce the public key, the wallet just needs to extract the private key 32B) and compute the public key point

private_key * Generator_point = public_key(x,y)

The resulting x, y public key point is your public key. If the compression market is on, take the x-coordinate and prepend a 0x02 or 0x03 depending on whether it is even or odd.

compressed public key: 0x02/0x03 + x_coordinate(32B)
uncompressed public key: 0x04 + x_coordinate(32B) + y_coordinate(32B)


Could not update Copay to 5.2.0 After you release about "Statement on NPM Package Vulnerability in v5.0.2-5.1.0 of Copay Wallets".
I could not update the wallet to 5.2.0. In App Store there is only 5.1.0 version.
Iphone 5se, iOS 12.1
What should I do? And hoe to secure my funds?

To clarify: CoPay has no relation to Bitcoin.SE, it was CoPay that issued that statement regarding the vulnerability. Bitcoin is a decentralized cryptocurrency, and Bitcoin.SE is a technical Q/A help site.

The statement released by CoPay/BitPay says the following:

  A security update version (5.2.0) has been released and will be available for all Copay and BitPay wallet users in the app stores momentarily.

If you do not see the v5.2.0 app available yet, I would suspect it will be available shortly. In the meantime, according to the statement above, do not open or run the old version of the app. Wait until the updated app is published, and then upgrade your app and follow any instructions provided by CoPay/Bitpay.


Multiple Inclusion of Transactions in a block If two miners pick up exactly the same transaction for mining, how do we ensure that the transaction is not included in the two different blocks created by each of the two miners.

It doesn't matter if it's included in 10 blocks, as far as one of them will survive in the longest chain.

All others will be in obsolete forks or orphaned blocks.


Can Litecoins be traded directly to Bitcoin? Can Litecoins be traded directly to Bitcoin?
If I have Litecoin, can I change for Bitcoin?
Just like Euro for U.S. dollar.

Yes, if you find an exchange or person that will accept the trade. Various major exchanges offer the LTCBTC trading pair. Also, there are a few coin swap products out there. I'm not writing any names because I've never used them. Shouldn't be hard to do an Internet search for those services and apps.
If you are asking about an on-chain exchange, that has been done too. The search term is atomic swap (Lighting Network).


How to determine right address from address hash I'm using private libbitcoin server and libbitcoin explorer.
When I use bx fetxh-transaction, it returns something like:

I'm trying to figure out, how to get right address from address_hash.
When I use bx base58check-encode for input address_hash without version (or -v 0) it returns:

When I use bx base58check-encode -v 5 it returns:

Check by blockexplorer shows the second way is right.
My question is: How to determine base58check-encode version to generate right address?

Thank you.

Your address 32feVAD9Haq1CtfT6JCLTt4L5qef3UnVpY is a P2SH mainnet address, with a 05 address prefix and represents the base58 encoding of the following data:

[05][20-byte hash][4-byte checksum]

So, the [05] prefix tells your wallet that your address represents a P2SH embedded script presage (20B).

On the other hand, a [00] prefix tells your wallet that the 20B digest represents a Public-Key-Hash, and that funds should be sent to a P2PKH (Pay-2-Public-Key-Hash) output.

The version number therefore gives your wallet the necessary information to produce the correct output type when sending funds, so that the recipient has the private keys (P2PKH) or presage (P2SH) to spend them.

The 05 prefix translates to a 3 in base58 encoding, which is why your addresses begin with 3. I cannot comment on what the embedded script type is though, since the P2SH has is simply the 20B hash-digest thereof. Perhaps a P2SH(P2WPKH) script type.

Amended Answer:

To determine the address version appropriate for a specific output from a transaction, simply look at the output script in question.

P2PKH: "hash160 [20B] equal" -> version 5
P2SH: "dup hash160 [20B] equalverify checksig" -> version 0
P2WPKH: "[00] [20B]" -> bech32 address


In a given contract, should the "LockTime" timestamp include an extra hour for confirmations to prevent a double spend? Anytime a transaction has a timestamp attached to it, and there are signed but not submitted transactions at play, shouldn't the holder of the non-submitted tx have to take into account the confirmations w.r.t. the expiration time?

Namely in example 7 of this wiki page on contracts I would think that if the AP waits until nearly midnight (almost when the tx expires) then there is a possibility of a double spend and the AP may not get paid.  That means the AP would have to submit the tx 6 confirmations early... almost one hour.

Is this a correct understanding of locktime in relation to double spend attacks?
How should this be handled when the network is rapidly increasing in block generation (and difficulty hasn't been adjusted)?  This is happening now with the GPU-> ASIC conversion

The nLockTime is the earliest time that a miner can include that transaction in a block.  It does not mean the exact time that both parties can assume final settlement has occurred.

You are correct to conclude that there is the potential for another transaction (with nLockTime = 0) to be broadcast and be in competition at the same time as the
original nLockTime > 0) transaction.

But it wouldn't necessarily be a double spend, as the transaction seen later with the nLockTime = 0 would have had to have been signed by both parties.

If a "double spend" scenario occurs, it wouldn't be a surprise to either party.

The situation can occur where the two parties believe the nLockTime = 0 transaction will be the one confirmed and for whatever reason it doesn't get confirmed fast enough.  Instead then at the original transaction's nLockTime (roughly, as there is a couple hour leeway available to the miner as far as timestamp goes) that transaction confirms and thus the transaction submitted later (where nLockTime = 0) will never confirm.

So the normal confirmation level threshold (e.g., six confirmations) still applies to these transactions as far as final settlement goes.


How does one manage the shifts of Channel Balances in the Lightning Network I saw the video below that shows the possibility of a shift in Channel Balances. It shows that the amount that one uses to fund a channel may "disappear" if the channel is used as part of a route to fulfill the payment for someone else.

Someone Else --> Me --> Store

https://youtu.be/pOZaLbUUZUs?t=2m18s

It this scenario:

-> I get ready to go to the store
-> I establish a payment channel between myself and the store and add $100 USD to it
-> Someone else uses my channel (i.e. me) as part of their payment routing - a go-between - to pay the same store (since they don't have
a direct channel to the store).
-> My direct channel to the store is now empty of funds.

How does one come about this problem?

TIA

It's actually a non problem deliberately set up in this video as a strawman. Professionally produced FUD.

In practice you're very unlikely to have a direct channel with the specific store in the first place, since for privacy reasons you actually want to be separated from that store at least 3 hops. But in either case you'd simply route your payment in the other direction through a different route towards that store. That's the whole point of this thing being a network. Payments can flow in both directions and the network is full of cycles.


Where is the block reward system coded in Bitcoin core? I'm taking a look at Bitcoin core and am looking for where the TX is effectively "generated" and send out to an address. I've found the nSubsidy block reward, but I'm currently looking for where the transaction is sent out and recorded on the blockchain. If I don't understand something right, please correct me, otherwise, if you have an answer please tell me!

The coinbase transaction is added to a block template by a miner:

https://github.com/bitcoin/bitcoin/blob/4af01b37d40246cd1fdb54719855927e36a36b46/src/miner.cpp#L157-L167

When the block is solved, the entire block is broadcast to the network.

Outside of a new block, you'll never see a subsidy transaction being broadcast on their own. Here's the logic that rejects subsidy transactions from mempool acceptance:

https://github.com/bitcoin/bitcoin/blob/4af01b37d40246cd1fdb54719855927e36a36b46/src/validation.cpp#L575-L577


understanding timestamp from blockexplorer.com What is the timestamp used for the blocks on blockexplorer.com
For example block 233969 has:
Time: 2013-04-30 23:27:36

is this time converted to 32bit hex for hash calculation, if so how ?

In the network protocol, times are represented as Unix timestamps stored as unsigned 32-bit integers.

  is this time converted to 32bit hex for hash calculation, if so how ?

Bitcoin uses a binary protocol. Nothing is hex. When viewing the binary data, your tools may display the data in hex, but you can't directly use these hex characters for hashing, etc.


Probablity that a Bitcoin has been Lost I am building some new metrics to better understand the Bitcoin economy and one that seems to be useful is a probabilistic notion that a Bitcoin has been lost. I'm aware of the bitcoin days destroyed, but has anyone done any modeling to gain a sense if a Bitcoin has been destroyed as a result of a lost key or a transaction to a bad address?

There is no way to determine (that I can imagine) the number of lost private keys, you would have to make a guess that after x years without movement the private key is lost but that would just be a guess.


What is the difference between the mnemonic and the private key? My thinking so far:

If I have a private number, then I can use that as the private key.

If I have a mnemonic, I can match up each word to a number in the wordlist to get the seed, which is the private key.

Is this correct?

Your mnemonic is creating an extending private key for deterministic wallets, which is different than a WIF Private Key. An extended private key can deterministicly generate millions of private keys, so that you can regenerate all those same addresses in the future as long as you have the extended private key or your mnemonic seed.

Example of extended private key:
xprv9s21ZrQH143K3S4Ab76xBk6gRfR2Z7Di2m1x75R8bLp6uETwpxB7A6KbbbEu4gPaEqSic6HCKBDAScGMpSHinsxJii7ao3EDWHDZixRp7g2

Here's a tool that can help show more of what's going on behind the scenes with a mnemonic https://iancoleman.io/bip39/


Could bitcoin "survive" a definitive hard fork, spawning a new currency? What happens if two different groups have a definitive disagreement about the evolution of the bitcoin protocol? I have read is several places that the "majority" somehow would win, but is this really true, or could two different branches (A and B) of the blockchain (now tree) survive indefinitely in parallel?

I imagine that since the coins can be spent twice, once in each branch, they would somehow have their effective value halved. Suppose I'm a supporter of branch B, I would want to sell the A versions of my coins to buy more B-coins. The exact exchange ratio between the two new type of coins would depends on the relative size of the two communities. Is this scenario plausible, or is it economically unstable?

You've described it very accurately. When there's a protocol change that not everyone adopts, you'll have essentially two different currencies, with any coin in the original currency turning into a coin in each of the new block chains. The total value of the coins in both chains will be roughly equal to the total value of the coins in the original currency. The division of value between the two currencies will depend on the respective demand.

However, if both currencies use the name "Bitcoin" to describe themselves, it will be very confusing, and will make both less usable because it's hard to know what someone means when he says "Bitcoin".


Sending and Receiving Mechanics I'm new to Bitcoin and am considering allowing people to pay for my software with them. Before I continue I would like to clarify some things. My googling did not get me the answers I was after.

I understand that you can create new addresses for each transaction. Say I have 1BTC paid to A and 1BTC paid to B.

On the overview tab of the default Bitcoin client, the balance would be displayed as 2BTC. I can only assume it has simply added up all the amounts in A and B address?

But when I send 2BTC to address C, does it create a new 'sending address' X and move to amounts from A and B to X and then send to C or send two transactions, one from each account A and B?

The coin selection that the client does is performed behind the scenes, the client takes care of the details.

But if you are curious to know what happens behind the scenes:

INPUT:

Address: A  1.0 BTC
Address: B  1.0 BTC

OUTPUT:

Address: C  2.0 BTC

FEE (derived as inputs - outputs): 0.0 BTC

This is assuming you didn't pay a fee.

Let's say instead you only were to pay 1.5 BTC, and a 0.0005 BTC Fee.

INPUT:

Address: A  1.0 BTC
Address: B  1.0 BTC

OUTPUT:

Address: C  1.5 BTC
Address: D  0.4995 BTC

FEE (derived as inputs - outputs): 0.0005 BTC

Address D was an address from your own wallet that the client chose to receive the change transaction.  Your balance in your wallet will then show 0.49995 BTC.

Here's a technical explanation:

http://en.bitcoin.it/wiki/Transactions


Risks involved choosing my own seed mnemonic? I reading that 'humans are bad at randomness' and one should always let an algorithm choose your seed for you.

While I agree that maybe it's not advised to make my brain wallet 'zoo' x 23 + checksum as an easy to remember phrase, but besides the obvious, what real risks are there to choosing your own seed?

I've also read that if you use the date as your seed's seed (akward phrase, the seed of the random function that my nmemonic seed is created from) then if that is known by an attacker they can use that to crack my wallet really easily.

What else could go wrong? for instance if i decide to use all the food words out the list, but change 1 of those to an easy to remember alternative, then I've a bunch of food words and one randomly out of place non-food word (seams ok to me). Are there brute force algorithms that could take advantage of that?

The BIP39 word list consists of 2048 words.

For a regular, 24 word mnemonic, you have: 2048^23 ways to arrange the non checksummed words. At 1 trillion combinations per second, this would take you  ≈ 3.3×10^46 times the age of the universe to compute, even before you bother checking the checksum options.

Now, let's say that out of these 2048 words, 500 are food items (this is an illustrative example, I haven't actually counted them). Now, your combinations are some combination of 22 items (possibly repeating) from those 500, plus a random word from the 2048.

This evaluates as 500^22 * 2048 * 21. At 1 trillion combinations per second, this would take you ≈ 2.4×10^46 times the age of the universe to compute. While this is still an extremely large number, it is still nearly 30% less than the initial case, which is a non-trivial loss of entropy.

Moreover, if an attacker is able to discover even a few words from your mnemonic (maybe a friend peaked at it while visiting, or you entered a fragment into a scammy wallet before catching on, or any number of other scenarios), your possible combinations go down extremely fast. Even a perceived small loss of entropy can mean the difference between being brute forceable after 6 known words and being brute forceable after 19 known words.

In 2019, with access to reliable entropy generation in nearly every device, it is simply not worth it to attempt to come up with convoluted schemes.


Does address-reuse make Bitcoin private keys vulnerable to quantum computing? Though quantum computing can technically break ECDSA with enough qubits, this has not the greatest implication on btc because public keys are not known as they are protected by the hashing used to create an address.

However, I've noticed online it's been said a few times that reusing addresses may reveal your public key?

Is this true?  Are there times your public key is revealed and quantum computers become a legitimate threat?

The simple explanation is that the attacks that quantum computing enables require information (the public key) that isn't available until after the first transaction is seen.

Until the first transaction spending an output, all that is known is the hashed version of the recipient key (aka the address) which isn't enough to mount the attack.  If fully developed quantum computers appear with no warning and somehow make it into the hands of a large miner they could potentially see an incoming transaction and race the transaction but the odds of this are vanishingly small.  Most likely, as QC becomes more of a danger, the algorithms in bitcoin will be swapped out for QC resistant ones.


Google's Sycamore processor has parallel-processed 2^53 states. Is this a threat to Bitcoin? Today, Google's Sycamore quantum computer has been confirmed to process 53 qubits in parallel.

In practical terms, for non-quantum experts, how relevant is this breakthrough in terms of secp256k1 and SHA256?

Does this new development come earlier than expected or is it within Bitcoin's predicted quantum safety margin, by which we'd have a couple of decades before quantum computing threatens the cryptocurrency's "mathematical shields"?

Reference: Quantum computing takes flight

First of all, it's important to note that Google's Sycamore has not (yet) processed any quantum algorithm, but instead has just proved that the quantum processor is capable of maintain quantum effects on all 53 qubits during operations. This is important because there's still controversy on if all quantum computers built to date exhibit real quantum advantages.

In order for this processor to become a "practical" quantum computer, also measurement physical errors must be lowered.

Also, to make computations that can actually break current cryptography algorithms, the number of qubits must probably be raised, to around 1000 or more, all depending on how low the error rate will be.

And answering the second question, no, this result is in line with prospections on quantum computing, so the (optimistic) estimations of around as early as 2027-2040 to break ECDS still maintain. But all depends on current trends that nobody knows if can be maintained or not, as this is all based on cutting-edge engineering and mathematical advances.

Also note the link indicated by @ugam-kamat regarding practical mathematical implementation of cryptography breaking algorithms that also points to a minimum of around a thousand usable qubits to break nowadays signatures. This would also raise the real number of needed qubits by some factor n>1 (n>>1?), as the previous noted increment was due to measurements errors which would still apply as the number of qubits raises.


Bitcoin wallet address format representation I want to send coins from my ether wallet to another bitcoin wallet that I have got.
I entered my bitcoin wallet receiving address, but MyEtherWallet transaction convert it to another address format that starts with '0x' and I think it's hexadcimal.

How can I know for sure that this address is actually related to the address that I typed??
I am looking for external generator to verify myself that the receiving address that my boitcoin wallet displayed turned into the hexadecimal code they show

You are trying to transact with two different types of cryptocurrency.

You cannot send/receive Bitcoin from an Ethereum wallet and vice versa.


Is there any guarantee that mining will be profitable? I'm not a money person. I deal with it only out of necessity. So say I have $1000.00 worth of Bitcoin and decide to enter the world of "mining". What's the physical process on my end and is there any guarantee that I will come out ahead?

There is no guarantee of profitability for any miner. What's more is that it is extremely difficult to estimate how profitable it will be because there are unpredictable variables involved. The mining difficulty is regularly re-targeted to account for increased mining power. The market exchange rate for BTC into dollars (or whatever currency your electricity bill is presumably paid in) fluctuates wildly, and the value of fees paid by users varies depending on mempool size or speed they wish to have confirmations. These variables are entirely out of anybody's control because they're a result of the actions of individuals.

Mining has been largely profitable due to the block subsidy which halves every 4 years. There is no guarantee that mining will remain profitable for existing miners when the next subsidy halving occurs (in 2021). If mining becomes unprofitable for them, they will have to scale back their operations or shut down and auction off their mining equipment. This will cause the difficulty to lower temporarily, which may make it profitable for new market entrants willing to take the risk.

Ultimately, mining is a risk-taking business and may never pay off. There are some obvious ways to try and increase your chance of becoming profitable though: Find the cheapest source of electricity you can and get the most efficient mining hardware for your price point.


What are the specific interactions between a Wallet client/node and a Miner? I'm researching the interactions between a Wallet and a Miner.  Although I'm also interested in the high level sequence of operations, I'm also interested in discovering the protocol and verbs used in the TCP connection.

  What are the specific interactions between a Wallet client/node and a Miner?

A wallet is used by a client to store Bitcoin Addresses. The standard client can be ran in a server mode, which will allow it to take HTTP JSON RPC commands. One of them is "getwork" - a standard command used by miners to get data to hash. The standard client creates new blocks crediting one of the addresses in its wallet with the block reward. A miner can submit finished work to the client to help it solve it.

This solution is not ideal for most miners, as the use of pools as an intermediary between a client and a miner allow the block reward to be split between them.


error: Authorization failed: Incorrect rpcuser or rpcpassword After installing bitcoin on CentOS/AWS, an error occurs when connecting with cli.

$ bitcoind -daemon -conf=/.bitcoin/bitcoin.conf
Bitcoin server starting
$ bitcoin-cli getbalance
error: Authorization failed: Incorrect rpcuser or rpcpassword

The following is bitcoin.conf.

mainnet = 1
txindex = 1
server = 1
rest = 1
rpcuser = a
rpcpassword = a
rpcport = 8332

In case you changed your /etc/systemd/system/bitcoind.service make sure you run
 sudo systemctl stop bitcoind
 sudo systemctl daemon-reload
 sudo systemctl start bitcoind

to apply the changes.


How Ripple is different from Bitcoin and other crypto-currencies? How Ripple is different from bitcoin and other crypto-currencies? What does Ripple do that is different from bitcoin?

Riple and Bitcoin are two different implementation of p2p currency and fund transfer protocol. Similar constructs exist both the sides, like bitcoin block chain vs. Ripple ledger, both systems support irreversible transactions, distributed, p2p (eliminates third party and banks), etc.

One difference I noticed, is transaction fees is lower in case of Ripple.

There are several major differences. Bitcoin is a currency with a built in payment system for its currency. The XRP Ledger is a payment system for arbitrary currencies with support for cross-currency transactions.

One big difference is that currencies (other than XRP) are represented as debts (IOUs) on the ledger. This is much the way currencies are represented in the conventional banking system. When you say, "I have $5,000 in my bank account", what you mean is that the bank owes you $5,000. When you write someone a check, you are transferring debt so that their bank owes them more money and thus they consider you to have paid them. Ripple works this same way -- payments occur by a transfer of debt (IOU).

You can generally get a Bitcoin transaction through for free if you're patient. XRP Ledger transactions always have an XRP cost. In practice, this cost should remain very low. Transaction fees are destroyed on the XRP Ledger, they aren't paid to anyone.

XRP Ledger payments that use assets other than XRP can incur fees other than transaction fees. It is hoped that competition will keep these costs low. If your payment requires using someone else's liquidity, they can impose a fee for that liquidity. IOU issuers can impose fees on transfers of IOUs.

XRP Ledger transactions should confirm more quickly, typically in under 10 seconds.

While the XRP Ledger is designed to operate without a central authority, currently almost all validating servers are operated or managed by Ripple Labs. So it's not fully distributed yet in that sense, but it will be. Currently, most XRP (the units used to pay transaction fees) are held by Ripple Labs.

It is also important to understand that using the XRP Ledger as a store of value for fiat currencies imposes a counter-party risk. If you hold dollars on the ledger, someone you have chosen to trust owes you those dollars. If you misplace trust, you can wind up with uncollectable IOUs.

The ledger can uss gateways, companies that make it their business to make "settle on demand" agreements with people, to hold IOUs. The ledger is much less useful for payments of fiat currencies if there aren't reliable gateways you can trust to hold your money.

In function, the XRP Ledger's way of handling assets other than XRP is more like PayPal or Visa than Bitcoin. But its internal implementation is based on the same technologies Bitcoin uses -- public transactions, no central authorities, cryptographically secured transactions, peer-to-peer transaction propagation, and so on. One key difference is that people who choose to use assets issued by different counterparties can seamlessly exchange value with each other through a distributed exchange. So there's a huge interoperability benefit.


What can 1 master public key in a multisig reveal? Assume you have the following situation:
You are going to create a new multisig wallet with Electrum.
2 signatures are from old hardware wallets and 1 signature is brand new.

The new multisig will only be used with Electrum and Electrum personal server connected to Bitcoin Core. The 2 old signatures from the hardware wallets has been used with the hardware wallets own wallets (like Ledger Live and Trezor Wallet). Then I guess we can assume that the master public keys from those 2 wallets has been uploaded to some server somewhere and could be "leaked".

From a privacy standpoint, if I create a new multisig, is it possible to get any information from the 2 old master public keys? Or, do you need all 3 keys?

Would it be a good practice to create two new master public keys (by "reinstalling" the old hardware wallets) and create a new multisig with 3 brand new keys (and treat them with more care in the future)? Or is it fine, because 1 key is new?

From a security perspective related to spending bitcoins, since only the master public keys have been compromised, there is no way that the attackers can derive the child public keys as they do not have access to the chain code. However, if the chain code is also revealed, there is no way to derive child private keys and hence the attacker cannot spend the funds. So if you are trying to create transactions with 1-of-3 or 2-of-3 multi-sig, the attacker still does not have access to the signatures (since he does not have the private keys)

However, if you are going to create a P2SH address of all the 3 public keys involved, there is no way anyone can recreate this address even if they know the 2 of the 3 public keys.


Is it safe to keep ONLY a time-locked tx? What if the tx become incompatible with future versions of Bitcoin? In which cases it would just stop being compatible? If there is no compatibility guarantee, how can this be useful at all?

It should be, since all changes to the Bitcoin protocol should be agreed on by the entire community. However, there is no way to guarantee a softfork can't be abused, or even necessarily invalidate such a transaction, and there has recently been hardfork efforts by incompetent people to promote breaking compatibility, so I would advise against relying on it at this time.


Could decentralised proof of time in BCHSV solve for high PoW power consumption? 0-conf requires decentralised consensus of time in order to determine the order and time of each transaction.

Bitcoin has a block time of 10 minutes achieved by brute forcing hashing algorithms of variable difficulty at enormous scale with a difficulty optimised for it to be solved in ~10 mins. This is what gives the currency its security.

With decentralised time consensus such as that required for 0-conf, would it not theoretically be possible to enforce a 10 minute block time by instead implementing the following conditions:

Each block submission must contain at least one transaction that has been entered 9mins 55secs after the previous block (ie: No incentive to mine until 5 seconds before 10 min block time)
Difficulty optimised to allow the network to solve the block within ~5 seconds
In the case of conflict within the 5 second challenge period, lowest hash in bit value wins
In the case of conflict after the 5 second challenge period, first hash wins
Network decides any further split in consensus thereafter by longest chain as it does now

Assuming this would be doable, would it not technically be possible to secure Bitcoin with the same hashrate it has now, but consume 0.0083% as much power, and make mining far more profitable for miners (especially in countries that don't have cheap energy) with no loss of security?

Mining is the timestamp in Bitcoin, it allows for a decentralized system to achieve synchronized ordering of transactions with high probability. If a system for doing decentralized time sync existed there would be no need for mining blocks at all, you'd simply timestamp transactions as they arrived and call it a day.

No system for this exists, hence we use Proof of Work to achieve an approximation.


Economic effect of Bitcoin I am an accounting student and I recently read about bitcoins, I was wondering if anybody could clear up my questions from my basic understanding of the bitcoin system.

Since Bitcoins on a whole, derive its uniqueness from the system of maintenance of a public ledger and an important part of this, are the miners, who are provided an incentive in bitcoins for for their hash creation. The cost of hashing and recording it in the public ledger is technically, the bit coins paid to the miner. My questions are

- Who bears the burden of the cost? Is it the user or is it the network?

- If its borne by the network, wouldn't this cause an increase in circulation      of bitcoins in a network and lead to reduction in their value making them unstable?

- If the this cost is borne by the user, then how does it make it an alternative to native banking transaction cost?

2) Based on what I have read online, so far, the circulation of bitcoins is capped of to a certain limit to prevent deflation but my question is

- If the mining of bitcoins also lead to circulation increase, how can the system handle the volume of transaction relating to a global economy? How would this effect the public book keeping system and the miners ?

Can somebody please help me understand this ?

Who bears the burden of the cost ? Is it the user or is it the network?

Just like what happens when more dollars are printed, the value of all the existing currency goes down.

  If its borne by the network, wouldn't this cause an increase in circulation of bitcoins in a network and lead to reduction in their value making them unstable?

It leads to a predictable increase in the total supply. There's no reason to expect a predictable change in supply to cause instability in value.

Think about oil, for example. If there are unexpected changes in the supply of oil, then the price will jump in response. But if we knew that the supply of oil would increase at a very predictable rate that changed only gradually, there would be no such jumps.

  If the this cost is borne by the user, then how does it make it an alternative to native banking transaction cost?

The idea is that by reducing transaction costs relative to existing cross-border payment systems, the Bitcoin system will create enough value to pay the miners and still be competitive. The mining reward drops over time, so it doesn't need to produce value forever to hold its value.

  If the mining of bitcoins also lead to circulation increase, how can the system handle the volume of transaction relating to a global economy? How would this effect the public book keeping system and the miners ?

The number of transactions or their size has no effect on the generation of Bitcoins which occurs on a predictable schedule up to the fixed limit at which time it stops.


CryptoGraffiti.info litecoin alternative I have some pictures and litecoins, and I would like to be able to upload images to the litecoin blockchain. I also have some bitcoin, but, because of the higher value of bitcoin, I think I would prefer to use the litecoin because it allows more uploads. There is a site called CryptoGraffiti.info that charges bitcoin and bitcoin SV. I thought about using the bitcoin SV, but that would require buying additional crypto, which I can afford (the big BTC, only a couple images for hundreds of $) and Litecoin is both significantly cheaper and more well maintained than Bitcoin SV. So, I want to know how to upload an image to litecoin using this type of tool.

Note: I want to use this to upload original pictures of things like New York City  and my home town.

I can't find much on writing data to the litecoin blockchain, you might need to code something yourself, perhaps taking the data you want to upload, chunk it and write it by using many transactions. To read it back you need to read these transactions from the blockchain and put the data chunks back together.

If I were you I would look into Ethereum instead. Ethereum has the ability to let you write customized smart contracts that can accept files/pictures data and store it forever on the Eth blockchain. If this gets too expensive you can offload storage using IPFS, so that the Eth blockchain would need to store only the hash of the files instead of the whole files.


C# library for exploring Bitcoin Cash blockchain Does anyone know of a good C# library which would enable me to explore the Bitcoin Cash blockchain by communicating with my own node?

Something like Nethereum (Web3) for Ethereum.

Or, alternatively, a third-party API provider, like BlockCypher for Bitcoin.

Since "Bitcoin Cash" is a fork of Bitcoin Core, you should be able to use the BitcoinLib C# Library to interact with a Bitcoin Cash node.


Is there a decentralized zk-SNARK (zero-knowledge Succinct Non-Interactive ARgument of Knowledge)? Normally, in zk-SNARK, we need to generate two public keys: one for prover and one for verifier. However, the input parameter of this generator algorithm must be secret, meaning that it must be hidden for both prover and verifier.

And because of this, the process of those public generation is done by a trusted third party.

Since using a trusted third party is not desirable for decentralized blockchain, I am looking for a decentralized approach of those public key generation. Is there ? or it's impossible to have a decentralized zk-SNARK ?

P.S. More information about zk-SNARK is found here: https://media.consensys.net/introduction-to-zksnarks-with-examples-3283b554fc3b

Here's Zcash's multi-party parameter calculation code, which...

  ... used a multi-party computation protocol with the property that the resulting parameters are secure unless all of the participants were dishonest or compromised during the ceremony.

By the way, you might find Bulletproofs more interesting which is newer and doesn't require a trusted setup.


Connecting Genesis Mining to a bitcoin wallet I am a noob to bitcoin and want to know a few things-:

I saw the Genesis Mining pricing here. Now my question is that if I use cloud mining can I transfer that amount to my Bitcoin wallet ? Like CoinBase or Bitcoin core ?

Can that be done in Genesis Mining ?

Yes, the payouts can be send to your Bitcoin wallet.

But as with all cloud mining services, they would not offer that service if they would not make any profit with it. Instead of investing $ 2400 on life time 10 TH/s mining, have you considered just buying Bitcoin worth $ 2400?

I tend to tell people to be cautious with such services and do the maths properly in advance. Let me do it for you:

10 TH/s, 2400 USD, 0 electricity, 0 fees:

You would lose around 1562 USD on that deal.


what if someone tries to finish public keys by non-stop creating Lets say one big company or country start a war against bitcoin and they have very powerful machines. What happens if they starts to create public key all the time? Is it possible to finish all the public keys?

Yes, in theory but it would take so long that neither you, nor I will still be alive by a long shot.

At about 10,000 key pairs per second, with an address space of 2^160, it would take you 50 tredecillion years to finish.

Thats 50,000,000,000,000,000,000,000,000,000,000,000,000,000,000 years
To put that into perspective, the age of the universe is about 13,000,000,000 years


What exactly would need to be added to Bitcoin to support Zerocoin? I have read some information about Zerocoin, but not the actual paper.

My question is - what exactly would need to be added to Bitcoin full nodes in order to implement it?

Just the special "zerocoin mint" and "zerocoin spend" transactions? Are they some special, non-standard transactions?

I found out that it's explained quite exactly here

https://github.com/Zerocoin/libzerocoin/wiki/Integrating-with-bitcoin-clients


Any studies on minimum USD value needed on BTC to make mining worth the cost? My understanding of the Bitcoin ecosystem is that the task referred to as "mining" is actually the processing (confirming) of the Bitcoin transactions, and that the miner "finds" a coin when they find the accepted hash of a block of transactions.

Based on the information in other questions here, the mathematical difficulty of processing the transactions is expected to increase as more Bitcoins enter the ecosystem while at the same time the block reward is expected to halve at every 210,000 blocks.

The mathematical difficulty present in the mining process has of course a bearing on the cost of electricity and processing time of the hardware. On top of that the miners do have costs for paying for the warehouse or other location where the server farms are kept, besides indirect costs in things like depreciation of the hardware.

Currently we also have the situation that the USD value of BTC has been going down.

With this in mind I wanted to ask if there are any studies about the minimum USD value that Bitcoin should have in order to make mining profitable?

I don't think a study is necessary - logic should suffice.

The difficulty of the hashing "puzzle" (how many zeroes the hash must start with) is automatically calculated based on the current hashing power - ie. how many miners are trying to solve the puzzle.

The difficulty is calculated so that the average time to mine a block is always around 10 minutes. No matter how many miners are trying to solve it.

...so if the dollar-value of bitcoin goes down it will lead to:

The value of the block reward going down - so the incentive to mine drops.
Some miners will then stop mining - because it's no longer profitable for them (who goes first depends on each miners ability to compete - ie. his cost for electricity and so on compared to competing miners - but someone will quit to do something profitable instead).
The combined hashing power of all miners will go down - since there are fewer of them.
The difficulty of the puzzle will self-adjust (it will become easier) - making it more likely for each remaining miner to solve a block and get the (smaller) reward.

And balance is restored... the miners who continued mining will still be able to turn a profit in spite of a lower reward per block.

It will always be profitable for some miners to continue mining - unless of course the value of bitcoin goes all the way to zero.

The point is that whatever the total reward for "finding" a block is (block reward and fees combined) - that is how much will be invested in mining it (minus of course a small profit for the miner - but this is likely only a tiny fraction of the actual reward).

The important point is that the lower the difficulty is, the lower the security is.

If we imagine that value goes all the way down to the point where the total reward for mining a block is for example $1, someone will still be mining - but there will be so few that it will be easy to do a 51% attack: You'd be able to construct an "alternate" history for just $1 per block, so it wouldn't cost much to get the longest chain.

...but the reward for taking over the chain will also be almost nothing - so why bother :)


How to simulate early bitcoin mining? I would like to design an application that involves integrating with the bitcoin mining process. My problem is that I don't have an environment that legitimately mines bitcoins because of hardware expenses. This makes it difficult for me to set up a solution around the bitcoin mining when I can't directly test my software with a newly mined block.

Is it possible to set up an alternate bitcoin network just on my LAN at home that would simulate the first beginnings of the actual bitcoin network (where mining a block is much easier)? Or is there a better to learn the exact specifics of what happens on a computer that successfully mines a block?

Check this: https://en.bitcoin.it/wiki/Testnet

The testnet is an alternative Bitcoin block chain, to be used for testing. This allows application developers or bitcoin testers to experiment, without having to use real bitcoins or worrying about breaking the main bitcoin chain.


Is it possible derive pathes without prive key? If so in which wallet? I implement a webshop, basically it is more than a wehshop a marketplace and I would offer Bitcoin payment. There are 3 roles: buyer, seller, and the marketplace.
The procedure I imagined, that that seller has the private key. Seller derive adresses, where one would epxect the incomes. Seller hands those addresses to marketplace.
When buyer comes and want to purchase a product, marketplace return an address. Marketplace record in DB which buyer and address belongs together. Later Maketplace pull Blockchain, and check wether amount appeared in the specified address. If so, than pruduct can be shipped.
So:
Is it possible derive pathes without prive key? If so in which wallet?

Yes, you can use a hierarchical key ("xpub") to do that. The seller will generate a wallet and provide you with their wallet's "xpub" public key, and they keep the corresponding private key "xprv". You can use the "xpub" to generate addresses for their wallet, and the seller can use their "xprv" private key to spend from those addresses.
I believe most wallet software supports this by default.


What happens if you send BTC to a testnet address? What happens if you send real Bitcoins to a testnet address?

You can't. The version byte for testnet addresses is different, so their addresses start with "m" or "n" rather than a 1 for the real network. A client will see the address as invalid.


How to give Bitcoin wallets as a gift I want to give Bitcoin as a gift to someone that has as little experience with them as I do.

Most importantly, I want to create a wallet (preferably offline, so I can just handover a USB stick with numbers stored on it, but online is also okay if it's with a trusted site) for them without involving their passport picture, email address etc.

I am happy to provide documents/setup 2FA myself as long as that data is not connected to the final wallet

I'm not talking about amounts that would raise any governments suspicion or reporting limits.

I prefer Bitcoin, but if the fact that I'd only purchase fractional coins makes things more difficult, I'm happy with liquid alternatives.

Create a new bitcoin wallet offline with a website like this one
https://walletgenerator.net/
Transfer the amount you want to give to your friend to this new
wallet
Write the private key on a paper and give it to him then explain  that since you have created his wallet he is not the real owner and tell him to do step 1 and 2 by himself if he want to really own his coins


Is it possible for there to be a virus in the blockchain? can a blockchain ever get a 'virus', that continually replicates itself, continues paying for gas (if on the ethereum network) and survives/self-replicates through the blockchain, similar to viruses on a PC?

I don't think it is possible in the way you are describing it.

Even if there was a smart contract which replicates itself and pays transactions and stuff. The thing is, a smart contract cannot act by itself. There has to be a user who initiates the actions. Then the smart contract could send a few transactions, but only within the block where the user started the actions of the smart contract. And as far as I know are smart contracts not able to pay gascosts, so the user itself has to pay for it.

Transactions which send other transactions are executed within the same block. So every action only lasts for one block and the initiating user would have to start the contract over and over again. Additionally there is a limit of executed gas within a block. So the smart contract could only send a few transactions before the block is full and will cancel all further transaction calls.

Besides this initiation issue, I cannot imagine a way how a smart contract could harm people by itself. Only if some other users would send money there, these funds might be lost. But it would be obviously stupid to do so.


Is it correct that more than 160 bits of input data for producing a private key are superfluous? If this is true, when I make a 64 character hexadecimal private key I need only provide randomness for the first 40 characters (40 x 4 bits per character = 160). The remaining 24 characters can be zeros.

No, that's not correct at all. If someone knew that your private key contained 96 zero bits, their search space would be drastically reduced. 256-bit private keys are used because they are the minimum considered sufficient to provide the level of ECDSA security required. 160-bits can be used in the hash function because hash functions get more security per bit than ECDSA does.

You could, however, use 160-bits as a seed to generate a 256-bit ECDSA private key. For example, you could use a SHA-256 hash of a 160-bit seed as your private key with no loss of security. You can even go down to 128-bits with no significant loss of security.


Ripple's fees per transaction I have Toast Wallet in order to store my XRP properly. Now I want to perform my first transaction from my wallet to my exchange in order to understand how it works.

In a note of the Toast Wallet is written:
"The Ripple Network requires a minimum 20 XRP balance at all times and charges fees based on congestion even for failed transactions"

Do you know how much are the charges fees more or less and if even in my case I have to pay that?

With what probability I receive a failed transaction? (supposing I'm typing all address and informations required well) .. [EG If there is a lot of traffic in the network is possible that I receive a refund and so I lost my fees?

How many XRPs can I transfer? Can I transfer only 1 XRP? (obviously I must have 20 XRPs on my balance wallet)

Thanks for the ansewrs,
Marco.

P.S. Sorry for my bad english but I'm Italian :)

The current minimum transaction cost required by the network for a standard transaction is 0.00001 XRP (10 drops). It sometimes increases due to higher than useal load.


Why do people burn Bitcoin or other cryptocurrencies? Burning is the process of destroying some of your tokens.

In the old days, this was done by sending them to an unexistend (or at least unclaimed, as far as known) address. Nowadays, some cryptocurrencies provide special 'burn' calls that can be used instead (and are easier for other parties to prove by that the tokens were burnt).

But wy do people burn their Bitcoin or other cryptocurrencies?

Counterparty coin is one instance I can recall that they burned 20+ bitcoins to prove they are "serious" about their project and from those burned coins they generated counterparty tokens. These tokens can be seen as proof that they are linked to burned bitcoins, but obviously doesn't give them the same bitcoin value. It's more of a: "Hey, I'm serious about my project. Here's proof that I'm going to work on my project by throwing away money, but I'll also generate new coins in its replacement".


Can I synchronize the blockchain on one computer then transfer the files to another? Possible Duplicate:
  Would it be possible to provide a downloadable blockchain that is updated and verified by a mass of people?

If I install and synchronize the official Bitcoin wallet, can I backup/transfer it to another computer, so that when I install Bitcoin wallet on the other computer it doesn't have to spend so much time synchronizing?

Yes. Simplify go into the Bitcoin folder and copy every thing to the new computer. (Make sure you keep wallet.dat safe)


Proper grammar regarding Bulletproofs For non-native speakers talking about Bulletproofs with correct grammar is tricky.
I tried to use the white paper as a reference, but it is not consistent. Even in the abstract it mixes plural and singular.

  Bulletproofs are especially [...] Moreover, Bulletproofs supports...

Should I use plural of singular after Bulletpoofs?
Bulletproofs are often abbreviated as BP. Is this a good abbreviation or BPs or something else would be better?
If BP is the correct way to abbreviate, then how should it be used? "BP is" or "BP are"?

If you're talking about the bulletproofs research or the bulletproofs topic, use "is".

If you're talking about the individual proofs, use "are".

Bulletproofs is shaping the future.
Bulletproofs is an important protocol.
Bulletproofs are short and don't require trusted setup.
Bulletproofs are going to replace the usual signatures.
Bulletproofs is going to replace the current signature protocol.


Installing Bitcoin Core On Raspbian with apt-get Is it possible to install Bitcoin Core on Raspbian OS with just apt-get?

I tried adding the Bitcoin repo using:

sudo add-apt-repository ppa:bitcoin/bitcoin

and I get:

sudo add-apt-repository ppa:bitcoin/bitcoin
Traceback (most recent call last):
  File "/usr/bin/add-apt-repository", line 95, in <module>
    sp = SoftwareProperties(options=options)
  File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 109, in __init__
    self.reload_sourceslist()
  File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 599, in reload_sourceslist
    self.distro.get_sources(self.sourceslist)
  File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 93, in get_sources
    (self.id, self.codename))
aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Raspbian/buster

PPAs are generally specific to ubuntu and usually can't be used with other Debian derivatives like Raspbian. Raspbian specific packages are not available in the bitcoin PPA.

Furthermore, the bitcoin/bitcoin PPA is discontinued and no longer being updated. If you still want to use a PPA to install onto Ubuntu and Ubuntu derived OSes, you can use luke-jr's PPA: https://launchpad.net/~luke-jr/+archive/ubuntu/bitcoincore


Would miners have an advantage by proceeding randomly? If most miners are looking for solving their proof of work in a prescribed order (perhaps preceded by a prescribed way to break down the search space, e.g. by dichotomy); is there not an advantage for a miner (especially a low hash power one) to proceed randomly and try to avoid common search space enumeration patterns where it will be more competitive?

Essentially, everyone is already proceeding randomly, and there is no common search space.

When miners are trying to find a block, everyone works on a different set of candidates: The block reward is paid out through the coinbase transaction. The coinbase transaction's output is specific to the miner because it includes the miner's address as recipient. The coinbase is part of the transaction set that is used to derive the Merkle root. The Merkle root is included in the blockheader. Ergo every mining entity works on different block candidates.
SHA-256 is a cryptographic hash function. One of their properties is that any change in the inputs will cause a completely different output. There is no predictable relation between the change in the input and the change in the output. Therefore, you cannot predict where you will find a block – any new candidate whatsoever could be a valid block. This means that there is no progress towards finding a block, there is no stack of work to power through – it's just random chance. The only way to predict whether a candidate will resolve to a valid block is by actually testing it.

Hence, the only thing that matters to every miner is to check as many unique candidate as possible, meaning that (beside faster hardware or quicker calculation of the hashing) it can only be sped up by making it as fast as possible to iterate through candidates. That's why miners prepare a blockheader and then for the most part only increment the nonce, extranonce, and the timestamp.


How to handle leading 0's (b58 1's) when base58check encoding I'm trying to more fully understand the base58check encoding algorithm.
Unfortunately, I keep running into a problem with how to handle a situation where the base58 value of an input would have leading 0's (1's in base58).
Everywhere I find any information about this online, it simply states that "the data is encoded to avoid having leading 0s, except to represent full '0' bytes in then input."
What I need to understand is:
What is changed in the data (input or output) to avoid/correct this situation in the output string?

Iterate from the beginning until you reach a non-zero byte. Base58 encode the non-zero byte and the following, and add 1s before the base58 string you made for each initial one zero byte (0x00) you counted.
Zero bytes after the first non-zero byte don't need special treatment.
For example, [0, 13, 36], is encoded as 1211 since the value is 1*58^2 and 1 in base58 alphabet is 2. From here, you see that if it's a multiple of 58, no special treatment is needed since the encoding is big endian and the 1s caused by 58's powers are automatically appended to the back


BIP39 hardware wallets Can I migrate from a trezor to a ledger nano s just by using my BIP 39 word list?

It is ok to use a duplicate hardware wallet? I assume it is, but would like to hear your opinion.

Both Trezor and Ledger support BIP 39 so yes they should be compatible.

Having the same keys on both just increases the risk because only one needs to be compromised to steal the coins, but it's not a big risk imo.


Unable to make custom Bitcoin command I'm writing a thesis on Bitcoin system and as a part of my assignment i have to explore Bitcoin-core source code.

I 've downloaded the code, compiled it and manage to run it.
However, I wanted to make a trivial change to the code and add some simple custom command as part of blockchain.cpp.
Problem is that my changes are not visible after i run make and when I run bitcoin-cli -testnet .

I always get:
error code: -32601
error message:
Method not found

Also, i tried commenting out one already functional method and tried to run bitcoin-cli and calling that function and it runs successfully.
NOTE: command "make" runs smoothly and it does detect errors if there are any.

Can someone explain me what is a proper way to make change to bitcoin-core? I am not planning to push any of those changes to master branch, I'm just interested in experimenting with code.

Thanks in advance :)

To add a new RPC, you need to write the function the implements it's action, add the function to the dispatch table, and update bitcoin-cli's type conversion table.

At the bottom of the RPC file you added your function to (in this case, src/rpc/blockchain.cpp, you will see a table that has all of the RPCs in that file as well as some extra information about them like category, name, and argument names. Add your new RPC to that table.

Next, if your command has any arguments which are not strings, open src/rpc/client.cpp and add those arguments to the vRPCConvertParams list there. In that list, you give it the RPC name, the index of the argument that needs to be converted, and the name of that argument.


BIP34, BIP66 and BIP65 should have been enforced at unique block heights. Why do different sources claim different block heights for enforcement? Inconsistent Consensus/Activation of BIPs

BIP34

Activated Block Height 227,835 (BitMEX Reference)

Activated Block Height 227,930 (Bitcoin Developer Reference)

Activated Block Height 227,931 (Github Reference)

BIP66

Activated Block Height 363,724 (Previous Question)

Activated Block Height 363,725 (Github Reference)

Activated Block Height 363,731 (BitMEX Reference)

BIP65

Activated Block Height 388,380 (BitMEX Reference)

Activated Block Height 388,381 (Github Reference)

Confusing Documentation

BIP34 says it activates when 950 out of 1000 blocks signal for Version 2. It is not clear if this includes the current block or refers to previous blocks

BIP66 says it activates when 950 of the previous 1000 blocks signal for Version 3. However, the client notes say 951 of the previous 1001 blocks. Then BIP66 says it activates using the protocol of BIP34. Now we have three possible methods. They do not match up.

Any advice on what is going on here?

I'll start with explaining the confusing documentation.

  BIP34 says it activates when 950 out of 1000 blocks signal for Version 2. It is not clear if this includes the current block or refers to previous blocks

It refers to previous blocks. To determine whether the rules are active for the block at height n, we check whether 950 of the blocks from n-1001 to n-1 signal version 2 or greater.

  BIP66 says it activates when 950 of the previous 1000 blocks signal for Version 3. However, the client notes say 951 of the previous 1001 blocks. Then BIP66 says it activates using the protocol of BIP34. Now we have three possible methods. They do not match up.

There are only two possible methods, and they're actually the same thing. 950 of the previous 1000 block is the same as the BIP 34 method. And this is actually the same thing as the 951 out of the previous 1001 if you consider a slightly different perspective. Either way, BIP 66 uses the same mechanism as BIP 34. Specifically, they use a function called IsSuperMajority to determine whether they are active. So both use the same mechanism. The issue is with how we describe this mechanism.

The "950 out of the previous 1000 blocks" wording used in BIPs is as I described earlier. It is determining whether the rules are being enforced for block n by looking at the 1000 blocks that precede it. So here n is not included in the count or in the sequence.

The "951/1001" wording includes block n. It looks at the blocks from n-1001 to block n (inclusive) and checks whether 951 of those blocks have the right version number. These two wordings are identical because the 1001 one includes the activation block while the 1000 one does not.

One way to think of the 950/1000 is: after seeing a sequence of 1000 blocks where 950 blocks signal the new version, the next block to be mined must follow the new rules. The new rules are about to begin enforcement.

One way to think of the 951/1001 is: after seeing a sequence of 1001 blocks where 951 blocks signal the new version, the 1001st block in that sequence already enforced the new rules and enforcement has already begun.

Basically humans suck at describing things with words. It's all much clearer when you look at the code.

Now onto the discrepancies. I've written a python script that does the IsSuperMajority check to verify these numbers.

BIP 34

I'm not sure where BitMex got their block height from. Checking that height, and ones before and after it do not result in activation. So I believe this is just incorrect.

Now for 277930 vs 277931, this is an interpretation issue. Like I talked about previously with the 950/100 vs 951/1001, this depends on inclusivity and perspective. At height 277930, a sequence of 1000 blocks was found where 950 had block version 2. So this means that at height 277930, the rules were not enforced for that block, but would be for the next one, i.e. 277931. Bitcoin Core uses 277931 because that is the first block that the BIP 34 rules are being enforced for so that is the value that is in the source code.

BIP 66

The 363724 vs 363725 discrepancy is the same thing as the 277930 vs 277931 in BIP 34.

BitMex's number is a little more confusing. The only way that this makes sense is if they are looking at the slightly difficult activation BIP 66 had. Due to miners spy mining, there was an inadvertent chain fork when BIP 66 activated. Block 363725 was the first block where the new rules were to be enforced. However a miner who had not upgraded found a block 363725. Because he was not upgraded, this block was invalid under the new rules and most of the network rejected it. But a many miners did not fully validate that block and mined on top of it. This turned out to be a significant portion of the hashrate and they ended up producing a fork 6 blocks in length before the valid main chain caught up and overtook them. This happened with block 363731. So one could say that is when BIP 66 activated.

But that's not the end of that story. The next day, there was a 3 block fork due to the same issue. So you could also say that BIP 66 activated a day later.

Either way, BIP 66 began being enforced with block 363725 being the first block under the new rules.

BIP 65

The 388380 vs 388381 discrepancy is the same thing as the 277930 vs 277931 in BIP 34.


Why does Bitcoin adjust the difficulty every 2016 instead of 2048 blocks? I am reading Bitcoin wiki and it says

over the previous 2016 blocks. Can be further simplified to
D * 2**32 / 600

without much loss of accuracy.

I guess the reason of reducing to 2**32 is for computing convenience (bit operation). However, 0xffffff / 2016 = 32.507440476190474 and 0xffffff / 2048 = 31.99951171875 which is more accurate.
Why was 2016 chosen instead of 2048?

2016 blocks at an expected interval of 10 minutes are exactly 14 days. Likely the window for the difficulty period and interval were picked first and 2016 resulted from that.


What are acausal blocks? In this forum post the poster (2112) writes:

It is my understanding that at least Eligius pool isn't a "honest node" and intentionally produces acausal blocks (or at least as close to acausal as they deem practical).

What is an acausal block? Or at least what did the poster mean by "acausal block". From reading the thread I get some idea that it is something to do with messing with the timestamp of the block but don't really understand it.
Perhaps this should be a separate question but does the block miner determine the timestamp that is recorded in that block?

It allows the pool to avoid making new work for every single request. Instead, it just increments the time by a second and gives that to the next miner. Under heavy load (longpolls), Eligius might use the same work for up to 7,200 miners, meaning the last miner gets a work timestamped 2 hours into the future. This helps reduce stale shares significantly.


How to get difficulty for Bitcoin and other coins How do I get access to the latest Bitcoin/Altcoin difficulties from the original "source/network"? I want to develop a C#/.NET application that collect this information.

I know that there are web sites that provide information about Bitcoin and Altcoin difficulty. Coinchoose and Coinwarz provides JSON APIs for example. There are also blockexporers like http://blockexplorer.com/q/nethash/2016 that could give me the current Bitcoin difficulty.

The problem with Coinchoose and Coinwarz is that they are not complete, not fully real-time and Coinwarz cost money in addition to that. The block explorer above is for Bitcoin only. Are there block explorers for all AltCoins as well? And are they all providing different API's?

There must be some "original source", like the mining network or similar, where you can connect and get this information in real-time? Or is that also completely different for each coin? I understand that each coin has its own mining network, but are they different except having different IP-addresses for example?

So the question is basically how do I get access to real-time coin difficulty information for Bitcoins and all other coins - not from an existing web site, but more on the API / programming level?

Bitcoins as well as all of the altcoins that I know of have their own API. For example here is bitcoins API. It has a method called getdifficulty which

  Returns the proof-of-work difficulty as a multiple of the minimum difficulty.

So if you had bitcoind installed, you could then just type in the terminal

bitcoind getdifficulty


I want to transfer my bitcoin but i cannot I want to transfer bitcoin to a wallet adress but when i send it gives me this error
There was a problem sending your transaction Uneconomical UTXO requested [type: 1 (limit 5643), txOut.val: 4123, required: 109544]
What it means and how can i send ?  Please help me thanks

Uneconomical UTXO requested

This usually means the amounts you are trying to send are so incredibly tiny that the transaction fees will cost more (perhaps much much more) than the amount being sent.

See dust

See helpful comments to other similar unanswered questions:

cant send btc, Uneconomical UTXO requested
Uneconomical UTXO requested

Maybe its like using DHL or FedEx to send a small piece of a 1 paisa coin to someone.


Update wallet to multi tokens I don't know if here, I have to ask, but if not, please direct me.
How can I make a wallet accept more coins.
More exactly: I have a wallet BEP2, native currecncies is BNB (Binance). What needs to be done for this wallet to accept other BEP2 tokens.
I didn't try anything because I don't know where to start.
Thank you.

I suggest that you buy a hardware wallet, such as ledger or trezor.
Those wallets are compatible with a wide range of cryptocurrencies. If they do not provide support to a coin, that coin is not worth buying.


Should fractional reserve banking be prohibited through the bitcoin protocol or otherwise, and how could such a change be implemented? There's a massive macroeconomic debate between Keynesians, who want central banks to control the money supply, and Austrians who want no central banks doing any such thing--or at least competing currencies which provide an alternative to central banks which do.  Bitcoin, with its set mining schedule, takes a clear stand against the former and opts for what will in 2033 become a stable/deflationary currency.

A debate which has not been settled, even among hardcore Austrians, is whether fractional reserve banking is good or bad for economies.  Similar to central banks, fractional reserve banking expands the money supply, but not at the fundamental level.  The effect is often the same, however, and the result is booms and inevitable busts as growing loans and investment cycle with contractions and bank runs.

For bitcoin enthusiasts who are skeptical about inflation, fractional reserve banking poses a similar threat.  As long as anyone except you are holding your bitcoins, there's no way to prove that your coins aren't being lent out at any possible reserve ratio.  Gresham's law suggests that 'bad money drives out good', meaning people will first use unsecure, inflationary currencies and hoard better ones.  Since bitcoin aims to be an optimal currency, it should explore avoiding the fate where it is bested by a regime which prevents fractional reserve banking.

My question is:  Can fractional reserve banking be prohibited, technically, a) through a change the bitcoin client itself; b) in a customer-bank protocol; or c) in another cryptocurrency scheme.

I don't know enough about public key cryptography, but I have an inkling that it would involve limiting return addresses, so for example, I send 10 bitcoins to address A, but those bitcoins can ONLY be sent back to an address I provide, and nowhere else.  Could that kind of scheme be implemented at any level, even just as an option?

No, you can't prevent fractional reserve banking technically. For example, IOUs can circulate just like Bitcoins and there's no technical means to stop it. Essentially, anything worth X Bitcoins (once risk and the like are factored in) can act just like X Bitcoins, even if it's not X Bitcoins. And since it's not Bitcoins, nothing Bitcoins can do can stop it.

Unless you foresee some massively powerful central coercive authority that prohibits it, you will always have fractional reserve banking. It just makes too much sense. It will happen absent the use of massive amounts of force.

There are trivial technical fixes to the "run on the banks" problem. However, there is still the very real "the bank is a crook" problem and the "the bank goes broke due to fundamentally unsound loans" problem.


Where do i get parts for diy hardware wallet and program I would like to know where to buy hardware for bitcoin wallet and program

Where do i get parts for diy hardware wallet and program

By DIY I guess you mean not a pre-built product like a Trezor.
Any electonics store or distributor (Mouser, Farnell, etc etc etc) will sell you parts to make any of the open-source options listed in https://en.bitcoin.it/wiki/Hardware_wallet
To pick a random easy example: pi-wallet - though a compute-module or zero-W would be more compact. There's plenty of open-source hand-held, battery-powered gaming devices based on that hardware that could be adapted to suit.
If you are more ambitious, and handy with a soldering iron, you could check out something like BitBox which is apparently based on standard electronics parts. They publish schematics and bill-of-materials for parts as well as the code. You'll not match their production quality but a functional portable device should be achievable with the right skills.


Why does the Segwit developer guide recommend to estimate fees on basis of vsize instead of weight? The Segwit Wallet Development Guide has a small section on fee estimation:

  Transaction Fee Estimation

  Instead of transaction size, a new metric is defined, called “virtual size” (vsize)
  vsize of a transaction equals to 3 times of the size with original serialization, plus the size with new serialization, divide the result by 4 and round up to the next integer. For example, if a transaction is 200 bytes with new serialization, and becomes 99 bytes with marker, flag, and witness removed, the vsize is (99 * 3 + 200) / 4 = 125 with round up.
  vsize of a non-segwit transaction is simply its size
  Transaction fee should be estimated by comparing the vsize with other transactions, not the size.
  Developers should be careful not to make an off-by-4-times mistake in fee estimation.

vsize therefore is a value that allows easy comparison to the previously used transaction size. What is the reason that it is being recommended as the basis of fee estimation? Wouldn't it make more sense to directly calculate fee estimates on the basis of weight?

The advantage of using vsize is that it is a smooth transition from size; every non-witness transaction has vsize equal to size.

All code and infrastructure that used satoshi/byte before, will keep working when substituting size with vsize, and give consistent results. Switching to weight would be confusing - would we be talking about satoshi/weightbyte?


Why does getblocktemplate use priority for transaction selection? I don't know how getblocktemplate works exactly, but it seems to include transactions based on priority.

Selecting transactions based on priority isn't the most profitable method for building a block (as opposed to fee/byte), so is getblocktemplate only going to be used by miners who haven't figured out how to construct their own blocks?

Why would anyone use getblocktemplate otherwise?

Bitcoin transaction priority calculation
https://github.com/bitcoin/bitcoin/blob/86b800c6a299455580fe76e5fb43218f0222e179/src/miner.cpp

Getblocktemplate builds a block based on configuration parameters. In recent versions, the default is to use fee per byte as criterion for the entire block.

History

In versions of Bitcoin up to 0.6, priority based selection was used for the entire block. It was a means to encourage the young Bitcoin economy to grow. However, it also had a minimum transaction fee that increased as the space in blocks grew closer to the limit.

In version 0.7 the -blockprioritysize setting was introduced, which divided blocks in a priority area and a fee area. The priority area was there to support a small number of low-fee transactions to continue, and was limited to 27 kB by default (50 kB since version 0.9). The fee area is sorted by fee per byte, and maximizes total fees for miners.

Recent versions

In Bitcoin Core 0.12 the default setting for the priority size was reduced to 0. It also introduced a more efficient algorithm for selecting transactions, which works suboptimally for the priority area.

In the upcoming Bitcoin Core 0.13 release the algorithm selection algorithm will be improved again and use Child-pays-for-parent (CPFP) logic. This logic uses fees from unconfirmed descendant transactions to determine whether to include parents. It increases the total fees that can be taken compared to the previous algorithm, and allows wallets to increase fees on a transaction by spending its change outputs with higher fee.


What order does Bitcoin Core place the inputs it spends in? What order does Bitcoin core place the inputs it spends in? Is it random? Is it sorted by anything? What, if anything, can you tell about the originator of a transaction by the input ordering?

The inputs are chosen by the function SelectCoins() in CreateTransaction() and then added one by one (without shuffling) to the transaction.

The order is defined by the coin selection (CWallet::SelectCoinsMinConf) which does a random shuffle of the potential useful inputs and a stochastic approximation.

Mind also that Bitcoin-Core's coin selection could be improved and there are several issues and improve proposals ([1], [2], [3])


Bitcoin block maturity and block reward rules According to the Bitcoin wiki:

"When a block becomes an orphan block, all of its valid transactions are re-added to the pool of queued transactions and will be included in another block. The 50 BTC reward for the orphan block will be lost, which is why a network-enforced 100-block maturation time for generations exists."

Ok, so let's say at block height X, two miners produce separate valid blocks - block A and block B. The miners compete with each other to mine on top of these two blocks. Eventually, the chain with block A becomes the longest chain, and thus block B becomes orphaned. However, the chain with block B is more than 100 blocks long (despite it being the shorter chain). Does this mean that, despite block B being orphaned, the miner who mined block B can still spend the block reward?

In addition, consider another scenario: a miner goes back to a previously orphaned block (a block that was orphaned in, say, 2 months ago) and starts mining on top of it. He produces a chain that is 150 blocks long. Although this chain is still shorter than the main chain, according to the 100-block maturation rule, the miner can spend the block rewards of the first 50 blocks of this 150-block orphan chain, right?

I know the scenarios I suggested above are very unlikely to happen in reality, but I'm just curious.......

Split chains can be seen as separate coins, except that a transaction with inputs valid in both chains (maybe a coinbase before the fork) would be valid in both. In that miner's chain, the miner can spend his coinbase. The rest of the nodes will see the transaction as invalid and ignore it, as his block isn't part of the main chain. If the miner wants, the miner can advertise his chain as a "new coin", referencing the first block that is not common, and nodes who would be built to recognize his chain would allow the miner to spend the coinbase transaction.

In the second scenario, the same thing happens. What he does is well-received in his chain, but ignored in the main chain (the chain with the largest proof-of-work)


bitcoind starting and then quickly shutting down automatically Lenovo E460, 8GB RAM,
Fedora 26,
bitcoin core command line version 0.16.0,
All blocks completely downloaded on a flash drive with 256GB capacity.

I rebooted my machine today without stopping the bitcoind before and since then the following happens:
1) starting "bitcoind -daemon -datadir=/path/to/flash/drive"
2) I see with "top" the process 'bitcoind'  running  for about 30-45 seconds
3) Suddenly under same process id the process names changes to "bitcoin-shutdown" and disappears a second after.
4) Stop or new start of bitcoind is not possible, message is "Error: Cannot obtain a lock on data directory /path/to/flash/drive. Bitcoin Core is probably already running."
5) Only way to start bitcoind again is to reboot the linux. Then loop 1)-5) starts again.

Any help appreciated!
Thanks!

The solution is time consuming but easy. The flash drive was finally reporting read/write errors after a harsh shutdown. Formatting it and new install of bitcoind and loading all blocks again (I had no other drive where I could have copied this amount of data to and wanted to exclude potential issues with the old file permissions).

So the next few days I assume the machine will be busy. However now at block 8000 the CPU is only using 1-2% (Intel Core i5 with 8GB RAM on fedora linux)


Is the transaction size relevant if fee per byte is the same? Is the size of the transaction some factor when the miner chooses one transaction over the other, provided that they both have the same fee per byte?
In other words, will the miner prefer larger or smaller transactions if they all have the same fee per byte?

TL;DR: Usually not.
Bitcoin holds a lottery to elect the author of the next block roughly every ten minutes. The participants enter by performing hashes on block candidates ("buying lottery tickets with power expenditure"). The "winning ticket" is found when a miner finds a valid block. Whatever (valid) set of transactions the miner had in their block candidate gets appended to the blockchain. The block includes a transaction that collects the block subsidy and transaction fees and pays it out to the block's author. This "distributed lottery" is used to rate limit updates to the system's shared state, giving everyone time to converge on a single ground-truth. While the block's content must fulfill the rules of the network, the actual selection of transaction for the block happens before consensus is established and is therefore each miner's sole prerogative.
Generally, miners get paid more when they include the transactions with the highest feerate first. If the feerate of the two described transactions is in the range of the next block, they should include both. If only one fits, they should pick the one that maximizes the transaction fees collected from the transactions that fill the remaining space in the block block. If only one fits, presumably preferring the bigger transaction would usually yield more total transaction fees, but for that to matter, the two transactions would need to fall right at the end of the next block.


Is there a minimum size of network for a cryptocurrency to be viable? I am not a technical person, so easy answers will be greatly appreciated.

What is the relevant unit for size of the network for this question? Nodes? Miners? Wallets? Users?
If a cryptocurrency has a very small network, e.g. 10 users, will it have 'technical' (not marketing) problems to function as a currency? (Like protection against hacking, efficiency of transaction speed and cost, etc.)
If yes in #2, what size of network would be required? 1000? 10,000? 100,000?

This question is too broad. It depends on the currency's system. And the figures are rather arbitrary.

Let's focus on bitcoin's proof of work system. Processing power (of miners) is required here to confirm transactions. Protocol adjusts processing power needed to confirm transactions depending on the current processing power.

If total processing power is low it is easy for attacker to enter the network with large processing power (comparable to total current processing power) and execute attack.

So it is important to have huge processing power in the network and that it is as much as possible distributed among the miners.

What is considered huge is arbitrary. What is considered sufficiently distributed is also arbitrary. Currently in bitcoin you have large mining pools that you can considered each a single miner. Don't know how many of these together at the moment have processing power comparable to all other miners.

If 10 mining pools have over 50% of network processing power they can (in some scenarios) collaborate and execute attacks.


Understanding how validation of a transaction works As far as I understood, a transaction works like this:

Alice wants to send 5 BTC to Bob. Alice creates her digital signature that contains transcation info like id etc. She encrypts the signature with her private key. She creates scriptPubKey and scriptSig, she has the Bitcoin-Adress of Bob.

This transaction has to be verified by nodes. A node checks this transaction. He checks if Alice really has 5 BTC by checking her input. If it's ok, then all is fine. The node additionally checks Alice's digital signature. The node extracs Bob's Bitcoin Adress from Alice's signature. If it's ok, the Node puts the transaction to the mempool.

Nothing was mined until here. Now, due to the broadcast system and p2p network of Bitcoin, a Miner picks this transcation from the mempool.

What does he do now? Does he assume, that the transaction is valid or does he check the transaction again ?

If he does not check the transaction again, and assumes, that the transcation is valid, he creates a Merkle-Tree of several transactions, puts it in a block. Uses SHA-256(Blockhash+nonce) and tries to mine.

Is that right, what I've understood so far or did I make a mistake ?

Alice creates her digital signature that contains transcation info like id etc.

The digital signature only applies to certain inputs and outputs within the transaction, depending on the SIGHASH type. The default is SIGHASH_ALL, in which case all inputs and outputs are signed by every participant in the transaction (where one participant equals the required keys for an input). It is possible that all participants are actually the same key (or set of keys for a multisig address).

  She encrypts the signature with her private key.

Nothing is encrypted. The signature is over plaintext data, and the signature is serialized into the tx as is. There is no encryption anywhere.

  She creates scriptPubKey and scriptSig, she has the Bitcoin-Adress of Bob.

The scriptPubKey is created prior to the signing, as it is part of the unsigned transaction in the vout. The scriptSig is created using the signature and the public key (when spending a pay-to-pubkey-hash input), or the redeem script (when spending a pay-to-script-hash input). For segwit addresses, the signature and witness program are not serialize within the input, but are added to a special witness field in the transaction.

  The node extracs Bob's Bitcoin Adress from Alice's signature

Bob's address is part of the vout set in the transaction. It is not included in the signature. In certain SIGHASH types, the output is signed and verified by the signature, but it is not included in it.

  a Miner picks this transcation from the mempool.

Every node maintains its own mempool. The correct flow would be:

The transaction makes its way across the p2p network to the miner's node
The miner's node verifies the transaction
If valid, the tx is added to that node's mempool
The tx may make its way into the block template being mined at some point, depending on the fee.

  he creates a Merkle-Tree of several transactions, puts it in a block. Uses SHA-256(Blockhash+nonce) and tries to mine.

Only the merkle tree root is added to the block header.

The hashing operations are performed on the block header, which contains the nonce.

The merkle tree is not stored anywhere. When needed, it is constructed from the list of transactions in the block.


How can i look into the Blockchain I have read that the blockchain is a public ledger with all transactions of a decentralized community, furthermore i read that everyone can check that ledger for transactions that happened within the network. My question is how i am able to look into the blockchain to check for transactions without using sites like blockchain.info.

All of the transaction history is communicated between peers over a binary gossip protocol. You can request specific blocks, sequences of blocks, or specific transactions, and clients will normally communicate by broadcasting all of the information they receive to other peers they are connected to - enabling each client to stay mostly up-to-date once they've downloaded the historical ledger. It is required that you connect to multiple peers to request information so that you are sure to get up-to-date information if a potentially malicious peer tries to withold information.

If you are already running a full node (which is a software client which uses the above protocol and stores the valid information it receives), then you already have the transaction history on your machine running the software. For Bitcoin Core, the files are stored in the ./store/blocks/ subdirectory of bitcoin's storage directory. The directory contains many files named blkXXXXX.dat, which are serialized sequences of blocks. Each file contains many Block File structures in serial, up to a limit of 128MB per file. The files are numbered ascendingly, with blk00000.dat being the oldest containing the genesis block as its first Block File. The Block File structure mimics the structure of the information of a block message received over the message protocol, except is prefixed with a magic number and size of the block.

Typically, if you want to write a block explorer, it would be simpler to read the information from the block files stored by Bitcoin Core, unless you need your block explorer to contain live information, in which case you will need to get information over the gossip protocol directly, or through Bitcoin Core's ZMQ interface, because the node software only commits confirmed transactions into block files.