Assume I created address#1 and address#2 under same wallet. How to transfer funds? Should I open a channel to do that?

You seem to confuse bitcoin addresses and lightning network ids. If you have a lightning node you have a node pubkey (called the node_id). Of course there is a corresponding private key / secret. From this you can derive bitcoin addresses in your bitcoin wallet that is attached to the lightning node. Those addresses are used to fund your node or to claim funds from channels that for some reason hit the chain.

  Is it possible to send funds from address in lightning network to simple bitcoin address?

As from the first part of the answer. once the channels hit the chain they are in the bitcon network and can be send to any other bitcoin address. There are exchange-services that allow and atomic on/off-chain swap. means you pay in invoice on lightning so that onchain bitcoin arrive at some address and vice versa.

  Are there any ways to choose sender address (in case users created thousands different addresses and user wants to send satoshis on behalf of himself)

If I understand your question correctly I would say it is possible. In the current setting people who offer a custodial wallet service seem to sign all invoices with the node ID of the lightningnode that is powering the custodial wallet. There speaks nothing against giving every user their own secrete and their own node id / bitcoin keys. You could even have virtual payment channels between the exchanges lightning network node that you maintain an run and between the "virtual" nodes of your customers which are basically private and suggest in the routing hints of the invoice to use the lightning node of your service.
In order to do these kinds of tricks you might want to switch to c-lightning as with their plugin infrastructure have an API that allow easier customization for such features.


ScriptSig (coinbase) structure of the Genesis Block

Here is a breakdown of the entire genesis block:

01000000 - version
0000000000000000000000000000000000000000000000000000000000000000 - prev block
3BA3EDFD7A7B12B27AC72C3E67768F617FC81BC3888A51323A9FB8AA4B1E5E4A - merkle root
29AB5F49 - timestamp
FFFF001D - bits
1DAC2B7C - nonce
01 - number of transactions
01000000 - version
01 - input
0000000000000000000000000000000000000000000000000000000000000000FFFFFFFF - prev output
4D - script length
04FFFF001D0104455468652054696D65732030332F4A616E2F32303039204368616E63656C6C6F72206F6E206272696E6B206F66207365636F6E64206261696C6F757420666F722062616E6B73 - scriptsig
FFFFFFFF - sequence
01 - outputs
00F2052A01000000 - 50 BTC
43 - pk_script length
4104678AFDB0FE5548271967F1A67130B7105CD6A828E03909A67962E0EA1F61DEB649F6BC3F4CEF38C4F35504E51EC112DE5C384DF7BA0B8D578A4C702B6BF11D5FAC - pk_script
00000000 - lock time

Decoding the ScriptSig:

04 - push the next 4 bytes to stack
FFFF001D - 4 bytes pushed, they appear to be the same as bits
01 - push the next 1 byte to stack
04 - 1 byte pushed
45 - push the next 69 bytes to stack
5468652054696D65732030332F4A616E2F32303039204368616E63656C6C6F72206F6E206272696E6B206F66207365636F6E64206261696C6F757420666F722062616E6B73 - pushed bytes, "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"

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


Can I use bitcoin-cli estimatefee API for Segwit?

size = 180 * len(inputs) * 34 * len(outputs) + 10

Unless you are using uncompressed keys (which very few wallets do today), this formula is wrong. It should be 148 instead of 180 as compressed keys are 32 bytes shorter than uncompressed keys.

  My question is that can I use bitcoin-cli estimatefee for weight?

No, you cannot. Bitcoin Core's fee estimation works on virtual size which is just the weight divided by 4. So instead you calculate the virtual size instead of the block weight and then you can use the fee estimate.


Why is 'p2pkh:' prepended at the beginning of private key addresses in electrum?

A single private key can lead to different addresses, depending on the script it is used in - These include p2pkh, p2wpkh, p2sh-p2wpkh.

Electrum prepends the script type to the private key during export and import so that it knows which address to derive and check for outputs on.


How do I find a renamed wallet whose name I can't remember?

Place to start - use the linux "file" command, which will show the following for a bitcoin wallet (at least in the client I use)

wallet.dat: Berkeley DB (Btree, version 9, native byte-order)

So - you could run something like:

find / -type f exec file '{U}' \; | grep "Berkeley DB"

That would be a start!


What will bitcoin prices do in the next months as ASIC miners become more widespread?

Difficulty adjusts every 2016 blocks, which is meant to average out to about 2 weeks.

But if you look at MtGox's average trading volume over the past few weeks it has been somewhere between 50K and 100K.  If difficulty remains constant you would expect there to be about 3,600 bitcoins minted per day, or 3-7% of average daily volume.

Also bear in mind that the bitcoins which are minted will be scattered across all the people in all the mining pools that are generating them, so without some concerted action you are very unlikely to see that many coins hitting the market at the same time.

I think that the reality is that the ramp-up of the ASIC manufacturers is such that we're unlikely to see some sort of cliff, either in bitcoin generation rates or in resultant prices.  The only way in which I could see the generation rates being tweaked is if someone built a very powerful ASIC farm and turned it on and off to bring the difficulty up and down at advantageous times.  But then I'd imagine that the developers would step in to tweak the difficulty calculation process to avoid such gaming of the system.


Can I do blind refunds relatively reliably?

Do not use the raw protocol to issue refunds to addresses without first confirming with the sender that this is acceptable.

Most services generate unique addresses for each transaction.  Unless your customer owns the private key to the address from which the initial funds were sent, you can't be sure that they will receive the refund.  Different services have different implementations but if a customer sends you funds from a third party service that uses a single address for payments, the funds would be deducted from their account via a SQL entry and sent through a shared address.  The returned funds would be received by the service but not necessarily by your customer.

You should contact customers and have them confirm a refund address before sending.


If it is only the balance of your channels that is changing I would assume that your node is routing payments. The lightning network is all about forwarding payments.

So the following explains what could have happened assuming you have two channels to a node A and a node B:

  (A)--20sat------40sat--(you)--30sat------50sat--(B)

meaning:

node A has 20 satoshi
your node has 40 satoshi + 30 satoshi = 70 Satoshi
node B has 50 satoshi

Let us assume B wants to pay 15 satoshi to A this does work via lightning and via your node. The channels will update their balance:

  (A)--35sat------25sat--(you)--45sat------35sat--(B)

meaning:

node A has 35 satoshi
List item
your node has 25 satoshi + 45 satoshi = 70 Satoshi
node B has 35 satoshi

Probably your node even takes some routing fee which could have a standard value of at least one satoshi in that case your final balance would look like this

  (A)--35sat------25sat--(you)--46sat------34sat--(B)

meaning:

node A has 35 satoshi
your node has 25 satoshi + 46 satoshi = 71 Satoshi
node B has 34 satoshi


From reading publicly available information it seems the intention of TruCoin is to create a set of stable business fronts that can benefit both the growth of bitcoin and also the company (ofcourse)

As we all know without stable business there will be very little growth. Working in close colaboration with the lead developer of bitcoin gives both a good understand of how to support the specific business metrics that bitcoin may demand when running a live and large e-commerce site.

Other upcoming sites may greatly benefit from any situations that they face and can certainly "test the water" for large organizations to use BTC.


how to calculate transaction bytes of a x BTC? x=0.2

In the simplest typical case, you'll have one input and two outputs (the recipient, and change). So in=1 and out=2. According to the linked formula, the transaction size will be about 160+2*34+10 = 258 bytes. It does not depend on how many bitcoins you are sending.

However, if the money you are sending came from many different sources, you will have many inputs and the transaction will be bigger. Again, this does not depend on the amount of money, but on the complexity of your wallet's history.


What are the different types of spam that the Lightning Network is subject to?

There are three types of spam problem in the Lightning Network. Let's
call them "local","fast" and "slow".
Local spam is someone sending or requesting too much data: that's a simple batter of code with rate limiting etc.
Fast spam is sending many failed payments.  You can't tell what will succeed and you can't blame the sending peer (they may not be the
source).  This attack is free since we only pay on success. The answer
is to require an up-front payment but it has to be small (making sure
your incentive is to succeed) and it should not leak information on
where you are in the path.  I've been unable to find a scheme I'm
happy with though, see my latest attempt here.
Slow spam is sending a long-lived payment. This consumes capacity > 1000x expected for a normal payment and is similarly free (if you fail). The only solution I like here is to penalize slow payments by
requiring proof-of-channel closure but you can't always tell if
the payment was really in the channel and what if the close
transaction pays super-low fees / conflicts?  You need a Merkle tree
of claimed HTLCs, plus onion unwrapping, agreement on valid closes,
handling of fake Merkle trees... all possible but real work.
Summary: We can mitigate some attacks but real fixes need spec
improvements and implementation.  More attention from Smarter People
Than Me (hi!) will help us here.

This question was answered by Rusty Russell on Twitter.


Because fees + 12.5 BTC > 0 + 12.5 BTC. It is a lose for the miner because they could have picked transactions that would have paid them more.


The Zcash testnet is currently in the midst of an upgrade. You need to upgrade your zcashd to at least 1.0.15, and it may be necessary to wait a while because the block frequency is artificially low at the moment.


bitcoin-cli "Could not connect to the server"

I encountered this error message when I have not started bitcoind.exe.
Starting bitcoind.exe solved the problem.


Manage / run commands in a NXT (nxtcoin) client/server via the command line in Linux?

I'm trying to figure this out too.

Instead of running the server interface at http://127.0.0.1:7876 try http://127.0.0.1:7876/test . Looks like a bunch of API calls. I'm playing with it right now.


What are the country-specific cryptocurrency prices on Yahoo finance?

There is a note in the footer under the details for BTC-AUD: Data provided by CryptoCompare

On this page: https://au.finance.yahoo.com/quote/BTC-AUD?p=BTC-AUD


difference between signing a message and signing a p2sh

You cannot. While both message and transaction signing use ECDSA and double sha256, signed messages slightly modify the message such that it is impossible to create a signature that works for that key in a transaction.

