How Bitcoin system prevents the previous owner of a Bitcoin to spend it? I am a Bitcoin noob.

As per my knowledge, a Bitcoin is a digital signature.
Owner of a bitcoin knows the private key of it.

If I spend my bitcoin, I still know the private key of it, using which I can spend it later despite not owning it.

Surely there must be something in the system which prevents this. One idea which comes to my mind is modifying the Bitcoin's Digital signature in a way so that the only new owner has the new private key.

I might be stupid and my above query may be just BS. Please guide me in the right direction.

If I spend my bitcoin, I still know the private key of it, using which I can spend it later despite not owning it.

Your are not really "the owner of the bitcoin". It's decentralized. You are the owner of a private key and of an adress.

And you can use the private key to send money away from your adress. Let's assume, you have only 1 BTC on your adress and send it all to your friend. After that, you can't send BTC from your adress anymore because there is nothing on the adress anymore. Only if someone sends BTC to your adress again, you can spend them again. You can't spend the 1 BTC again because it's on your friend's adress. You don't have the private key for his adress, but he has. So he can spend the BTC.


How do I get money on and off of harborly? I signed up for a harborly account but I'm still not quite sure how it works. I would like to buy some bitcoins, but how do I get money onto the site?

You cannot store your fiat currency directly on harborly. They're a lot like coinbase in that they allow you to sync your bank accounts with your wallet. Instead of sending money to them, then buying and selling, whenever you buy or sell they directly credit or debit your synced bank account.


