How can I use bitcoins on deposit? I had received bitcoins before my wallet was fully synchronized and it took several days for it to finish the process, so I decided to deposit the bitcoins in another wallet. Now I can see they are "on deposit", but they do not show up in my other wallet. How can I move them to my wallet or use them?
Thank you!

If you want to send newly received Bitcoins from a wallet that is not yet synchronized you have two choices:

Wait until your incoming Bitcoin transaction has synced. Your wallet cannot send Bitcoins that it cannot yet determine it has received (because it has not yet synced to the block height were you received the BTC)
Import the keys of your receiving address or HD wallet into a wallet that has fully synced the blockchain or a light/SPV wallet

Please understand that you own any Bitcoin for which you control the private keys and that Bitcoin can be used with any wallet. However just because you own Bitcoin does not mean that you can spend it from a wallet that is not yet synchronized. When a wallet is not synchronized at least up to the point where an address you control has received the Bitcoin you are looking for, your wallet has no way to verify your ownership of that BTC.


Which kinds of transactions show quadratic signature-hashing scaling? It has been stated:

  A major problem with simple approaches to increasing the Bitcoin blocksize is that for certain transactions, signature-hashing scales quadratically rather than linearly.

https://bitcoincore.org/en/2016/01/26/segwit-benefits/#linear-scaling-of-sighash-operations

What are some examples of transactions with this behavior, and what do they have in common?

Does a simple one-input-two-output Alice-pays-Bob transaction show quadratic signature-hashing scaling?

Quadratic means that something grows as a square function of something else. If you're just talking about a single transaction, there is nothing that changes.

The quadratic hashing issue is that the amount of data to hash to compute or verify signatures grows as a square of the number of non-segwit inputs.


Building the merkle root from transactions in a template block I want to compute the merkle root for transactions in a given template block -  bitcoind:getblocktemplate().

I understand the merkle root is a hash of all the transactions in a block from the last up to the coinbase transaction, but this is currently way above my pay grade and the documentation I can find for this process is abstract and sketchy at best.

Has anyone done this in JavaScript or know of a resource that could be helpful?

Thanks in advance.

client.getBlockTemplate( function(error, template) {
    if (error) return console.log(error);

    // SETUP MINING
    nonce=0;
    const block = {
        version: template.version
        ,previousblockhash: template.previousblockhash
        ,merkleroot: calculateMerkleRoot(template)
        ,time: template.mintime
        ,bits: template.bits
    }

    // START MINER
    miner(block,nonce);
});

I'm much closer now I hope this helps someone else trying to do this!

REQUIREMENTS:

NPM bitcoin bitcoin-js merkle-lib

CODE:

client.getBlockTemplate( function(error, template) {
    if (error) return console.log(error);
    txhashes = template.transactions.map(function(tx){ return Buffer.from(tx.txid, 'hex').reverse() });
    merkleRoot = fastMerkleRoot(txhashes, bcrypto.hash256);
    console.log(merkleRoot);
)};

The result is in a Buffer and I'm having trouble converting it to hex.


Sent to wrong address! :( Hi I need some help, I ordered some bit coin from bitcoin.co.uk and sent them what I thought was my wallet address on mycelium, but what I sent them was a qr code address when u click on recive! Will it be sent to that at code or will it just be lost? And if it’s not do I just need to scan that qr code with a different wallet qr scanner?? :(

Yes the address in QR code is your address. so no worries your bitcoins has to go to your wallet.


How does a blockchain relying on PoW verify that a hash is computed using an algorithm and not made up by a human? How does a blockchain verify that the hash provided (the one with the leading zeros that is supposed to be unique, computed using lots of processing power) is indeed unique and that it wasn't just a random number some one came up with and then just added the expected leading zeros to it?

A Hash Function maps "data of arbitrary size to fixed-size values". As an incredibly simple hash, consider a function only works on numbers and simply returns the last 3 (decimal) digits (ie., the 1s, 10s, and 100s places).
Using this simple hash, 5 would hash to 005, and 123,456 would hash to 456.
A Bitcoin block contains a handful of fields (source):

Version
Previous block hash
Merkle root
Time stamp
Difficulty bits
Nonce

All of those can be represented by numbers (the time stamp is Unix time (source), which means it's basically the number of seconds since 00:00:00 UTC on 1 January 1970).
Of those values, only the nonce can be freely changed without invalidating the block. The timestamp can take a range of values (roughly "1 hour ago" to "2 hours from now" (source)), and the version number has a great deal of flexibility (ibid). I'll focus on the nonce since that's the easiest for me to talk about.
Proof of work, in this simplified scenario, is accomplished by adding all of those numbers together and finding a nonce that results in the hash being 000. In this simplified scenario, that's trivial to do: you can just add the other numbers together, hash that partial sum, then set the nonce to 1,000 - that partial hash. So, it's not a very good hashing algorithm for this purpose.
Instead, Bitcoin uses SHA256. SHA256 has a couple of advantages which stem from its being a cryptographic hash function; the big three are that calculating the SHA256 hash of a given value is "cheap" but generating a value that will produce a given SHA256 hash is hard, and that tiny changes in the input will produce large changes in the output (the avalanche effect).
In fact, to the best of our collective knowledge, the only way to generate an input that produces a given SHA256 hash is to keep trying inputs until you find one that works.
So: unlike the simple hash at the beginning, we can't figure out what the nonce should be just by looking at the rest of the data. And, we can't just tweak the nonce to get the hash we want: the avalanche effect means that every small change to the input will have large changes to the output. Therefore, the only way to find a nonce that produces a valid SHA256 hash is to start at 0 and work up 'til a suitable nonce is found.
Once a suitable nonce is found, anyone can verify that the nonce/hash pair is valid by hashing the block with that nonce and seeing that the hash matches. This check can be done very quickly, and serves to prove that whoever found that nonce did the work.
The nonce is a 32-bit integer (source), which means that there are 4,294,967,295 (just under 4.3 billion) possible nonces. Compare that to the Powerball lottery, in which a single ticket has about a 1-in-300,000,000 chance of winning the jackpot, and it becomes clear how unlikely a randomly-chosen nonce is to be valid; even if there were thousands of nonces that could produce a SHA256 hash with enough leading zeroes, picking nonces at random would still be staggeringly unlikely.
Then, the time can take any value in a roughly 3-hour window and has second-resolution, so there are ~10,800 values it can take. The version has some limits, but it appears to be another 4-bit integer like the nonce; for rough calculations' sake, let's say it can take half of the possible values that the nonce can. That means that there are around 9e+22 (a 9 followed by 22 zeroes) possible combinations. There are about 200 billion stars in the milky way (source); that is, 200,000,000,000 or 2e+11. Finding a correct header randomly had odds in the realm of two people randomly choosing the same grain of sand from the whole of the galaxy.


Is there an updated accurate list of retailers who accept Bitcoin from Canadians? I'm new to Bitcoin and I wanted to know which retailers/hotels would accept Bitcoin as a form of payment from Canadians. If a site accepts Bitcoin as a form of payment does that mean they accept it from every country or just specific countries though they might accept credit card as a form from every country.

You're asking 2 questions here..

1) list of retailers/hotels: try this site https://spendbitcoins.ca/

2) bitcoin is borderless. if they accept it, they accept it. now that's not to say a geo-located website might accept btc on their american (.com) site but not the british version (.co.uk), as overstock do. but that's a business decision, not a property of crypto currencies. think of it this way: if a business accepts it, they have a wallet address you can send money to, as long as you have a wallet too. doesn't matter where in the world you are. kind of like email.


Does the Bitcoin client not record original signature data per connection? I just read the malleability page.

Can someone confirm that this

  While transactions are signed, the signature does not currently cover all the data in a transaction that is hashed to create the transaction hash. Thus while uncommon it is possible for a node on the network to change a transaction you send in such a way that the hash is invalidated.

means that the protocol actually doesn't assign signature data to addresses in the database?

Please tell me that's not true.

The signature covers everything except the signature itself.  Since the signature and public key make up the input script for the most common payment type (pay-to-pubkey-hash), the input script is not part of the signed data.  This means the input script can be modified and not break the signed transaction as long as the new input script is equivalent to the original input script.  The recent attack did this by changing one of the script opcodes to an equivalent opcode.  So the new script was valid and performed the same function.  But since the opcode was changed, the transaction hash was different.

Once a transaction is part of a block, the transaction hash cannot be changed since it is now included in the Merkle tree for the block.  So the attack window is only from the time the transaction is created until a miner includes it in a block.  During this window, a modified transaction can be broadcast and it is a race to see which one makes it into the block.  The one that loses will never be confirmed since it spends inputs that are already spent.  No matter which one wins, the coins are sent to the proper destination.

The problem for Mt Gox (and others) is they track a transaction based on its transaction ID.  If the modified transaction wins and gets included in a block, the original transaction will be discarded.  This then led Mt Gox to think the money was not paid (since the transaction ID was not in the block chain) and they would create a new transaction to pay the money again.


Learning + checking the bitcoin address creation process at each step I’m learning how hashing algorithms are used around the process of bitcoin address creation.

I’ve read lots of great examples online that, step by step, show the output of each sequential hashing stage - start to finish.

I’ve occasionally copied one of the outputs from one of the steps (from the online 'worked example') using copy (Ctrl C) and then pasted it (Ctrl V) into one of the many online hashing sites to simply confirm the next step in the process to see it for myself.

I’m doing something wrong. Convinced that my simple ‘copy and paste’ approach must be flawed as my hashed output won’t ever match the hashed output shown on the example online -never does.

I’ve checked for the hard to see white space and carriage returns but to no avail.

Any comments greatly appreciated regarding what I might be doing wrong when I’m simply double checking each stage for myself ?

Here’s two sites I’ve studied:
https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
https://en.bitcoin.it/wiki/Wallet_import_format

and two sites I’ve used for checking hashing:
https://hash.online-convert.com/sha256-generator
https://md5calc.com/hash/ripemd160

Any program actually generating bitcoin addresses will always be hashing the bytes directly - what you see on the Wiki are simple hexadecimal strings representing those bytes.

The various hashing sites you have tried will treat those inputs as strings. For example, instead of hashing the byte 0xFF when you enter FF, they will hash the text FF, which is actually two bytes if interpreted as ASCII. You will never get a correct answer using such sites.


Woo Commerce pubKey+publicIP (URI)? I have integrated my bitcoin lightning network node with the Woo Commerce plugin available on the " https://github.com/ElementsProject/woocommerce-gateway-lightning" .

But facing trouble to get payment on my generated invoice .So somebody recommended to connect to WooCommerce Shopping Store.

Can anybody help in finding pubKey+publicIP (URI) for WooCommerce Shopping Store. I found it on Internet but could not find it.

You should only need to connect to any of the nodes in the Lightning network and it should take care of learning about the rest of the network. So my suggestion would be to take any node on https://lnmainnet.gaben.win/, look at its details, and if it has a public key and IP associated just connect to that one.


Motivation to run full nodes I'm sorry if I ask a stupid question. Bitcoin network was conceived by Satoshi Nakamoto as a decentralized network, but now we are seeing the full centralization of nodes in the United States.
The user lacks motivation for hosting the full node as it requires financial costs but it does not pay off.
I have a question. Does the bitcoin network protocol display address when requesting a useragent. Now we can see only the version and ip address. To anyone could donate a certain amount of coins for those who start a full node in the network.
The ideal option proposed by the bitcoin core developer Jeff Garzik  would be to make a commission for that unit is now fully take miners to share with all the owners of the full nodes.
Sorry for my English.

I'm not sure I understand your question, but: No, Bitcoin nodes do not announce their own Bitcoin addresses as part of the network protocol.

One could imagine modifying the protocol so that they did, but it would raise anonymity concerns: currently, by design, it is difficult to match an address with its owner's IP address.  If you knew at least one address that belonged to a particular node, you  might be able to look at other transactions in the block chain and deduce other addresses belonging to that node.  And ISPs usually have records that determine the identity of a user from their IP address.


Which API provides the website URL for a cryptocurrency? I've been searching for an API that returns the website/URL for a cryptocurrency. Is there any public API which provides the website for a specific cryptocurrency?

CryptoCompare's API has the website URLs if you use CoinSnapshopFullById:

CryptoCompare API


Why can't I use Electrum seed to recover my wallet on Trezor and Blockchain.info? I wanted to use my BCH after the hard fork so I was going to import my wallet on Trezor or Blockchain.info since they support BCH (Electrum doesn't support BCH AFAIK) but it seems both Trezor and Blockchain.info can't recover seed generated from Electrum. Am I missing something ?