Specifically, bitcoin signed messages are prefixed with the string Bitcoin Signed Message:\n (\n is the newline character, not literally \ and n). This means that the data that is actually signed cannot be for a transaction since the data signed for a transaction cannot begin with that string. This design is intentional so that users cannot be tricked into signing a message which can be used in a transaction to take their money.

The output looks different just due to serialization. If the signatures were compatible, you would just deserialize the signed message signature and reserialize it differently. But because the signatures are not compatible, this point is moot.


What method does My Wallet use to encode messages in the blockchain?

Messages are stored in a database at blockchain.info (so that text should probably be changed). For a while it did use the blockchain for storing messages but this was changed after concerns from a few of the core developers.

Concerns were expressed by Matt Corallo here

  Oh god, thats awful...that is quite possibly the worst way to
  implement messages in terms of network load...

and by Gavin Andresen here.

  Yes, please don't create lots of unspendable scriptPubKeys. There are
  more prunable ways of embedding messages into transactions. And there
  are even better ways of associating messages with transactions, so
  only people involved with the transaction can read the message (if
  that's desired).

Here is the message that implementation was changed back to using a centralized database.

  Since a few developers have expressed concern I've changed the notes
  back to the centralised database for now. I still think there are many
  use cases where you might want to contact the owner of an address
  without needing to know an email etc, a decentralised way to do this
  would be great.


Yes - from the bitcoin wiki:

"The original Bitcoin client stores private key information in a file named wallet.dat following the so called "bitkeys" format.

It contains:

keypairs for each of your addresses
transactions done from/to your addresses
user preferences
default key
reserve keys
accounts
a version number
Key pool
Since 0.3.21: information about the current best chain, to be able to rescan automatically when restoring from a backup.
The wallet.dat file is located in the Bitcoin data directory.

It is intended that a wallet file be used on only one installation of Bitcoin at a time. Attempting to clone a wallet file for use on multiple computers will result in "weird behavior"[1].

The format of this file is Berkeley DB. Tools that can manipulate wallet files include pywallet."

Also, there is a tool for viewing these files directly; https://code.google.com/archive/p/bdbvu/


Why this alternative method to mining will fail?

This is actually a good idea in principle. The reason why this method will not work in the Bitcoin setting is that it is not Sybil-resilient. In particular, Bitcoin solves the problem in the anonymous setting, meaning that the parties participating do not know who else is on the network and more specifically do not know how many others are on the network.

If we imagined this idea implemented naively in Bitcoin, one could create a construction as follows: First, somehow maintain a list of all the nodes in the network (while from a network engineering point of view this is difficult, I will argue that, even if it were easy, the method remains insufficient), perhaps by IP. When nodes exit and enter the network, update that list. Every desired interval of time, say every 10 minutes, elect one peer from the network as "leader" in a globally consistent manner such that every node agrees on who is leader. The leader is allowed to produce a block within 10 minutes; regardless of whether they manage to produce a block within this timeframe, a new leader is elected for the next block generation afterwards.

Now let's think what the problem with this construction is: Because IPs are not authenticated and their allocation is somewhat centralized, you could imagine an adversary allocating multiple IP addresses and using one computer to connect to the network from multiple addresses. This increases their probability of being elected leader. An adversary who controls more than 51% of the IPs on the network would then be able to perform 51% attacks. While this might seem implausible, we actually know ways of doing it using, for example, BGP attacks. The critical observation is that such a mechanism would require an assumption of honest majority by IP address, not honest majority by computational power. This is a much stronger assumption than the honest majority by computational power assumption that Bitcoin makes today. Bitcoin's assumption makes it resilient to Sybil attacks because computational power cannot be faked in the same manner that IP address can be.

Lastly, let me say that there exist protocols which use your idea. However, they do not pick a network participant at random by IP address, but use other means for selection. One such example is the Ouroboros BFT protocol in which participants are chosen sequentially to produce blocks -- in this case the population is fixed and does not evolve. Another example is the Ouroboros protocol in which participants are chosen exactly as you describe, but with a weight which is proportional to the amount of money they own in the system -- here the population is evolving as money is changing hands (note that other flavours of Ouroboros, such as Ouroboros Praos or Ouroboros Genesis, do not work in this manner). Another line of work in similar directions is Algorand.

There are many subtle details on how to implement such protocols which are covered in these papers: How to do the random selection efficiently; how to do the random selection in an unbiased manner (or mostly unbiased manner); how to make sure all participants agree about who is elected leader; how to deal with people entering and leaving the network; how to deal with prediction of this randomness to harm the network; and so on.


The green spikes indicate when you receive a new block, on average every 10 minutes. Then your node is busy for a little while to verify the block and then it starts uploading it to other nodes (red).

I think there's TCP congestion collapse happening when your link is saturated by the high amount of traffic when a new block comes in. After that all TCP sessions start speeding up again slowly. Another keyword to look for is bufferbloat.

Sometimes QOS settings on your router might prevent this. If you have the ability to specify a maximum bandwidth use which is ~5% below the theoretical limit, usually that helps a lot.

If I'm not mistaken, the upcoming version of bitcoind will have some rudimentary bandwidth control options, then it might help to restrict it a little bit.


General Block Chain questions / Js Block Chain

People say that it isn't possible to shut down the block chain but the more that I look into the subject it doesn't matter how much tech you have behind your block chain there has to be an entry point I.E to the master node with a dedicated I.P address. If this is the case then how is it not possible to shut it down? Wouldn't it be a simple fact of blocking the ip like it has been done for so long in other countries?

That is completely incorrect. There is no master node nor is there any central source that dictates what the blockchain is. The blockchain is distributed to all nodes, and all nodes update their local copy of the blockchain according to the consensus rules that the node is following. If everyone is following the same consensus rules, then everyone will converge onto the using the same blockchain. However, there are some circumstances where a node will not use the same blockchain as all other nodes, but these only happen when the node is under attack.

  Proof Of Work: I get that there has to be some sort of way of proving the source of information came from a certain contributing node. However I'm not totally understanding the point of the POW. For eg, if there was 100 block nodes connected to various master nodes then the information that would be processed by each node would be then emitted by each node to the master nodes which would then process the master nodes for insertion into the ledger, correct??? If that is the case then what is the point of the POW/High powered computer specs etc?? isn't it just using up computer resources with the algorithm??? isn't there nay other more efficient way to do this. It sound like a job that any average computer could do in this day and age without having to max out the CPU etc. This is just something that I'm not understanding.

Again, there is no master node that inserts things into the blockchain.

The proof of work is something that is done by miners to show that a certain amount of work was done to produce this block. This secures the blockchain because nodes will use a blockchain which has the most proof of work and is valid under its other consensus rules. This means that if an attacker wished to defraud someone by convincing their node that a different blockchain were the real blockchain, then they would have to do the same amount of work that has been done on the real blockchain. At that point, it would be far more cost effective to simply be an actual miner instead of maliciously attacking someone as the cost of doing that much work is very high.


Adroid Blockchain wallet ver 4.0.12 recovery

Is there any way to recover this now seven years old wallet?

No.
This is because you probably ignored any advice to

keep somewhere safe a separate written note of your recovery phrase (seed phrase, backup phrase) or private key.

Make regular backups of important data on your computers (including on your phones)

Practise recovery from those notes and backups.

It is also because Android phones protected by PINs and passwords take measures to prevent thieves accessing your private data. As an inevitable side-effect, those measures also prevent you accessing that data if you forget your phone's PIN and Password and didn't make a written note kept somewhere safe.

I can open the phone, that PIN code I can remember. However, I do not remember the PIN code for the Blockchain wallet.

If you have access to the phone, and have some idea of what your wallet password might have been like, there are tools that may help you to sucessfully guess the password. These tools may take a very long time and not succeed.
For example https://github.com/gurnec/btcrecover says

Bitcoin wallet password recovery support for:
[...]

Blockchain.info

[...]


How can I find out the current exchange rate of Bitcoin/USD?

Very simple. Go to google and type: BTC to USD

A nice box with the current exchange rate should appear on your browser.


Are Bitcoin transactions really "frictionless" given confirmation time?

For small amounts it's fine to accept unconfirmed transactions. You must really understand how the protocol works to be able to double-spend an unconfirmed transaction. I'm sure in the future hackers will build tools to allow for these sort of scenarios to benefit them, but also bitcoin clients will grow more secure and be able to diminish the propagation of a double-spend in the network, perhaps using trusted central entities that can propagate your transaction much quicker than the attacker could propagate their double-spend.

If I'm selling something for lots of bitcoins, yes I'd wait at least 10 minutes. But if you compare this to selling something for cash, you'd still need the time to sit down and count the money and make sure it's real and that you're not being scammed. This could take you more than 10 minutes and you'd probably need to do it in a private area. With bitcoin you can do it in any public place using your phone, and instead of using the 10 minutes to check whether you're being scammed, you can have a friendly conversation with the person you're doing business with.


Fast way to get details of all transactions in a block

Use getblock with verbosity level 2. e.g.

getblock 0000000000000000000cedb96c93635edfb2755a3357e7febe5929fb6db1658d 2

This will return the block with all of the transactions already decoded.

Since you mentioned that you are doing getrawtransaction and then decoderawtransaction, getrawtransaction has another parameter to decode a transaction for you so you don't have to go to decoderawtransaction. You can do something like

getrawtransaction 0374d2bab7ce78429dc8660fb0100f260e1528dca4854ca7d761dd849211ff75 true

Lastly, most RPCs have a set of options with a description of what they do and an explanation of the output. You can do something lie

help getblock

to get the help description. In the future, you can do this for any command that you are using so that you can use it to its fullest potential.


Why is it impossible to get a straight answer as to whether Bitcoin is anonymous or not?

Because privacy is not binary in nature. It is not as if there is some moment at which your information flips from being not-private, to private. Privacy exists on a spectrum, and as a bitcoin user, where you sit on that spectrum depends entirely on the actions you take.
This means that there are ways which bitcoin can be used which afford the user a very large degree of privacy, and there are always ways to use it which afford the user no privacy whatsoever.
Some things that the average user can do to help improve their privacy:

Never give up personally identifying information to exchanges or other bitcoin businesses
Never re-use bitcoin addresses to receive funds
Run a full node to validate the network state themselves, run it over Tor only
Only use wallets which connect to their own full node to query blockchain information
Only use wallets which allow coin control and UTXO labelling
Never look up addresses of interest on blockchain explorer websites (unless using Tor)
Never publicly post any information that could tie them to certain addresses or transactions
Use the lightning network to make payments
Do not send round number amounts when making payments (eg send 0.00104103 BTC, instead of 0.001 BTC)
Use privacy-focused wallet software, such as JoinMarket or Wasabi, to create coinjoin/payjoin/etc transactions .

As a user, you need to decide what level of privacy you need/desire. Maybe following every point on the list above is too much for you, or maybe it isn't enough. There is no 'one size fits all' for privacy, though generally I would recommend endeavouring to retain your privacy whenever possible.
To quote this great article, which I would highly recommend reading:

As of 2019 most casual enthusiasts of bitcoin believe it is perfectly traceable; this is completely false. Around 2011 most casual enthusiasts believed it is totally private; which is also false. There is some nuance - in certain situations bitcoin can be very private. But it is not simple to understand, and it takes some time and reading.


If you have bitcoins in any address, they should be there unless someone else got access to your wallet and stole them, in which case you should see in a block explorer the corresponding transaction.


Why bitcoin private key WIF format always be started in K or L?

Base58 check encoding is really just a base conversion. It follows the standard base conversion algorithm in mathematics.

Right before we perform the base conversion, we will have a sequence of 38 bytes. It's 0x80 + 32 byte private key + 1 byte compression indicator + 4 bytes checksum. For the encoding itself, these 38 bytes are interpreted as a very large number, and then a base 58 version of that number is computed.

Let's look at our number in hexadecimal (base 16). The constraints we have mean that the number will be at least 0x0x8000000000000000000000000000000000000000000000000000000000000000000000000000 and at most 0x80ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff. Now in base 58, these two numbers are KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73NTmk4WB and L5oLkpV3aqBjhki6LmvChTCq73v9gyymzzMpBbhDLjDpKhfJuTe6.

Since every possible value that can be encoded falls between those two base 58 numbers, all possible values that can be encoded must begin with a K or L.


Getting historic exchange data through an API

Have a look at the API of Bitcoin Charts. They have trade data available for all the major exchanges but delayed by 15 minutes. You can then fill up the gap using the available exchange APIs.


Your transaction are NOT unconfirmed. As you can see here:
https://blockchain.info/tx/b5a9cb6a67429ec60c51f3aa197bec67af0003c841890132051f9fea40f71f76
https://blockchain.info/tx/77fc2aa152a80e0abe382a53d5254f113460a6f17cff95852bd0827a572e01cb

Both of them have over 700 confirmations. All, but one of your outputs are already spent.


HD Wallet with BIP44 - workaround of deriving public keys knowing only a xpub

This is, in fact, the intended approach and use of BIP 44.
The purpose is to derive to the account level with hardened derivation. Then export that xpub to be imported into other software which derives the receiving and change addresses. When signing a transaction, the wallet with the private keys can derive the entire path to get the individual child private keys needed to sign.


Are there any combination of letters that a namecoin address cannot start with?

Namecoin addresses, like Bitcoin addresses, are Base58 encodings of a public key hash. The encoded data starts with a version byte, and the value of this byte affects the first characters of the result.

Namecoin addresses specifically use a version byte of 52, which dictates a certain range of initials. The prefixes you listed are simply too high - they correspond to a version byte of 53 or even 54. Likewise, some prefixes starting with M are impossible because they correspond to a version byte of 49, 50 or 51. You could give a more precise "lowest" and "highest" addresses, in lexicographic ordering - the address must be between MvaNCeVyvP6ZXYFWGpKaDX9ujEQ418F7sm and NKuyBkoGdZZSLyPbJEetheRhMjezbtjJCf.

A full list of version bytes and first characters is available here, and the possible 2nd character ranges can be interpolated from it. For version bytes 0-2 and 144-255 the address length can be different from 34 so it makes the ranges less intuitive. But for 3-143 it's fairly straightforward: You have about 58^2 possibilities for first 2 characters to go between 141 version bytes, so each is only allocated a range of about 23 combinations. For Namecoin addresses that would be Mv to NK.


How do exchanges automatically forward deposited bitcoin?

Generally, the exchange will use a full node that is continuously checking the network for received transactions. Once it detects a transaction has been made to your deposit address it waits for the transaction to be confirmed, then it will credit you the balance. This data is stored in a private database managed by the exchange where they keep track of each user's balance. The bitcoins you deposited are then either pooled to pay for someone else's withdrawals or sent to a cold wallet (an air-gapped device that is not connected to internet) where they are stored securely if they're not going to be used in the near future.


That isn't the way a block header is created. The block header is constructed as

the version
the hash of the previous block
the merkle root
the timestamp
the nBits field
and the nonce.

Once serialized in bytes, the header is hashed twice with SHA256 not just once.

A common mistake is to hash the string of hex representation of the bytes, you must hash the bytes themselves.

See here for more info: https://en.bitcoin.it/wiki/Block_hashing_algorithm

The hash is the hash of that block. It does not give the hash of the next block following it, there is no way to know what the next block hash will be and there are many possible hashes it could be.


Trojans detected in ldb bitcoin database?

No, it's vandalism. Some virus signatures were uploaded to the blockchain as a prank: https://www.reddit.com/r/Bitcoin/comments/25otbt/someone_put_a_virus_signature_in_the_bitcoin/

It seems those are some of that cases.


Is a privacy preserving coin mixer possible on Liquid?

In the following I focus on Confidential Transactions (instead of the extension Confidential Assets) for simplicity, but all of what I say is also true for Confidential Assets.

Yes, it's possible to use cryptographic protocols to organize the CoinJoin transaction in a privacy-preserving manner. The ValueShuffle protocol is designed for exactly this purpose.

ValueShuffle indeed makes sure that no third party (e.g., a server facilitating the CoinJoin) learns the involved amounts (or assets). But its privacy guarantees go beyond this requirement: In a nutshell, ValueShuffle makes sure that the amounts of your inputs and output, and the relationship between inputs and output remain private not only to third parties but also to the other the participants of the CoinJoin.

See the ValueShuffle paper for all the details and limitations. Disclaimer: I'm one of the authors.

Your intuition that CoinJoin and Confidential Transactions are a good match is correct.
More concretely, we can exploit two important synergies.

If we have Confidential Transactions, CoinJoins with different output amounts are suddenly possible. This eliminates one of the major restrictions of CoinJoin in practice.
The combination of CoinJoin and Confidential Transaction makes it possible to mix multiple payments instead of merely mixing self-sends (if the payer additionally has a mechanism to get more than one possible address of the payee). As a result, you can mix and pay with your coins in a single transaction. This is much better than CoinJoins without Confidential Transactions, where you first need to perform a mixing transaction and only after mixing you can perform an actual payment in a second transaction. This means that CoinJoining your payments will actually be cheaper (in terms of blockchain space and thus transaction fees) than performing payments individual. This provides a great incentive for doing CoinJoins. This is remarkable because privacy usually comes at a cost -- but in a scenario where Confidential Transactions are already available, CoinJoin comes with a discount.

My talk at Scaling Bitcoin 2017 provides a more detailed explanation on the advantages of combining CoinJoin and Confidential Transactions.


Does any exchange provide API to call callback function on each transaction?

It is not common to have Push APIs for Exchange sites. However Poloniex has WAMP (Web Application Messaging Protocol) over WebSocket for ticker:

https://poloniex.com/support/api/


Why are some transactions larger (in bytes) than others?

I give a formula that you can use to calculate the size of a transaction given the number of inputs and outputs here.

The most significant factor contributing to the size of a transaction is the number of inputs to transaction has.  Each input contributes 179 to 181 bytes to the size, and each output contributes 34 bytes to the size.

Your large transaction has 4 inputs - that's why it's bigger than the other transaction, which has none.

The actual number of bitcoins spent by a transaction is completely irrelevant, except that there may be a tendency for transactions which spend more coins to require more inputs to make up the amount.


SegWit and previous hash: txid or wtxid, or either?

Inside transaction inputs, you have to refer to previous transactions using the txid. Allowing a wtxid there would be (1) a hard fork and (2) defeating the purpose, as it'd make transactions malleable again.

The wtxid is only used to compute the Witness merkle root, which is committed to in the coinbase.


What happens if my wallet gets "hacked" and my BTC is stolen?

All BTC transfers are final. If a hacker moved your BTC elsewhere, you can't get it back.

You have to keep your funds safe. See https://en.bitcoin.it/wiki/Securing_your_wallet.


You can use MacMiner, either the CPU miner window for scrypt mode or the FPGA/ASIC window for BTC mode and the GPU window for dual mode - the last two both use bfgminer
There's more information here and Mac mining forums here with lots of detailed info in some of the gridseed posts.


Can I create a public address for Bitcoin without the private address appearing on the screen?

If you're afraid of screen grabbing you should also be afraid of memory grabbing malware.

If however you make sure that such malware can never communicate anything to the outside world then you don't have to worry about either of those types of malware.

You can do that by booting from a write protected media (CD) and making sure there is no other writable media ( harddisk) connected. Also of course make sure the machine is offline (no network cable or WiFi etc).

After generating the private key write it down (error sensitive!) or print it (not on the big printer in the office, those often have harddisks in them). And after that turn off the computer to erase the memory.

Even in this setup you still don't want malware on the PC because it could influence the creation of the private key by making it predictable.


The Bitcoin-Gold fork came before I expected.... can I still access my BTG?

According to this article, Bitcoin-Gold forked "at block 491,407 on the original blockchain".

If you look up your sending or receiving address in blockchain.info, and drill down into the transaction id, you should be able to find the block number that it was included in. This will allow you to work out whether your transaction was before or after the fork.

If you have access to the private key of an address where bitcoins were stored at the time of the fork, you should be able to get the BTG and the BTC as you have full control of them.

However, I believe Gemini is an exchange, so if you have bitcoins stored on the exchange at the time of the fork you'll be relying on them to give you any BTG you would otherwise have access to (assuming they don't give you access to the private key of the funds stored on the site... but exchanges usually don't).

Note that on 8th Oct 2017, Gemini announced on Twitter that they would allow users to withdraw Bitcoin-Cash, which was created as a fork of Bitcoin in a similar way to Bitcoin-Gold. Perhaps this is a good indication they will do the same for Bitcoin-Gold.


How does the SuperNet NXT Multigateway Exchange work?

The main advantage of the MGW exchange over traditional exchanges is that for protocols which support multisig, all funds are stored under 2/3 multisig accounts on 3 geographically separate servers, most likely, owned by different entities.


Is there a database of wallet addresses with lost private keys?

No, because it's not possible to prove a negative ("No I don't have the private key for that address") and I can't think of a use for that.


What is a relationship with total hash rate(hash power) and average block generation time?

This chart - hash rate means total hash rate of All minor?

No, it represents the hash rate of the network. It is determined by using the time it took to find the block and the current difficulty of the Bitcoin blockchain. To cite an example, the current difficulty bits are 0x1729fb45, which means we need to find a block header hash that is less than '0x00000000000000000029fb450000000000000000000000000000000000000000. This represents a one in 2.88e+22 chance of finding the header hash. Assuming block time of 10 min, this is 2.88e+22/600 = 47e+18 hashes/sec. If the block are found faster than 10 minutes the hash rate is higher, if it is found in more than 10 minutes, the hash rate is lower. That is what you see in the hash rate graph.

  I want to assure it that if there is a mining pool have 30% of total hash rate and this mining pool is the biggest pool. Then this mining pool will succeed to find target hash value faster than others(stochastically).

No. Your big mining pool will only have a 30% influence over the difficulty adjustment. The rest of the network will have a 70% influence, which is more than what a solo miner has. The block time adjustement is based on how fast the blocks are mined (the algo tends to keep the average time at 10 min) not how much percent hash power each miner has.

  Can a miner find if fork happened?

If miner receives two different blocks at the same height then he will know that the network has forked as half of the network will be seeing a different tip versus others. When the next block will be mined, on top of either of them, the network will converge again.


bcoin does not use webpack anymore, and in fact the browser node as a proof of concept isn't really being maintained since it is practically very silly :-)
The webpack config files were removed form the repo here and here. If you REALLY want to try the browser node, you will need to checkout a git commit of bcoin from before those changes were made.
The bcoin library can still be compiled for browser usage in simple webapps and is still very useful for small applications like that. I refer you to this guide: https://bcoin.io/guides/webapp.html ...which uses bpkg instead of webpack or browserify.
That browser-node guide should probably just be removed, or at least updated with a deprecation notice. If you feel like it you can make a PR to the website here: https://github.com/bcoin-org/bcoin-org.github.io
Feel free to join us on IRC #bcoin or on Slack to chat more about this.


I know I had Bitcoins back in the Day, but

It depends on the version you were running, and the operating system, and when you say you are looking for your bitcoins, what you are really looking for are the private keys.

Bitcoin Core

The keys are in a file called wallet.dat which was stored in the bitcoin core data directory, which I'll call <data-dir>. The wallet.dat file was stored in <data-dir>/ on versions prior to v0.16.0 and moved to <data-dir>/wallets in later versions, see files.md. This uses the bitkeys format.

Linux
On linux, the data directory <data-dir> is ~/.bitcoin/wallets/wallet.dat

Windows
On Windows, the data directory <data-dir> is %APPDATA%\Bitcoin\wallet.dat

Mac
On Mac, the data directory <data-dir> is ~/Library/Application Support/Bitcoin/

Reference: https://en.bitcoin.it/wiki/Data_directory#Mac

The next question is "How do I restore the keys?", and there are many answers for that already, example: Import wallet.dat into a new Bitcoin-Qt client


As far as I understand, my bitcoin [..] are somewhere in the big block chain and are not bound to a specific app.

This is correct, what is held within your app is the private key that allows you to spend the bitcoins held at that key's address. Without the key, the coins cannot be spent.

So, to make the bitcoins accessible in your blockchain.info wallet, you can do one of two things:

Send a bitcoin transaction using bread, to a receiving address generated by your blockchain.info wallet.
Import your bread wallet into blockchain.info, by inputting the bread wallet seed phrase or private keys into the blockchain wallet. Doing this will copy the keys held in your bread wallet, effectively creating two instances of the wallet instead of just one.

I don't know your exact reasoning or circumstance for switching wallets, but for what its worth, I like the security model used by bread much more than the one used by blockchain.info. At any rate, make sure your seed phrase is stored in a secure place!


How would AML techniques work in Ripple?

AML is only applied to customer relationships. In this case that would be people that have an account with a gateway and are using said account to either deposit or withdraw massive amounts of money/crypto from the gateway.

It cannot apply to rippled balances, as you don't need to provide any information to another entity in Ripple in order to extend a trust line to said entity. I.e. there is no customer relationship in that case.

All of the above is AFAIK and IANAL.


API to know if bitcoin-core has the private key (in the wallet.dat file) of a certain Bitcoin address?

Use validateaddress [address].

It will give you all information about that address, including whether it has the private key (it will "ismine" : true and "iswatchonly" : false.


secp256k1 lib compiling issue "invalid use of incomplete type secp256k1_context"

The reason for this error is that secp256k1_context is an opaque type. This means that you cannot create it on the stack; you need to create a heap-allocated version (and destroy it) using the functions from the API (specifically secp256k1_context_create and secp256k1_context_destroy, as Mark H mentioned in a comment). There is no way to access the internals.
You're right not to try to #include <secp256k1.c> ... aside from being unlikely to build and requiring you to bundle a copy of the whole library, it would expose internals of the library to your code which are not safe to use directly.
For what you are doing (replacing internal signing functionality with OCL-enabled versions) you are probably better off forking the library and directly editing the source. This isn't much more invasive than what you're trying to do, and it would let you use the existing unit tests and valgrind ctime tests to check your work.


The term is used specifically in Monero's ring signature based spending scheme.

Monero transactions do not exactly specify which previous outputs are being spent. Instead, a list of alternative inputs is provided (consisting of the real one, and a number of chaff coins). A ring signature is then used to prove authority to spend from the real one, without revealing which one that is.

This has the advantage of obscuring the transaction graph significantly. It also comes at a very high price - as it means validation cannot use a UTXO set based approach, and must instead maintain an ever-growing database of spent coins to prevent double spending.


How do I run Armory Testnet on Win7 x64 using Bitcoin Core 0.9.3 using remote datadir?

I'm going to answer my own question for those interested in the solution:

Armory and Bitcoin-QT use confusing switches; Armory going for the --flag while the latter uses the -flag
A remote Blockchain directory is identified using --Satoshi-datadir= while -datadir= is used with Bitcoin-QT
Ensuring the Bitcoin.conf file is correct is the main issue. Correct values required are: listen=1, allowip=127.1.1.1


After last bitcoin is mined, can miner(s) with nefarious reasons kill bitcoin by holding fees thereby deflating Bitcoin eventually to zero?

This would be fantastic for everyone but the attacker.

First, everyone who held bitcoin would be rich. As bitcoin became more and more scarce, the price would go up. The attacker would have to offer full value for every bitcoin it managed to acquire, so it's no different from an attack where you buy all the bitcoins.

However, as the distribution becomes more and more skewed, the value of bitcoin will eventually crash because people couldn't get it.

Once that happens, everyone who likes to use bitcoin for payments or as a store of value, now all fantastically rich, would simply migrate to a different system. The attacker would have bought every bitcoin all the way up the rise in price.

Of course, this would be so obvious to all involved (at least eventually) that it would never get this far. Whether the result would be changing the mining algorithm, restoring the block reward, or something else, I can't predict. But likely the mere threat of changing the mining algorithm would be sufficient to end this.

A related, but more realistic, attack involves someone with 51% of the mining power taking all the transaction fees for themselves by refusing to mine on top of blocks mined by anyone else. As a monopolist, they could increase the transaction fees to as much as the "market" would bear. This faces the same problem -- everyone else can threaten to change the mining algorithm. If decentralization is the value proposition, such a chain would have no value proposition -- so why would anyone pay high fees to use it?


Yes. More miners -> Higher difficulty -> Less chance of finding a block with a given hashrate -> less reward.

Long-term, it will only remain profitable for those who are more efficient than others.


Bitcoin mining: internet connection status?

To clarify, For solo mining a fast internet connection DOES matter, but in the case of a pool, it's a lot less.

  On Stratum with variable difficulty, you should need ~1kbps (0.125 KB/sec).  It doesn't matter how fast you are, which is why the new protocols were implemented.  1 GH/s, 1 TH/s, 1 PH/s, with proper server implementation it should all use the same bandwidth per connection.`

You should need barely any bandwidth for pool mining. If you watch packets between your rig and the server, they make up a very small amount of data
(1-10kb?) The requirements are extremely small for most of them. This would be ~10 MB per day.

It also depends on the pool you're going to mine on.


You've asked about five different questions here.

This is a standard scam and there is no reason to think they actually have anything.
There is no way to trace the owner of a Bitcoin address. That's why these scammers ask for payment in Bitcoin.
The cost of one bitcoin varies continuously, just like stock prices or currency exchange rates, but you can easily find the current exchange rate by Googling for something like "current bitcoin price".


Bitcoin uses two rounds of SHA256 on the entire contents of each block (which includes a reference to the previous block) as well as a randomly varied nonce. When the result of those calculations are below a network-determined threshold it is considered to be a valid solution. These solutions are published along with the block as it is distributed to the network so finding the hash of old blocks is trivially easy, you just look them up. Verifying that the math was done correctly and that the result meets the criteria requires only a single iteration of sha256(sha256(block+nonce)) while finding the appropriate nonce the first time takes an absolutely insane number of attempts.

The insane number of attempts is necessarily because the output of sha256 is, effectively, pseudorandom and covers a huge space. The algorithm is deterministic, so sha256(x) will always have the same result, but the result is entirely unpredictable and minor changes in the value of x will dramatically alter the results.

The only way to predict the output of a cryptographically secure hash algorithm like sha256 is a pre-image attack: You would have to pre-generate the contents of all possible blocks, hash them and store the results. At that point solving a block would be as trivial as a database lookup, assuming you could store all 2^256 possible outcomes, which you can't, and that you could generate all 2^256 possible outcomes before the heat death of the universe, which you can't.


What happens if a miner deliberately ignores a transaction, and "wins"?

Miners have complete perogative over what transactions to include. They may include random transactions, the highest fee paying transactions, just their own transactions, or no transactions at all.
If a miner doesn't include a particular transaction from their mempool, it stays there. It will be available for later miners to pick it up and include in their blocks later.
To incentivize miners to include your transaction, you can include a fee. Miners in practice will pick the transactions with the highest fee first. First matters, because blocks have limited capacity, and so there may be more transactions on the network than can fit in a block.


Disclaimer: I worked at BitGo when WBTC was kicked off, but I didn't work on the WBTC project.
Wrapped Bitcoin (WBTC) is an ERC20 token fully backed by bitcoins held in BitGo's custody. BitGo mints new WBTC when bitcoins are deposited into custody and WBTC is burned when bitcoins are withdrawn from custody. WBTC is a means to get an IOU for hard money into the ETH ecosystem.
As a "scaling solution", it fits somewhere between a sidechain and payments between two user accounts on a custodial service:

There is no "BTC on ETH", all bitcoins are held by BitGo (or other custodian if another gets added). WBTC is a promissory note for the assets held by BitGo.
Payments using WBTC do not interact with the Bitcoin blockchain, they happen on the ETH network
WBTC can be freely sent and received on ETH
The WBTC token cannot be trustlessly redeemed for bitcoin, entering and exiting WBTC requires actions by BitGo

As ETH is still figuring out its monetary policy, the ETH ecosystem lacks a hard money. WBTC is frequently used to represent Bitcoin's value in the ETH ecosystem. Under the assumption that WBTC is a faithful representation of Bitcoin balances and since WBTC payments do not consume Bitcoin on-chain resources, one could consider them a scaling technique. Representing WBTC as "the scaling solution" for Bitcoin is a silly misrepresentation.


Who bitcoin get the transaction fee? part2

Miners receive the fees. Really.

If you're not getting fees, either you mine in a mining pool that doesn't keep track of fees and block reward separately, or you mine for a mining pool that doesn't distribute transaction fees to its miners, or you aren't including transactions in your blocks.

So either 1) you get the transaction fee, but you don't know it, or 2) the pool keeps the transaction fee, or 3) the pool includes no transactions and therefore gets no fees.


Can the system of votes (of Stack Exchange) be considered as a blockchain?

First off, no, I would not consider StackExchange to be a blockchain.  StackExchange is a centralized web site, just like most (arguably all) websites.

Many of the proposals people make for using blockchains nowadays don't really require a blockchain to work.  So while, yes, you could use a blockchain to create a StackExchange-like voting system...you probably wouldn't want to.

When deciding if a blockchain is the correct solution, ask yourself "can this project work if I have to trust a centralized authority?".  If the answer is "yes", then you probably don't want to use a blockchain.  A blockchain is the solution to the problem of needing a data store that you can trust, yet not being able to trust any single individual or organization to run that data store.

In the case of StackExchange, the maintainers of the site have a vested interest in making it useful, informative, and collaborative.  If they don't, nobody will use it, and they won't make any money from advertisements.  Therefore we can trust them to do a good job maintaining the site.  This is also probably true for a company maintaining a reputation system for their employees.

In the case of Bitcoin, we can't have a central authority that we all trust.  In the past, centralized alternative currencies were shut down by governments, so even if we trust an organization, it has a weakness.  Furthermore, how much more can we trust a centralized upstart currency than we can government fiat currencies?  Bitcoin needed a blockchain to work, because centralized trust does not work for the project.

Here's a couple of other relevant questions you may find interesting:

How to implement a Bitcoin voting system:

Blockchain-based polling/voting systems

...and why you shouldn't:

Blockchain Tools for Voting Among Small Groups?


The configuration file is definitely in $HOME/.bitcoin/. If you cannot see it, the most likely explanation is that you have not created it. Just use your favorite text editor to do so. As far as I can tell, bitcoind -daemon will run without bitcoin.conf being present and you will still get the message 'Using config file /home/user/.bitcoin/bitcoin.conf' in debug.log even when no file exists.


How do you setup a bundler for mining / forging child chain coins on the Ardor platform?

From the wallet cogwheel menu select the bundlers page and start a bundler.
You will need to specify your passphrase in order to run a bundler so you'll have to run it on your own node. You also need the node admin password in order to list the bundlers.
Here is some additional discussion https://nxtforum.org/general-discussion/ardor-child-chain-bundler-questions/


Have a look at cryptoarchive.com.au for historical crypto data.


Is it possible to recover my money?

No, Bitcoin transactions are irreversible.

You could try to contact the other party and either ask about the delay or request a refund.

If you believe the other party is committing a fraud, you can report the problem to your local police - but for small amounts it is unlikely that any action can be taken.


The timestamps on those blocks are indeed quite varied so I think that blockr.io is not using the timestamp field in the block as sole timing information, instead using something like min(relayed time, block timestamp) so that blocks that have a future timestamp are shown as "right now" because they use the relayed time. They probably are not only using the relayed time since in that case they'd be misdating all blocks after downtime.

TL;DR: do not trust the timestamp field in the block, it can be manipulated.


Bitcoin Mining Pool setup - Pool does not own wallet address

To all the future folks coming to this page from Google. The solution is simple.
The solution is for UNOMP, but it should be same for other pools as well.
Open:
paymentProcessors.js

go to line 84 and change
isMine to isValid

restart the pool and payment processor will load without error. I just realized that validateAddress response has changed but pool libs are not updated.


What is stopping pool managers to fake a miner?

The pool members will notice that the pool is not mining as many blocks as it ought to, given its supposed total hash power as reported by the manager, and that they are therefore not earning as much money as they should.  A certain amount of this could be attributed to "bad luck"; but over time, or if it becomes extreme, they can tell statistically that something is fishy, and then they will switch to other pools.


If bitcoin value is going down do you lose anything or only when you sell like the stock market?

Well basically, think of it as if u had an apple. If you decide at any moment that you want to sell it, you get a specific price for it, which is the current price of an apple.
So if you bought 1 bitcoin when 1 bitcoin was worth 18K USD and sold it at 27K USD you have now a profit of 50% which means that you now have 27K USD as fiat in your hand instead of having 18K (which you had when you bought a single BTC worth 18K back then)
This works the same if you buy it at 27k and sell it at 18k, except, you then lose 33% of your money that you invested in it when you bought it. That means that if you buy 1 BTC at 27K and sell it at 18K because maybe you are scared to lose more, you end up losing 9K because you sold it.
If you don't sell it, you will remain with that 1 BTC the whole time when it's price fluctuates, but it is basically worth more (or less) depending on it's current market price.


Why is halving the best time for block size increase hard fork?

There's definitely no reason for that from a technical perspective. Success is entirely dependent on convincing all the wallets, nodes, and lastly miners in the network to make a breaking change to their software.


Here is how to create a paper wallet for almost any Cryptocurrency :
https://steemit.com/cryptocurrency/@bad.r2017/how-to-create-a-paper-wallet-for-any-cryptocurrency-in-7-steps


How does the block discovery rate of a mining rig relate to the overall computing power of the network?

This is approximately correct. You will actually get a bit more than one block per hour because so long as hashing power is increasing, the difficulty will lag behind the actual computing power.


HD Wallet Child Private Key Derivation Function

A private key is a number, a very big 256 bit number. You can do ordinary arithmetic on such numbers, for example addition modulo n, where n is the order of the curve (someone else will have to expand on that if needed). n is very close to but less than 2^256.

Here's a diagram of the child private key derivation:

The left 256 bits of the 512 bit hash is added modulo n to the parent private key. The sum, which is also a 256 bit number (because of modulo n), is the child private key. The sum of the parent private key and a seemingly random 256 bit number is a seemingly random 256 bit number, so that sum will function just fine as a private key.


Using Bitcoin Core Wallet, encrypted it, now it won't recognize password

Try to unlock it on console by using the walletpassphrase command (e.g. walletpassphrase (5 digit here) timeouthere)


in fact the current consensus rules are defined in code of bitcoin client which is used today by majority. this is by the definition of term "consensus". tomorrow we can have another consensus rules.

the wiki page https://en.bitcoin.it/wiki/Protocol_rules is good, but it does not describe BIP16 and many other protocol improvements which were already put as consensus rules (CSV, CLTV opcodes handling, may be something else)

some things mentioned on wiki page seems to be wrong, for example the transaction can be less than 100 bytes (tx messsages, rule #6)


To verify the auxiliary chain, you need to prove that a certain amount of work has been done upon the latest block in that auxiliary chain. As with any form of mining, this involves computing a hash to be below a threshold.

However, it doesn't matter that the pre-image of the hash has a lot of other irrelevant data in it too, so long as it contains the relevant auxiliary-block header in there somewhere. I.e. from a proof-of-work perspective it makes no difference if you calculate this:

while(h > aux-threshold) {
    h = hash(aux-header + nonce)
    nonce++
}
result = nonce

versus this:

container = hash(hash(aux-header) + other-data)
while(h > aux-threshold) {
    h = hash(container + nonce)
    nonce++
}
result = nonce

Both will take the same amount of work and both will prove that the work has been done on aux-header. This is so because container can be proven to contain the aux-header, and since aux-header and other-data are stored in the aux-chain block and the hash can be re-computed at any time.

So, for merged mining, container is actually the hashed header of the parent-chain block and aux-header just needs to be included in the parent block somewhere. It really could be included anywhere so long as the parent block passes the verification process. For example, you could include the aux-chain-header-hash as an address in a multisig transaction, or as a piece of data that gets placed on the stack but never popped off in one of the transactions. Yet, the easiest place to put it is in the txin script of the coinbase transaction. This always contains arbitrary data anyway, and its location at the top of the chain means that other-data can contain the smallest number of merkle branches.


You use the explorer and typing the ip adresse for the prospero, and then you get a web interface for setup.


Can I use my wallet on different computers?

It is, with three provisos.

Never run the same wallet on more than one computer at a time.
Never run an older copy of a wallet when a newer version exists. If you send any funds, make sure to keep the newer copy of the wallet.
Make sure all client programs are linked to the same version of BerkeleyDB.

Overall, I think it's just not a good idea. The client software wasn't designed to cleanly handle the many things that can go wrong.


Yes.

The private key is used to send from an address.
The public key is used to send to an address.
The public key is generated from the private key.

So if you have the private key you have full control over an address.


Upgrading Multibit (without losing wallet)

Pretty much every single program allows you to upgrade it without losing data, and Multibit almost certainly isn't exception.

Just upgrade it.

In case you're worried, backup your wallet first.


Does P2PKH substitute P2PK in any circumstances? Why?

Both P2PK and P2PKH were part of the first bitcoin 0.1 release, so that second point isn't true.

P2PKH is theoretically safer because the pubKeyScript only reveals the hash of the public key rather than the public key itself (which only matters in the case that the elliptic curve crypto involved is broken). So as long as you don't reuse the address, no-one else will know the public key before the money is spent.

All bitcoin addresses encode public key hashes so only P2PKH can be used with an address, as the public key is not known. P2PK were mainly designed for IP-to-IP payments, which is no longer possible in Bitcoin Core since version 0.8.0


Where can I buy an xbox live subscription with BTC?

Microsoft accepts Bitcoin to fund your account. From the following link: https://commerce.microsoft.com/PaymentHub/Help/Right?helppagename=CSV_BitcoinHowTo.htm

  To add money to your Microsoft account with Bitcoin:

  Sign in to Microsoft account - Billing with your Microsoft account
  Select Payment options > Microsoft account > redeem bitcoin
  Select the amount you want to add, then click Next
  Review the amount of Bitcoin needed and use your digital wallet to complete the transaction within 15 minutes:

  On your computer – select Pay with Bitcoin and then pay from your        Bitcoin wallet on the same device.
  On your smartphone – scan the QR      code displayed on the page to    pay from your mobile wallet app.
  If your wallet is on another device, you can copy the receiving address     and BTC amount to the wallet on your device or the Web and
  then make     your purchase.


How come Merkle tree is more efficient when tree branches are not stored in blockchain?

The speed of the hash is roughly linear in the number of bytes processed: SHA2 processes block of 64 bytes at a time, and the time taken is equal to the number of blocks processed.  Computing a hashtree processes more blocks due to the intermediate levels but almost all the processing can be done in parallel unlike the linear hash which must be done sequentially.

A node only verifies a block once.  For that purpose it doesn't matter much if the hash is a tree or linear though if the parallelism is exploited computing a tree hash is faster.

[And Bitcoin Core uses vector instructions to processes tree hashes in parallel for a several times speedup. It doesn't currently bother using multiple cores for that, though it could.]

A lite client, however, does not validate a whole block, it normally doesn't even fetch a whole block.  Instead, it wants to know if a transaction is in a block.  Here, the hash structure matters a lot. If a linear hash were used the only way to prove that a transaction is in a block to a lite client would be to send it the whole block.  With a tree hash one need only send it log2(n) values and the transaction itself.

The tree isn't stored in current Bitcoin implementations because there is no operation that would really benefit from it being stored in the implementations. Proving a lite client was paid is a relatively infrequent operation and recomputing the hash tree is inexpensive. An implementation could start storing it if it had a reason to do so.  TXIDs aren't stored either as they can just be computed from the transactions themselves.


This really helped me understand it:

  A solo miner increments Nonce until it overflows. Then it increments extraNonce and resets Nonce. extraNonce is located in the coinbase transaction, so changing it alters the Merkle root. extraNonce is reset based on the time.


Bitcoin Sellers who Request Photo ID, is this safe?

Cryptocurrency companies generally require photo identification to protect the company. The legal concern of exchange of cryptocurrency is money laundering, and by requiring identity verification, you know who you're receiving currency from or giving it to. Of course, companies will also need to have procedures in place to detect identity fraud. Some exchanges will require you to provide a picture of yourself holding your photo identification.

As for whether it is safe or not, it really depends on how trustworthy people believe the company is.


Ivy is a higher-level language that allows you to write smart contracts for the Bitcoin protocol. It can compile to instructions for Bitcoin’s virtual machine, Bitcoin Script, and can be used to create SegWit-compatible Bitcoin addresses.

Ivy GitHub Repository

Another interesting approach is to use RSK. Rootstock is a project to execute smart contracts (turing complete) to the ecosystem of Bitcoin. It is a Sidechain that uses as currency the SBTC (Smart-BTC) which is convertible 1: 1 with Bitcoin (2-way peg).

Balzac is an high-level language for writing transactions, verifying their correctness, and compiling them into actual Bitcoin transactions. You can also use Balzac to design Bitcoin smart contracts.


Given the tags you're setting on your question, I believe you're confusing currencies, wallets, and explorers.

Bitcoin (BTC) and Bitcoin Cash (BCH) are currencies with an associated blockchain.

Wallet/node software is what you use to interact with that currency.

Software that interacts with BTC includes Bitcoin Core, Bitcoin Knots, btcd, Electrum, Greenbits, ...
Software that interacts with BCH includes Bitcoin ABC, BUCash, Electron Cash, ...

Explorers are independently run websites that visualize information in particular blockchains. They are unrelated to wallets, and generally something you should avoid for anything but debugging purposes. Relying on a specific website as your source of truth is dangerous as the website may lie. Wallet software generally performs some level of local validation of transactions (or even full validation, meaning that no invalid transactions will ever be accepted). Some explorers have associated wallet software, which relies on that website for information, rather than directly connecting to the network. These are generally discouraged for the same reason.


Why is this (testnet) transaction considered invalid?


Is it possible to recognize conflicting 0-confirmation transactions with the Bitcoin client or other available software?

A merchant can lessen the risk of being defrauded in a race attack (on 0/unconfirmed) by:

Using an explicit list of peers to connect to (with most of the known IP addresses of miners)
Not allowing incoming connections (turn off uPnP)

this still leaves the merchant vulnerable to a 51% attack that all transactions below 6 confirmations are subject to but also to the Finney attack and another type of attack even where 2 confirmations is required (as described by vector76 here: https://bitcointalk.org/index.php?topic=36788.msg463391#msg463391 )

What you are asking for is a solution that would be useful for merchants who can absorb some risk that comes with accepting a bitcoin transaction at 0/unconfirmed.  Currently there is only a trivial number of merchants that accept bitcoin at a retail establishment.  And thus, no solution provider -- yet.

There is an API to the service http://transactionradar.com which might make it possible to monitor for double spend attempts.

Some useful conversations related to this topic:

http://bitcointalk.org/index.php?topic=36788.0
http://bitcointalk.org/index.php?topic=39562.0
Has there ever been a successful double spend attack on the Bitcoin network? If not, is it really necessary to wait for confirmations?
http://sourceforge.net/mailarchive/message.php?msg_id=27899173
http://sourceforge.net/mailarchive/message.php?msg_id=27964471
Can bitcoins be counterfeited?
http://bitcointalk.org/index.php?topic=69520


Lightning Network: Is it creating 3 transactions instead of 2?

Is all of this effectively 3 transactions?

No, assuming you mean '3 on-chain transactions'. It is useful to make a distinction between an 'on-chain transaction' and a payment being sent. To open a LN channel requires one (on-chain) transaction, and to close it requires another.

But while the LN channel is open, the participants can send each-other an unlimited number of payments using the channel (up to their channel capacity, of course). These payments are not recorded on-chain, instead their LN nods keep track of the channel's current state. This allows for more efficient use of blockchain space, while simultaneously giving the channel participants a mechanism for sending payments efficiently and without needing to trust their counter-party, or a third party.

Further, the channel participants can also route payments to other LN users, assuming that there is a valid route with the proper capacity available. A highly connected LN graph could allow all users to make payments to each other, without needing to constantly publish on-chain transactions.


Is it more dangerous when 51% attack happens than just having a pool with >50% hashrate?

One can't say what's more or less dangerous for a cryptocurrency value. You don't have a control group. You would need a parallel universe where Flypool had no more than 51% to compare prices there to prices in our universe.

Saying that, being decentralized it's the very point of a cryptocurrency, and very few people will invest in one of them that's actually centralized. I can only speculate what's in their minds, but maybe people invest in ZCash today hoping it will become less centralized in the future. Flypool, despite having more than 50% hashpower, like you said, probably don't mine only on their own blocks because they would make people sure the thing it's centralized. Or maybe because they sincerely want the security of ZCash against a double-spend, so the accept the smaller pools help. Both things must probably increase an overall reputation of the ZCash in people's mind and must probably keep the price a little high.


Why CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY opcodes have to be succeeded with DROP Opcode?

This is because CSV and CLTV are NOP opcodes that were redefined in a softfork.

As a softfork can only change the validity of transactions from valid to invalid, the only effect this redefinition was allowed to have is making the script abort in some conditions, and keep acting like NOP otherwise.

NOP does not pop anything off the stack, and as a result, neither can CLTV and CSV. Otherwise a script like "0 n CSV 0 EQUAL" would go from invalid to valid.


Sharing BIP32 extended master public key

That would achieve the expected result, as both User A and User B can derive every possible address from that Master Public Key. It would effectively be the same as User B running a watch-only wallet with that MPK; they have to be able to see all the addresses:)


Bitcoin-Qt client wallet.dat extract private key to import on another service

I would use the dumpwallet approach using Core, then use a script to remove everything but the WIF private keys and import them to Electrum which can import a list of private keys


How does a range proof bound lower at 0 and not -1?

What if C and C' are commitments to 0 and -1? Then if I can sign, that means the ring signature is a proof is over {0,-1}.

To create a signature, the public key must be a known multiple of G. That multiple is known as the private key. When a point has a nonzero H term in it, no signature with that point as public key can be created. In order to write rG+vH as a multiple k of G, k = r + v*(G/H). H is constructed in such a way that nobody knows the ratio between G and H. As a result, rG+vH can only be a known multiple of G when v = 0.

As a result, you can only sign for public keys that are points which are commitments to the value 0.

A ring signature means you're picking multiple points as public key, and signing for 1 of them, without revealing which one.

So if C is a commitment to 0, and thus C' a commitment to -1, you absolutely can create a ring signature with {C, C'} as public keys. But it's due to the presence of C there.

  I'm probably missing something, so please tell me, why can't the amount be -1 in this proof?

There is no 'value' in the proof. There is a choice of two values. The signer only proves he can sign for one of them, and verifiers cannot know which one he meant.


Bitcoins sent and confirmed by blockchain. But hasn’t been recieved

The blockchain is the truth, the whole truth and nothing but the truth. It is the only truth,  the absolute truth. It is incontestible.
If the blockchain says the money was received it has been received. Money that has been received with more than five confirmations virtually never ever becomes unreceived.
It is probably worth checking several different copies of the blockchain by using several different blockchain explorers.
If a wallet does not show this amount it means one of:

The wallet doesn't know about the receiving address. Perhaps because the address was not generated by that wallet.
The wallet isn't fully synchronised
The wallet is broken in some way
A person managing the wallet is lying to someone without direct access to that wallet.

See also

Answers to other questions about money not received


Colobit LTD looks like Bitpetite! Anyone have any experience with them?

Is ColoBit a Ponzie scheme?

It's a scam of some sort, probably akin to a Ponzi scheme.

  thought I'd be the first to sign up and get out before everyone else jumped in.

Perhaps you knew what you were getting into.


How can I check what mining algorithm does an altcoin use?

Depending on the coin, you can find the PoW algorithm by perusing the source code of the coin. For the coin you referenced, reviewing the directory Chronon/src/pow.cpp one can see the algorithm is X11.


Is there a liquidity aggregator service for bitcoins?

Coral Blocks has a free service that provides aggregated liquidity from Coinbase, Coinsetter, Okcoin and LakeBTC. You can get the aggregated book in JSON through the link:

http://www.coralblocks.com:45453/book/BTC-USD

{
    "last updated":     "20151015-21:01:27.551",
    "time zone":        "America/New_York",
    "symbol":           "BTC-USD",
    "exchange":         null,
    "spread":           -0.90,
    "best bid size":        0.07000000,
    "best bid price":       255.87,
    "best ask size":        0.00090000,
    "best ask price":       254.97,

    "bids": [

        [ "OKCN",       0.07000000,     255.87],
        [ "OKCN",       0.07000000,     255.84],
        [ "OKCN",       0.07000000,     255.81],
        ...
    ],

    "asks": [

        [ "LAKE",       0.00090000,     254.97],
        [ "LAKE",       0.06700000,     254.98],
        [ "LAKE",       0.60000000,     254.99],
        ...
    ]
}

You can also get real-time updates through TCP and FIX. More info about the API here:

http://www.coralblocks.com/index.php/2015/10/free-real-time-bitcoin-market-data/

Disclaimer: I am a developer at Coral Blocks.


secret sharing scheme for 3-of-5 shares (for BIP39 mnemonic phrase of 24 words)

Figured out a solution that can easily be done with a pen and paper and at most a pocket calculator.

You take your secret (264 bits) and divide into 6 equal-length parts. Call them A, B, C, D, E, F.

For brevity I write XY as meaning X xor Y.

Share 1: A,B
Share 2: C,D
Share 3: E,F
Share 4: CE,AF,BD (remember these are xors)
Share 5: ABCE,ACDF,BDEF

Now with a bit of xoring any 3 of these give you the entire secret. I'll write a proper blog post with instructions exactly how to combine shares and a proof that it's reliable.

Downside is that unlike SSSS, each share is only 1/3 of the entropy, so if someone has two of the five shares, it's only 2**88 attempts to guess the third. Still, 88 bit entropy by itself is not bad at all, at least in my book.

Also, unlike SSSS, the "order" of shares is important. You need to note beside each share which it's supposed to be (S1, S2...) so you know what sort of xoring to do.

What do you think? Any other weakness in this?


Which blk*.dat file contains a particular block?

Is there a way to find out which blk*.dat file contains a particular block?

We can't tell you which of your *.dat files contains block 478558 because there is no requirement that different nodes store their data in the same way.
Two installations of the same software (e.g. Bitcoin core) could have different blocks in a blk*.dat file of the same name. In fact this is probable.
See Is every copy of the Blockchain the same?
So the only way for you to find out is to parse the indexes or search every file until you find the block. I imagine you could probably make an estimate of which file is most likely based on current blockchain height + sought block and start your search in files near your best guess.


Is there only ever 1 send address for a wallet

It doesn't work that way.

Any address can send and receive. Since you'll receive coins on multiple addresses, sooner or later you will have to use those addresses to send too, in order to spend those coins.


What is the max allowed depth for bip32 derivation paths?

A path can have, at most, 256 elements, including the master. This limitation comes from the extended public key serialization format's depth field. This field is a single  byte which means it only has 256 possible values.


Is the transaction size relevant if fee per byte is the same?

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.


How do I list the addesses in my keypool?

Providing that you're referring to BitcoinCore, and that by "not being used right now" you mean there's no transaction associated with them yet, you can use this command to list them:

bitcoin-cli listreceivedbyaddress 0 true

The parameters are:

minconf = 0
includeempty = true


Is it true that only one message can be sent at a time in Bitcoin Core?

That's not quite right.

There are two main threads involved in the network code, the network thread and the message handler thread.

The network thread receives data from peers, parses it into messages, and puts those messages on per-peer queue for processing. It only serves one peer at a time, but is not restricted to processing full messages. For example when only 10 kB of a block have been received, it will process those 10 kB, and continue with another peer. When all TCP packets for a particular message have been completed, the full block message is given to the message handler thread.

The message handler thread is what implements the P2P protocol - it knows how to respond to various incoming messages. It works on a single message at a time, but it never needs to wait for incoming messages - the network thread already dealt with that. If a message is to be sent back in response to an incoming one, that again isn't done directly - it's put on another per-peer queue, where the network thread will pick it up and send it out incrementally until it is gone.

So while it is true that the message handler only operates on full messages at a time, it never needs to wait for a message to be received or sent out on the network.


What happens once the mining reward gets cut in half?

Assuming blocks are solved at the targeted rate of one block every six minutes going forward from today, the date the block block reward subsidy drop will occur happens in late November.

http://www.BitcoinClock.com

Currently the target rate is 7,200 BTC per day.  Starting with block 210,000, this will drop to a targeted rate of 3,600 BTC per day.

This event has been known (and anticipated) since Bitcoin was first released to the world in 2009.

Whether this will cause the exchange rate to rise or fall or the amount of hashing power to rise or fall is mostly speculation.

If investors are counting on the price going up, maybe to $20 let's say, and instead it sticks at around $12, then maybe they sell as it didn't deliver the gains they were hoping for.  So the lowered new supply of coins doesn't necessarily guarantee a corresponding rise in the exchange rate.

The amount of hashing that occurs will roughly approximate miner's profitability.  As long as miners can mine profitably, they will continue to mine.  If their revenue drops by half but it still exceeds the cost of electricity and other operating costs, then they will leave the equipment operating, bringing in mined coins.

Those miners whose costs put them among the least profitable will likely be forced to drop out.  These are those who currently mine with a GPU and pay avergage (e.g., $0.12 per kWh) or above average electric rates.   Unless the future exchange rate rises faster than difficulty from here, come block 210,000, possibly 50% or more of GPU miners will be dropping out -- either immediately if the have done the math, or within weeks when the total revenue calculation for the first month after the drop gets matched up against the monthly electric bill.

FPGA miners operate 5X or more efficiently in terms of electrical consumption so they are still producing positive cash flows and thus most will continue mining even after the drop.


With the current hashrate, how does it still take 10min to solve a bitcoin block?

Mining basically works like this:

Make a candidate block, try all nonces.
If none yielded a valid block, change something in the coinbase transaction.
Repeat from step 1.

Miners collect transactions and then try to create a valid block by bruteforcing nonces. The difficulty of creating a block is related to the maximum hash value a valid block may have.

For example the current blockchain head (while posting this) has a block hash of 00000000000000000077d9c18fdbd5cf45b2652fe6db9089558eb8fc9fc3b397.
As you can see it has many leading zeros, because most hashes above this value are rejected. With the 2^32 nonce values and other header fields you cannot try enough blocks to be likely to hit any block hash small enough. Miners will switch some bytes in transactions (normally in the coinbase) to create even more new block candidates.

Furthermore different miners will try different blocks, as they should have different receivers of the coinbase transactions.


If there are a significant number of pruned nodes on the network will it impact network security?

Your points 1 & 2 are both correct. The good news is the only time those old blocks get requested is by new nodes that are still bootstrapping and downloading the blockchain for the first time. As long as those old blocks are available and accessible somewhere, those new nodes will sync up just fine.
Another fact about pruned nodes is they are required to store at least the most recent 288 blocks. So if your node has only been offline for a day, you can still sync up from a pruned peer.


Is this an ok "poor man's 2 out of 3" key solution?

There are two problems with your approach. The second one's more difficult to solve than the other.

Problem 1

While it would take me a 100 million years to brute force the key 1 2 3 4 5 6 7 8 9, if I know two thirds of the key, it doesn't take just 1/3 the time, but a cube root of the time, meaning that I might actually be able to guess it.

Giving everyone a part of the key without making bruteforce faster

Instead, you generate 3 totally random strings of bytes as long as the key. We'll call these R1, R2, and R3.
We'll call the private key K, and the clients, C1, C2, and C3.
To C1, you give R1, and R2 ^ K. (^ is shorthand for XOR)
To C2: R2, R3 ^ K
To C3: R3, R1 ^ K

Example: If C1 and C2 put their heads together, they could combine R2 and R2 ^ K. This is important, because R2 ^ R2 ^ K = K
Space requirement: Given that n = number of people, and m = maximum number of people  abstain, you need n!/m!/(n-m)! ciphertexts. Okay for 3 people, starts to get unwieldy for 10.

Problem 2

When generating the key in the first place, somebody needs to know the full private key before they split it up. In other words, you need a trusted third party. To get around this, you need to do something called Distributed Key Generation. I'm not sure if this can be done for ECDSA. This paper looks encouraging based on the abstract, but I can't see the whole article.

Multi-signature transactions

This is a much more scalable and secure system. Unfortunately, it's not really ready for real-world use yet.


Why doesn't basepoint G of Secp256K1 seem to be on the Elliptic Curve?


Can same private key generate multiple addresses?

One private key maps onto two addresses - one that uses an uncompressed public key, and one that uses a compressed public key.

What you might also be interested in is a deterministic wallet - a Bitcoin wallet holding multiple addresses generated from one private key / secret. This will let you secure multiple addresses and store only one key.


Which block explorers recognize bech32 addresses?

Blockchair announced support for Bech32 addresses last month.

This page about Bech32 adoption on bitcoin.it wiki page is tracking blockexplorers that support Bech32 addresses.


What are all the small transactions in Satoshi's address?

Of course, because Bitcoin is (mostly) anonymous, we can't know for sure who has been sending these, let alone their reasons.  But some guesses:

People donating money to Satoshi, since it's known to be his address.
Mistakes.  Satoshi's address is commonly used as an example in guides for creating transactions, etc, and it could be that some people copied the example and forgot to change the destination address.
Attention.  I saw some transactions with attached OP_RETURN messages, e.g. this one (see under "Output Scripts" near the bottom).  By sending to a well-known address, there is a better chance that curious people like you will stumble upon the transaction and read the message.
Just for lols.
There are altcoins and other protocols that rely on "burning" bitcoins by sending them to a well-known address with no known private key.  A variant on this would be to send the coins to Satoshi.  Either he eventually spends them (so it becomes a donation) or he doesn't (so it's a burn), but either way the parties involved probably aren't getting the coins back.  I haven't seen this variant in practice but it's conceivable that someone has tried it.


Can a regtest bitcoind node use SignRawTransactionWithKey + prevtxs for a mainnet raw transaction?

No, you will get an Invalid private key error. Note that if you use a correct-network private key but it is the wrong key to sign the input you provide you get a different error: Unable to sign input, invalid stack size (possibly missing key)
The base58 prefix is checked against a constant value that is different for each network (main, regtest, etc)
const std::vector<unsigned char>& privkey_prefix =
    Params().Base58Prefix(CChainParams::SECRET_KEY);

https://github.com/bitcoin/bitcoin/blob/master/src/key_io.cpp#L132-L148


From multibit to electrum : low fee and unconfirmed parent

Seems like your 589 Sat/Byte went through now, however that transaction is not a double-spend of your 1st transaction because the total output Total Input amount is different.

Transaction e9723fdf6c923a278304e7bffcd3089f4175dabf2ca1702516718195e005e5dd is also not a CPFP of the 3 transactions you mentioned above.

If you want to attempt a CPFP on those 3 transactions, you have to spend the unspent output 17HiELrskFprzREjeLDYNuDARV64Q59Ta6, transaction cf617f5908f89c604a5a575b0eac1c570141868569be38510da8916d5f397628.

Did the math for you:

Add all transactions including your new soon to create CPFP transaction:
Great-grandparent + Grandparent + Parent + Child
225 Bytes + 521 Bytes + 192 Bytes + 192 Bytes = 1130 Bytes

Then add up all paid fees:
10000 Sat + 10000 sat + 10000 sat = 30000 sat

Divide to get current Sat/Byte:
30000 Sat / 1130 Bytes = 26,55 Sat/B

Estimated fee to confirm within 60 min. At least 379 Sat/Byte.
Check out https://estimatefee.com
Subtract to find difference needed:
379 - 26,55 = 352,45 missing Sat/B

Fee for new CPFP transaction:
352,45 Sat/B * 1130 Bytes = 398268,5 sat = 0.00398268 BTC

Fee per byte for the new CPFP transaction:
398268,5 Sat / 192 Bytes = 2074,3 Sat/B

Conclusion:
Make a new transaction, send BTC from 17HiELrskFprzREjeLDYNuDARV64Q59Ta6 with a minimum fee of 2074,3 Sat/B and all your transactions will most likely confirm within 60 min. Or ask miners for help.

Click here for visualization of double spend

Click here for double spend example with Electrum.

How to double-spend(if your client allows it):

For example directly to your Bittrex address and some changes to yourself:
Create a transaction that spend the same
Unspent Transaction Output(0.16123728 BTC) as in your 1st transaction.

FROM 1GeAmqqQn1LxBebtt6tmuPVHfzEo9jWPrH (0.16123728 BTC)
TO   17HiELrskFprzREjeLDYNuDARV64Q59Ta6 (0.04497458 BTC)
AND TO  1GeAmqqQn1LxBebtt6tmuPVHfzEo9jWPrH (0.1153587 BTC)
With 400 Sat/B as fee.
If I did the math correctly this transaction should have total output 0.16033328 BTC.

Or if you prefer to send it all to yourself:
FROM 1GeAmqqQn1LxBebtt6tmuPVHfzEo9jWPrH (0.16123728 BTC)
TO   1GeAmqqQn1LxBebtt6tmuPVHfzEo9jWPrH (0.16123728 BTC - fee)
Include a reasonable fee(estimatefee.com) so it confirms within your desired timeframe.
If this transaction gets confirmed first, then your 3 transactions mentioned above will be rendered invalid/disappear.


You can check this github page about btcd, one of the concurrent of bitcoin core where they talk about their API which is fully compatible with bitcoin

  btcd provides a JSON-RPC API that is fully compatible with the original bitcoind/bitcoin-qt. There are a few key differences between btcd and bitcoind as far as how RPCs are serviced:

https://github.com/btcsuite/btcd/blob/master/docs/json_rpc_api.md


What is the cause of "version handshake timeout"?

You’re connecting to peers that aren’t responding to you in a sensible time period so you disconnect them and try somewhere else. This isn’t really indicative of anything other than some nodes not being particularly useful to connect to.


transaction inputs does not have prev_out field

Transactions without prev_outs are known as coinbase transactions (not to be confused with transactions from the company named Coinbase) or coin generation transactions. They create outputs without needing any inputs to the transaction. Coinbase transactions are special transactions which are created miners and included as the first transaction in a block. They are what pays miners for their work.

There can only be one coinbase transaction per block, and it must be the first transaction of the block. The sum of the outputs must also meet certain constraints: it can be no more than the sum of the block subsidy and the sum of the transaction fees paid by all transactions in the block.


How different crypto exchange correlate with prices

Your base assumption that exchanges only accept local identities is false. Most accept traders from around the world.

Take Binance.com for instance, which is based in China with servers in South Korea\Japan, and they accept international IDs when you verify your account.


Is there any relation between the block version field and the one of the transaction?

I would send your solved block to a core node of your own and then check the debug.log file to see why it wasn't accepted.

But, no, in general there is no necessary relationship between the version of the block and the version of transactions. Version numbers just give a signal to other nodes if there is any special way to handle new blocks/transactions.

As per BIP34, version 2 blocks now have the block height put into the scriptSig of the coinbase input so that no one can make a transaction with a duplicate transaction id (hash).


Getting source address of a Tx message from it's signature script

You can't.

If all you have is a capture of the wire traffic for a single tx, you can't (always) compute the actual address.

In a certain subset of cases, such as for standardized scripts such as P2PKH or P2SH multisig, you might be able to assume the script sig to correspond to one of them, if it has the right data.

The scriptsig mentioned is for a segwit address, and is commonly put as the redeem script for P2SH wrapped segwit addresses.

However, note that just because a script sig matches the expected form for an address does not mean that the actual output corresponds to that address. For example, a P2PKH address would have a script sig with two pushes (one for the signature, one for the public key) - If you were so inclined, you could build an output script that simply consumes the top two elements of the stack, and create an output that will accept a P2PKH script sig as valid, while having absolutely no relation to the P2PKH address.

In general, if you want to know the source address, look up the transaction being spent, and use the locking script from that vout.


For Mac OSX users, you must have Snow Leopard (10.6) or newer
installed.
A fully-connected BitCoin wallet. see http://bitcoin.org/
If this is the first time you have launched BitCoin, it must
download and verify all the existing blocks in the system.

 This can
    take an hour or longer - just ignore it for a while.

  Update: since the time of this post the block chain has grown It can take several days on a slow connection to download and is currently pushing past 15GB

Install DiabloMiner see
https://github.com/Diablo-D3/DiabloMiner/wiki/Solo-Mining