Best Python API for sending Bitcoins from a Multi-Sig wallet I want to create a multi-sig wallet which I can broadcast transactions through an API. I would like a wallet with a permanent public address not one that changes every time I run the code. I was going to use Blocktrail but some of their API features are broken. Does anyone know any other good API`s?

Some context as to what I want to do: automate the sending of coins to certain addresses at a certain time each week.

Thanks,

Maybe pyCoin can be useful for your purpose?
https://github.com/richardkiss/pycoin/blob/master/COMMAND-LINE-TOOLS.md


Explicit message length in Bitcoin Signed message the message format is:

length(prefix),prefix,length(message),message
with prefix="Bitcoin Signed Message:\n"

now I am wondering why the length(message) in the middle is needed as it should be able to just calculate it from total_length-prefix_length

Some context here: https://github.com/ethereum/EIPs/pull/683#issuecomment-358460381

It's a quirk of the original implementation of the message signing logic which was introduced in Bitcoin Core in 2011.

When the message is signed, it must be serialized before it is hashed. The serialize methods in Bitcoin Core are shared between the network, hash preimage, file, etc. serializations, most of which require that the data be prepended with a compact size uint that specifies the length of the data. Thus those methods will prepend such a compact size uint when serializing whatever data.

The implementation of the message signing logic used those same serialization methods in order to produce the preimage that would be hashed. Thus the strings must be prepended with their lengths for the hash preimage.


Why my bitcoin node does not show the same mempool size than a web blockexplorer? It's supposed to match after a while. When several bitcoin nodes are running for days they should have the same mempool, but my bitcoind node shows arround 2k transactions less than blockchain.info webpage. My mempool size limit is 300Mb and at the moment of writing is arround 16Mb. Why is this happening?

Mempools between nodes will be different. There is no "supposed to match after a while" as the mempool does not have anything that makes all nodes' mempools converge to the same thing. There is no "the mempool", there is only "a node's mempool" and these will differ based on the settings for accepting transactions.

The settings on your node's mempool are likely much stricter than the settings for blockchain.info's mempool since blockchain.info shows data for a variety of transactions that most nodes will reject (e.g. transaction fees less than 1000 sat/kB, creating dust outputs, unconfirmed transaction chains longer than 20 txs, etc.).


What happens if a network “splits” I’m a developer but a total noob about bitcoin and Blockchain so i’ll, for sure, say something wrong.
I know that bitcoin approve transactions via nodes (normal and full nodes) and that they are distributed in the world
Everyone can create his own node or shut it down.
So...suppose this fantasy scenario.
The USA govern decide to block all internet connections from/to USA, creating a giant “intranet” for one day.
All USA nodes and all “rest of the world” nodes will continue working? For the (low) level of knowledge I have now, I think they will, and in that moment two different Blockchains will diverge: one with the USA transactions, and another with the rest of the world transactions.
Will they reconcile when the connections come back?
Moreover, what happens if a citizen spend all his money in the USA, then find a secret access to the outside internet and connects to the rest of the world network? Can in this case double spend?

I know that these are “fantasy scenarios” but will help me to understand better how the machine works :-)

Thanks

The chain would split and when the networks re-connected the longer chain would take precedence.

All transactions on the orphaned chain from the time of the split would be invalidated. Good if you were a spender, bad if you were a receiver.

Note that one company in particular has already deployed a satellite system that broadcasts bitcoin blocks. If there were nodes on both parts of the network receiving the satellite broadcasts when the "split brain" occurred they would be able to keep it from forking, at least that's the theory.


Why does Electrum's SPV require proprietary servers? What does an Electrum server do that a regular Core full node doesn't do? If the wallet downloads block headers and verifies transactions using SPV and bloom filters, why does it require special servers at all?

Quoted directly from the source:

  One security advantage of Electrum is that servers are authenticated
  using SSL; this provides protection against MITM attacks, which is a
  problem for thin clients, including bloom filter clients. However,
  this advantage comes at the cost of  privacy, because the main
  Electrum server you use knowns which addresses you are using; bloom
  filter clients have more privacy although the default setting in other
  clients is to favor speed at the expense of privacy.


How much can you compress a bitcoin for storage? I've just implanted an NFC chip in my hand and I'm wondering if a bitcoin will fit in the chip. it has a capacity of 868 bytes.

"A bitcoin" is not really a single concept. A bitcoin can be composed of 1000 outputs worth 0.001 BTC each, or 1 output worth 1 BTC, or any other such combination.

Bitcoin outputs are linked to private keys (for standard outputs). There are many ways to derive and encode private keys, and each of them would certainly fit in 868 bytes. However, you would likely have to extract the key into another device to actually use to to access your coins, which could be a security issue. You will most likely be better served, and more secure, by buying a hardware wallet.


Spending transaction with custom output I've recently entered the bitcoin arena, and bitcoinj was my tool choice. Experimenting on regression test mode, I was able to create the following custom transaction. It has a modified locking script and would need a modified unlocking, input, script.

 //Sender: sig pubk [dup() hash() pubk equ() chksig() OP_VERIFY() match_me eqal()]
 //Receiver: matcher sig pubk [dup() hash() pubk equ() chksig()]

 Script locking = new ScriptBuilder()
      .op(OP_DUP)
      .op(OP_HASH160)
      .data(address3.getHash160())
      .op(OP_EQUALVERIFY).op(OP_CHECKSIG)
      .op(OP_VERIFY)/*gets rid of the true left by previous checksig*/
      .data(match_me)/*32bytes to be matched in unlocking script*/
      .op(OP_EQUAL)/*checks the equality of match_me with one provided by receiver*/
      .build();

 Transaction contract = new Transaction(params);

 contract.addOutput(COIN.multiply(25), locking);
 SendRequest req = SendRequest.forTx(contract);
 wallet2.wallet().completeTx(req);
 wallet2.peerGroup().broadcastTransaction(req.tx);

Here, I'm trying to create this transaction that won't be spent until the receiver provides data that matches 'match_me'. The transaction half successfully spends the coins from the sender's wallet, subtracting 25 BTC from wallet2. However, wallet3 was still empty even after generating a new block.

 Transaction:
   bd52d8ef024715096b5177d581121122dc1ce9f8925c105a496bb290691ba1a7
   updated: 2016-10-02T23:19:14Z
      in   PUSHDATA(72)     [3045022100f5664de61bd0c9576d7dd2aaf98f2ba4e60c1013e55a36e62bf1d47c38a0fb5c02206872b35821f05069df5d2302dadc55011e6e6d7569e2e46c655deb9265390f3f01] PUSHDATA(33)[035562c04ff3ddb5a8ba566f4cd84c3e47478997ab8730bd923a4260fc9dfe246e] 50.00 BTC
      outpoint:7738e333b27700e835d3c118444d9f2181033c8d796ca116c66d795140ad64df:1 hash160:67d4ea4c50e80497380b7eb2f901664dc341db4b
 out  DUP HASH160 PUSHDATA(20)[d713cf366138ad0d0aac8c148ca724c18a8c4e4d] EQUALVERIFY CHECKSIG VERIFY PUSHDATA(16)[e04fd020ea3a6910a2d808002b30309d] EQUAL 25.00 BTC
 out  DUP HASH160 PUSHDATA(20)[2515ad4a14c15cc363796684149fd23ae1c3146e] EQUALVERIFY CHECKSIG 24.999877 BTC
 fee  0.00050204 BTC/kB, 0.000123 BTC for 245 bytes
 prps USER_PAYMENT

I speculate that it could be the case that wallet3 doesn't recognize the custom transaction, so it doesn't include it in its balance. Do you think so?
If I decided to spend the transaction using the txid, how would I create the inputs to unlock it? how do I create scriptsig with (.data(matcher).data(sig).data(pubkey))?

Thank you

Typically wallets do not support spending coins with any scriptPubKey except the ones they hand out themselves (in the sense that an address is a shorthand for a particulatlr scriptPubKey).

This is for good reasons. It's impossible for wallets to scan for all possible combinations and alterations of scripts with keys they know, so it would inherently be a subset anyway. It being a subset would just create unclear expectations, as senders may wonder what exactly is permitted. Furthermore, it is not the sender's business to decide what script the receiver should accept money at.

Compare this to a real life scenario where you're asked to pay someone by slipping an envelope under their door. Instead, you take the envelope and put it under their doormat. You wouldn't expect this to be a fulfillment of the payment either.


Receive coins from my physical wallet I'm new at this. I opened a wallet on my computer, I  have a physical wallet I'm trying to get the coins from my physical wallet to my computer. I went into my wallet, clicked help, selected the debug window option, clicked on the console tap typed in my importprivkey  then what do I do?

By physical wallet I assume you mean like a printed paper wallet. But your paper wallet should be an address and the corresponding private key (don't share this!). To access it all you need to do is import it to bitcoin-qt through one of the options. To do it through console:

importprivkey <private key>

Where  is your private key. It should take your client like 30-60 mins to rescan the block chain to update the balance.


Is there a difference between the multi-signature and Shamir's secret sharing? Is there a difference between the multi-signature and Shamir's secret sharing?

Technology/algorithm-wise.

The most fundamental difference is that Shamir Secret Shares shares... well, a secret. Multisig shares the ability to sign, but does not share the private keys directly.

You could use SSS to implement a sort-of multisig scheme. Multiple people come up jointly with a single key, split it into pieces, and then separate them. Now they want to produce a signature... the only way to do that is to first reconstruct the original key, as no signing is possible without it. This implies that to sign, at some point, someone needs to see the full key. If he makes a copy of that key, he can sign any number of messages afterwards. In short: SSS for multisig is only usable if you ever only sign one message. Afterwards, its security advantages are broken.

This is not the case for typical multisig schemes (including Bitcoin's). In that, everyone has their own independent key, and the private keys never need to leave the ownership of their holder. They merely each produce a partial signature, and all partial signatures are combined into a full one. However, a partial signature does not reveal the secret key at all.


Various questions regarding wallet and mining Ok so I downloaded the bitcoin program and started it up.
And the program started downloading thousands of blocks.
I haven't clicked anything or signed up anywhere, I have tried and i think succeeded in finding my address, no sure though.
Now it is still busy downloading blocks.
On the overview screen it shows wallet out of sync.
How do I sync this or does this happen once the blocks are done?
How do I make/get/mine bitcoins, any websites that can be recommended?
Do I have to add my own money to get started?

1) yes, "out of sync" means that it hasn't downloaded the whole blockchain yet.

2) to mine ("make") them, you need special hardware and software.

3) it is much easier, yes. There are many exchanges where you can buy bitcoins, such as Mt. Gox or Bitcoin Central


Why coin wallet shows only 1 connection? I have wallet software (compile for my altcoin) and there are 3 nodes running. When i run wallet software in Mac (not core wallet), it shows only one connection to altcoin network, when it should be 3. The 3 IPs are added through dns seeds.

Why wallet software is not doing dns lookup and not connecting to 3 nodes?

There is only one IP hardcoded into chainparamsbase.cpp. I cannot hardcode more IP into the code, wallets already compiled, which is why i am adding node IPs into DNS seeder.

Am i doing something wrong?

As you said you have only 1 IP hardcoded in chainparams.cpp and when you run your wallet without any .conf file with added nodes it will lookup only for the IP given in the source code.

If you want to add more nodes just write:

addnode=ip.ip.ip.ip

in your coin.conf file. Restart your wallet and it will try to sync to new nodes also.

If you need to hardcode the IPs in your wallet you can contact me here: https://bitcointalk.org/index.php?topic=3196213.0


Sending confidential transaction amount to the receiver In confidential transaction proposed by Maxwell, instead of transaction amounts we use pedersen commitments to hide the amount and add the range proof to the transaction to prevent overflow. A simple commitment with one input and one output C1 and C2 is as follow: (Ignore the fee for simplicity)

C1 = C2 => BF1*G + a*H = BF2*G + a*H

where in this example BF1 = BF2 obviously since it only has one input and output.
How does the sender send the amount and blinding factor to the receiver? Receiver can check if the amount is correct! I noticed Maxwell said they use ECDH. I assume there is no additional communication channel for ECDH. Then how does the sender get receivers public key? and does sender need to reveal both blinding factor and amount in the ECDH?

In Elements Alpha, output "amounts" consist of 3 pieces of data:

The Petersen commitment to the value, blinded by the blinding factor.
The range proof, which can publicly prove that the value is within range [0..2^32-1] units (satoshis) without revealing anything about the blinding factor.
An ECDH ephemeral public key of the sender.

The latter is where the solution lies. Every confidential transactions address contains an ECDH public key of the receiver (the blinding key), in addition to normal P2PKH or P2SH data.

When a CT transaction is sent, the sender chooses an ECDH ephemeral private key, and combines it with the blinding key to derive a blinding seed. This seed is used as a basis for the random number generator to create the range proof. The public version of the ephemeral key is then written in the 3rd field of the amount.

When the receiver sees this ECDH ephemeral public key, he combines it with his private blinding key, to derive the same seed as the sender used. Using this same seed, he can "unwind" the range proof, and decode the secret information that was used when creating it: the value and the blinding factor. There is in fact space for another 2 kilobytes of data in the range proof, only visible to the receiver (or anyone holding the private blinding key).


Which wallets are built deterministically? (Besides Bitcoin Core) Bitcoin Core can be built deterministically, allowing anyone to compile the software themselves and compare it to the released version to see if they're identical.  Presumably, software forks of Bitcoin Core like Bitcoin Knots also provide this capability, and I recall that some people did this also for BIP148 UASF forks of Bitcoin Core.

What other software[1] wallets typically provided in pre-compiled form[2] are deterministically built?  Deterministic builds seem like a powerful and useful security feature, but as far as I know, almost no software wallets besides Bitcoin Core provide that feature.

Note: deterministic builds should not be confused with BIP32 Hierachical Deterministic (HD) wallets.

[1] Some hardware wallets, like Trezor, provide deterministic builds of their firmware, which is a nice feature.  However, that does nothing to prove the security of the hardware, which is hard to audit with the tools found even in a typical geek's home office.

[2] That is, not provided entirely using interpreted code.

Electrum's distributed binaries are determinisitc. Although Electrum is written in an interpreted language, the distributed binaries also need to provide the dependencies and the packaging process for producing binaries for python software is not deterministic. Electrum has their own process for ensuring dependency versions and determinism of their binaries.

Mycelium's distributed binaries are deterministic built. They use a docker container instead of Gitian to produce their binaries.


Do I need to secure my Master Public Key generated from an Electrum wallet? I have an electrum wallet and have exported the Master Public Key.  What level of security should I use for the MPK?  Should I keep it offline?  Can I keep it in plaintext in an online computer?  Back it up somewhere ( gmail / dropbox )?

The xpubkey (your master public key) is not something you need to export.

What you need to store is your seed value for the Electrum wallet. With this it can regenerate you the xpubkey.

The xpubkey is not really useful unless you are providing it to someone who intends to make multiple payments to you. If this is the case then make sure only that individual or business will be sending you funds to the address set as once the xpubkey is shared it allows them to see all addresses down that chain.


What is the different between BitcoinCore and other full node wallet? As I understand, BitcoinCore is implementation of Bitcoin protocol. And within BitCoinCore is wallet functionality located in wallet.cpp/h. My question is, if I have some other wallet that has complete copy of a blockchain (full node wallet) how it will be different from BitcoinCore? Which parts of the code that other wallet wont have in it?

Bitcoin Core is primarily a node (also known as a peer) intended to join the Bitcoin network. It includes wallet functionality, but its primary purpose is to interact with the Bitcoin p2p network, and help validate all blocks and transactions for adherence to the consensus rules, which are encoded in the Bitcoin Core source code.
Due to this, it also functions as the reference implementation of the Bitcoin Protocol.
If you had another piece of software that connects to the Bitcoin network and performs all functions a full node does (checking block and transaction validity, following the best chain, serving data to other nodes, etc.) and it offered a wallet, it would be functionally equivalent to Bitcoin Core.
However, there are not a whole lot of these softwares around - btcd is one of the most well known and complete ones, but most projects aim to just build a wallet on top of protocols like Simplified Payment Verification (SPV), electrum, or custom solutions to share only the data required by the wallet, instead of the entirety of the Bitcoin blockchain.
Note that even running Bitcoin Core in pruned mode disqualifies it from being a full node, as it is no longer able to fulfill the function of being able to serve historical data to other nodes.


How to backup Android Wallet? I'm finally getting ready to install an Android client.
I believe Android Wallet is the most popular one.

How do I back up the bitcoins stored on it?

Also, is there a thin native Android client being developed?

Bitcoin Wallet for Android supports backing up your private keys to external storage (e.g. SD Card). Just select "Export/Import private keys" from the action bar overflow menu.


Merged mining: are there any ways to prevent it? Supporting merged mining allows a cryptocurrency A to improve the security its blockchain (increase the hash rate) by accepting work done on the blockchain of cryptocurrency B through insertion of a hash of a valid A-block.

Is it possible for cryptocurrency B (say Bitcoin) to prevent its blockchain from being used to effectively enhance the security of a rival coin? (I am assuming the 'A'-hash insertion takes place in the coinbase, which is normally used for entropy).

It should be possible for the parent coin protocol to prevent being used for merged mining, by eliminating the ability to populate the coinbase transaction with random data.

Merged mining works because it is possible to inject a hash of an auxiliary block into a block of the parent blockchain.

The coinbase block does need to contain some random data because otherwise miners would hash to the same values and it would restrict the range of the hashing function.

However if the source of this entropy is restricted to a well-formed address (remember all bitcoin addresses are unique), and a consequence of putting the address in the coinbase is that it will be credited with the mining rewards, then it would not be possible to insert the auxiliary chain hash without forgoing the parent chain reward.

To my knowledge the provision of a bitcoin address + nonce within a certain range, would be a sufficient source of entropy for hashing purposes.


Help! I sent coins to my bitcoin wallet before it was properly synced! I sent coins to my Bitcoin wallet not after installing it, but before it had fully synced! Then I closed and reopened it after sending the coins.

It had generated a bitcoin address to send to, but is that address "officially mine" prior to the program actually having updated and being "officially on the network"?

Yes it is, worry not.

The client can generate valid addresses without ever being connected to the internet.

When the blockchain finishes downloading, you should see the incoming transaction.


Litecoin - mandatory-script-verify-flag-failed (Signature must be zero for failed CHECK(MULTI)SIG operation) I have manually a raw transaction using bit library in order to send a transaction using Litecoin testnet. After adjusting fee's and other network variables I got the following error that is stated in the subject of the post. This transaction isn't a multisignature one. This is the hex value of the raw transaction

0100000001d0e0112dd6bf2b44c44895d5363f2d2b940d4aff8d7fc2852a4c751e90200a5e000000006b483045022100ac91b8da716668553088da2da32c596a03973fffcbc36d2a7f3ecb8e93c3de07022040b7015c065e74d6f5fc30c9458c0631ddfb2d72feae3bb699c6ce835cd0ba54012102d41b76393d5f82b1856343623974684ff2bf03b26ec6bc2d0391ae0768cd9ebdffffffff0200286bee000000001976a914df918d7a0efe546d0284e217a3a322bb09f37f3988acb0a69a3b000000001976a914f2ebf3c5642abf069b4197a08e116937503d13e488ac00000000

After decoding this hex, this is the output:

{
  "txid": "2915435fbfb199670280d564b948d5a52fb4002f238f2980effef10818a84fc5",
  "hash": "2915435fbfb199670280d564b948d5a52fb4002f238f2980effef10818a84fc5",
  "version": 1,
  "size": 226,
  "vsize": 226,
  "locktime": 0,
  "vin": [
    {
      "txid": "5e0a20901e754c2a85c27f8dff4a0d942b2d3f36d59548c4442bbfd62d11e0d0",
      "vout": 0,
      "scriptSig": {
        "asm": "3045022100ac91b8da716668553088da2da32c596a03973fffcbc36d2a7f3ecb8e93c3de07022040b7015c065e74d6f5fc30c9458c0631ddfb2d72feae3bb699c6ce835cd0ba54[ALL] 02d41b76393d5f82b1856343623974684ff2bf03b26ec6bc2d0391ae0768cd9ebd",
        "hex": "483045022100ac91b8da716668553088da2da32c596a03973fffcbc36d2a7f3ecb8e93c3de07022040b7015c065e74d6f5fc30c9458c0631ddfb2d72feae3bb699c6ce835cd0ba54012102d41b76393d5f82b1856343623974684ff2bf03b26ec6bc2d0391ae0768cd9ebd"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 40.00000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 df918d7a0efe546d0284e217a3a322bb09f37f39 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914df918d7a0efe546d0284e217a3a322bb09f37f3988ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "n1u5M1NRi1VGDrAQujjzaRhRsfWBtvsVLA"
        ]
      }
    },
    {
      "value": 9.99990960,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 f2ebf3c5642abf069b4197a08e116937503d13e4 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914f2ebf3c5642abf069b4197a08e116937503d13e488ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "n3fQUj2SSLcuAQjeL97WWuLm3n5DvjNYA8"
        ]
      }
    }
  ]
}

Thank you in advance! :)

I am not 100% sure, if this also applies to Litecoin, as it is a clone of Bitcoin. But I understand the signature scheme is the same... So it should be possible to use openssl or any ECDSA library to check the signature. Therefor the double sea of the unsigned tx must be created, as per these steps by amaclin's answer:

  1) Remove input script from transaction

  2) Replace it with the previous TX's pubkeyscript

  3) Append SIGHASH_ALL

  4) Hash it twice with SHA256

I try to replay it, and get these values:

sig:         3045022100ac91b8da716668553088da2da32c596a03973fffcbc36d2a7f3ecb8e93c3de07022040b7015c065e74d6f5fc30c9458c0631ddfb2d72feae3bb699c6ce835cd0ba54
pubkey:      02d41b76393d5f82b1856343623974684ff2bf03b26ec6bc2d0391ae0768cd9ebd
double hash: c54fa81808f1feef80298f232f00b42fa5d548b964d580026799b1bf5f431529

This returns an error in signature verification. This can have several root causes... You said, "after adjusting fee's and other network variables": the fees are related to the amounts in the output structure, and they are signed. At anytime something of the signed tx is changed, invalidates the signature. This might be the root cause ...
Can we see the unsigned transaction?


(Why) is it difficult to merge and split wallet.dat? It is a common question, how to sync a wallet across different devices.

As far as I understand, a wallet is just a collection of private keys. Each private key can be uniquely identified using the bitcoin address associated with the key. Thus, why don't we think of wallet.dat as if it was a directory:

Filename     File Content
=Address     =Private Key

1HB5XMLmzFV  8ALj6mfBsbifRo
...          ...

Now, syncing such a directory is trivial. If the filename (address) matches, the file is identical and does not need to be synced. If a filename is only present on one side, just copy the file, it's a new address.

Is something like this going to be implemented in a future client version? Or is my idea faulty?

The ability to import and export keys is in the works, with several forks in the Github project trying out various methods. One of them will eventually be selected and make its way into the official client. Until then we're reliant on tools like pywallet to import and export keys.

As for the directory concept, the wallet.dat file stores this information in a BerkeleyDB format, as well as a transactions list. I can see the potential benefits, though there are likely downsides that I've not considered and I'm certainly not qualified to speak to the mindset of the developers. Perhaps you'll get lucky though, at least one big name from the Bitcoin devs has been known to frequent these parts.


API for large number of queries to different addresses every few minutes I have an application that needs to makes queries to get address balances and transaction data from Bitcoin.
What are some possible solutions to this? It would be great if I didn't have to manage a full node if possible.

You can use a self-hosted (but low-burden!) instance of Esplora.
Blockstream is also exposing an instance for free (at the moment) at blockstream.info.
Disclaimer: if you take part of Bitcoin as an economic actor (as an application providing account balances may imply), you should really consider using your own source of truth and self-host the instance. It's just a docker to start and an nginx reverse proxy to set up after all :-).


starting alphad what is the correct rpcconnectport following the instructions in the alpha-README.md file on GitHub
in step number 2, to start alphad it is suggested to do:

./alphad -rpcuser=$RPC_USER -rpcpassword=$RPC_PASS -testnet -rpcconnect=127.0.0.1 -rpcconnectport=18332 -tracksidechain=all -txindex -blindtrust=true -daemon

my question is about the rpcconnectport=18332
why 18332 instead of 4241?  like in step 5

Because in order to validate sidechain transfers, alphad needs to connect to a testnet bitcoind. The rpcconnect-like flags passed to it are information about how it can do that, so you need to use the running bitcoind's port.


Stratum proxy on Windows I am looking to do solo mining on a SHA-256 altcoin by purchasing hashrate from NiceHash. I have the client set up on a Windows Server 2016 VPS and the blockchain is synced. For NiceHash to point the miners to me, I need to offer a stratum+tcp connection.

I have attempted to set up a mining pool using NOMP, but ran into countless errors that - when fixed - generated even more abstract errors, so dead end there.

Essentially what I am looking for is a proxy (?) that will get work from my client (JSON-RPC works and is potentially reachable from other servers) and deliver it to the NiceHash miners over stratum+tcp. I need no payout system or similar.
Is there any ready windows ( /java /...) program that covers this?

Thanks in advance!

If anybody is searching this in the future: CoiniumServ can be self-compiled from the github source and runs on windows.


Can Large Bitcoin Collider break into the wallet which is created by new version of Electrum? I have heard that Large Bitcoin Collider can only break into wallets that are created by broken software.
My other question is that it seems the last private key that they found was on 2017-11-15 01:25:58 UTC. Am I right? Does it mean that their project is not successful any more?

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

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

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


If I want to build up a website to offer bitcoin exchange service, how to add my site to https://bitcoin.org/en/exchanges Does anybody give me a clue?
I want to run some business with exchange bitcoin for people. But how to make it well known? Adding it to bitcoin.org's list is a good idea, but is that possible, and how to achieve this?

You could probably open a pull request to the bitcoin.org github repository here: https://github.com/bitcoin-dot-org/bitcoin.org

Specifically, this file is the one which provides the content for the exchanges page: https://github.com/bitcoin-dot-org/bitcoin.org/blob/master/_templates/exchanges.html

Then the owners of that project can review the change and decide whether it is an appropriate addition to the website. Keep in mind that if you are just starting out a new exchange, it may not be established/trusted well enough to be featured on such a site, and that is up the site owners' discretion.


Choose where to install bitcoin-qt (linux) I don't have much space on my / (~12GB) so I would like to install bitcoin-qt to some other drive with free space (since the data files will take around 10GB after synchronization). How do I do that?

Run bitcoin with the flag

-datadir=<path to a directory>


After sending/flooding transactions, how do we know that a specific transaction is on all nodes? In the book "Mastering the Blockchain" by Imran Bashir, it says that a transaction's life cycle is the following:

  A user/sender sends a transaction using wallet software or some other interface.
  The wallet software signs the transaction using the sender's private key.
  The transaction is broadcasted to the Bitcoin network using a flooding algorithm.
  Mining nodes include this transaction in the next block to be mined.
  Mining starts once a miner who solves the Proof of Work problem broadcasts the newly mined
  block to the network. Proof of Work is explained in detail later in this chapter.
  The nodes verify the block and propagate the block further, and confirmation starts to generate.
  Finally, the confirmations start to appear in the receiver's wallet and after approximately six
  confirmations, the transaction is considered finalized and confirmed. However, six is just a
  recommended number; the transaction can be considered final even after the first confirmation.
  The key idea behind waiting for six confirmations is that the probability of double spending is
  virtually eliminated after six confirmations.

My question:

Now all nodes have competing miners to create a block by receiving all transactions by all nodes/users that submit transactions and packing it, which is not coming from one place. If we call the winner, the miner that solves the PoW problem first, then how do we know that he received all the transactions he's supposed to receive before announcing that he created a valid block? My miner software could ignore a few transactions and get to mining earlier than others, and hence beat everyone else (assuming we all have the same computational power).

My question also can be read in a different way: How do ensure that all miners are solving the same PoW problem, while big latency times can be involved in the Bitcoin network (because we're mining from around the world)?

From a novice, what it means that if someone who isn't bitcoin savvy accepted bitcoin on the deprecated block and gave that person something of value, that person is out of luck, you just lost that item of value.
Previous answers eluded to it, but, simpletons like me look at "So what does this really mean".  It means, when you get paid in BitCoins, you are not "PAID" until that transaction appears in at least 6 blocks to that chain, since that chain could be voted invalid anytime before that 6th block is reached (It can still be called invalid after that but highly unlikely).
This means, instantaneous transactions using BitCoin are "RISK".  If I accept bitcoin at my restaurant, it is possible that the chain in which I got paid could be voted invalid, thus, I never received actual payment.  I think the time is currently 10 minutes to "confirm" a transaction is on the valid chain "6 blocks deep".
A person could gamble and spend money twice, the money doesn't actually get spent twice, but a novice person could be taken advantage if they don't understand how things work.  In short, don't give up anything of value until the chain gets at least 6 blocks deep, then your "payment" is most likely confirmed.


Why is OP_CHECKLOCKTIMEVERIFY disabled by maximum sequence number? In the code for OP_CHECKLOCKTIMEVERIFY i noticed that if the txin sequence number is maxxed out then the script will fail to validate. I'm wondering what the point of this is? Why would anybody ever submit a transaction that will fail to verify to the network?

Here is the relevant section of code:

// Finally the nLockTime feature can be disabled and thus
// CHECKLOCKTIMEVERIFY bypassed if every txin has been
// finalized by setting nSequence to maxint. The
// transaction would be allowed into the blockchain, making
// the opcode ineffective.
//
// Testing if this vin is not final is sufficient to
// prevent this condition. Alternatively we could test all
// inputs, but testing just this input minimizes the data
// required to prove correct CHECKLOCKTIMEVERIFY execution.
if (txTo->vin[nIn].IsFinal())
    return false;

I'm also confused about the comments in the code for this. They say that every sequence number has to be maxxed out to get the script to fail to validate, but it looks to me like this is not true - it looks like only one sequence number needs to be maxxed out and then the whole transaction (all txins) will fail. And I assume this would mean that the transaction will therefore not be included in the blockchain? But that runs counter to the code comments. It would make sense if there were a ! on the if condition.

the purpose of OP_CHECKLOCKTIMEVERIFY is kind of the opposite to the purpose of tx.nLockTime. tx.nLockTime prevents transactions with future dates from entering the blockchain, whereas OP_CHECKLOCKTIMEVERIFY enables someone to freeze funds so that they can only be spent after a given timestamp or block height.

tx.nLockTime

tx.nLockTime is validated by function IsFinalTx() in src/main.cpp:

bool IsFinalTx(const CTransaction &tx, int nBlockHeight, int64_t nBlockTime)
{
    if (tx.nLockTime == 0)
        return true;
    if ((int64_t)tx.nLockTime < ((int64_t)tx.nLockTime < LOCKTIME_THRESHOLD ? (int64_t)nBlockHeight : nBlockTime))
        return true;
    BOOST_FOREACH(const CTxIn& txin, tx.vin)
        if (!txin.IsFinal())
            return false;
    return true;
}

where txin.IsFinal() is in src/primitives/transaction.h:

bool IsFinal() const
{
    return (nSequence == std::numeric_limits<uint32_t>::max());
}

If the tx locktime is below the threshold then it is treated as a block height and if it is above the threshold then it is treated as a timestamp. Either way, the transaction locktime value must be smaller than the relevant constraint. If it is larger then miners must wait before including the transaction in a block.

The only way to bypass this transaction locktime constraint is to disable the transaction locktime completely by setting all txin sequence numbers to maxint. When this is done then miners will include the transaction straight away, even if the locktime has not yet been reached.

The idea with the transaction locktime is that before the transaction is locked (ie before the block height or timestamp catch up with tx locktime), someone can make amendments to the transaction. Each time they make a change then they must increment the sequence number to let miners know which amendment comes after another.

One use case for this might be a digital will. If you wanted to pass your money on to someone else specifically in the event of your death then you could create a transaction with a locktime of one year from now and then give it to a few friends. In the event of your death they can broadcast this transaction on the network after one year and the funds will be sent accordingly. Broadcasting the transaction before this time period of one year would not enable them to receive funds, since miners will ignore the transaction until the time period becomes valid (and obviously the friends cannot alter the functionality of this transaction since it is signed by your private key which you never disclose).

If you don't die then you can spend the funds to a different address of your own choosing by broadcasting a different transaction on the network. Your friends will then not be able to use the original transaction you gave them since this would be a doublespend, which the miners do not allow. For the transaction which you broadcast to cancel the will you would alter the locktime to make it sooner, and increment the sequence number. Alternatively you could set the locktime to 0 or set the sequence number to maxint to spend straight away.

OP_CHECKLOCKTIMEVERIFY

OP_CHECKLOCKTIMEVERIFY has a very different use. It is validated in function EvalScript() in src/script/interpreter.cpp:

            case OP_CHECKLOCKTIMEVERIFY:
            {
                if (!(flags & SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY)) {
                    // not enabled; treat as a NOP2
                    if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
                        return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
                    }
                    break;
                }

                if (stack.size() < 1)
                    return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);

                // Note that elsewhere numeric opcodes are limited to
                // operands in the range -2**31+1 to 2**31-1, however it is
                // legal for opcodes to produce results exceeding that
                // range. This limitation is implemented by CScriptNum's
                // default 4-byte limit.
                //
                // If we kept to that limit we'd have a year 2038 problem,
                // even though the nLockTime field in transactions
                // themselves is uint32 which only becomes meaningless
                // after the year 2106.
                //
                // Thus as a special case we tell CScriptNum to accept up
                // to 5-byte bignums, which are good until 2**39-1, well
                // beyond the 2**32-1 limit of the nLockTime field itself.
                const CScriptNum nLockTime(stacktop(-1), fRequireMinimal, 5);

                // In the rare event that the argument may be < 0 due to
                // some arithmetic being done first, you can always use
                // 0 MAX CHECKLOCKTIMEVERIFY.
                if (nLockTime < 0)
                    return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME);

                // Actually compare the specified lock time with the transaction.
                if (!checker.CheckLockTime(nLockTime))
                    return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);

                break;
            }

which relies on function CheckLockTime() in the same file:

bool TransactionSignatureChecker::CheckLockTime(const CScriptNum& nLockTime) const
{
    // There are two kinds of nLockTime: lock-by-blockheight
    // and lock-by-blocktime, distinguished by whether
    // nLockTime < LOCKTIME_THRESHOLD.
    //
    // We want to compare apples to apples, so fail the script
    // unless the type of nLockTime being tested is the same as
    // the nLockTime in the transaction.
    if (!(
        (txTo->nLockTime <  LOCKTIME_THRESHOLD && nLockTime <  LOCKTIME_THRESHOLD) ||
        (txTo->nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD)
    ))
        return false;

    // Now that we know we're comparing apples-to-apples, the
    // comparison is a simple numeric one.
    if (nLockTime > (int64_t)txTo->nLockTime)
        return false;

    // Finally the nLockTime feature can be disabled and thus
    // CHECKLOCKTIMEVERIFY bypassed if every txin has been
    // finalized by setting nSequence to maxint. The
    // transaction would be allowed into the blockchain, making
    // the opcode ineffective.
    //
    // Testing if this vin is not final is sufficient to
    // prevent this condition. Alternatively we could test all
    // inputs, but testing just this input minimizes the data
    // required to prove correct CHECKLOCKTIMEVERIFY execution.
    if (txTo->vin[nIn].IsFinal())
        return false;

    return true;
}

Here the transaction locktime is compared to a value on the stack. To validate successfully, both must be the same side of the theshold (ie both must be interpreted as a block height, or both as a timestamp), and the script will only validate if the stack value is lower than the tx locktime. Or to put it another way, the script will only validate if the transaction locktime has passed the stack value.

Whereas IsFinalTx() prevents transactions with locktimes in the future from being included into the blockchain in the present, OP_CHECKLOCKTIMEVERIFY freezes funds in the blockchain so that they can only be spent after a specified time in the future.

Note that the stack value used for comparison is most useful when placed in the scriptPubKey. The locktime used for comparison against the stack value is that of the signing transaction. This forces the spender to wait for the block or timestamp in order to spend the funds.

As previously discussed, IsFinalTx() does allow transactions with locktimes above the current block height or timestamp to be mined - providing the sequence number is maxxed out, thus disabling the tx locktime. Submitting such a transaction with a maxxed out sequence number would be a sneaky way for the recipient to spend the funds earlier than the time specified by the sender in the txout script. So, to prevent the OP_CHECKLOCKTIMEVERIFY criteria from being bypassed, the script validation must fail when the tx locktime is disabled by the sequence number.


REST API to create Stellar account? In the REST API documentation, I didn't see an option to create an account. Obviously then, the code snippet here to create an account has to be front-ended by some other API so that a request to create an account can be catered to. I am not sure why this is so. Is there a HTTP POST REST API to create an account?

Also, normally, to build a REST interface, one starts with identifying all 'resources' whose state changes over time and can be changed in a state-less operation. Then, for every such resource, the CRUD operations are implemented. For example, in Stellar, the resources could be account, anchor, trustlines, transactions, etc.

There is no REST endpoint to create an account. An account is implicitly created after receiving at least 20 lumens.

To create an account:

Generate a private/public keypair. You can use the Stellar Laboratory Account Creator for that.
Get at least 20 lumens, either from an exchange or through another account, sent to the public key you just created.

That's it.

Official guide : https://www.stellar.org/developers/guides/get-started/create-account.html


Can I rely on my full node to always have the most recent blocks? I have a full node running and I am using ZMQ to let me know when new blocks arrive. How can I make sure that this block that my node received is a valid block written in the blockchain ledger and it is not an orphan block?
Can I rely on my full node to have the most recent blocks?

how can I make sure that this block that my node received is a valid block

Bitcoin Core will only announce (through ZMQ) blocks that change the tip of the best-known valid chain. This implies they together with all their ancestors are fully valid.

  and it is not an orphan block

At the time it is announced, you know that it is part of the best-known valid chain. Of course, it's always possible that a better alternative branch is received later, which reorganizes the old one you heard about. In that case, you'll receive a new ZMQ notification for the new best tip.

  Can I rely on my full node to have the most recent blocks?

No, of course not. The speed of communication around the earth is finite; if a new block has been found somewhere on earth, there is no way you can know about it before it's had time to propagate to you.

Even ignoring that, it's always possible for the nodes you are connected to to be slow, broken, or malicious, in a way that prevents them from propagating blocks to you.

The only correct way to think about this is that there simply is no such thing as "the best/most recent block", and every node is continuously trying to catch up with new information. In theory, you never have any guarantees. In practice, usually nodes learn about blocks within seconds, and if it takes way too long (say, hours), you'll know something is wrong.


Transactions not showing up in bitcoind log? I have a bitcoind running on a server behind the www box which I poll every minute for new transactions and save new data into a table.

Something strange is happening sometimes. If i send 1 btc from my wallet to an address on the bitcoind server, it gets through just fine and shows up right away in the log when downloading transactions via RPC.

If however I send from an exchange, it does not show up (at least not for a day or two). I've noticed that these exchanges add another address and amount to the same txid, could that be the cause?

Is there a workaround for this?

TIA

Use walletnotify instead of polling.

how to do address callbacks?

It's basically a argument you can specify and Bitcoin will the specified program upon receiving a transaction (BOTH receives and sends from an address in wallet get notified). So you just setup a small script to run and point to it in bitcoin.conf.

Be sure to check for duplicates as walletnotify sends notifications for when a txn is first received (unconfirmed) and when it receives a confirmation.

Also blocknotify does the same thing as walletnotify but for blocks, may be useful for checking unconfirmed transactions.


How exactly does short selling with Bitcoins work? Bitcoinica does (or did) offer short selling, but the question is how?

If I fund my account with 100 BTC and I want to short BTC, can I do that, or do I need USD to do that?

Short selling is essentially an agreement between you and Bitcoinica where Bitcoinica pays you if the BTC/USD price decreases, and you pay them if the price increases, in an amount equal to the price difference multiplied by the number of bitcoins you sold short.

Presumably you trust Bitcoinica to hold up its end of the deal, but they don't know you and don't trust you, so they require you to make a deposit which they deem more than enough to be able to cover your obligations. It may happen that when the price changes they are no longer confident your deposit is enough; they will then do a forced liquidation, settling the agreement up to this point and only allowing you to make a smaller agreement going forward.

The deposit can be in either BTC or USD. If you have BTC, however, you may want to consider first selling the BTC (which is functionally equivalent to taking a short position), which may be done cheaper than in Bitcoinica, and then short-sell on Bitcoinica.

An alternative view of short-selling is that you borrow bitcoins from Bitcoinica, offering a deposit as collateral, and then selling them. With Bitcoinica out of the picture for now, short-selling can be done by literally finding someone to borrow bitcoins from.

You can also learn more about Margin trading in general on Wikipedia.


How are colored coins enforced? How are colored coins enforced?

A signature can easily be rejected, and so can a block.

How does the blockchain enforce that a particular asset is tied to the colored coin or has been delivered?

I can see how another cryptosecurity could be tied to a cryptocurrency, but does the blockchain physically manifest itself, kick down the door of 31uEbMgunupShBVTewXjtqbBv5MndwfXhb, and collect the asset if 31... doesn't deliver?

You could imagine that you're selling a car to someone. The key to open the car is tied to your bitcoin address. So only you, owner of the private key for that address, can open and turn on the car.

Once you sell the car you make a symbolical transaction to the buyer and you configure the car key with the buyer's address, so only s/he can open the car.

The symbolical transaction is actually a colored coin. It's proof that you've sold the car. That proof is also attached to the physical key itself. That proof will forever exist (or at least until bitcoin exists) in the blockchain.

If then they decide to sell the car once more, they can use that same colored coin and make another symbolical transaction. Now the third owner of the car can see the proof of ownership of his car just by looking at the blockchain.


Public Key VS Wallet Address - What is the difference? I am seeing a lot of contradictory information on why we now use Wallet Addresses rather than Public Keys.

Some say that due to additional level of hashing (double hashing), Wallet addresses are harder to crack, making them virtually quantum computing resistant.

But then others are saying that public keys are always being added into the script of every transaction, making the additional layer of security irrelevant.

My question is, why are we using wallet addresses now, when transacting?

Note that an address is just an encoding of some data and that not all addresses have to be the encoding of hashes.

The reason we use an address is because it is easier for humans to read, identify, and transport. But I suspect you are asking why we use the hash of public keys rather than the public key itself.

Encoding the hash of a public key as an address began with Satoshi writing the original Bitcoin client. It is likely that he chose to encode the hash rather than the public key itself in order to be more space efficient - it is easier to transcribe an encoding of the shorter hash rather than an encoding of the public key itself. Since Base58 includes both upper and lower case characters as well as having only a checksum at the end, it is annoying to read out or copy it easily, so shorter is better.

Since then, new address types that have been introduced have followed the same practice pretty much because addresses were first done this way, so why change. When P2SH addresses were introduced, it made sense (and still makes sense) to encode the hash of the script rather than the entire script itself since scripts are variable length and can be very long.

However the proposed Segwit v1 addresses for taproot will not be using hashed public keys. Rather the it uses public keys themselves encoded as bech32 addresses. Even though this is not as space efficient, it does make transactions more efficient, and does away with the suggestion that outputs might be quantum safe. Furthermore, because it uses bech32, the case-ness of each letter does not matter and since it uses BCH error correcting codes, it can tell you where you've made an error and what that letter should have been (assuming that you have not made a lot of errors). So this avoids the other issues with using Base58 encoded addresses.


Is there a way to configure bitcoind to be nicer about its harddrive bandwidth usage? I'm running bitcoind and its using literally 100% of my primary SDD's throughput. This is making my computer run very slowly in some cases (eg saving files is absurdly slow). Is there a way to configure it to only us maybe 95% of the available throughput at max so other stuff can get through?

OS: Windows

I don't think there's any way to configure bitcoin to self-limit.

That said, Windows has an IO scheduler, which shares read/write bandwidth between processes. You can tell this IO scheduler to deprioritize a specific process. This isn't directly accessible from Task Manager or Process Explorer, but there are two third-party programs, called Process Lasso and Process Hacker which are capable of changing this.

(Source.)

(I think your problem is more likely to be a CPU bottleneck than IO, but you asked for this approach, and I assume you have a good reason.)


How would bitcoins "crash"? The value of bitcoins has been fluctuating like crazy over the last week, experiencing exponential growth in the BTC to USD valuation. There is no way that that can be maintained longterm. What would make it crash?

If there are no more buyers at price X, then a seller has to lower his price by Y. If there are still no buyers, she will have to lower it more. If there a lot more sellers than there are buyers the price can drop very quickly, just as right now there are a lot more buyers than there are sellers and the price is rising very quickly.


Fees for Multisig Addreses Twice as High as Standard Address? Based on my research the cost to transfer funds from a 2/3 MultiSig address to any other address (be it a standard or MultiSig address) is approx. 2 x the cost of transferring funds from a standard address to another address since it consumes approx. 2 x the amount of data (147 bytes vs. 295 bytes) (pretty costly!).
A single output is roughly 34 bytes per output regardless of whether the output represents a standard address or multisig address. Is this correct? In other words, the higher price for a MultiSig only matters when it's being used as the input of a transaction, not the output?
If so, does the data size grow linearly with each additional signature? (i.e, what would be the approx. number of bytes for a 2/2 and a 3/4 MultiSig transaction)?
Thanks

A single output is roughly 34 bytes per output regardless of whether the output represents a standard address or multisig address. Is this correct?

Yes, in modern Bitcoin transactions the size of producing an output (ie, paying to an address) is constant and has no relation to the size of the actual script. For native segwit outputs the size is somewhat larger (42 bytes) due to a safer hash function being used, but this is still unrelated to the size of the script.

In other words, the higher price for a MultiSig only matters when it's being used as the input of a transaction, not the output?

Yes, the cost of using a larger multisig transaction is born by the person who owns the keys, which makes sense economically. In the original transaction type of Bitcoin (P2PK) this was not the case, and the additional cost was born by the person sending money, which didn't make a great deal of sense economically.


Using bitcore to create a transaction with two addresses and change address I'm playing around with bitcore transactions and multi-sig transactions and was wondering how to send a transaction to more than one address, and keep the change.

Currently when I try to send the transaction it is sent, but the fee is calculated as:

unspent - satoshis

An example of this transaction I've made in the block chain can be seen here:

Example Transaction

Ad you can see it's calculated like this:

Original unspent amount: 0.09000000

Fee: 0.08990000

Traded: 0.00010000

Transaction sum: 0.00010000

Now I understand that one must spend all of the unspent outputs in a transaction, but how can I stop the fee from being as above, the remaining unspent balance?

Basically I want to split the transaction for two addresses, and send the rest to a change address.

Code:

var utxo = new bitcore.Transaction.UnspentOutput({
  "txid" : "f42af6ab8b4dc3c636c5bfc6ce819063a55060c5619d31a6fa45a36413cb7953",
  "vout" : 0,
  "address" : "2MzuRYCXSHcBDEsSS4rziShvEzWSfoDe2zL",
  "scriptPubKey" : "OP_HASH160 20 0x54025426880aa847ec86f4d2488bbe260bfe0fcb OP_EQUAL",
  "satoshis" : 10000
});

var pubs = [
    "02758b89e56bfa8da41f2c1701aa5927bc026cc3b51bbeff399c53a15f2ae52e28",
    "02987ab3466118bd3fb5cb0c4fddbdd7ff8e21188314ffed4ecad83fb7689d57d7",
    "037b7f8cea06cfd5a96023341441b52431e31867c6f3716e5f20be24b709d023eb"
];

var multiSigTx = new bitcore.Transaction()
    .from(utxo, pubs, 2)
    .to("n1fqBkX6GtUsaV3EPqjpHcTuWhAQQgKXov", 10000)
    .fee(5430)
    .change("2MzuRYCXSHcBDEsSS4rziShvEzWSfoDe2zL")
    .sign(["083b63f9dbaa100c1714e05a04c20ab32f83f7726ba54a682013a13df6a92949" ,"5bef634cdcc7f9c2fd2b429d1ddf6cae56923433b6e8b2c5515cf87d84751e0a"]);

var txSerialized = multiSigTx.serialize(true);

// Broadcast

insight.broadcast(txSerialized, function(err, returnedTxId) {
  if (err) {
    console.log(err);
  } else {
    console.log("Sent coins, tx id is: ");
    console.log(returnedTxId);
  }
});

I figured this out, the new transaction code should look like this with the address generated using fromString() method using bitcore.

var address = bitcore.Address.fromString('2NEvGYDNxcVPZ2ThtmPKYoKBCEa3aJNjPL3');
var multiSigTx = new bitcore.Transaction()
    .from(utxo, pubs, 2)
    .to("mntnnj64W4po96m2ck4GXQJTAiKZQChpWB", 10000)
    .to("msR1bBwUWjTTNYFU5UTVNCXDUnEx1y2MMQ", 10000)
    .fee(5430)
    .change(address)
    .sign(["7e925007e09447fa6160597391d7a24f8f47e40222d6c94b06bd9cecee5eddff" ,"6b8adfd22b8dd3186ea5333602b39a59fc1c40c543dc3848ea88c6cd6b738594"]);

var txSerialized = multiSigTx.serialize(true);

This will then show the correct change output for the transaction.

console.log(multiSigTx.getChangeOutput());


Peercoin proof-of-stake: When a person with large computing power and a person with a large stake both compete to generate a new block who wins? In other words, if one user is trying to find a block using staked coins and another using PoW, which one will find it and why? Will there be a fork in the blockchain in this scenario? If yes, then how does the network decide which chain to accept?

I have a fairly good understanding of proof-of-work, and am trying to understand proof-of-stake correctly as well.

In case of fork, according to whitepaper, the chain with highest consumed coin age wins:

  The protocol for determining which competing block chain wins as main
  chain has been  switched over to use consumed coin age. Here every
  transaction in a block contributes its consumed coin age to the score
  of the block. The block chain with highest total consumed coin age is
  chosen as main chain.

In actual implementation, sightly more complicated algorithm based on PoS difficulty is used:

PoS_block_trust = 2^256 / (target+1)
PoW_block_trust = 1

And the chain with highest total "trust" is preferred.

So, the answer to your question is: PoS block wins.


Is it possible to have a shared access bitcoin wallet? I'm trying to get my Rugby Club involved in Bitcoin.

I'm really looking for ideas on the easiest way to integrate BTC at the bar. Is it possible to have a single wallet for the Club accessible from multiple devices?

I would need bar payments to go into one overall account or wallet somehow, as the responsibility for running the bar falls to different people every weekend.

I dont want to risk 20 different wallets being used, and some people not forwarding the relevant bitcoins on to a central wallet at the end of night.

Any ideas on a work around?

Many thanks,
Kate

you could use multisig wallet, e.g. Copay - a secure bitcoin wallet platform for both desktop and mobile devices.

Check out miltisig use cases:

m = signatures required to spend
n = signatures possible

m=1 and n>1
Shared Wallet

Could be used for small group funds that do not require much security. Least secure multi-sig option because it is not multi-factor. Any compromised individual would compromise the entire group. Group funds for a weekend or evening event might be a good use case. A shared wallet might also be fun for some kind of games too. Besides being convenient to spend from the only benefit of this setup is that all but one of the backup/password pairs could be lost and all of the funds would be recoverable.

m=n
Partner Wallet

Scary because no keys can be lost. As the number of signatures required increases the risk also increases. Could be thought of as hard multi-factor authentication.

m<.5*n
Buddy Account

Could be used for spending from corporate group funds. Consequence for the colluding minority need to be greater than possible benefits. Is less convenient than a Shared Wallet, but much more secure.

m>.5*n
Consensus Account

The Classic Multi-Sig Wallet is a 2 of 3 and is a special case of a Consensus Account. I think 2 of 3 is the sweet spot for multi-sig. It has the best characteristics for creating new bitcoin address and for securely storing and spending BTC. One compromised machine does not compromise the funds. A password can be lost and the funds can still be recovered. If done correctly, off-site backups are created during wallet setup. The way to recover funds is known by more than one party.

The balance of power created with a multi-sig wallet can be shifted by having one party control more keys than the other parties. If one person alone controls enough keys to use the wallet then it could be considered a Boss Account. When one party controls multiple keys there is a greater risk of those keys not remaining as multiple factors. A Boss Account also introduces a single point of failure, if the boss disappears, funds may not be recoverable.

m=.5*n
Split Account

An interesting use case would be a 3 of 6 where one person holds 3 keys and 3 people each hold 1 key. In this way one person could control their own money, but the funds could still be recoverable even if the primary key holder were to disappear with all of his keys. As n increases, the level of trust in the secondary parties can decrease. A good use case might be a family savings account that would just automatically become an inheritance account if the primary account holder were to die.


What will happen to Bitcoin when it takes years to complete a calculation? Ok, we already experienced over the last 6yr's how bitcoin mining calculations went from mineable with a cpu, to where you need very expensive computer equipment to mine profitably. So what's going to happen to Bitcoin mining when virtually nobody can afford the equipment, and not to mention the calculations get so complex and difficult that it takes months or even yrs to complete a calculation? Only thing I can think of is Bitcoin exchange rate will increase to a point where 1 bitcoin would be worth millions, NO??

Mining is a self-adjusting system. The difficulty only rises in accordance to the available mining power. Hence, it can neither go to a difficulty where it will take months for a block to be found, nor can it become prohibitely expensive to mine.

Also see How is difficulty calculated?.


Are stale blocks retained forever or are they "pruned" automatically at some depth in the chain? In theory the chain could be re-mined from a stale block, and their existence seems superfluous and just use up data storage, are they automatically pruned after x height, and if so where in the code does this happen?

In Bitcoin Core (as of 0.19.1) they are not pruned unless pruning is enabled in general (in which case they're pruned along with all other blocks).

They are indeed superfluous, but they're also cheap to keep. Stale blocks are assumed to be rare (if they're not, the network has bigger problems), and if disk space is an issue in general, pruning should already be enabled.

Note that only blocks with verified PoW and a chance to be part of the best chain are actually downloaded and stored. This means that exploiting stale block storage as a DoS attack is incredibly expensive.


What are some pitfalls of having 1 minute blocktimes? What vulnerabilities would this introduce? For example, dogecoin has 1 minute blocktimes and they seem to be doing fine for the past 5 years. What are some issues they might run into with 1 minute blocktimes and increased adoption? What other downsides does something like dogecoin have vs bitcoin, in relation to a shortened blocktime?

Shorter block times hurt decentralization

because they hurt smaller mining pools
because smaller mining pools depend on orphaning rate more
because orphaning rate depends on the number of competing blocks in unit time

since network connection quality becomes more important with higher orphaning rate

and of competing blocks, the larger miner with better connection is more likely to win

because the number of competing blocks in unit time depends on the number of blocks in unit time

Bitcoin has 6 blocks per hour. Doge has 60. Doge would have more competing blocks. In the end, larger miners are more likely to unfairly (i.e. not proportional to hashrate) win with the competing block. Hence longer block times means fairer block reward distribution to pools.
Unfair: Larger pools get larger more easily, smaller pools can't achieve their fair potential and would lose some % of their blocks hence their rewards and might not be able to compete.


How to use my own web hosting server to mine a bitcoin? I have a web hosting with unlimited bandwidth and unlimited disk space, Cpanel and much more. Can anyone guide me. How to mine a bitcoin by using my own web hosting?. Then there is any mining software is available to install into my web hosting?. please anyone help me to find out the solution.

Note: I am not consider the hash rate and money. If it is possible I will try otherwise i am not doing anything?

Thank You!

It's as simple as sshing into your server and installing a bitcoin miner such as this one. A server is just a computer and a bitcoin miner is just a program so as long as you can install programs via a terminal you should have no problem and any old getting stated bitcoin mining guide should work.

That being said, this is generally not a good idea to do. Bitcoin mining has gotten to the point where to be cost effective you have to use custom built chips. This means that if you mine bitcoins on a regular old web server making use of the CPU or even the GPU, you will loose money on electricity + server costs.

If you truly do have unlimited free webserver time, then hell, go for it, but understand that this is a net capital loss, your just externalizing the cost to your server provider.


Bitfinex get Trading Fees via API After placing a market order, I got its order_id & checked its status via this end point /v1/order/status and I got the following:

Array
(
[id] => 18141116927
[cid] => 43611135723
[cid_date] => 2018-10-17
[gid] =>
[symbol] => iotusd
[exchange] => bitfinex
[price] => 0.51251
[avg_execution_price] => 0.51234
[side] => sell
[type] => market
[timestamp] => 1539778090.0
[is_live] =>
[is_cancelled] =>
[is_hidden] =>
[oco_order] =>
[was_forced] =>
[original_amount] => 20.0
[remaining_amount] => 0.0
[executed_amount] => 20.0
[src] => api
)

In this array, I don't see exchange fees for this order. Also the above order is closing a margin position and I was expecting to see fees associated to margin like borrowing costs etc.

How do I get these information via API?

Thanks

Here is the endpoint where trade fees along with order_id and fee_currency are included https://api.bitfinex.com/v1/mytrades

Array
(
[0] => Array
    (
        [price] => 0.53018
        [amount] => 20.0
        [timestamp] => 1539786993.0
        [type] => Sell
        [fee_currency] => USD
        [fee_amount] => -0.0212072
        [tid] => 301116948
        [order_id] => 18151111432
    )

[1] => Array
    (
        [price] => 0.5317
        [amount] => 20.0
        [timestamp] => 1539786941.0
        [type] => Buy
        [fee_currency] => IOT
        [fee_amount] => -0.04
        [tid] => 301116560
        [order_id] => 1815111391
    )
)

This endpoint can also accept limit_trades parameter to limit the number of results returned. Then use foreach loop to get to the required order_id & retrieve the trade fee. Not sure why bitfinex has chosen to make it complicated, this information should be included with the "order status" endpoint.


Eloipool only public Server avaiable Maybe a simple answer

From what I can research so far

Is Eloipool the only public Server avaiable that is not parked or deprecated and that has support for the ASIC chips using stratum  ?

Is there any support for Non Linux based solutions ?

Thanks in Advance

(I can take it Doc give it too me straight) :S

Eloipool & Stratum (Slush) seem to be the only active devs that will support the new ASIC chips and move away from the Getwork method.

Going to port an IronPython Version of Stratum :D

Use this as an educational process & maybe one day get a C# version to support the large body of .NET programmers out there

Thanks to Slush & Luke Jr


Namecoin Offline Wallet Generator I want to keep some NMC offline. Is there a way to generate an offline wallet like bitaddress.org that I can run on a live CD, generate wallet and keep offline?

I'd check out the python library Coinkit - it's for generating cryptocurrency wallets (Bitcoin, Namecoin, Litecoin, Peercoin, Primecoin, Dogecoin and a bunch of others are currently supported).

Just do "pip install coinkit".


Generate QR Code tesnet I would like to generate a bitcoin paper testnet wallet.
A paper wallet is a QR code of a private key and a QR code of a bitcoin testnet address, I assume it can be generate juste like this link does : https://api.qrserver.com/v1/create-qr-code/?size=150x150&data=privateKeyOrBtcAddress

But when I'm trying to read it via Testnet3 android app, funds are not recognized. When I read the QR Code from a QR Reader app, I see correctly the content (privateKey for instance).Should I conclude that the application has a problem with this feature or did I miss something ?

Here is an example of taking a 256-bit hex-encoded private key and creating an uncompressed Wallet Input Format (WIF) private key for testnet using the libbitcoin v3.0 bitcoin-explorer (bx) command line interface. bx sub-commands manual pages are located on the right column of its Wiki

% echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | bx base58check-encode -v 239

91avAoeY5k21BDnfaHNLv63frRJhn5RmnEw4XgcsbfpWxPg1A9N

Similarly, here are the results for the associated  compressed public key.  (Note by convention that "01" is tucked on to the private key.)

echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff01" | bx base58check-encode -v 239

cMahgGtgBvsRn7SZFuFCuKGnV8H8yxYLegVcaRsLL2LjD6WFLuAg

More details for using bx for altcoins can be found at Altcoin Version Mapping.  There is a table up top of the wiki that provides insight as to why 239 and 111 are used as versions in bx commands above and below.

Use what ever QR-encoding mechanism you like (e.g., QRencode and encode either 91avAoeY5k21BDnfaHNLv63frRJhn5RmnEw4XgcsbfpWxPg1A9N or cMahgGtgBvsRn7SZFuFCuKGnV8H8yxYLegVcaRsLL2LjD6WFLuAg, but remember the following 256-bit hex encoded private key

0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff

is one of the worst private keys ever... but makes the point real clear we have a 256-bit hex-encoded key.

Be aware if the funds are deposited to an uncompressed public address and you provide the private WIF key for a compressed address an import or sweep is not likely to work.

The uncompressed public address for the very simple private key can be found by:

% echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | bx ec-to-public -u | bx ec-to-address -v 111

n2nkn4KFNtNbu6Q6GQPZwNZWDiiNsmm9d8

Similarly, the compressed public address can be found by:

% echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | bx ec-to-public | bx ec-to-address -v 111

n47QBape2PcisN2mkHR2YnhqoBr56iPhJh


What is a private key and a public key? What exactly is a private key and public key in relation to Bitcoin? What are they, how are they used, and how does one find out what their private and public keys are?

Both of the keys are a part of the Elliptic Curve Digital Signature Algorithm. A private key is just a random number, while the public key is a 2D point coordinate on an Elliptic Curve derived from it. The private key is used to sign messages (in case of Bitcoin - the transactions), and the public key is used to check whether the signature is correct. The public key can either be used raw in a transaction, or turned into a Bitcoin address by means of hashing and other operations.

One can use any library that supports the ECDSA curve used by Bitcoin (secp256k1) to generate the appropriate keypair. There are some online solutions for these tasks, for example my small testing suite website.

However, most commonly one leaves key pair generation to the Bitcoin program. If needed be, the private key can be retrieved from the program by using dumpprivkey Bitcoin API call.


How is hash160 calculated from an unseen public key? I was looking thru Block explorer at an address with a balance.  It has never been spent from thus the public key is unknown.  If the public key is unknown, how can Block explorer calculate the hash160 of the public key?

Because an address is the Hash160 (=RIPEMD160(SHA256(x))) of the public key. The transaction output lists that 160-bit hash directly.

When redeeming such an output, you provide both the public key (which must hash to the value given in the output) and a signature (which must be valid for the given public key).


What happens once the mining reward gets cut in half? Sometime around the end of 2012 the mining reward is expected to be cut in half from 50BTC/block to 25BTC/block.

What effect will this have? Doesn't this mean that it will be less economic to run a Bitcoin miner? Will the hashing power be severely reduced? Will BTC prices soar (or alternatively, crash)?

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

http://www.BitcoinClock.com

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

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

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

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

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

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

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


Is Bitcoin deflationary and inflationary at the same time? I was wondering as Bitcoin is represented in the public and media as a deflationary currency (for more adept media as payment protocol). Is it really deflationary?

Deflation is described on Wikipedia as:

  In economics, deflation is a decrease in the general price level of goods and services ...
  This allows one to buy more goods with the same amount of money over
  time.

Inflation is described on Wikipedia as:

  Economists generally believe that high rates of inflation and hyperinflation are caused by >an excessive growth of the money supply.

At the moment there is really an excessive growth of Bitcoin supply - in the past 4 years there was mined over 12 millions of bitcoins and will continue
 with every block rewarded by c. 2140 when all bitcoins are expected to be mined. So there will be only transaction fees as block rewards, which will  end the growth of the units supply.

Can we consider Bitcoin as inflationary and deflationary currency until 2140, because there are still new bitcoins generated until c. 2140?

The keyword is "excessive".

Inflation can be related to the supply of money with the quantity theory of money:

MV = PQ

Where M is the supply of money, V is the velocity of money, P is prices, and Q is production, all taken as the temporal quotient thus geometrically added.

Prices can only go up or down.  Judging by the exchange rate, prices in terms of BTC are deflating as no one would pay 3 BTC for a gallon of gasoline as they would at the beginning of 2012 or so; now, they would pay 0.0003 BTC.

Price are deflating because demand for bitcoin is rising as evidenced by the skyrocketing velocity.

So even though the supply is growing, it is not excessive because velocity is growing so much faster.  Actually, the supply of bitcoin should've grown faster during this period, but it is not programmed to do that.

No cryptocurrency is currently programmed for perfect price stability.


How much does the weight of 2-of-3 multisignature inputs differ between P2SH and P2SH-P2WSH? I'm trying to calculate the weight of a 2-of-3 multisignature P2SH-P2WSH input. I found the related question Predict multi signature transaction size, which I've calculated with m=2, n=3 here:
pubkeySize=33
sigSize=72

SizeOfRedeemScript = 1+n*(1+pubkeySize)+1+1
// 2-of-3: SizeOfRedeemScript = 1+3*(1+33)+1+1 = 105

SizeOfScriptSig = 1+m*(1+sigSize)+SizeOfPushDataFor(RedeemScript)+SizeOfRedeemScript
// 2-of-3: SizeOfScriptSig = 1+2*(1+72)+2+105 = 1 + 146 + 2 + 105 = 254

sizeOf(input) = 32+4+SizeOfCsuintFor(SizeOfScriptSig) + SizeOfScriptSig + 4
// 2-of-3: sizeOf(input) = 32+4+3+254+4 = 297

The size of 2-of-3 input in P2SH has 293 to 297 bytes1. Thus, this  would correspond to up to 297*4 bytes = 1188 wu.
How would I calculate the corresponding weight for a 2-of-3 multisignature P2SH-P2WSH input?

1Note that if both signatures are 71 bytes, the scriptSig is 252 bytes which as a length can be encoded in 1 byte, but in the worst case both signatures are 72 bytes and the length of the scriptSig needs 3 bytes.

To calculate the block weight, you need to know the size in bytes of the non-witness data and the size in bytes of the witness data.

With a P2SH-P2WSH input, your scriptSig will always be 35 bytes. This makes the size in bytes of the inputs to be 36 + 35 + 4 = 75. The witnesses contain your signatures and scripts, so the witness for that input will be 1+m*(1 + sigSize) + SizeOfVarIntFor(RedeemScript) + SizeOfRedeemScript. For a 2-of-3 multsig input, you will thus have 1 + 2*(1 + 72) + 2 + 105 = 254 as the size in bytes of your witness.

The formula for calculating block weight is base size * 3 + total size. The base size is the size of all non-witness data, so your base size is 75 bytes. The total size is the size of all data, including witnesses, so your total size will be 75 + 254 = 329. Plugging this into the formula gets 75 * 3 + 329 = 554. Thus the weight of the P2SH-P2WSH 2-of-3 multisig is 554.

*Note that SizeOfVarIntFor(RedeemScript) is actually two bytes because you need to use OP_PUSHDATA1 since the length of the redeemscript is longer than 75 bytes.


Have any books has been written about Ripple and Litecoin? I buy some ebooks about cryptocurrency, bitcoin and blockchain from
http://sacredtraders.com/index.php/product-category/crypto-book

Have there been any books written about Ripple and Litecoin?

I found a few books on Amazon that may interest you.

Ripple Book

Generic book explaining Ripple

Litecoin

These books can be very generic.
For understanding the technology, I would recommend that you read the white-paper (yellow-paper if super interested).

Whitepaper-Ripple

Solutions using Ripple

Ripple whitepaper explained

Video Resources

Ripple consensus algorithm explained

Litecoin explained by its founder

P.S. As of writing this answer, there's no official whitepaper for Litecoin, as it is a fork of Bitcoin and uses similar underlying technology with the claims of being faster than its predecessor.


How would this double spend attack be prevented? I know, that a user cannot create a fork in the chain.

Also, it is said, that since every transaction is publicly announced, any attempt of double-spend on the same chain would be rejected as the network would know that these bitcoins have been spent previously in the chain. But how would the network determine, that these bitcoins have been spent previously because, the identity of payer and payee is not known? Only the newly created addresses are known at time of spending which can be later changed during double-spend.

For example, if Alice sends 10 BTC to Bob using 0000ab578c4 as her address and this forms part of 50th block in block chain. Now again she spents 10 BTC to Bob using another address 004325bda in the 67th block of same chain, how would the network determine that this is a double spend? (No one knows to whom 004325bda belongs).

Transactions create Unspent Transaction Outputs utxo. UTXO are uniquely identifiable. UTXO are indivisible, they are destroyed completely, when money is spent from them. (Which is why you need to send change back to yourself.)
Naturally, this also means that you cannot chose what address you send money from, in fact the "sending address" only exists implicitly by being the address that received the funding payment.

So, putting all this together, whenever someone tries to spend money, the network's nodes check if the corresponding UTXO are available to be spent, i.e. listed in the set of UTXO.

If somebody tried to spend money twice, the UTXO would have been consumed by the first transaction already, and would therefore no longer be listed in the set of UTXO.


Where are the exchange keys kept? Following what happened in Kucoin, a doubt arises.

Where are the exchange keys kept?
Are HSMs not used for key storage?

Most of the exchanges divide their funds into hotwallets and coldwallets. Hotwallets usually are made of one bigger aggregate-address known publicly and a set of deposit addresses assigned to specific users.
When it comes to coldwallets the case is pretty easy, usually it's a hardware wallet or hardware wallet multisig scheme which exchange only uses manually or through some watch-only features.
When it comes to hotwallets, a lot of exchanges have multisig schemes or just API access to services of external vaults, like Bitgo, or Casa. Mostly because security of hotwallet isn't that trivial. Many exchanges decide to work with their own custody solutions and many times it doesn't work that well.
There are some solutions though, which are both fairly cheap and dosn't require external service fees, but fairly secure, like the multisig scheme with coldcard wallet (CKbunker) that aims to automatize spending rules.
It's important to notice that even that most of the cryptocurrency exchanges are under scrutinized regulations, these regulations aren't there to protect the users, but to enforce the possible exclusion of some parties from using the cryptocurrencies.


Upgrade from Bitcoin QT 0.8.5 to latest Bitcoin Core 0.15.X I bought and transacted BTC in 2013/2014.  I had a Bitcoin QT 0.8.5 wallet.  I plugged it in and it updated correctly to the latest block.  It correctly showed my BTC balance.  I made a transaction without enough fees, which has sat unconfirmed for weeks now.  I decided to upgrade to the latest Bitcoin Core wallet and so downloaded it, checked the Checksum, and then loaded it.  I swapped out the wallet file with my backup of my original wallet.  For some reason, it only shows about 1/1000th of my BTC holding.  I have got the blockchain completely up to date.  There are no other transactions showing, only those I have made.  I have gone back to QT 0.8.5 and it still shows the correct balance when the blockchain updates.  What am I doing wrong in the latest Core version?

Go to Bitcoin 0.8.5 Console Window and run :

dumpprivkey "myaddress"

Then in bitcoin 0.15.1

 importprivkey "mykey"

if you don't need to unlock your wallet even if it's encrypted since you are using Bitcoin-qt not RPC commands and you've already set your password when you started it.

if you don't want to use bitcoin-qt. go to terminal and run on v.8.5.0:

unlock your wallet if encrypted

(space)bitcoin-cli walletpassphrase "passphrase" timeout

Get private key of any address:

(space)bitcoin-cli dumpprivkey "myaddress"

if your wallet is encrypted run:

(space)bitcoin-cli walletpassphrase "passphrase" timeout

Then go to the latest version and run:

 (space)bitcoin-cli importprivkey "mykey"

The space before the commands is important to the command will never be saved to logs.


What's the relationship of Bitcoin addresses to public keys? A Bitcoin wallet can handle multiple private keys.  In ECC, you can have 2^256 private keys, and for each key, you can have 2^256 public keys.  Assuming that's right (please correct me if I'm wrong), you generate a Bitcoin address basically by hashing a public key with a RIPEMD160 hash function, which can produce 2^160 different addresses.

Is the relationship between the Bitcoin address and the public key 1:1 (one address for each public key)?  If not, how is it possible to connect more than one address to a single public key, since this "connection" is made through hash functions and the hash for one entry (the public key) doesn't change unless you change the entry itself?

Thanks in advance.

you generate a Bitcoin address basically by hashing a public key with a RIPEMD160 hash function,

You use HASH160, actually. HASH160 is RIPEMD160(SHA256(x)).

This is a good resource for learning how to transform a private key into a Bitcoin address: https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses

  how is it possible to connect more than 1 address to a single public key

The compressed and uncompressed versions of an address hash to different values. That's one way that the same key could hash to two different values. There are also Hierarchical Deterministic wallets that allow you to take a single key, and derive many different subkeys from it, all of which have different addresses.

It's also not 1:1 in the sense that it's theoretically possible to create two different public keys that hash to the same value.


ScriptHash from bitcoin address with BitcoinJS I need to interact with Electrum server API, in order to get UTXOs of a bech32 address.

Electrum doesn't support bech32 but supports searching by ScriptHash, which is  be obtainable from an address.

I think that the name ScriptHash is a little ambiguous here (i think locking script hash can make more sense)

So how can i get the scripthash from the address as in the following example using bitcoinjs :

       {'priv': 'L8g5V8kFFeg2WbecahRSdobARbHz2w2STH9S8ePHVSY4fmia7Rsj',
        'pub': '03e9f948421aaa89415dc5f281a61b60dde12aae3181b3a76cd2d849b164fc6d0b',
        'address': 'bc1qqmpt7u5e9hfznljta5gnvhyvfd2kdd0r90hwue',
        'minikey': False,
        'txin_type': 'p2wpkh',
        'compressed': True,
        'addr_encoding': 'bech32',
        'scripthash': '1929acaaef3a208c715228e9f1ca0318e3a6b9394ab53c8d026137f847ecf97b'}

Got the answer via github

let script = bitcoin.address.toOutputScript(address)
let hash = bitcoin.crypto.sha256(script)
let reversedHash = new Buffer(hash.reverse())

console.log(address, ' maps to ', reversedHash.toString('hex'))

Note that -for some reason- Electrum uses the reverse scripthash


Transaction still unconfirmed I sent some money 3 hours ago my BTC client (Bitcoin Core) still says the payment is unconfirmed ?.
Any help much appriciated

This could happen for two reasons:

1 - You did not included tx fee in your transactions so the priority of your tx is lower than the ones which paid for transactions network fees. You can check this simply using your TX ID on a block explorer like www.blockchain.info. You will see which is the priority for your transaction and the status of it in real time.

2 - The other reason could be that, as Murch suggested, the network has been over stressed for some reasons and this takes some txs to take more time to get confirmed. However this happens rarely and you should always check the first option before.


What is the difference between Bitcoin Core and UASF? I am a little confused about what the actual difference is between Bitcoin Core and UASF, are they both only for SegWit?

If so who is then for SegWit2X?

Correct, core and UASF groups are both Segwit supporters (as are Segwit2x supporters).  Both core and UASF are against 2x.  UASF is just an attempt to force segwit if miners had rejected it (miners did not reject). I'm not really sure how they expect UASF could have been successful without hash power if miners had actually rejected Segwit.

I've seen some core supporters argue that UASF was reckless (would have disrupted non-Segwit nodes), so though the chains they support today are the same, the groups are not perfectly in alignment.  More details here:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014152.html

You can see who supports the New York Agreement (Segwit2x) here:

https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77

As stated in the link, they represent (at the time of the agreement):

58 companies located in 22 countries
83.28% of hashing power
5.1 billion USD monthly on chain transaction volume (likely larger now with higher price)
20.5 million bitcoin wallets

Most notable from my perspective are Bitpay, Coinbase, and the majority of miners.

Here you can also find those who supported the original Hong Kong Agreement from a year ago:

https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff

The original HKA failed.  Many who signed onto the HKA (e.g. Adam Back of blockstream and the core contributors) seem strongly opposed to 2x today, which is most of why it failed. The Segwit2x of NYA is in some ways an attempt to bypass those who agreed to pursue 2x a year ago but who actually ended up fighting it.

Opposition (the core devs, who effectively want to retain veto power) argue that giving in to miners/businesses gives them too much power.  Some from the 2x crowd argue blockstream & core are attempting to block capacity increases to force users into the lightning network. It's all rather political and there isn't much trust.  Ill will is taken for granted in most debates.

The HKA was a bit less committal ("This hard-fork...will only be adopted with broad support across the entire Bitcoin community") which I suppose is how the core team can say they aren't technically violating their word.

My impression is that these particular core HKA signatories are the primary driver of "the Bitcoin community" that opposed.  When it became clear that core had no intention of pursuing 2x and were actively fighting it, the initial HKA compromise no longer seemed relevant or in good faith -- i.e. activating Segwit would sacrifice any near-term opportunity for a meaningful capacity increase. Blocking Segwit became a tool to fight for a capacity increase. All this further fanned the flames of the rather toxic scaling/capacity debate.

Here's a list of companies tracked by coin dance that support or oppose segwit2x, though the data is a bit sparse. As of today 67% are neutral, 24% support, and 9% oppose. I don't recognize many of the "no" voting companies other than blockstream. They give the option to weight the votes by total web traffic (not perfect but gives some indication of relevance), bringing support to 44%, neutral to 56%, and opposition to nearly zero.

https://coin.dance/poli