Electrum uses a custom mnemonic format so yes Electrum wallets cannot be restored in any other wallet using the seed mnemonic. Instead I suggest installing and running electron cash to get access to your BCH straight away. It's a fork of electrum for bitcoin cash and by default it imports all your electrum wallets automatically. The official site is https://electroncash.org/


What were IP transactions supposed to be useful for? Besides sending BitCoins using wallet addresses, there used to be another way, through IP transactions as described in the wiki.

The disadvantages were obvious (man-in-middle attacks etc).

However, were there any benefits (to the individual or to the whole system) in using IP transactions?

First, it needs mentioning that this functionality has already been removed from the original Bitcoin client.

Here is the GitHub pull request removing this functionality that has been accepted 2 years ago. The wiki page you refer to seems outdated.

The only known use for IP transactions I could find is the one mentioned in the pull request by gmaxwell:

  Aww. The removal of this would mean we can't run a lottery for nodes running the most recent version of bitcoin as an incentive to make people upgrade. :)

Another use I can come up with myself would be that you could use the DNS system to create a human-readable address to your IP and use that as your payment address. F.e. I could use bitcoin.stevenroose.be and put the IP address of the computer running my Bitcoin client in the DNS table for that record. I could then tell people to send bitcoins to that address. However, this method would require a PC to be permanently running and connected to the network in order to be able to receive bitcoins.


Tramsaction taking long, 1 part is spent So i made a transaction today:

https://blockchain.info/tx/1eab828a3e673e322aa4da4ff03962dbad3b2fa5b70818e3db9c5dc32abead93

Besides the fact that this is taking ages, 1 of them has the state 'spent'. I am missing some informatioon on this. Could someone explain this? And why is the rest unspent?

Some exchanges combine many transactions into a single transaction when withdrawing, to save fees and be more efficient with space. It will likely confirm eventually, you'll just have to wait for a miner to put it in a block. One output could be spent already because it is possible to spend from unconfirmed outputs, just slightly more risky.

See also: Why is my transaction not getting confirmed and what can I do about it?


Does wallet support multi account/user? Does bitcoinj wallet support multiple accounts/users?

It seems BIP44 is not supported and found multiple threads indicating lack of support.
Just wanna get a definitely answer. If not yet, any plan to support it in the near future?
Thanks in advance.

Bitcoinj only supports one user and one account per wallet. Because i think managing multiple accounts can make the API
unnecessary complex. Normally you would use one wallet per user and that's what happens
automatically if you use your OS to switch users.

Also

I would recommend taking a look at this if you're interested in using BitcoinJ with BIP44. You would have to have one instance of Wallet per "BIP44 account" but it can still work.


transaction's limits I'm new about this market and I don't know if there's some limits about the transactions on the copay wallet. I think to use this wallet for personal and business transactions.
Someone can answer me if I can receive on the wallet several transactions and if there's some limits about btc I can receive?
Tks

Coins are sent to addresses in a globally distributed ledger, not to wallets. The Bitcoin network does not “know” what wallet-software you are using to manage your addresses, and it cannot prevent people from sending coins to addresses that you own. So, the short answer to your question is “No limits.”

One thing that might delay a transaction would be if the payee set the transaction fee too low. Miners, being economically rational, tend to validate transaction sooner if the fees are higher. If the fee is too low, then the coins may get returned to the sender without ever being credited to the recipient. But this has nothing to do with the recipient's wallet-software, since fees are set by the sender.


What are the limitations for amortizing the interactive session setup of MuSig? I'm trying to find a way to amortize the interactive session setup in the MuSig signature aggregation scheme.  My motivation is to use signature aggregation between devices communicating using low bandwidth (radio) channels without having to do the session setup multiple times. Ideally pre-shared public nonces could be reused for different signer sets, public keys and messages.

I've summarized below how I understand it works now, mostly from looking at the code example here:

each peer creates a per session secret key from the hash of the set of signers public keys and the secret key for the peer's public key (independent of the nonce)
each peer creates a secret nonce from the signers public keys and other hashed information, including a random number
each peer creates a public nonce, generated like a public key from the secret nonce.
all peers send to all other peers a 32-byte nonce commitment
all peers send to all other peers their 32-byte public nonce and verify the others against their previously shared nonce commitments

  the key point seems to be that the public nonce should NOT be freely chosen by anyone after learning the public nonces of the other signers

each peer can now sign using their session secret key and secret nonce
other peers can verify the final (or partial) multi-signature using the other signers chosen public keys and their corresponding public nonces.
What I wonder is if the public nonce can be committed to once in advance by all peers, and then reused for different combinations of (public key, other peers public keys, messages).

It seems like peers could cache each others public nonces and reuse them for different signing sessions with different public keys and other signers as long as all signers were compelled to use the same public nonce every time they signed.

Any pointers on the restrictions for reusing these MuSig public nonces would be appreciated.

Nonces must not be reused! In particular, in MuSig, nonces can not be reused
for other combinations of public keys or messages (also if everyone uses the
same public nonces all the time). This would leak private keys.

You pre-share fresh nonces by running multiple signing rounds in parallel.
With the library you link to
(secp256k1-zkp) this is
secure as you long as you keep the session states in memory and don't copy it.
Serializing the state and storing it on a persistent medium is not supported by
secp256k1-zkp and difficult to get right because if you accidentally use the
wrong nonce, you leak the private key.

A straightforward way to eliminate the overhead of the first two interaction
rounds is by attaching the nonce commitment and nonce to already existing
messages in your protocol. That way you would only have two parallel signing
sessions.

There is research being done on deterministic nonces for MuSig which have
zero-knowledge proofs that the nonce is derived correctly. With such proofs
nonces can be derived on demand from the signer set, your private key and the
message and there is no state to keep track of.


How Would One Premine an AltCoin? Looking to create an Altcoin for fun and I heard about premining. Can this be done to premine all the coins without leaving my computer mining for days?

I followed a guide here: http://andarazoroflove.org/how-to-create-alt-coin-scrypt-clones-for-fun-and-profit-bitcoin-litecoin-secrets-exposed/

Thanks

If you create the coin, you get to make the rules.  Nothing stops you from patching the software to make your premining as easy or as hard as you want.  For instance, you could set the difficulty schedule so that the first billion coins require very little or zero proof of work to mine; then you could mine them all at once and award them to yourself.

Of course, the hard part becomes convincing anyone else to use a currency that's so obviously slanted in your favor.


Is a hypothetical Bitcoin network on Mars guaranteed to fork from the one on Earth? Electromagnetic waves take between ~4 and ~24 minutes (mean: ~14 minutes) to travel a one-way trip between Earth and Mars. Suppose I set up a Bitcoin network on Mars. Is it guaranteed to eventually fork from the Bitcoin network on Earth?

I would expect the Bitcoin network on Mars to fork from the one on Earth, because Bitcoin's target inter-block time is 10 minutes, which is less than average time it takes for electromagnetic waves to travel between Earth and Mars. Am I correct?

No, not necessarily, but mining in both locations is infeasible.

As Pieter explained in Is it possible to use bitcoin as interplanetary money/store of value?, exorbitant latency between miners would cause perpetual forks especially when the latency exceeds the targeted block interval. Only one of the two latency-separated mining clusters can be profitable: the stronger mining cluster will over-proportionally win cases of competing chain-tips, curbing the revenue of the weaker mining cluster due to mostly losing rewards to extinction of their blocks.

While mining is impractical, it would be possible to send and receive Bitcoin payments. Since communication between the planets could potentially be censored, a user located on Mars (i.e. the weaker mining cluster) must wait for an ample number of confirmations before relying on the payment's finality.


Why do the biggest exchanges reuse Bitcoin addresses if doing so is unsafe? It's generally accepted that using one address for multiple transactions is unsafe, because sending a transaction reveals your public key (whereas only the hash of your public key is required to receive transactions).

If this is actually a safety concern, why do the biggest exchanges like Binance reuse their core storage addresses for many months, storing hundreds of millions of dollars? For example, Binance cold storage has 100 transactions:
https://blockchain.info/address/16ftSEQ4ctQFDtVZiUBusQUjRrGhM3JYwe
and Binance hot storage makes hundreds of transactions every day:
https://blockchain.info/address/1NDyJtNTjmwk5xPNhjgAMu4HDHigtobu1s

As a side question, in theory everyone knows the public key of these addresses since they have outgoing transactions. Where is this information written? I can't find it on the transaction page of Blockchain.info:
https://blockchain.info/tx/4d5b7175b4553d3239dae830837045adbe880b3d57dfc0c59a1bb8e6991b8ff8

It's generally accepted that using one address for multiple transactions is unsafe, because sending a transaction reveals your public key (whereas only the hash of your public key is required to receive transactions).

It's not unsafe. It is however gratuitously giving up privacy - yours, and that of others you interact with.


How to decode messages embedded with btcmsg? btcmsg seems to be using proprietary software to encode and decode messages in the blockchain.

Did they expose their algorithm? If they shut down tomorrow, how can someone decode messages he stored using their service?

Their FAQ links to a document that describes the protocol, and they provide an open source Python client to decode the messages. The server implementation is also open source.

I put the client files + protocol spec on a github gist, just in case.


Who Really Controls Bitcoin? Source: https://steemit.com/bitcoin/@dantheman/who-really-controls-bitcoin

This article suggests that governments and electricity companies have the power to control bitcoin.  Any truth in this article?

I've attempted to post this question twice on reddit bitcoin and reddit btc, but my question keeps disappearing.

As we've answered earlier today the description of what happens when 90% of the hashpower is lost is approximately accurate, although somewhat exaggerated:

  "A 90% loss will create 2 hour block intervals and take a year to resolve."

Actually, it would be 100 minute blocks and would take less than half a year even assuming that no new hashrate were added and the event were directly after a difficulty reset.

Now, luckily, no single government can intervene with 90% of the hashpower. I've seen estimates that about 60% of the hashpower is in China, which if taken out at once would be a major blow, but would only delay the network's rebalance for three weeks (five instead of two weeks for the difficulty period).

Besides, if really 90% of the hashpower were taken out at once with no chance of recovery, a lot would speak for an emergency hardfork to a new hashing algorithm, both to resolve the difficulty hike as well as evading a potential majority attack from the government(s) that took control of the 90% hashpower. While the article alludes that

  "forking is impossible without an effective voting / governance system for Bitcoin"

It seems to me that in the face of such an external attack a fork with the single purpose of changing the hashing algorithm would be achievable.

Finally, the article states:

  "Only Delegated Proof of Stake (DPOS) has the ability to remain independent of direct government control due to the much lower resource requirements for operating a node."

Which feels like an oversimplification to me. PoS is widely considered as being less secure than PoW among experts, but even so one can say certainly that it makes different security trade-offs. E.g. it is susceptible to one or a few parties holding a majority of the system's tokens, and since POS deployment often is combined with a large pre-mine, it is not hard to be concerned about the initial distribution. One must also consider that the author Daniel "dantheman" Larimer is the founder of Steemit, so it would make sense to get another opinion on the trade-offs between PoW and DPOS…


LND funding transaction stuck in mempool due to low fees I have a funding transaction stuck in mempool due to low fees. Searchng around I have find that there is "BumpFee" wallet option to push your transaction. i have tried in this way:

~$ lncli wallet bumpfee [Channel_point] --sat_per_byte 150

>[lncli] rpc error: code = Unknown desc = the passed output doesn't belong to the wallet

When type:

~ $ lncli pendingchannels

i can see the transaction waiting for confirmation, but when type:

~$ lncli wallet pendingsweeps

  {
                "pending_sweeps": []
    }

there arent.
The transaction is still present when type:

~ $ lncli listchaintxns

Someone can  try to explain or have had similar behaviour?
Don’t found so much useful stuff in Github

https://github.com/lightningnetwork/lnd/blob/master/lnrpc/walletrpc/walletkit.proto

I solved the problem whit CPFP (children pay for parent).

I used the  unconfirmed change of the fund TX stuck in mempool to open a new channel.

At the time of broadcasting TX the median fee is around 150sat/vb, so i chose to slight increase at 200 sat to ensure good probability to push the first fund tx and the second one in the next block avaible.


how to retrieve BTC from BCH address I was on KuCoin and accidentally sent BTC to the BCH address (thinking I was buying BCH). Of course nothing shows in the BCH wallet on KuCoin. I can see it on the blackchain but cannot access it.

At a technical level, this is possible. You can retrieve BTC from a BCH address by importing the private key into a BCH wallet.

However, for many exchanges, security systems do not allow the removal of private keys (for instance, they may be locked in an HSM, or tied down through other security controls). They would also not allow for the signing of arbitrary transactions in some cases, preventing manual recovery.

Your only option is to reach out to Kraken and request them to access the private keys in some manner and sign a transaction for you that sends the BTC back to an address you control. It may not be possible with their setup, but it is your best (and only) course of action.


What are seeds in the source code of bitcoin? https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp

starting from line 132, I see the function vSeeds.emplace_back("seed.bitcoin.") and next to them there are real full names. What do seeds do? What are these lines for? What is the meaning of those names? Can someone give a technical detail please?

In order for a bitcoin node to start connections with other nodes, it first needs a seed node. A seed node can be any node (listening) connected to the bitcoin network. Once the node has connected to the initial seed node, it can then retrieve information about other nodes in the network and start connections with those ones as well.

The names you are seeing in the source code are the URLs of some of the bitcoin core developers that host seed nodes. If you don't trust these crazy cypherpunks, you can actually specify your own seed node in your bitcoin.conf under the option seednode=<your_seed_node>


error durring the bitcoincore installation I want to use python-OP_RETURN library.
For this I need to install bitcoin core.
But when I exceute this command
sudo apt-get update I have this error :

Err http://ppa.launchpad.net jessie/main amd64 Packages

Err http://ppa.launchpad.net jessie/main amd64 Packages

Err http://ppa.launchpad.net jessie/main amd64 Packages

Err http://ppa.launchpad.net jessie/main amd64 Packages

Err http://ppa.launchpad.net jessie/main amd64 Packages
  404  Not Found
Get:2 http://security.debian.org jessie/updates/main amd64 Packages [371 kB]
Ign http://httpredir.debian.org jessie InRelease
Get:3 http://httpredir.debian.org jessie-updates InRelease [142 kB]
Hit http://httpredir.debian.org jessie Release.gpg
Hit http://httpredir.debian.org jessie Release
Get:4 http://httpredir.debian.org jessie-updates/main amd64 Packages [17.6 kB]
Get:5 http://httpredir.debian.org jessie/main amd64 Packages [9032 kB]
Fetched 9626 kB in 8s (1085 kB/s)
W: Failed to fetch http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu/dists/jessie/main/binary-amd64/Packages  404  Not Found

E: Some index files failed to download. They have been ignored, or old ones used instead.

What does it mean?

Your on debian the bitcoin PPA only works on ubuntu.
See this guide to build it on debian.
https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md


How do I mine with FPGAs? I'm not entirely sure how FPGA's work...

Do I simply buy a ZTEX and it mines, or do I need to plug it into a computer via USB?

Can I chain them?

I'm so confused.

The very basic idea of an FPGA is that it can be loaded with a specific firmware (a layout of logical gates, in essence). That page contains the firmware you'd need to load onto a Xilinx FPGA (A Spartan 6) in order to use it as a mining device. ZTEX refers to a suite of the FPGA, and various IO controllers (USB, etc.).

Roughly speaking, the steps you'd need to follow would be:

Buy device
Plug in device to your computer
Load firmware onto device from your computer
Run a piece of software on your computer that interfaces with the firmware now loaded on the FPGA
Profit (in a couple years)

To answer your questions: yes, the device would need to be plugged in to a computer using the method in your link, and yes, you can "chain" them - i.e. have more than one plugged in. I've greatly oversimplified steps 3 & 4, by the way.


How does the wallet identify which UTXOs belong to a public address while creating a new transaction? I am a beginner here. A Transaction output has a field for amount and a locking script but no direct field for public address for which the output is meant. When a new transaction is being created, the wallet searches the UTXO set for outputs that is locked to one of the wallet's public addresses.

  My question is, how does the wallet, while searching, know that a
  particular UTXO is locked to its public address?

  Does it check each UTXO using a unlocking script to find whether it
  is locked to its public address?

  Or does it maintain a separate database which maps public addresses to
  UTXOs meant for it, or anything similar for faster lookup?

  How does it find this subset of UTXOs which is locked to the public
  address?

A Transaction output has a field for amount and a locking script but no direct field for public address for which the output is meant.

This is not quite correct and seems to be the source of the confusion.  A "locking script" contains the essential part of an address surrounded by the additional commands necessary to lock (or encumber) the bitcoins in that output to the address.  Let's look at an example; first we get an address:

$ bitcoin-cli getnewaddress
397yNmAFc1w6AK1gqkKNxJPb44jnvznm2b

Then let's ask the wallet what it knows about this address:

$ bitcoin-cli validateaddress 397yNmAFc1w6AK1gqkKNxJPb44jnvznm2b
{
  "isvalid": true,
  "address": "397yNmAFc1w6AK1gqkKNxJPb44jnvznm2b",
  "scriptPubKey": "a91451812710fc166bf61033afc0d2a8d7cda7a0fd8c87",
  "isscript": true,
  "iswitness": false
}

Note the scriptPubKey---that's what you're calling the "locking script."  Let's see what that script says:

$ bitcoin-cli decodescript a91451812710fc166bf61033afc0d2a8d7cda7a0fd8c87
{
  "asm": "OP_HASH160 51812710fc166bf61033afc0d2a8d7cda7a0fd8c OP_EQUAL",
  "reqSigs": 1,
  "type": "scripthash",
  "addresses": [
    "397yNmAFc1w6AK1gqkKNxJPb44jnvznm2b"
  ]
}

The asm field is the interpreted form of the locking script; OP_HASH160 and OP_EQUAL are two parts of the P2SH-style encumbrance for addresses starting with a 3.  The value in the middle 5181...fd8c is the hex form of the essential component of the address (other parts of the address are a version byte and a checksum; these aren't necessary to put in the locking script).

So, in short, the address 397yNmAFc1w6AK1gqkKNxJPb44jnvznm2b is a representation of the same thing as the scriptPubKey a91451812710fc166bf61033afc0d2a8d7cda7a0fd8c87.  The scriptPubKey is the data that actually gets placed in the output to indicate that a certain set of bitcoins are controlled by the owner of the corresponding address.

  How does it find this subset of UTXOs which is locked to the public address?

A wallet that's part of a full node simply scans every transaction the full node receives to see if any of their outputs pays one of that wallet's scriptPubKeys (addresses).  If it does, the wallet saves that UTXO in its own database until it's time to spend it.

Lightweight wallets typically ask full nodes or servers to help them find the outputs.  Sometimes this entails scanning blocks basically the same way the full node wallet does with some extra steps (see BIP37), sometimes the server builds a giant database of every address every seen and performs lookup queries on it (see Electrum servers), and sometimes the full node builds a very compact index and sends that to the lightweight client so the client can request blocks that might contain its transactions (see BIP158).

Notably, wallets need to know which UTXO paid you in order to show you your balance, so wallets don't look up UTXOs when spending, they look them up when receiving.


is my xPub published when I make a payment? (wallet privacy) I'm generating new addresses for every payment I receive, but what happen when I transfer the bitcoins from my wallet to another address?
is my xPub exposed when doing that (maybe to the bitcoin node?)
if yes, what is the recommended way to avoid exposing my full wallet history?

No, the xpub is not published anywhere. Only individual public keys are published and those are permanently stored in the blockchain. There is also no way for someone to figure out the xpub and any related keys given just those public keys.


What is the transaction ID? I have sent a Bitcoin amount to someone who wants the transaction ID. What is this? Is it the hash shown on the LHS of the transaction?

Transaction ID usually refers to the 2xSHA256 hash of the transaction serialized as it would have been transferred in the network. This is also the ID as peers refer to them when broadcasting through the network.

Notice that due to transaction malleability a transaction may have multiple IDs.


Why can't bech32 addresses be mixed case? I know that they cannot be mixed case due to their BIP but what was the intention behind this idea and would it be problematical to convert a mixed case bech32 address to a lower/upper case bech32 address?

Having only one case (which is really no case) makes bech32 less prone to handwriting errors. It makes it easier for people to write down a bech32 address as they don't need to be concerned about which casing to use and to distinguish cases. It makes it easier to type in an address as it doesn't matter whether something was accidentally the wrong case.

In general, it is easier to deal with a character set that does not have mixed case characters.

The BIP specifies that mixed case shouldn't be used so that parsers don't mistakenly treat random strings as valid bech32 strings. While it wouldn't matter if a parser normalized the strings to a particular case, doing so would increase the probability that something that is not bech32 is interpreted as bech32. This has some money losing risk so precaution is necessary.


Is mining with my computer worth it? I have a computer with a Phenom II X6 1090T 3.2 GHz, and a GT430 gfx card. Obviously I know I won't be able to mine lots of bitcoins, but I want to start getting some money for a car and such. Is the only solution to mining by getting a ASIC Machine, or people on other forums run a pool using a huge botnet.

If you guys can give me any tips to start, it would be appreciated.

So according to this wiki[1] your GT430 can run at 20 MHash/s. And if you plug 20 MHash/s into the mining calculator[2] you're looking at around $0.08 a day in revenue. Your daily power consumption will be larger than that.

Or to think of that another way, the current rates mean $0.41 USD/24h@100MHash/s, and you're one-fifth of that.

8 cents per day. That's a long way to save for a car.

[1] https://en.bitcoin.it/wiki/Mining_hardware_comparison
[2] http://www.bitcoinx.com/profit/


Search and delete bitcoin core and other related files to reduce attack surface Do we have any option in Bitcoin Core to search files used by it? Or any option to delete all such files?

Are all important files deleted when uninstalling Bitcoin Core?

Should we remove such files from different machines and what are the easiest ways possible to do this for images, VMs and hosts?

No

No. What happens to wallet.dat if I uninstall and re-install on Windows Bitcoin desktop client?

Depends on the user and it's good to delete such files from system that will not be used anymore if you have backup.

Scanning bitcoin core related important files with an open source tool: https://github.com/deepfence/SecretScanner
It will search for lot of files including 3 related to Bitcoin Core:
  - part:  'filename'
    match: 'wallet.dat'
    name: 'Bitcoin Core wallet'
  - part:  'filename'
    match: 'onion_v3_private_key'
    name: 'Private key for Bitcoin Core onion service'
  - part:  'filename'
    match: 'bitcoin.conf'
    name: 'Bitcoin Core config'

https://github.com/deepfence/SecretScanner/blob/779b22df6d536b54bc4fb74fdf56d582f008f4a0/config.yaml#L477
Maybe we can even add debug.log in this.
A blog post about "Detecting secrets to reduce attack surface": https://medium.com/deepfence-cloud-native-security/detecting-secrets-to-reduce-attack-surface-3405ee6329b5
TLDR:

Secrets are as important as vulnerabilities from cybersecurity point of view, as attackers can very easily get backdoor access into customer infrastructure and spread laterally to launch multi-stage attacks due to leakage of secrets.


No Account number or Address in listtransactions for generated blocks I am in the need (for my app development) of having more information printed with the "listtransactions" of the bitcoind daemon.

For blocks generated it shows the account as "" and no bitcoin address is shown either.
Why in fact not? The blockexplorer shows the address that "mined" the block, and the mapping of the address to the account number works perfectly when receiving coins, why not for generated blocks?

Even this request doesnt make it into the mainstream client, any help telling me where in the code to put it (if at all technically feasable) is very much appreciated.

There is an embryo of a  patch on github which was precisely meant to solve this issue. It was announced on the dev mailing list but never received much attention. Now it's a bit outdated (the latest merge with master is from Sep 26). Maybe you can start from here.


Why does the wallet keep a pointer to the best chain When I run Bitcoin core to synchronize the blockchain without getting innvolved in any transaction, the wallet.dat gets written to nevertheless.

I believe this is the case because the wallet keeps track of the best chain. (However, I am not sure if this is the only change that is written to the wallet.)

Now, I am wondering why the wallet needs to keep track of the best chain. My possibly faulty understaning is that there is a consensus about the best chain which can be deduced from the blockchain. Hence, no seperate storing of it should be necessary.

I think it is necessary. The wallet doesn't just contain addresses. It also contains transactions that are sent to you.

Suppose you generate a wallet, then back it up. You receive a bunch of money. You delete the wallet on your computer, and restore the old wallet. How does Bitcoin know that it should rescan the blockchain for transactions sent to you? I don't think it can, unless the wallet contains a field that represents the current best chaintip.

If you don't want Bitcoin to ever write to the wallet, you can compile it with --disable-wallet.


Why couldn't bitcoin be hosted on the internet? I was wondering why bitcoin wasn't hosted on the internet? Why create a completely separate decentralized network, I thought the internet was already decentralized. For example, couldn't they have rented a few amazon ec2's or some other servers hosted on xyz host and call it a day?

(Sorry for newb question)

First of all, bitcoin is on the internet, and the Internet is not decentralized, its managed by several private companies, universities and governmental institutions.

You said "couldn't they have rented a few amazon ec2's or some other servers hosted on xyz host and call it a day"

I don't know who do you mean by "they" whoever you mean, just replace it by bitcoin users and the answer is Yes, I've rented some servers on Amazon and it's connected to other bitcoin nodes.


What kind of bug does bitcoin core possess that have to be replicated In order to build a bitcoin client accepted by the current bitcoin nodes we to have to emulate the C++ code present in the bitcoin core client, with all its attributes even the bugs.

For example the same function written in C++ will not work exactly the same as one in Python.

Do we have example of those bitcoin core bugs or attributes that has to be present in a bitcoin client?

Bitcoin's consensus rules are defined by (economically relevant) running nodes. Right now, those are primarily various versions of Bitcoin Core, but there is no inherent reason why that would always be the case.

What this means is that there cannot be a specification of those rules. Imagine we write a document with as close a description of what the most recent version of Bitcoin Core does as we can muster, and declare it to be "The Bitcoin protocol". Now what happens if we discover that the code actually does something slightly different. Which is now wrong? The code or the document? If it's something that constitutes a serious problem (say, stealing money), people may try to convince the world to migrate to a modified implementation, or a different one. But this approach cannot be guaranteed: node owners are sovereign and nobody can force them to adopt new code. In the end, it would just mean that our document is not a correct description of the rules.

Ultimately, this means that at best we can create a document that describes our best knowledge of the consensus rules, but not one that prescribes it. The code that people actually run has the last word, always.

So why can't we just make an exact description of what the current code does? Because we don't know. Knowing the exact behavior of code is remarkably difficult. In what follows I'm going to use the term "quirk" rather than "bug", because for all intents and purposes, these details constitute the Bitcoin protocol, for better or for worse. Here are some examples:

Initially Bitcoin relied on OpenSSL for ECDSA verification. ECDSA is well specified, and one would expect that what OpenSSL implements is exactly follows that specification. It didn't. It allowed various weird deviations from the DER standard (which specifies how the big numbers in ECDSA signatures are turned into bytes). This doesn't break the security of the signature system (it's still impossible for someone without private key to produce a signature), but it did pose a problem for Bitcoin as it meant we'd have to maintain OpenSSL's quirks forever. This was eventually resolved using a softfork (BIP 66) that restricted the set of valid signatures to a well-defined subset. In fact, the situation was even worse than this: OpenSSL turned out to be inconsistent with itself about exactly which deviations from DER were accepted: it behaved different on 64-bit Linux and Windows, which would have allowed an attacker to fork the network between those two. You can read my disclosure of this issue (after BIP 66 solved it) here.
In March 2013, the network experienced a fork between nodes running Bitcoin 0.7 and those running 0.8. The history is described as a port-mortem in BIP 50. The problem was that every version before 0.8 used a database library called BDB. BDB requires configuring a maximum number of "locks" (limiting the number of simultaneous operations that could be performed). It turned out that this number was by default slightly too low. Bitcoin 0.8 replaced BDB with LevelDB which did not have any such requirement. 0.8 was significantly faster, so miners upgraded quickly - and accidentally constructed a block that exceeded the maximum number of locks 0.7 used. The majority of the ecosystem other than miners was still on 0.7, and they rejected the majority chain. It was resolved by having miners revert to 0.7 temporarily, introducing a temporary softfork that "simulated" the locks limit in 0.8, and eventually having the entire network on 0.8.

As you can see, these things aren't as easy as looking at a function and thinking about what it does. These examples both involved an external dependency out of Bitcoin's control, and not quite exactly specified behavior for those. That doesn't mean they're the only source of quirks, but they certainly complicate things.

  For example the same function written in C++ will not work exactly the same as one in Python.

I hope you see now this has actually nothing to do with programming language. If the exact consensus rules were known it would certainly be possible to replicate them in another language (assuming it were possible to also reason exactly about the behavior in that other language). Conversely, reimplementing the consensus in the same programming language has the same problems. The point is simply not taking unnecessary risks when dealing with consensus code - using the code that's already in use has the lowest risk, and small easily auditable changes to it where necessary for performance reasons or intentional protocol changes.

The problem also isn't the known quirks - it's the unknown ones, and I cannot tell you where those are. There are plenty of gotchas that have been discovered over the years and are still relevant in the current rules - and maybe that's the only thing you were after in your question. In that case, there is an old answer here: Satoshi's bitcoind implementation bugs. I'll try to think if I can come up with more recent examples to add there.


Create unsigned tx (PSBT) in a watch-only wallet using bitcoin core, sign it in electrum and broadcast using bitcoin core What are the steps that we can follow to create an unsigned tx for watch-only cold storage address using bitcoin core? How can we sign the transaction and broadcast it later?

Run the below commands in electrum console:

>> getaddresshistory('tb1qu2l4n8st9w3hhsxstd8muaxgnu63fql9rkylmd')
[
    {
        "height": 1807710,
        "tx_hash": "727707cced87f9bc2a1ca3ed28df39588e9881fd50c272e78bc76a5bb1ffde9c"
    }
]
>> deserialize(gettransaction('727707cced87f9bc2a1ca3ed28df39588e9881fd50c272e78bc76a5bb1ffde9c'))
{
    "inputs": [
        {
            "coinbase": false,
            "nsequence": 4294967295,
            "prevout_hash": "99ebe2d047c545a50cf86f0ff5f4c0648437cb8724137f1a33c2f06eb06ef35a",
            "prevout_n": 1,
            "scriptSig": "",
            "witness": "0247304402206379d344d75fbee07f54213378f95e44dc757872d59a35efbc14ec7e1ca7dfd102207a47f9c1be39cafa8f9ac8a879e2b968e2359bead23a1f6598478ed7d141c73d012103ee169045615c663c0204472f86e3c2b2ae43e574146d30607c42fe6d670ac7be"
        }
    ],
    "locktime": 0,
    "outputs": [
        {
            "address": "tb1qu2l4n8st9w3hhsxstd8muaxgnu63fql9rkylmd",
            "scriptpubkey": "0014e2bf599e0b2ba37bc0d05b4fbe74c89f351483e5",
            "value_sats": 3000000
        },
        {
            "address": "tb1q7sx47sra5w7kw8we5xeusl4089ryverhjcft6q",
            "scriptpubkey": "0014f40d5f407da3bd671dd9a1b3c87eaf3946466477",
            "value_sats": 61797954
        }
    ],
    "version": 2
}

You get the scriptPubKey in above output which can be used in importmulti command in bitcoin core:
"address": "tb1qu2l4n8st9w3hhsxstd8muaxgnu63fql9rkylmd",
"scriptpubkey": "0014e2bf599e0b2ba37bc0d05b4fbe74c89f351483e5"
Get the public key of the address from details:

If you are using bitcoin core wallet instead of electrum in this example, you can run the getaddressinfo command in console to get scriptPubKey and pubkey of the address.
Run the below command in bitcoin core console to import the address with the details copied from electrum:
importmulti '[{"scriptPubKey" : "0014e2bf599e0b2ba37bc0d05b4fbe74c89f351483e5","pubkeys" : ["0304c5184085eea27a072628de03fbb953f5fdd99fb526f097fdd4c6968d165f1a"],"timestamp" : "now","label" : "watch-address-test", "watchonly": true}
You can ignore the steps mentioned above for scriptPubKey and only use the "Public Key" of an address by using descriptor:
We need checksum in importmulti which is returned in descriptorinfo for the public key mentioned

Next, we can run importmulti command (I have used public key for a different address in this command):

importmulti '[{"desc" : "wpkh(026641b79d7ffa40ddf994f0277c2649f3ddcbd871194ba6ef87687daea22ca503)#zl4yt8hu","timestamp" : "now","label" : "watch-address-test", "watchonly": true}]'

rescanblockchain 1800000 1835099
I can see available inputs in GUI:

We still get an error if trying to create an unsigned tx which involves sending some amount to change address because we aren't trying to spend the whole balance.

Add a change address for creating unsigned tx:

Option to copy PSBT:

Load transaction using the copied text in electrum:

Copy the hex of signed tx and run the below command in bitcoin core:

sendrawtransaction 020000000001019cdeffb15b6ac78be772c250fd81988e5839df28eda31c2abcf987edcc0777720000000000fdffffff02b3410f0000000000160014112c8ecb9e0876a645e7b8e89eed83bd61096e2c80841e00000000001600145f24e8fbfe65840c27dad3b053855de4cee843820247304402200d7cc29a8588c180e6a460e0eb88ea830db76dbb040a875d45fe8c64c9509a80022060879365af1c6d19e7c47bdbfa402a053ed42809c52db6816cd249dff46529b001210304c5184085eea27a072628de03fbb953f5fdd99fb526f097fdd4c6968d165f1a5f001c00

It returns the transaction id: 4890c14e7635a3e72320046645686052339e443eba56e5a62849a48b3f67f419
You can check the details in a block explorer: https://blockstream.info/testnet/tx/4890c14e7635a3e72320046645686052339e443eba56e5a62849a48b3f67f419
Related questions:
How to create unsigned tx in a watch-only wallet?
How to move/sweep your Bitcoin Core bitcoins safely and air-gapped to your new fancy cold storage?
Related issues:
https://github.com/bitcoin-core/gui/issues/94


Sent btc to unknown address. Btc remains unspent I have sent BTC to an unknown address. The BTC shows up as "unspent" on a blockchain explorer. How can I locate or retrieve the BTC?

There is a plethora of things wrong here that make it almost impossible if not impossible to receive your Bitcoin Back.

You must know who you send the Bitcoin to in order to contact them, if you don't know who they are, you cannot find out their identity (pretty much), because Bitcoin is supposed to be anonymous and its near impossible to find someones identity from a wallet address (pretty much impossible)
The Blockchain is completely transparent, you can see all transactions ever made, so if you sent any Bitcoin to a wrong address, you could see to what address you sent it to.
Even if you knew the address, like I said in number 1, you would have to have their contact information and ask them to send the Bitcoin back to you
The person you've sent it to might not want to send it back to you, if you somehow get their contact.
that wallet address you sent the Bitcoin to might be inactive... in other words you (dropped it into a black hole that gobbled it up forever, or) sent it to someone's old wallet they don't use anymore/lost/deleted or will never look at it and it will always remain there, unspent, forever.


What is the difference between P2SH redeem script on Bitcoin and on Litecoin? I am building a service that is based on multisig wallets. My current progress is so that I've implemented the multisigs for Bitcoin network and it works fine. Now I am on Litecoin and I am facing some issues and would appreciate any help or guidance on that.

Disclaimer: This may be related to how Electrum-LTC works, I am not sure. I am happy to hear experts oppinion on that.

On Bitcoin network your multisig wallet is composed of 3 parts:

ScriptSig
  Signatures
  0 <Sig1> <Sig2> ... <SigM>

  Redeem script
  M <PubKey1> <PubKey2> ... <PubKeyN> N OP_CHECKMULTISIG

ScriptPubKey
  OP_HASH160 <Redeem script hash> OP_EQUAL

And that works just fine with my implementation. I can generate 2-of-2 multisig with Electrum (btc) and sign it with both keys, both with my code and with Electrum wallets. Outcome transaction in both cases is correct and accepted by network.

Now, for Litecoin I am using Electrum-ltc and the process is exactly the same. I can successfully generate multisig address on Litecoin

Suppose I Have following  Redeem script
  2 028c895128a8113bb5d599b4f463df685220ba726fc664013b3df56cb0bae74dc4 02c09fdcf2cd2281ac5d35dedb8b19499db847fad469c151428d28c9cf1aabf435 2 OP_CHECKMULTISIG

The address I see in Electrum-ltc matches the one I generated myself which tells me I am on the right way.

However, when I sing a transaction with wallet a redeem script in the transaction hex looks totally different and does not match my manually generated redeem script

Manually generated redeem script
5221028c895128a8113bb5d599b4f463df685220ba726fc664013b3df56cb0bae74dc42102c09fdcf2cd2281ac5d35dedb8b19499db847fad469c151428d28c9cf1aabf43552ae

broken apart
52 - OP_2
21028c895128a8113bb5d599b4f463df685220ba726fc664013b3df56cb0bae74dc4 - PubKey1
2102c09fdcf2cd2281ac5d35dedb8b19499db847fad469c151428d28c9cf1aabf435 - PubKey2
52 - OP_2
ae - OP_CHECKMULTISIG

And here is a redeem script that I get from Electrum-ltc once I signed transaction with one key

524c53ff0488b21e0000000000000000006a88a8afff7c30e2adc4ebee877e842b7868f11c6fafe5635fecd85337366bd802f8ecc3fc0be1c7b7d7bf4968df349845ede9dd6044beb0bcf25145612fa3b4e4000000002102c09fdcf2cd2281ac5d35dedb8b19499db847fad469c151428d28c9cf1aabf43552ae

broken apart
52 - OP_2
4c53ff0488b21e0000000000000000006a88a8afff7c30e2adc4ebee877e842b7868f11c6fafe5635fecd85337366bd802f8ecc3fc0be1c7b7d7bf4968df349845ede9dd6044beb0bcf25145612fa3b4e4000000002102c09fdcf2cd2281ac5d35dedb8b19499db847fad469c151428d28c9cf1aabf435
52 - OP_2
ae - OP_CHECKMULTISIG

So, what this thing the middle? And why it does not match my redeem script? Is this a bug with Electrum-ltc or I am missing something. Would appreciate any feedback.

If you signed your Bitcoin transaction with only one key, you would see the same behavior.

What you are observing is how Electrum handles partially signed transactions. It does not produce the correct scripts until the transaction is fully signed. What you see as the public key in your transaction is just how Electrum internally represents public keys.


How does bitcoin broadcast information? On Bitcoin's Blockchain, how is information transmitted instantly to all other nodes and do nodes 'talk to each other' through an API?

Do Blockchain nodes communicate with each other through HTTP requests? If yes,
do they use a Pub/Sub to transmit information to all the nodes? Or is there a delay until the full blockchain information reaches all nodes?

On Bitcoin's Blockchain, how is information transmitted instantly to all other nodes and do nodes 'talk to each other' through an API?

Information is not instantly transmitted. It takes time, nothing is instant.

The Bitcoin network has a network protocol which nodes using it speak. This network protocol allows a node to send and receive data to and from a node that it is connected to. A node will connect to multiple other nodes on the network.

This network protocol uses TCP connections and Bitcoin specific network messages.

  Do Blockchain nodes communicate with each other through HTTP requests?

No. That would be inefficient.

  Or is there a delay until the full blockchain information reaches all nodes?

Of course there is a delay, the speed of light is only so fast. Data takes time to transmit due to the capabilities of physical connections and the distances that information has to travel. There is always a latency due to physics. Furthermore, Bitcoin nodes will have random delays between each of their announcements of transactions in order to better preserve privacy.


obtaining currency exchange rate values for different coins via apis ive been trying to work out what the best way of obtaining the exchange rate of a bitcoin or any other digital currency is via online resources for a website I want to build.

I've seen this question/answer here; Displaying price in BTC based on USD exchange rate

So sure thats easy but what about other coins against the dollar or against bitcoins.  Am I going to have to obtain all this info from different sources?

If you are not actually trading, you can pull the price from multiple exchanges and show an average, since there is no such thing as fixed price for the exchange, preev.com is a nice converter that shows average of 4 sources which you can modify from the settings menu, it should give you an idea.


Decreasing Energy Consumption of Bitcoin's PoW with paired mining rounds I found the following whitepaper on an algorithm called "Green-PoW" by the authors and i'm quite sure this would be a perfacet solution and also would get acceptance by the miners and the community.
You can find the white paper here:
https://arxiv.org/pdf/2007.04086.pdf
Key point of the paper here as a quote:

"In order to reduce the energy consumption in PoW, Green-PoW considers
mining rounds in pairs and adjusts the election mechanism during the
first mining round in the pair, to allow the election of a small
subset of miners that will exclusively mine in the second round.
Assuming the total network hashing power is equally distributed among
miners, a significant energy saving up to 50% could thus be achieved"

What is your opinion on this approach, are there any problems with this?

I think that implementing the protocol described in this paper wouldn't do much to diminish the total energy spent mining, but it would increase network instability and the potential for malicious miners to game the network to their advantage.
This protocol creates a condition where every other block actually requires that the miner to find 2 valid blocks in a row (the election block, and then the second round block), with a fall-back timeout of x minutes coming into effect after the first election block is found. Before x minutes has passed, the election winning miner(s) will have much less competition in trying to find the new block, so it seems to me that it is in their best interest to not publish their election block, until they also find a second round block! This way, the timeout condition will never be hit, but this also means that all other miners on the network will be working to mine their own election-blocks (and second round blocks), with little incentive to stop the search.
With this in mind, it is unclear if any rational miner would turn off their mining hardware ('mining-save-mode'), especially when considering that a miner will have many costs, including overhead (rent), staff, electricity, etc. Turning off their mining hardware will mean completely forgoing their chance of any revenue (the block reward), while only dropping their electrical consumption (and not any of their other costs). This only serves to put a high opportunity cost on any time spent not-mining.
Other issues I can see:

the bitcoin network has no mechanism for registering/identifying individual miners over time, so it is unclear how the protocol could restrict the eligibility of miners participating in the second round in each mining epoch.

The paper claims that the miner which wins the first round of the epoch would not
be allowed to participate in the second round, but it is unclear how
such a thing would be enforced. What is to stop the first-round winner from also attempting to find a 'runner-up' block and compete in the second round? Even if miners were somehow made to register an identity with the network (how such a thing would be possible is a big question in itself), what is to stop a miner from registering many identities, and switching between them?

There is no way to reliably enforce the time-out process for the second round. The network is asynchronous, it is not possible to accurately define '10 minutes after the election-block was found' as a starting point for the fallback process of allowing all miners to participate in the round to help guarantee network liveness. This creates instability at the chain-tip, as the validity of blocks created by the fallback process may be unclear to network participants.
This protocol may create incentives for miners to coordinate externally. For example: if I am a miner and I find a valid election-block, then I may want to sell the ability to participate in the second-round block to other miners! Doing so could help normalize my expected returns, while allowing other miners to reduce their opportunity cost of otherwise not mining in the second round.
Supposing the miners do not perform the election-block-withholding attack described above, in the event a single miner finds an election block, they may be further incentivized to perform a block withholding attack using their round 2 block as well! With little competition for the round 2 block, the miner would enjoy a much higher chance of having the withholding attack succeed, and they could begin searching for the round-1 block of the next epoch while withholding the round-2 block of the current epoch.

These are just some of my initial thoughts, I'm open to criticism of them, and there may be further issues I haven't seen. But at this time, I'm seeing a lot of problems that make this proposal somewhat uninteresting and untenable.

Perhaps also worth mentioning, I think that the premise of the paper is erroneous in the first place. The energy spent by bitcoin miners provides a mechanism by which the network is secured. Valuable things require security, and security cannot be gained for free. The openness of the bitcoin network simply allows a rather objective quantification of the energy (ie the opportunity cost) used to secure it, compared to other systems which have a more obfuscated or social form of security, that comes at a higher relative opportunity cost!


Integrity of ensuring the correct recipient of a BTC public address? If a hacker gains access to a website and proceeds to vandalize the website, including changing the public-key of a BTC wallet, this would direct all payments to the hacker. Is this a security risk inherent to the use of BTC or is there something implemented that could prevent this? I am new to BTC/crypto-currency, so I don't fully understand all the details.

Yes. Somehow, you need to tell the client what public key/address to send to. If the attacker has full control over the client, or your server, they can replace your address with whatever they'd like.


how can i track a bitcoin sent to someone claiming not to have seen it i transfer bitcoin to account 3CcKWXXC1BXvctthfaFyeWYXG8mZWT1HUU and he claim not to have seen it for 2 days. i have tried to look for the causes of this but i can see that it has been deliver to him just pretending not to have seen it

There's no evidence of any such transfer. Check this page and you'll see.


I am eager to know details about distribution of bitcoin Bitcoin only has 21 million possible coins so far I know. Who hold these coins? I just want rough estimation.

According to Steven Englander: Best estimates are that there are about one million holders of Bitcoin;  47 individuals hold about 30 percent, another 900 hold a further 20 percent, the next 10,000 about 25% and another million about 20%, with 5% being lost.

Read more: http://www.businessinsider.com/bitcoin-inequality-2014-1#ixzz2rEi2kG5g


Why is the change address for a transaction the same as the originator address? I was under the impression that if address abc has 100 BTC assigned to it, and it pays address def 20 BTC, 80 BTC will be transferred from abc to a new address ghi. But in this transaction:

https://blockchain.info/tx/15bf8b35c9210efe7e448c5fc6b69b47b3a8cac9c148c7cc57c65f266384d9b8

The change address is the same as the originator. Why is that?

Many wallets let you control where to send the change. In most cases it is advisable to send to a new address to reduce traceability and increase your privacy a little, but not everyone does and sometimes it makes sense not to do it. Most modern wallets will create a new address automatically unless you stop them.
Bad reasons to send change to the same address

Fees. Some people think that they will pay less fess if all their funds are in the same address. That is not the case, fees are determined by number of inputs (and age, signatures and outputs), not addresses. 1 BTC in address A and another one in address B will cost to send the same than 2 BTC in two different inputs in adress A
Convenience. Some people think that having many addresses is more difficult to manage. This is wrong, all wallets will do this automatically.

Good reasons to send change to the same address

Multisignature addresses (those that need several parties signing transactions). Those work in a different way than regular addresses and don't "live" in a wallet. Users need to create them one by one, usually for very good reasons (like needed two signatures to pay with shared money) and sending change to a new non multisignature address would defeat their purpose.
Accountability. If someone publishes an address so others can check what he does with the funds it makes sense to always send the change there so it is easier for those who check.


How to recover my Copay wallet using the 12 word seed phrase I'm new to Bitcoin/Copay. I decided to signup at coinbase deposited $80. I read you needed a wallet. I decided on copay. Transferred the funds to my wallet. Everything processed smoothly and my copay wallet showed $76. I then went to the merchant and tried to pay. A spend password popped up. i couldn't remember the password. I may have mixed it up with my coinbase password instead.

I then did a little digging online and read that I could delete copay from my Android phone and reinstall it using the 12 word phrase to by pass/reset spending password. I did that. Now if I restore using only the phrase it creates a "Personal Wallet" with no funds in it.

If I try and restore wallet with 12 word phrase and try and guess the recovery phrase password (Under Advanced Options) I get an error saying
"Could not access the wallet at the server
Please Check
The password of the recovery phrase (if Set)
The derivation path
The wallet service URL
Is there any way I can recover my wallet/funds I do know the 12 word phrase. and I thought that would have all I would have needed.

Thanks for any help fixing this.

Are you using the Import option when you try to recover the wallet?

This issue looks similar to what you're experiencing: https://github.com/bitpay/copay/issues/7399


How does the Bitcoin block propagation process recover when false positive happens? I have read articles about how Invertible Bloom Filters (IBLT) work and I have some basic knowledge how Bitcoin works for block propagation using IBLT. But since IBLT would introduce false positive, participants in the network would have a chance in unsuccessful in receiving all differences between two IBLTs. So I am wondering how Bitcoin solve this problem to recover all blocks?

The purpose of IBLT-based block transfer mechanism is reducing bandwidth (how much data is sent in total) and latency (how long it takes to transfer the block), and depending on which has the priority there are different solutions.

If latency is of no concern at all, you would simply send a block header together with a list of (truncated) txids, and the peer would reply with "i'm missing transactions 3, 7, 112, and 234", followed by just sending those transactions. Such a solution would require several round trips: first sending the txids, the peer requesting the ones he is missing, and us sending the transactions.

If latency is a concern however, that's still just 3 steps, but each of those steps may be in the order of half a second or more, depending on how far away you are. If your network connection is over 10 Mbit/s, you could just transmit the entire block in the extra time wasted by the roundtrips.

So this is where IBLT and other efficient block propagation protocols come in: they try to construct a single packet that gives enough information for the peer to reconstruct the block, but without sending the full block. Occasionally that attempt will fail, false positives will occur, and the reconstruction will fail (as the block hash doesn't match what was claimed). In that case we just fall back to the naive version: go request the transactions you're missing, and incur the associated extra latency.


Why doesn't address contain a full scriptPubKey? This is a general question, but let's suppose a P2PKH transaction. P2PKH address starts with "1" and the sender incorporates it into the scriptPubKey as:

OP_DUP OP_HASH160 <PublicKeyHash> OP_EQUALVERIFY OP_CHECKSIG

Why does an address contain only the <PublicKeyHash> instead of the full scriptPubKey including the Script commands? At the current scenario the wallet software needs to recognize the address and assemble the scriptPubKey itself.

If the full Script code would be incorporated in the address, the wallet software would not have to understand it and would simply set the scriptPubKey equal to whatever the address contains.

This seems to me as very useful in terms of forward-compatibility for future types, where the wallet software doesn't have to be upgraded to understand some new forms of transaction.

There are several reasons for this, some historical and some more recently:

At first, addresses were probably not intended to cover everything Bitcoin Script could do. They were a fallback for the case where the recipient was not online (we're calling addresses still addresses because they were originally IP addresses you'd connect to to request a scriptPubKey). So at the time they were introduced, a focus on size was probably far more relevant than considerations about flexibility. Note that addresses have a 'version byte' (which was intended for upgrading the format, not for identifying altcoins).
Later, when P2SH was introduced the concern about flexibility went away entirely: P2SH permitted conveying any spendability concern in a constant-size address. Furthermore, it removed the concern of senders needing to create larger outputs. The fact that I am using a multisig wallet shouldn't mean you have to pay a higher fee when sending to me.
When SegWit was introduced, P2SH was no longer sufficient to encode any output, for reasons of efficiency and security. Despite the need for a new format anyway, we still chose not to propose something that could encode arbitrary scriptPubKeys. The reasoning given in BIP173:

Why not make an address format that is generic for all scriptPubKeys? That would lead to confusion about addresses for existing scriptPubKey types. Furthermore, if addresses that do not have a one-to-one mapping with scriptPubKeys (such as ECDH-based addresses) are ever introduced, having a fully generic old address type available would permit reinterpreting the resulting scriptPubKeys using the old address format, with lost funds as a result if bitcoins are sent to them.


How is it possibile to verify payments without running a full network node? I've read the Nakamoto's paper "Bitcoin: a peer-to-peer electronic cash system". In paragraph Simplified Payment Verification he said that is possible to verify payments without running a full network node.

I don't understand how, having a Markle's Tree Root hash, verify payment. In fact, in order to check payment, I need to combine and hash all node of right or left branch, not just the root.

Moreover, how can choose which Root hash needs to get without see in all nodes?

You are right, in order to prove that a transaction is confirmed in a block you need more than only the Merkle root. The information needed is called the Merkle path and consists of the left/right leaf to your transaction node and the right/left parent, and so on up to the root.

Here is a graph depicting a Merkle path:
http://chimera.labs.oreilly.com/books/1234000001802/ch07.html#merkle_tree_path

The Merkle root and path, and also the block headers of the blockchain, are requested from a selection of random Bitcoin nodes.
Your SPV client cannot verify that the transaction is valid (not a double spend, correct signatures, etc.), but since it can verify that the transaction was included in a block with X confirmations, it can assume that the Bitcoin network accepted the transaction. Thus your SPV node will accept the transaction by trusting that the Bitcoin network only includes valid transactions to the blockchain.


Developments to prevent 51% hack How might Bitcoin be made impervious from attack by large monied interests that could atttack with a brute force majority hashrate hack?

A brute force hack would not work. Image a computer capable of expelling the lowest amount of energy conceivable to record a change in a bit from 1-0 or 0-1. Now take this computer and make it on the scale of our sun. Also imagine we can cool this computer to near zero kelvin with no other energy input. All input energy goes into changing bits and that's it.

Now take all the power our sun will make in its lifetime, and power the computer with it. It will take longer than imaginable to even just simple count to 2^256 let alone try to brute force attack a sha-256 algorithm. So brute force will never work.

--

You must gain more computing power than 50% of the network. This means on average you will create more block solvers than the <50%.

But wait again you need to account for the blockchain to date, so once you get this computer power you must now create a new fake blockchain which will take time; (Currently it take 8 hours to download the full chain, imagine how long it would take to compute it!) your new blockchain must be made (this is the whole point of the attack change the blockchain so you have more btc).

So assuming you have time to create this new blockchain, no everyone must accept it. It is in the bitcoin protocol to accept the longest blockchain to date, because it has the most transactions the most knowledge of the entire system.

So you create this blockchain and send it to everyone, they all then proceed to take their 8 hours to get the new blockchain, but wait.... why is there a new blockchain everyone would say!?

It would be obvious someone has made a new one because you are downloading it as if this is the first time on the network. And the real smart people who write bitcoin protocol would be very privy to this, and at the least have 8 hours to react. It would be to obvious.

--

The only real way I think to hurt bitcoin is to buy up all the coins, or release a whole bunch of coins into circulation greatly affecting prices.

But this would even be sorted out by the bitcoin design.

The price drops, people stop mining because it become less profitable. Cause the miners stop difficulty goes down, more people mine because it is profitable because the difficulty is so easy they can make enough btc to cover their costs, bitcoin is up and running again.


Mining profitability sounds too good! Where is the catch? (2017 edition) Given the staggering increase in BTC value over the last few months (nearly 600% in 12 months), I am kicking myself for not getting into the game earlier. I've been lurking around this for years but have been too risk-averse to dive in, and I haven't been paying attention lately. Now, looking into matters again, I am bound to ask: Where is the catch?

(This has been asked before, but the information is outdated.)

A cost/income calculation with present-day numbers (Aug'17) tells me that a dedicated mining device would pay for itself in 86 days and would generate in excess of $2500 per year. That sounds like free money!

If this is really true, then why isn't the whole world up in arms about this new gold rush? Or is it true, and most people are just living under a rock?
If this is true, then why not rush out and buy as many miners as I can afford? Or is it wiser to just buy a bunch of coins instead?

I've tried to take into account current values of:

best hash rate (14Th/s)
difficulty (860,221,984,436) as well as the expected increase
block reward (12, halving to 6 expected in the year 2020)
BTC exchange rate (currently 4162 USD per 1 BTC)
purchase cost of miner ($1288)
cost of miner's power consumption.

Using various online calculators (coinish, blockchained) I arrive at 16.35 USD/day or 2597.50 USD/year when taking difficulty and power cost into account. This still sounds like free money; what's the catch?

(edit: Due to a typo my initial calculation was one order of magnitude too high. These values are now corrected.)

There are many catches.

First of all, the difficulty will adjust and change as new hash power is added. That will then cause profitability to decrease. When new hash power is added to the network, the difficulty adjusts upwards to compensate for that so that blocks continue to be found at a 10 minute interval on average. This means that more work (i.e. more hash rate) is required to mine blocks and thus, given a fixed hash rate, profitability will decrease.

Also, the block reward halves every 4 or so years. That will also effect profitability.

Besides the technicalities of mining, there are also other forces in play that effect profitability. Mining hardware is kind of difficult to acquire; either you have to have millions of dollars to buy something from BitFury or buy equipment from Bitmain which can often be out of stock and unavailable.

Lastly, the price of Bitcoin has a significant effect on profitability. Only recently has Bitcoin's price been high enough to be profitable to mine in the United States (or in many other First World countries). The price of Bitcoin remains highly volatile, so investing a lot of money into mining equipment is extremely risky; the price could drop quickly within a few weeks and make mining very unprofitable.


How did this block end up on blockchain.info? How did this happen?

https://blockchain.info/block/000000004b7959f66c9dab42b8933f0a43c9705bd9bd486de3a69407fb072cd3

That's a fork of the original blockchain (started from genesis block) which was 9 blocks long and appeared in 2013. Why did blockchain.info accept this orphaned blockchain, why didn't it just discard it?

Blockchain.info is a special Bitcoin node created especially for it's purpose. So, it will act differently as well.

I suppose Blockchain.info's created configured it so to keep a record of all information it comes across, including orphaned blocks.

You might think that it is risky to do so because knowing this, people can try to flood the servers with irrelevant data. However, even with difficulty 1, it costs way more resources to create valid blocks than it will take for Blockchain.info to store them. It will only be possible to add a block every few minutes with regular mining hardware. Considering the mining profits you could earn by regular mining, I think it's safe to suppose no one is going to try flooding the Blockchain.info server.


Is it worthy to use "bitcoin usb block erupter" I was searching for Mining hardware on internet and found that a new technology is available known as "bitcoin usb block erupter" for mining bitcoins as 300MH/S

I just want to know if it is useful to use these hardware instead of GPU mining and how to calculate breakeven point for them.

P.S. : I've searched google for many things but there were mixed responses that's why I asked this question here

A typical USB block erupter will get 333MH/s under realistic conditions. Today, a share is worth about 1/156 of a penny and 333MH/s will get you a share every 13 seconds. That comes out to 43 cents per day per erupter, not counting the cost of electricity. Difficulty is going up, and thus profitability going down, around 25% per month. So you can figure maybe $11 your first month, $8 your next, $6 the next, then $5, and so on. You might get about $50 before it becomes more trouble than it's worth.


Can blockchain size become a blocker for bitcoin adoption? When I run bitcoin-qt, I noticed that it is taking lot of time to download recent blocks. It gives me impression that the more transactions, the bigger the blockchain. Even today the download is taking around a day. What happens after a year?

It may easily take more than 5 days. If it grows huge, can the current software handle it?

What is the estimation of the blockchain to grow in next 10 years? Is it possible to split the blockchain into multiple blockchains? Could it become a blocker for Bitcoin adoption?

Actually, as Satoshi explained in his paper, you can use a Simplified Payment Verification (SPV) client which would only require you to download the headers of each block.

From the paper itself:

  As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker.

So if you're not mining, and the network is overpowered by honest nodes (as it should always be for Bitcoin's integrity) you don't need to use a full node.

Bitcoin-QT is a full node probably because it's the official client and it bundles all the features since day one. Using something like MultiBit, which is an SPV client, would offer you the same exact amount of security as Bitcoin-QT.

So no, the increasing size of the blockchain is not really a blocker for Bitcoin's adoption because only miners would need the entire blockchain data.


Is Gpu mining still an option? My friend asked me to do a research for him on bitcoin mining, I don't know a lot so I'm asking. He's consider buying either NVIDIA gtx titan or NVIDIA gtc 980. Decent motherboard and internet speed. I stumbled upon a question on this site which says that Gpu and Cpu mining is over, it's all about ASIC now, but we can't afford ASIC.

All in USA, we're living in Lebanon
Overly expensive and we didn't count shipping costs

Now I want you to consider

Internet is free
Electricity is free
Other than buying the hardware, we have no expenses at all

My question now is the following:

In best case scenario, using NVIDIA gtx titan or NVIDIA gtc 980, how
much bitcoin can we expect to mine? (unless it's really dead)
Is it wise to buy NVIDIA gtx titan or NVIDIA gtc 980 to mine bitcoins if you don't pay taxes? Would it pay off?

Thanks for asking this question. I see a lot of people all the time who assume GPU mining is profitable.

Try googling "bitcoin mining calculator" and see.

Presently (in 2015) the calculator will tell you that you would be able to mine one bitcoin in about 1000 to 10 000 years. But you have to consider that there are reward halvings every four years, which those calculators don't take into account. A more realistic scenario then is that it would take over a million years to mine one bitcoin.

Of course you don't have to mine a whole bitcoin. If you are lucky you could perhaps mine 0.01 BTC in 10 000 years. That's worth a little over three US dollars at the time I write this.

There are still a few people mining on GPU or even CPU. Some of them may have free electricity. But what they fail to understand is how extremely slow this is. Most ditch GPU/CPU mining when they see that you'd be lucky to earn three dollars in 10 000 years. But there are still some (in my mining pool) who refuse to give up.

TL;DR: no, GPU mining is not viable.


Bitcoin successfully deducted on sender wallet but did not reach receiver wallet Here is the wallet address for receiver: 1Gouzjo9Jav1k4AmRoUJJMzidVfnMoSieS.
I had used the Blockchair site to see and track status. Based on the details, account had seen receiving last 21 hours. Also on the picture, there is no check icon on this transaction. I'm referring to 0.026 BTC. Thanks for those who will answer and help track this transaction.

It's not completely clear what the situation is, but from what I gather it seems that you're the sender and the recipient is not acknowledging a payment you have sent.

I assume that you have verified that the credited address 1Gouzjo9Jav1k4AmRoUJJMzidVfnMoSieS matches the one that you were supposed to pay to, and that the amount matches the invoiced amount.

The address 1Gouzjo9Jav1k4AmRoUJJMzidVfnMoSieS has received 0.02661900 BTC in transaction b36157a7ca9630a88d98125fca91de81f488ef7d9a60f9e57af055d4d91f7a50. This transaction has been written to the blockchain more than a day ago and is confirmed. Given that this is the correct address, the receiver did get paid, whatever they may be claiming. Secondly, the money already got spent again which means that they must be fully aware the money arrived.

Assuming that you have paid the right address, the issue is on the receiver's end:
Either they gave you the wrong address which you paid correctly and someone else received the money (unlikely), they do not understand that they already got paid or incorrectly accounted for your payment (unlikely, since you already tried following up with them), or they're lying to you.

You should follow up with them and firmly assert that the requested address in question has been paid (after you have verified that it was the correct address) and ask them to check that their systems are working correctly. Perhaps that will prompt them to "suddenly find your payment".

Do not under any circumstances send them any more money, if they don't acknowledge that your payment has succeeded and deliver their side of your agreement. Often scammers will make up nonsense excuses to get you to pay even more money. If they do not acknowledge your payment, you may need to decide to write-off that money or sue them.


Bitcoin daemon sends "Empty reply from server" when in test net I'm trying to work with the bitcoin daemon and rpc.

Using the user & password I set I can't connect to it, trying with curl I always get "Empty reply from server".

It works just fine in the real network, I can connect, getinfo, etc, etc...

Is there something I might be missing? the output log in the daemon only shows:

accepted connection 190.xxx:62470
disconnecting node 190.xxx:62470

Thanks!
Javyer

I leave it here. Because i spent about two days on it :-o
https://github.com/bitcoin/bitcoin/issues/10218

  Authentication is not optional. Configuring it yourself is optional, but bitcoind never accepts RPC connections without explicitly or implicitly configured username/password.

So, I just added user and pass from file /root/.bitcoin/.cache.
And get this:

curl --user __cookie__:96fea535b009e62ddffe1c6f5090c50396d17e7f96d0b0a75eb580bdd1771d29 --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getinfo","params":[]}' -H 'content-type:text/plain;' http://127.0.0.1:8332


Why didn't my change come back to my wallet? And where is it now? I sent a payment for 198.52 mBTC using Electrum. There were two outputs. One for 196.39 mBTC that arrived. There was another output of 2 mBTC that I'm assuming  was processed as change. Does anyone know where the 2 mBTC might have gone? It didn't arrive with the recipient and it didn't come back to my wallet as change.

I'm new to Bitcoin and I'm just concerned that in the future if I want to pay somebody, my payment may not reach them in full and, money during the transaction may disappear that I won't be able to recover. Both these things occured in this case and I'd like to understand why before I use Bitcoin for any more transactions.

Any help is greatly appreciated.

The change should be in your wallet. Open up Electrum and check if your balance is what you expect it to be. You can also look in the addresses tab and click the arrow next to "Change" to see your change addresses and the Bitcoin that is held there.

If you are just looking at an address in a block explorer, you will not see the change return to that address. This is because nearly all wallet software follow the recommendation of generating new change addresses for each transaction. It is important to remember that an address is not your wallet; your wallet contains several addresses, but an address itself is not your wallet. You should not be looking at a block explorer to determine your wallet balance; it will be inaccurate as the block explorer does not know what addresses are actually in your wallet.


How can I find out which wallet belongs to which cryptocoin? I have multiple decrypted wallets in the same folder. How can I find out which wallet belongs to which cryptocoin? All wallets are named wallet_x.dat, so the name gives no hint.

UPDATE:
I have no access to the addresses within the wallet, because I can't import them, because I don't know which client I would need.

Take a look at the wallet address, if it starts with 1 it is a Bitcoin wallet, if it starts with an L it is a litecoin wallet and so on, google to know how to identify the starting of the rest of the crypto wallets (blockchains are the first places to go).


Pending transaction xxx Please have sent my bitcoin from block chain wallet to localbitcoin wallet and keep telling me unconfirmed transaction and pending Xx please what can I do to get my bitcoin back.

There is currently a spam attack: https://blockchain.info/unconfirmed-transactions

Your transaction is likely to get confirmed If you paid enough fees but It will take time. Try to send it to ViaBTC accelerator and see how things goes.


Electrum: How to generate hardened public addresses with HD BIP32 wallet Please comment on the accuracy of this explanation.

Scenario: The master public key is compromised and so all non-hardened public addresses can be generated and monitored by a third party. This negates the privacy gained from avoiding address reuse. (The third party cannot spend any bitcoins from these addresses however).

Hardened public keys cannot be generated from the master public key, and a priori cannot be attributed to the owner of the non-hardened addresses above.

Is it possible to generate such hardened keys in Electrum, and if so, how?

Electrum uses a few different derivation paths for various script types. For example for legacy p2pkh addresses (addresses beginning with 1) it uses m/n/i where m is the extended private key (xprv) derived from the seed, n is 0 for external and 1 for change addresses and i is the address index with addresses being generated sequentially starting from 0. Electrum also lets you create a wallet using any xprv and then it'll assume that xprv is m in the derivation path and generate addresses relative to that. So all you have to do is restore your wallet from a hardened xprv such m/1' and electrum will then generate addresses relative to that. These addresses will not be visible to the person who has the extended public key for m.

To generate a wallet using m/1' you can use this script like so:

electrum getmasterprivate| python3 xprv.py -m - -d "m/1'" -p|electrum -w wallet_name restore -


Why are block header bits necessary? (Valid difficulty is already implied by chain history) Difficulty or target is implied by chain history, so why does it need to be explicit in the header? I suppose it exposes miner-intended-difficulty, but I don't see why that would be relevant without chain context.

So it seemingly represents redundant data in the header, unless there are any historical reasons for this design choice?

They aren't really necessary. The reason that they are included can only be known by Satoshi, and AFAIK, he did not state why he chose to include nBits in the block header (or many other things that are just arbitrary). This is one of the many things that Satoshi chose to do and no one really knows why. It remains in the block header today because removing it would require a hard fork and there really is not much benefit to be gained by removing it.

The nBits field can be useful, and it likely was included as a convenience sort of thing. Instead of having to have the full chain history in order to know the current difficulty, you can instead look at the nBits. But that is just speculation, and full nodes don't use the nBits to determine the current difficulty (except those of the genesis block).


Multibit password error: Could not decrypt bits I am attempting to remove my password from my wallet in Multibit. However, everytime I try my password it says "The removal of the password has failed. The error is "could not decrypt bytes.""

I've tried searching online but I can't seem to figure out what this means/how to fix this.

It means literally that the decryption operation of the wallet failed.

If the password you enter is different in any way from the password you entered when you encrypted your wallet with "File | Add Password" you will get this error.

I would check things like:

Are you definitely entering the same password you used to encrypt this wallet.
CAPS lock key
If you use an Input Method Editor, are you entering exactly the same characters.

There is also another copy of your private keys on your disk if you need to use them:
When MultiBit encrypts the wallet it writes out the private keys to an export file, encrypted with the wallet password. As long as you have the correct password you can create a new wallet and import the private keys into the new wallet. You will then have access to your bitcoin.

There are more details about this in the help (https://multibit.org/en/help/v0.5/help_contents.html) in the topics:

Help on specific tabs | Importing private keys
More technical details | File descriptions