Is the Bitcoin protocol secure if two parts of the network have no connection? I'm trying to understand the Bitcoin protocol, and I have a security scenario.

Let's assume that today between the internet connection between Europe and America is lost.
John is in Europe
John sends money to Henry while he is in Europe.

Then John saves his wallet to a CD and travels to America, were he uses another computer. The connection between Europe and America is still broken.

Can John send the same money to another Bitcoin client? In America nobody knows what John did in Europe.

If he can send the same money again in America, what will happen when America and Europe reconnect?

Edit after Murch's answer:

I have a new story, it is the same except for some little modifications.

John is a bad boy. He cracked Alton's router and put him into a fake network. This network includes some (fake) Bitcoin peers that don't have a connection to internet.
John, Alton and other peers are located in an isolated network.
John sends money to Alton. Alton and the other isolated peers confirm this transaction, but it is not confirmed in the global block chain yet. Now, Alton thinks that he has the money.
John takes his wallet and connects to internet. And sends the same money to his other account. This transaction is confirmed in global block chain.
John releases Alton's router, now Alton can connect to internet.
When Alton connects to internet he will see that his transaction is unconfirmed in the global block chain.

I think Alton needs a service to confirm that he had a real transaction and it is confirmed in global block chain.

Are there a service like this? I don't know do we really need a service to confirm transactions?

The direct effects of the netsplit

Miners in both the European network and the American network will continue to find blocks and validate transactions in their respective network part. However, until the difficulty will be adjusted, the validation will be slower, because the difficulty was set for a greater mining power than is available in each part of the world.

Let's assume that

2/3 of the mining power are in the Americas and 1/3 is in Europe
the hashing power remains constant (simplification) for the time of the network split
the network was operating at a previous block interval of 10 minutes in average before the split

Then the Americas should find a block every 15 minutes and the European network should take 30 minutes per block after the split. When the difficulty adjustment block is reached, both networks will return to creating blocks every 10 minutes in average. However, up to the adjustment the Americas will be twice as fast and thus their blockchain will be ahead significantly, specifically one and a half blocks for each block that had to be mined until the difficulty was scheduled to be adjusted.

John can spend his money again

When John goes to the Americas, the transactions sent in the European network have not been taken into account there. His wallet thus will still allow him to spend all the bitcoins that he had before the netsplit. He can now cheat Henry out of the money: John decides to send all the money to another of his own addresses.*

Reconnection: Shorter blockchain will be invalidated

Now, when the connection of the two networks is reconciliated, the American network's blockchain is longer (i.e. the total difficulty of the mined blocks is greater). All blocks in the European blockchain mined since the network split will be rejected by the American network, the European miners will retroactively lose their mining gains. The transaction John did in the Americas takes precedent, because it is part of the blockchain there and the transactions of the European network are just now readmitted to be validated by the global network. John's balance had already been sent to his other address, so the transaction that now tries to send the bitcoins to Henry is thrown out as invalid.

Alice, who had sent money to Bob in Europe, will see that her transaction (along with all others that were only seen in the European network) will go back to being unconfirmed in the new global blockchain (that is based on the longer American blockchain), because the block that had validated it in Europe has been obsoleted. The transactions that had been sent in the American network don't see any effect.

The global network will now find a new block every 6.67 minutes, until the difficulty is readjusted, because it had reduced the difficulty to fit the American miners' hashpower and is now returning to full power.

*However, if Gustav had taken his computer with him from Europe and connected it to the American bitcoin network before John arrived, Gustav could have submitted all transactions that had meanwhile occured in Europe to the American network as well, and John would not have been able to spend his balance again.


MultiBit won't open, says "Java not installed" My MultiBit wallet won't open, because "Java is not installed", though I have Java 8, 7u51, and 6u49 installed... Which version of Java should I have installed?

Define a JAVA_HOME environment variable with the path to your jre/jdk installation in it. That worked for me.


Full list of "special cases" during Bitcoin Script execution (p2sh, p2wsh, etc.)? When executing a Bitcoin Script, there are some "special cases" where the interpreter performs extra verification beyond just executing scriptSig and then scriptPubKey.
For example, if the scriptPubKey has the following specific format:
OP_HASH160 <20 byte hash> OP_EQUAL

then the interpreter will additionally apply the BIP 0016 "Pay to Script Hash" (P2SH) rules.
What's the full list of "special cases" that could be encountered during Script execution, and when is each encountered?

As of January 2021, "high-level" script validation with all active consensus rules on the network is approximately this:
Top level evaluation

Execute the scriptSig, and call the resulting stack stack. If execution aborts, fail.
Execute the scriptPubKey with stack as input, and call the resulting stack result. If execution aborts, fail.
If result is empty, or its top element has numerical value 0, fail.
If scriptPubKey is exactly equal to an OP_n (with n between 0 and 16, inclusive) followed by a direct push of exactly 2 to 40 bytes inclusive:

If scriptSig not empty, fail.
Run segwit validation with the scriptPubKey as program, the n value as version, and witness as input (see further). If this execution aborts, fail.

If scriptPubKey is exactly equal to OP_HASH160 + a 20 byte push + OP_EQUAL, run P2SH validation:

If scriptSig does not consists of only pushes, fail.
If result is empty, fail.
Interpret the top element of result as a script, and execute it, with the rest of result as input. Call the resulting stack p2sh_result. If this execution aborts, fail.
If p2sh_result is empty, or its top element has numerical value 0, fail.
If the top element of result is exactly OP_n (with n between 0 and 16 inclusive) followed by a direct push of 2 through 40 bytes inclusive:

If scriptSig is not exactly a direct push of the top element of result, fail.
Run segwit validation with the scriptPubKey as program, the n value as version, and witness as input (see further). If this execution aborts, fail.

If no failure occurred before this point, the script is valid.

Segwit validation
Segwit validation for version version, with program program, and input input:

If the version is 0:

If the program is not 20 or 32 bytes, fail.
If the program is 20 bytes hash:

Execute the script OP_DUP OP_HASH160 hash OP_EQUALVERIFY OP_CHECKSIG, with initial stack input. If execution aborts, fail.
If the resulting stack is not exactly one element, or that element has numerical value 0, fail.

If the program is 32 bytes hash:

If input is empty, or its top element's SHA256 hash does not equal hash, fail.
Execute the top element of input as script, with the other elements as input. If execution aborts, fail.
If the resulting stack is not exactly one element, or that element has numerical value 0, fail.

If no failure occurred up to this point, return success.

This answer does not include the changes introduced by BIP341 and BIP342, as these are not active on the network. It also does not include various standardness/policy rules.
Source: https://github.com/bitcoin/bitcoin/blob/v0.20.1/src/script/interpreter.cpp, functions VerifyScript, VerifyWitnessProgram, ExecuteWitnessScript.
TL;DR: only the BIP16 P2SH pattern (OP_HASH160 <20 bytes> OP_EQUAL) and the BIP141 segwit pattern (OP_n <2 to 40 bytes>) are actual special cases that trigger additional rules. But the details are more complex.


When does Blockchain.info show 127.0.0.1 as "first relayed by" for a transaction? Does this mean the transaction had to come from a Blockchain.info/wallet user (or perhaps someone using Blockchain.info/pushtx)?  Or could this indicate something else (e.g., a node from Tor even)?

Yes, It means blockchain.info broadcast the transaction itself. So it was either created using My Wallet, the merchant API or submitted through /pushtx. A live list can be seen here http://blockchain.info/ip-address/127.0.0.1

Mixer transactions are broadcast through separate nodes.


Exchange API - more frequent high and low value Any way to get high-low values more frequent than every 24 hours from say the Bitstamp API ticker? The link only tells you how to get the value for every 24 hours.

This also seems to be a problem with every other exchange I've tried.

These functions return the high or low over for the past 24 hours.  You can poll the API for this data as often as the API allows for (600 times over 10 mins according to your link). The data that it returns does only consider the past 24 hour prices however.  If you want to find out the high and lower prices over a longer time frame you will need to look at historical ticker data and determine the high and low values returned from the data set that you are requesting.


Automatic savings account using 2 wallets? Sorry if this has already been asked; Stack Exchange didn't have this exact question in the "related" field.

Let's say I have two bitcoin wallets. Somebody sends wallet 1 a transaction of 0.5 BTC.

What I am wondering is if I can take that transaction and create a new one, where I'm sending 0.4 BTC to that same address in wallet 1 with the original 0.5 BTC (the one listed in the "receive" data in the UTXO), and sending the 0.1 BTC change to an address in wallet 2.

I would think this is possible since the address in wallet 2 referenced as part of the second transaction would then have the funds available once the transaction confirms in the block chain.

I just don't know enough about Bitcoin's code to know for sure if this won't cause some sort of hiccup, as my general conception of "transaction change" is that an address local to the wallet, in this case wallet 1, is generated for capturing the change from the transaction to avoid overspending in transaction fees.

Using a separate wallet's address as the change may well break something in the code that accounts for the total balance of the first wallet.

This is why I need an expert to help me out here. Too many unknown outcomes for me!

I answered my own question.

I used the following PHP code...

$savings = 0.001;
$txfee = 0.0001;
$amount = floatval(($bitcoind->getbalance() - $savings) - $txfee); // getbalance() returns 0.005
$outputAddr = [
    '1GAnaq3atnKkxFsUC4Vky8Ysb751LbxHSC' => $amount, // wallet 1 address
    '122ExHr92bEgJbepSHmQCruCRR3YRR6dx5' => $savings // wallet 2 address
];

$rawtxUnspent = [];
$unspent = $bitcoind->listunspent();
foreach($unspent as $tx) {
    array_push($rawtxUnspent, [
        'txid' => $tx['txid'],
        'vout' => $tx['vout']
    ]);
}

$rawtx = $bitcoind->createrawtransaction($rawtxUnspent, $outputAddr);
$signedtx = $bitcoind->signrawtransaction($rawtx);
$senttx = $bitcoind->sendrawtransaction($signedtx['hex']);

$senttx === false ? print $bitcoind->error : var_dump($senttx);

and got this output...

string(64) "bae6d6978da7a50422a943ac42017c64478169ce87a264d7cedbaa5a869558b4"

The transaction is confirmed and worked exactly as I hoped. :)

https://blockchain.info/tx/bae6d6978da7a50422a943ac42017c64478169ce87a264d7cedbaa5a869558b4


Signature generation I am trying to unwrap bitcoin transaction generation process.

A bit confused about signing part.

My understanding is the transaction is sha256'd, then sha256'd one more time, then ECDSA'd.

Based off https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm, ECDSA will first hash the message. Does that mean the transaction is sha256'd 3 times in total?

All the best!

Johnny

No, only two hashes. The hash itself isn't typically described as a part of ECDSA though the input must already be hashed (because e.g. a signature of 0 is trivially forged).


How does one claim ownership of an NXT address? Apparently, NTX uses very short addresses and a very small alphabet. There is a system designed to claim ownership of a given address, but I couldn't find much information on it. How is it handled in the NXT system?

The first out-going transaction for an address claims the address. To make such a transaction, you need to know a private key for the address. The first transaction causes the corresponding public key to be stored against the address in the block-chain, and then subsequent transactions are only accepted if they have the same public (and hence private) key.

The addresses are 64-bit, which would probably take a few years to crack by brute force. The public and private keys are 256-bit.


electrum wallet listaddress without change addresses i use the command

  electrum listaddresses -w .electrum/testnet/wallets....

On a bash console to get all addresses of the wallet.
This however also return the "change" addresses which i cannot actually use on my project.
Is there anyway to filter those addresses on bash or i need to open the wallet file and read it?

There's command specific help with electrum help <commandname>. If you run that for listaddresses you will see that the --receiving switch does what you want. So electrum listaddresses --receiving.


I mistakenly deposit my BTC to my BCC address. How can i get it back? I intended to withdraw BTC from my Yobit.net account, and send it to my BTC address of HitBTC.com account.
But, unfortunately, by my critical mistake, I sent it to my BCC address of HitBTC.com account. This transaction already went through 6 confirms, and the message in Yobit.net indicates that transaction was completed, but there is no deposit in my BTC as well as BCC account in HitBTC.com
Because it's an address of HitBTC.com, I don't have a private key for that BCC address.
I sent e-mails to Yobit.net, and HitBTC.com, but haven't received any response yet. Is there anyone who know I can get my BTC back? Please help me.

You will need to contact HitBTC and ask them to correct it. In theory they have the private keys and can recover these coins in a way similar to splitting Bcash and Bitcoin in the first place, but prudent security practices may make this difficult for them to do.

You might also want to contact the creators of BCash and point out to them how this decision to use addresses which are indistinguishable from Bitcoin has caused you problems. This was a conscious choice on their part and has resulted in funds losses for a number of people, just as Litcoin's similar mistake years ago with P2SH addresses caused.


Is there a bot or service that buys a diversified portfolio of altcoins on a schedule? Is there a service or a script that just buys a mix of altcoins on a set schedule, like every week? Instead of trading, I just want to buy the top 20 coins by highest volume every week regardless of price.

You should be able to modify zenbot to do this. I have not used it , please use it at your own risk. It will essentially hook you up to one of the exchanges. You will need to figure out the top 10 ,perhaps using an external service or one of the API's for volume. All in all , i feel it is a risky proposition in a highly volatile market.


What sort of service is Bitcoinica? What sort of service is Bitcoinica (or was before it was closed)?

From the Bitcoin wiki:

  An exchange that enables leveraged speculation in its
  contract-for-difference (CFD) market against the Bitcoin to USD
  (BTC/USD) exchange rate.

  The service charges no trading fees but instead earns from the trading
  spread -- similar to how forex trading functions.

This was a powerful (and risky) service to provide to traders as leveraging allowed them to invest in more bitcoins than what they owned, and the contract-for-difference market allowed traders to take a position (gamble?) on exchange rate movements.

There appeared to be a strong appetite for such a service, because it grew in popularity very quickly - it was first mentioned on bitcointalk.org in Sep 2011 and by March 2012 was large enough to be holding BTC43,000 (when it was first hacked).


I sent $50 worth of bitcoins from coinbase wallet to bittrex wallet but received only a third of it in the bittrex I sent $50 worth of bitcoins from coinbase wallet to bittrex wallet but received only a third of it in the bittrex. Could someone please explain if the i will get more bitcoins later or did i just lose it?
This has never happened before as i have done this transfer previously as well.
It shows confirmed on coinbase but it still doesn't show all my bitcoins on bittrex wallet.

EDIT - i just found out that 66% was the fee they charged me. Why is that? They generally charge 0.25% but this is ridiculously high.

This is normal, Bitcoin's transaction fees are getting excessively expensive. That could be why altcoins like BCH are gaining popularity


Are the blocks in blkxxxxx.dat files ordered by block height? I'm parsing out de blockxxxxx.dat files for the bitcoin blockchain. Are the blocks ordered by height? So is the order of the data for everybody the same?

No, they are in the order by which your node received the blocks. This can be in any particular order as nodes receive blocks out of order during the initial sync. Furthermore, some nodes will receive and store blocks that become stale, while other nodes (particularly ones that come online after that block has been found) will not. So the blk*.dat files between two nodes are likely to differ.


When a new block is propagated, nodes validate from genesis block to propagated block? For example, I have a nth block and when n + 1 th block is propagated, i have to compare with n+1 block's previous hash and nth block's hash for validation. It is pretty trivial.

But do i have to compare hash value for validation from genesis block to n + 1 block?

like comparing 0 and 1, 1 and 2, 2, and 3 ... n and n + 1

One of the most famous pseudo block chain code in github
https://github.com/dvf/blockchain/blob/master/blockchain.py#L37, block is validated from genesis block.

Bitcoin use similar way to validate a new block?

Nodes do not validate blocks from genesis each time a new block is received.

During the initial sync, nodes will validate, at the very minimum, the headers from the genesis block upto the current chain head - this allows them to find the best chain (by amount of work done). They also usually verify the utxo set.

When a new block is received, simply validating it against the previous block hash and the current utxo set is enough, as your previous block is already verified, which means all blocks before that are also verified.

If you happen to lose your local copy of the chainstate and only have raw blocks left, then you would need to revalidate from genesis.


Is it possible to write a script, which can allow spend only own inputs except all of them? Let's imagine:
We have just one BTC address.
Users send some coins to this shared address. And can spend only own inputs.

P.S. If someone can provide some example script for this I'll be very thankful.

No, it is not possible for a script to be able to determine who "owns" the input (as in whether the input was created by Alice or by Bob). Scripts cannot look at things like the txid of the input it belongs to, the index of the output the input spents, or any of the output scripts. There is no facility in Bitcoin to do that. So no, such a script is impossible to do in Bitcoin.


litecoin transaction time without transaction fee I've sent 927 ltc from my wallet to btc-e but didn't left enough in my wallet to cover the 0.01 transaction fee. My litecoin wallet is showing 'this payment has not been transmitted yet' and it's been a couple of days now. How long is it going to take? Is there a way to cancel the transaction?

You may find the solutions offered here to be of help:

http://bitcoin.stackexchange.com/questions/23012/btc-stuck-with-zero-confirmations

see also:

https://code.google.com/p/bitcoin-wallet/wiki/UnstickLowFeeTransactions


How can I contribute content to bitcoincore.org? I want to contribute relevant quality content to bitcoincore.org that would be valuable to its readers.

The source code for bitcoincore.org (the website) is maintained via a GitHub repository. Content updates are proposed and reviewed by means of pull requests. Instructions for contributing to the website can be found in the repo's CONTRIBUTING.md.
Given that this question was tagged with "news", I am wondering whether the purpose of the bitcoincore.org website is clear. The above linked contribution guidelines state:

Content Policy
The purpose of the website is to be an official mouthpiece for the
Bitcoin Core project as well as be a resource for technical
information that has a direct impact on Bitcoin Core software. This
can include research, presentations, and developer blogs.
Where proposed content is about Bitcoin Core project policy, there
should rough consensus of the Bitcoin Core project maintainers as a
minimum bar and final decision is with the Bitcoin Core project lead.
via
CONTRIBUTING.md#content-policy,
retrieved 2020-06-27

News seems out of scope per these guidelines.


Need help with encrypted wallet.dat. I can't access it with my expected pass-phrase I created an offline wallet in 7/13 via a Ubuntu live CD. I recently imported the encrypted wallet.dat file into the bitcoin-qt wallet on Windows 7. Coins appeared. But, my expected passphrase is incorrect. At first I though I mis-recorded it or mis-typed it at inception. I have contacted a service to try to brute force it. However, I just went to restore and access my offline LTC wallet and same thing. Coins appear but passphrase is wrong. Same mistake twice seems pretty unlikely. Is there any other mistake I could have made that led to this? Please help me brainstorm.

Edit:
I think I figured out I may have done.

1. encrypted wallet
2. copy wallet.dat
3. change passphrase
4. did not make new copy of `wallet.dat`

First encrypted copy would not decrypt with the new passphrase. Unfortunately, at that time I would not have grasped the consequence of resetting the passkey (ie re-encrypting the wallet.dat) and not creating a new backup of wallet.dat.

Edit 2: As a follow up it was a passphrase issue (mistyped twice at encryption). I was able to discover the actual passphrase by using the ruby script from this thread https://bitcointalk.org/index.php?topic=85495.

See my post # 312 for the details if you need help solving this kind of problem. The folks in that thread are very helpful.

Much thanks to all who helped. It was a stressful and frustrating experience - from which I learned a lot. :)

As a follow up I was able to discover the actual passphrase by using the ruby script from this thread https://bitcointalk.org/index.php?topic=85495.

See my post # 312 for the details if you need help solving this kind of problem. The folks in that thread are very helpful.

Much thanks to all who helped. It was a stressful and frustrating experience - from which I learned a lot. :)


How do I check if an address belongs to my wallet using bitcoinJ? I'm using bitcoinJ and I want to verify if some of the destination addresses in a transaction belongs to my wallet when I receive a amount of bitcoin. How can I verify it?

you could check thepubkey hash in the transaction outputs

this code for exemple check if an adresse belonging to your wallet is in the output

    Address to= null;
        boolean tome= false;
        //from = tx.getInputs().get(0).getFromAddress();
        to=tx.getOutputs().get(0).getScriptPubKey().getToAddress(Constants.NETWORK_PARAMETERS);
tome= w.isPubKeyHashMine(from.getHash160());
        return tome;


What's the blocksize limit after segwit and how do legacy nodes deal with segwit transactions? Normally, I heard that the bitcoin blocksize is 1MB, but with the Segwit update the blocksize can be up to 4MB, so we should say that the blocksize is 4MB, right? Moreover legacy nodes only receive the input and output data of segwit transactions. How do the legacy nodes verify the validity of segwit transactions. The legacy node can verify it during propagation from a segwit node, but how does it work for propagation between two legacy nodes, where the segwit data is missing completely? Thank you

Segregated witness therefore takes advantage of this opportunity to raise the block size limit to nearly 4 MB, and adds a new cost limit to ensure blocks remain balanced in their resource use (this effectively results in an effective limit closer to 1.6 to 2 MB).

https://bitcoincore.org/en/2016/01/26/segwit-benefits/#block-capacitysize-increase

The maximum block size is 4,000,000 bytes (4 MB). This is because the block weight calculation is base size (in MB) * 3 + total size (in MB) = block weight (see BIP 141). Since the only units are MB, the block weight's only units are also MB, thus the maximum block size is the same as the block weight.

In theory, you can get pretty close to 4M, by having transactions that consist almost entirely of witness data. In practice, that won't happen for normal financial transactions, closer to 2M.
https://bitcoin.stackexchange.com/a/54949/

SegWit simply lets you verify non-witness transaction data without downloading (then discarding) the witnesses, which solves the problem of light clients having to download things they don’t care about and can’t verify anyway.

https://blockstream.com/2017/07/31/en-segwit-myths-debunked/

When Segwit transactions are sent to Legacy nodes the witness data is stripped. The key is that these “stripped” transactions are still valid transactions on Legacy nodes, which gives us a savings over non-Segwit transactions. Thus, more transactions can fit into the block sent to Legacy nodes without going over the 1,000,000 byte limit.

Segwit nodes get Segwit transactions and blocks that include the witness data using alternate network messages. The new network messages are defined in BIP144 as part of Segwit. The Segwit blocks which include the witness data can be over 1,000,000 bytes. Legacy nodes, as mentioned, receive the same blocks and transactions, but with the witness data stripped. This is a way to make Segwit a soft fork.
The Segwit blocks are restricted by something called Block Weight. Block Weight is a new concept introduced in Segwit, and it’s calculated on a per-transaction basis.
Each transaction has a “weight” which is defined this way:
(tx size with witness data stripped) * 3 + (tx size)
Segwit transactions are transmitted to Legacy nodes without witness data, so this formula will always result in blocks communicated to Legacy Nodes that are less than or equal to 1,000,000 bytes. Again, this is why Segwit is a soft fork.
https://link.medium.com/3lvCPzo5q9

Size vs Weight: What is block weight and how is it different from block size?


Why do self-loops exist in the bitcoin transaction graph? I have obtained bitcoin data from block explorer and created the transaction graph. The graph consists of millions of nodes and edges.

i wrote a query that creates a relationship from source address to destination address and visualized a portion of the network; approx. 4500 nodes along with 50000 edges. What this means is that I omit the nodes depicting the blocks txs belong to, nodes depicting txs etc.

The nodes in the graph illustrate addresses connected by a relationship " sent_money_to "

There are many self-loops. In several instances a node u has n out-links to node w, while the same node u has n self-loops.

By no means I am an expert on the graph properties or protocol of the bitcoin network.

Any possible explanations? Trivial or non-trivial.

Thanks.

You are looking at transactions the wrong way. Bitcoin does not actually use addresses and their balances. The protocol has no concept of what an address is, nor does it need to. It also has no idea of an address or an account balance.

Rather how Bitcoin works is with transaction outputs. Transaction outputs are spent as the inputs to other transactions, and created as the outputs of transactions. Addresses are merely a human abstraction to quickly specify the locking conditions (the conditions that need to be met in order to spend) of a transaction output. They are not an identifier, just shorthand for an output script.

Since addresses are just shorthand for an output script rather than identifiers, nodes do not care about the contents of the scripts except when verifying that an input has met the conditions to spend the output it specifies. Other than that, a transaction output can contain whatever the user wants in the script, including invalid scripts. Outputs with such scripts just cannot be spent.

So these self loops exist because people can create a transaction which spends an output with a particular script, and then they create a new output which has the same script. Because nodes don't check the scripts, this is perfectly fine and valid.


How can I import a private key into a pruned node? I am trying to restore my Bitcoin Core wallet, but I only have the private key and passphrase, I don't have a wallet.dat file.
I tried using
importprivkey privatekey xxxxxxxxxxxxxxxxxxxx

which gave me the error Rescan is disabled when blocks are pruned (code -4).
How can I import the key?

I think your choices are

Restart your Bitcore-core node with adequate diskspace and pruning mode disabled, wait for it to sync all over again and then use importprivkey or
Import or sweep your private key into a different wallet such as Electrum. Optionally transfer the money back to your Bitcoin-core wallet. This might be quicker but you won't get the full transaction history back into Bitcoin-core


Is it possible to run more than one client instance on a machine? Is it possible to run more than one Bitcoin client at the same time on the same machine? I tried to set different working ports, but it seems not to be working.

You need both a different RPC port (-rpcport), a different P2P port (-port), and a different working directory (-datadir).  You will also need to use the daemon (bitcoind) for everything after the first instance, since only one GUI can be running at the same time.


Do miners prefer RBF transactions over non-RBF transactions? Given a replace-by-fee (RBF) transaction and a non-RBF transaction with equal fees, do miners prefer the RBF transaction over the non-RBF one? Or is this entirely up to the particular miner?

It is up to the miner, but typically they do not care whether it is RBF or not. There's no difference to the miner whether they choose one or the other; the miner still earns the same amount in transaction fees.


What are the trade-offs between the different algorithms for deciding which UTXOs to spend? When someone would like to make a transaction, their software has to choose which of their UTXOs to spend. Here are a few different ways that one might prioritize which UTXOs get spent.

Oldest UTXOs first
Newest UTXOs first
UTXOs with the smallest amounts first
UTXOs with the greatest amounts first
The Core Client Selection Algorithm: What is the coin selection algorithm?
Others?

What the trade-offs are for the different ways of prioritizing spending of UTXOs? Are some faster? Do some make make the block chain less big (grow less quickly)? Do some make the UTXO set smaller? What about making it so that the user has to pay the least fees? Taking all these factors into consideration, is there a method that is generally accepted to be the best way?

On possibility, which I like, is to spend the most UTXOs possible while still staying in the 1kb minimum fee limit. That way if nodes that prune the blockchain of STXOs (spent transaction outputs), they can prune more and it makes the blockchain smaller for them. Although, this might cause a small amount of bloating for nodes who keep the whole block chain, so it's a tradeoff.

The challenge for picking a Coin Selection Algorithm is that there are multiple goals to optimize for:
Privacy
The Coin Selection should reveal as little as possible about the user's wallet contents.
Transaction Fee
One wants to minimize the current transaction fee, but also the overall long-term transaction fees.
Non-dust change creation
It would be preferable to create non-dust change.
Reduction of Dust UTXO
Dust UTXO have to be stored on all users' devices and therefore create data volume even on thin clients. It should be a priority to reduce their number.
Unfortunately, these are contradictory to one another, and therefore every solution must find an appropriate balance for itself.

Oldest UTXOs first (FIFO)
Good

Will use up dust UTXO as they come up in your transaction history.

Bad

Gives a date for the oldest UTXO the sender has in his wallet. E.g. reveals how long a user at least has been using Bitcoin (with that wallet), might even be used to guess the amount of bitcoins someone is holding by watching when he spends a known output.
Will not minimize the transaction fee.

Newest UTXOs first (LIFO)
Good

Reveals less information about your wallet than FIFO.
Most of your UTXOs see hardly any action at all (potentially good for privacy).

Bad

Grinds your latest UTXO to dust, until a newer is received or it is used up. Might generate a wallet full of small UTXOs.
At equal or more income than spending, dust will never be consolidated.
Will not minimize transaction fee.
Will link your recent activities by always reusing the newest change output.

UTXOs with the smallest amounts first
Good

Consolidates dust asap.
Continuously keeps number of UTXO at minimum in wallet.

Bad

Reveals lower bound of UTXO value in wallet.
Large input lists (especially as long as dust exists in wallet) cause huge fees and slow confirmation.
Links lots of addresses in your wallet together.
Can be exploited to increase your transaction fee, if people just send you low-value outputs.

UTXOs with the greatest amounts first
Good

Minimal transaction fees.
Likely to create non-dust changes.

Bad

Reveals upper bound of UTXO value in wallet.
Never consolidates dust.
Usually increases number of UTXO in network.

The Knapsack Selection Algorithm used by Bitcoin Core
Good

Often small transaction fees
Random selection of UTXOs seldomly reveals any information about the wallet.
May consolidate dust UTXOs at random.

Bad

Always aims for 10 mBTC change outputs.
With a lot of small UTXOs in your wallet, likely to cause big transaction fees.

(2014:) I have been looking into coming up with a better Coin Selection Algorithm, but haven't found one yet that significantly improves on the Core Client Selection Algorithm.
Here are some ideas to improve it:

When a UTXO is randomly selected, add all other UTXOs associated with the same address as well: less linking of transactions improves privacy, potentially consolidates UTXOs into fewer.
Instead of selecting the smallest change, one could aim to create a change of the same size as the spending target. Assuming that people mostly send useful amounts, this would create new UTXOs of useful value instead of the smallest possible changes as it currently does. It also makes it harder to guess what was the change and what was the payment.
Select UTXO set to minimize transaction fee, instead of minimizing change output.

Update in 2021:

Removed a few allusions to Coin Age Priority as transaction selection policy in block building which was removed in Bitcoin Core 0.12.0 in 2016.
Removed erroneous claim that spending multiple inputs from the same address is cheaper

Note that Bitcoin Core used the Knapsack solver as its only algorithm until 2017, but since then has added an improved algorithm proposed by the author of this answer.


Planning to build a mining rig im new to the digital currency scene. Im very interested in bitcoins and litecoins. I know about bitcoins a couple of months ago and how foolish of me not to invest in it.

Anyways, im interested in litecoins now as they are really easier to mine and they can also be mined using the CPU which on my computer is probably the best thing. this is my setup:
AMD Phenom II X2 550 3.1GHz (unlocked the 2 cores so bascially a quad core at 3.1Ghz).
4GB RAM
9800GT

Im actually thinking of setting up a litecoin rig, which has 2x 7850's but im really unsure about how much power that will use and what power supply i should buy (e.g. 600W or a 700W etc). Ive seen some videos on youtube about mining using the 7850 and this guy was mining using 2 7850's and he total power was about 850W which is pretty crazy (he did overclock and things like that). Im planning to mine on stock hardware meaning no overclocking so how much power in total do you guys think that will take?

But now i guess the news has gotten around about a ASIC litecoin mining machine coming up so no doubt the value of litecoins will increase and i want to take advantage of this situation.

So should I go for that rig with 2x 7850's or is there a better rig I can come up with that will use less power? (My budget is about £400. This includes the power supply, cpu, ram etc). Also, would it be better if I just buy the litecoins directly rather than mining them?

I also used this litecoin calculator to see whether I would be getting a profit/loss:
http://www.coinwarz.com/calculators/litecoin-mining-calculator/?h=650&p=450.00&pc=0.26&pf=0.00&d=2218.89256388&r=50.00000000&er=0.03408000&hc=0.00
I used the 650KH/s since I assumed at stock 7850, it would give about ~325KH/s. Since the gpu uses about 120W, i got the 450W from 2 7850s, the cpu, and some other electrical components (e.g. RAM, HDD etc). Since I live in the UK, the average price per kWh is 16p so thats ~$0.26.
What I dont understand is that on the summary where it says 'Days to generate one block mining solo: 169.69 days'. What does this actaully mean because bitcoins are harder to mine compared to litecoin but on that calculator, it says i'll mine a bitcoin in 99.59 days...

Also, where it says estimated expected earning, it says i'll generate  ~8 litecoins in a month but previously it said that I'll only be able to mine 1 litecoin in 169.69 days... Is this talking about mining in pools?

169.69 days you will get solo reward (keep in mind that it is not guranted, so it could take more days), I`m not sure how much it is now, e.g. in bitcoins now you get 25BTC for success solo mining. Earning table, that you see, definitly talking about mining pool.


Are there any privacy benefits in using a separate wallet in Bitcoin Core to separate myself from my service? I currently run Bitcoin Core with the following wallets loaded in:

hot.dat. Contains the smallest possible sum of Bitcoin. Unencrypted and used by myself for various personal Bitcoin purchases, and I intend to have it double as the wallet for my Bitcoin-based website. (Unless you tell me a good reason not to.)
lukewarm.dat. Contains more than the "hot" wallet, but still not much compared to cold.dat. Encrypted with a long passphrase, but which is located on the same computer in a text document. I recon that it will stop at least automated malware which simply checks for wallet.dats and merely "sends them home". It of course won't stop somebody from manually finding the text document on my machine and figuring out that it's the passphrase to use.
cold.dat. Contains the vast majority of my satoshis. Encrypted with a long passphrase (partially stored on the same computer) with a bunch of additional parts with "hints" to myself rather than explicitly spelled out. This passphrase has never been entered to unlock the wallet outside of the dedicated Linux computer where it was created. (Not this machine.)

I'm aware that many would not consider my cold.dat to be a "cold wallet", but I thought the naming scheme fit well enough. The reason I don't use a truly "cold" wallet (where it's not stored on a "live" computer even encrypted) has to do with me fearing losing the file or having a fire or getting it seized more than I fear somebody first hacking into my machine and then somehow figuring out my complicated passphrase scheme. I consider that so unlikely that it is far more likely that I would lose access to it in other ways.
Now I wonder if I should be having a separate "service.dat" wallet dedicated to my new service, or if I can just generate new receive addresses for my existing hot.dat and use those. Is there any privacy benefit in me doing that? Or would I just be wasting yet another transaction fee to send over some satoshis from my hot.dat to my potential "service.dat"?
What if somebody who I do private business with knows who I am (because I have to give them my home address) and when I've paid them using hot.dat, those "inputs"/"outputs" are reused for my service, and suddenly they can associate me, the individual, with my service? And would that change at all if I used a separate "service.dat" wallet for the service? Won't it be the same "track" either way?
It's not something illegal or immoral. I'm simply trying to avoid any association between myself and the service, plus I'm also curious about this in general.

Yes, it's good practice to use different wallets for different mental entities that you don't want associated. Two different wallets cannot be linked from blockchain data alone.
However, that doesn't mean they couldn't be associated by different means, say someone seeing you use both of them, or monitoring transactions that are first relayed by your node.


How to Bitcoin Core daemon start automatically each time your reboot your computer.? In the official document of bitcoin.org, they ask to use an init script instead of cron job, see the init scripts directory in Bitcoin Core’s source tree.

But the link is not working
Bitcoin Core’s source tree

Cron Job option

  @reboot bitcoind -daemon

I wanted to know the init script to restart a daemon

The init scripts can be found here: https://github.com/bitcoin/bitcoin/tree/master/contrib/init.


How do you import Block Chain from bitcoincharts? I went to http://eu1.bitcoincharts.com/blockchain/ and downloaded the most recent build. Then I extracted it and was left with BLK0001.dat and BLK0002.dat. What is the next step? I tried replacing the current BLK files with those and performed a -rescan but that gave me a BLKINDEX  error.

My wallet data was backed up by the way. Then I moved my BLKINDEX somewhere safe so it would have to create a new one but this process didn't work because it's building BLK0002.dat still. It was super fast until it reached about 70,000 blocks left and then majorly slowed down. What is the proper way to import it? Is there a special commandline parameter that I should use to fix this?

BTW: The whole reason I had to download it seperately was because Bitcoin Wallet was taking forever to download the block chain and was stuck around 97% for an eternity!

Thank you so much.

EDIT: Why does this guy even provide this website (noted above) if Blkindex needs to be created anyways.

EDIT: I gave up and decided just to use multibit and blockchain.info my wallet. I found a way to store my blockchain address on multibit so I could view it there offline.

If you are using the not-yet-released Bitcoin.org client v0.7, you can use the -loadblock=FILE to import the blockchain from the blk0001.dat file. [Update: actually need to do two of those inline, -loadblock=blk0001.dat -loadblock=blk0002.dat in order to get both to load.]

There is a blockchain with index through block 170,000 here:

http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/

That is the most complete distribution of the blockchain that I know of where the blkindex.dat is included.


Get Bitcoin Gold from paper wallet Now that bitcoin gold launched, I am looking for a way to get my BTG from the BTC paper wallet they were held at the forked block.

I know Coinomi works, but it only has an android app... any other that has a web or desktop app?

You can run Coinomi through the Google Chrome browser. You install the ARC Welder extension...
https://chrome.google.com/webstore/detail/arc-welder/emfinbmielocnlhgmfkkmkngdoccbadn

...which lets you run Android apps without an Android device. Download the required .apk (the wallet app) from https://coinomi.com/downloads .

Edit: I discovered this on this reddit thread:
https://www.reddit.com/r/BitcoinAirdrops/comments/7hc0qu/best_way_to_claim_bcash_from_old_core_walletdat/

which also has some possibly helpful tips.


Is there a way to tell which *coin is most profitable to mine? Basically a program that could run some hashes for all of the different hash functions that are used in the different big cryptocurrencies and then get the current difficulty from all of them. From there you can determine how many of those coins you could be mining and look up an exchange rate from there.

I was guessing that I should switch my GPU mining from bitcoins to litecoins, but I was just wondering if its worth it.

I was thinking about starting to write a small script to do this automatically if nothing like it exists.

This site allows you to compare the mining profitability of the various coins:
http://dustcoin.com/mining


Why a specific bitcoin value of a tx message appears in source IP address and then comes to same IP address as the destination address? Sometime back, I created two wallets on two distinct cellphones. I sent a specific bitcoin value (A bitcoin) from one cellphone to another one. During this process, I captured the entire traffic.

After that, I extracted all tx values and output addresses. I saw same value (A bitcoin) and its output address (Address B) in the output which was sent from Source IP address (my cellphone) to destination IP address. Also this value and address was sent to some other IPs.

I also saw that this value (A bitcoin) and its output address (address B) is in some tx messages which is sent from another IP address to my IP address (my cellphone). In another words, I see that the specific value and its address return to my address again. It should be noted that this is a spent value and is not an UTXO. Why does my Bitcoin transaction value and its address in some tx messages gets returned back to me?

Since you using wallets on the cell phone, I presume you are running a SPV node. SPV nodes verify transactions using a slightly different method that relies on peers to provide partial views of relevant parts of the blockchain on demand. In order to ensure that the transaction that you have sent has been confirmed in a block, your SPV nodes will use bloom filters and send that to the full nodes connected to it. Those full nodes will then test each transaction’s outputs against the bloom filter. Only transactions that match the filter are sent to the node.

In response to a getdata message from the node, peers will send a merkleblock message that contains only block headers for blocks matching the filter, a merkle path for each matching transaction and then also send tx messages containing the transactions matched by the filter.

It is this transaction that is sent again to the node is what you are seeing in the packet traffic.


What is the preferred way to denote orders of magnitude in BTC? If I have 36,235.97 BTC, would I shorten that by writing that I have 36.2k BTC or would I write 36.2 kBTC?

It seems that latter is proper for SI units, while the former is used more often for money, at least in the U.S.

I would write 36.2K BTC.

On the other hand, if I had 0.0362 BTC, I would write 36.2 mBTC.


Where can I find people willing to pay me in bitcoin for services? For those of us unable or unwilling to spend our native currencies on bitcoin, but willing to work for them. Where are the bitcoin-jobs(or micro-jobs) to be found?

CoinWorker pays Bitcoins for repetitive jobs such as identifying images that contain adult content, or rating search engine results.  It acts as a Bitcoin interface to the CrowdFlower network.


How does BTC, LTC, TRC ,etc Wallet implementations differ? If there are tools such as BitcoinSharp, to allow me to code up functionality such as a bitcoin wallet, how do i do the same for other coins?

As alot of the newer curruencies are based of litecoin, is it just network settings that change between each wallet type?

So my question is, What makes a BTC wallet different to a LTC wallet?

You are correct that the hex representations of the private keys and public keys are the same.

However, the difference between various cryptocurrency wallets lies in how the private keys and addresses are commonly displayed.

There is a preference for displaying private keys in "wallet import format" (WIF) and addresses in "base58check".

The first digit of these numbers is determined by what's called the "version byte".

For Bitcoin, the WIF version byte is 128 (resulting in WIF keys starting with a "5"), while the address version byte is 0 (resulting in addresses starting with a "1"). For Litecoin, these leading numbers change to "6" and "L", respectively.

Here is a table of version bytes and address prefixes: https://en.bitcoin.it/wiki/List_of_address_prefixes

And if you're interested in python code that can help you generate different types of wallets, without having to worry about version bytes, I'd check out the python library Coinkit (just "pip install coinkit").


How do I find the public key of a bitcoin address? I want to know the public key of my bitcoin address, (e.g. 13mtYzgprJuLUWw1EVWSPPuC88q7fGuSX1), how do I do that?

Get the private key of your address, then go to brainwallet.org, and switch the tab to Generator->Private Key, then paste in your private key. Your address should show up on the right. If it doesn't try switching it to Compressed. Your public key (in hex) will be the thing marked Public Key (SEC).


How an order fulfillment works I'm trying to understand how order fulfillment algorithm works from technical point of view.

Let's say I created an order to sell 0.8 BTC and buy 5400 XRP along with other orders to sell 0.35 BTC, 2.7 BTC, etc. On the other side, there are some traders who sell different amount of XRP to but BTC.

To be more specific, imagine:

trader1 wants to sell 0.8 BTC,

trader2 wants to sell 2.7 BTC
...

But there are no traders that are willing to sell exactly the same amount of XRP. There is a traderX who wants to sell 7000 XRP so in this case he may have a deal with trader1 and partial deal with trader2. However, this is not how all exchangers work, right? Usually all orders processed as a single transaction.

So how all these orders match to have a trading?
Any algorithm or code in any programming language would be very helpful. Thank you!

"so in this case he may have a deal with trader1 and partial deal
  with trader2."

This happens all the time in the markets. Majority of the people don't really notice this happen because the size of the trades are small enough relative to the liquidity of the market and get they get complete fills.

If you tried selling a huge amount, lets say, 1000000 XRP at a particular BTC price, you're likely not going to get a complete fill right away.

Another way to get a 100% fill is when some other trader places a market order bigger than the size of your limit order. In that case, the exchange will "eat through" your limit order and move on to the next best available order in the orderbook. Or may be there are multiple market orders that can be filled against your limit order, so your limit order gets filled as more and more market orders come through.

There's a lot to read about similar topics, search for order matching algorithms: https://stackoverflow.com/questions/13112062/which-are-the-order-matching-algorithms-most-commonly-used-by-electronic-financi


Where can I find a Windows binary of MultiCoin? MultiCoin is AFAIK the only GUI client that supports NameCoin. Is there a trusted Windows binary to be found?

I have been doing windows builds of multicoin-exp, but have not heard of anyone using them so don't keep it up to date unless I get a request usually.

http://www.wuala.com/jbw9/pub/Bitcoin/multicoin/MultiCoin-exp/src/bitcoin.exe/ is actually mutlicoin, however I am pretty sure this version only works with the config file that would have been compatible with .62 and needs to be updated for .63 now that we have passed block 19200.  I can update it if anyone wants it to be.


How many nodes is too many? Has anyone done the math on this?

For example, if we had 10’s of millions of nodes all connecting to 8 peers would there be some latency issues in propagating blocks across the network in the 10 minute block intervals?

The probability that 1 node is connected to another node will be 1 in 8, so if there were 10 million nodes, we can divide it in 8 block of nodes, every node will have access to one of the blocks.

The transaction takes less than 1 second to transfer from one node to the other, let suppose it takes 1 second, to make it easier.

On first second 8 nodes will be notified
On second 2, 8*8 = 64 nodes will be notified
On second 3, 8*8*8 = 512 nodes
Continuing this way, 8 seconds after the block is issued, a total amount of 16 million nodes can be notified of that transaction

So there is no problem with 10 minutes block, the problem arises when the block is for low times, like on some chains with 1 minute per block or less.


What are the different upgradeability features in the BIP-Taproot (BIP 341) proposal? What are the different upgradability features in the BIP-Taproot (BIP 341) proposal?
Why are there so many upgradability paths? Is there something an annex can do that a leaf version can't?
This question was asked by James Prestwich on Twitter.

There is the annex, leaf version, ext_flag, OP_SUCCESS, unknown pubkey
types and you could probably include the existing witness version too.
I believe that list is exhaustive.
The ext_flag isn't so much an extension mechanism in itself; more a
structure that permits safely reusing the sighashing code (as opposed
to needing a new tag or other mechanism for collision avoidance).

Leaf versions: for revamping script semantics
OP_SUCCESSx: for new opcodes, without coordinating new version
Pubkey types: for new sighash flags/cryptography without needing an explosion of new opcodes
Annex: for effectively adding new fields like nLockTime

Leaf versions were really only added because we had a few bits to
spare in the control block, and it seemed wasteful to reserve them.
They're mostly a convenience, I think, as OP_SUCCESSx can achieve the
same (add an OP_V2 etc).
As the annex isn't committed to by the scriptPubKey, it's more a way
to extend witness possibilities than it is directly a way to add new
semantics.
So is there something an annex can do that a new leaf version can't? I
think they're orthogonal.
For example, a feature where you could restrict a tx to only be valid
in a chain that contains a certain block hash. It can't be done with a
leaf version, as it's a sign-time thing. I believe the annex can't be
used to introduce new script conditions. A new leaf version could
introduce its own annex-like thing, but that wouldn't be able to apply
to old leaf versions.
The motivating example for the annex is this. Imagine a new opcode is
added that needs few bytes but has high CPU cost. You'd want a high
weight budget per such opcode, but that may require actually stuffing
the witness with dummy data just to get the necessary budget. Instead,
it would be nice if there could just be a marker on the input that
says "increment the apparent weight (and corresponding op budget) by
N", without taking N bytes. Logistically, it would be annoying if that
marker can only be parsed when the spent output is available. The
annex is recognizable without context, mostly by exploiting a thankful
coincidence about what set of witnesses is valid for v0 (first byte of
last witness stack item can only take on certain byte values). This, I
think, can't be accomplished with a new leaf version.

This question was answered by Pieter Wuille on Twitter.


i sent bitcoin from my coinbase account to my bittrex account but i used the Bitcoin cash address on accident I have sent bitcoin from my coinbase account to my bittrex account but i have used my bitcoin cash address from bittrex on accident, Where did my money go and is there a way i could access it thru chain block and if so how can i do that? Please help me out with this i'm fairly new to this and don't know what to do, How can i get my money back?

Thank you in advance

You can try contacting Coinbase and/or Bittrex, however when you open your bitcoin cash wallet on Bittrex it clearly says, "Depositing tokens to this address other than BCH may result in your funds being lost", so there's no guarantee.


Does port 8333 need to be opened as TCP_OUT or TCP_IN? Does port 8333 need to be listed in TCP_OUT in a firewall or in TCP_IN as well?

Port 8333 is only relevant for inbound connections. Opening it allows other nodes to start talking with your node.
That said, a Bitcoin node can fully participate in the network even if you don't allow inbound connections (to port 8333). It'll use outgoing connections, which start from random higher unprivileged ports and connect to port 8333 of another node. If you can allow incoming connections that's good for the health of the Bitcoin network, otherwise outbound connections are functionally equivalent.
Bitcoin Core can also offer a JSON-RPC interface on port 8332, so if you need that, act accordingly.


how a system based on a blockchain would deal with exponential growth of informations carried in it? I was reading this article about the difference between a blockchain and centralized servers and a question came up to my mind: if I understand well the difference stands in the fact that in a blockchain there isn't a centralized server that maintains online a version of the informations based on it and protects them from corruption. I'm thinking for instance about wikipedia. Every "miner" instead has a copy of the informations - of the blockchain - and that is why it is so difficoult to alter a blockchain.

But what if these informations, and with them the blockchain itself, became too heavy to be supported by little private servers? My question is how a system based on a blockchain deals with exponential growth of informations.

I hope to ask in the right place, if it isn't I beg your pardon!

Bitcoin's blockchain grows currently at the rate of one block every ten minutes on average, according to consensus parameters. That's not an exponential growth, but a linear one. At present this is well below the growth in storage capacity allowed for by Moore's-law.

If in future the consensus parameters were to change, either to make blocks more frequent or, larger, then the storage requirements are one consideration that would have to be taken in hand.

In 2009 we had the first 2.0 terabyte hard drive, by early 2018 it is expected that a 14TB HDD should be available.[1] The cost per Gigabyte has reduced from nearly $0.12 per GB in 2009 almost down to $0.02 per GB in 2017.[2]

If the cost in whatever terms of running a full node becomes too onerous then we would expect to see more SPV nodes and, SPV nodes connecting to full node servers i.e. Electrum.

  "Bitcoin wallets like Electrum have been using SPV successfully for years without any problems, and they save users the hassles of maintaining a full network node."[3]

SPV was discussed in section 8 of the original Bitcoin whitepaper.

rel:
[1] Wikipedia - History of hard disk drives - https://en.wikipedia.org/wiki/History_of_hard_disk_drives

[2] BackBlaze - Hard Drive Cost Per Gigabyte - https://www.backblaze.com/blog/hard-drive-cost-per-gigabyte/

[3] medium.com - Why Every Bitcoin User Should Understand “SPV Security” - https://medium.com/@jonaldfyookball/why-every-bitcoin-user-should-understand-spv-security-520d1d45e0b9


Is there any desktop notifier application for bitcoin prices? There's a nice C2DM push based notifier for android but I'd like to know if there is one for the desktop environment, ideally linux?

Does anyone know if one exists?

If you're looking for a solution which will run on linux, then there's always a the wget command:

wget -q -O - https://mtgox.com/code/ticker.php

You can run it in a loop in a terminal :)

Under the xfce desktop environment you could use the genmon panel plugin and feed it Mt. Gox's last trade data. Speaking of which, I think I'll do that myself. :)


How does the electrum wallet 'payto' command work Hello fellow bitcoin users,

I'm currently working on developing an application that takes advantage of the Electrum wallet in order to receive and payout to users of my service.

My application uses the built in json-rpc server from Electrum to communicate. I am able to accept and monitor incoming payments just fine with the request mechanism but I'm facing some difficulties in terms of paying out.

By running the 'electrum -h' from command line I see that I should be using the 'payto' command to make payments. I need to specify an address and an amount at minimum and then also a password if required.

In order to see what sort of response I'm expected I first tried this directly from the command line using 'electrum payto [BTC_ADDRESS] [AMOUNT]' and then I'm prompted for my password.

Also when entering an incorrect password I get denied (so this isn't the reason).

I enter it and receieve the following response:

{
"complete": true,
"final": true,
"hex": "01000000026a7bb00035a682b0c51b00f7e60673a7c9480d03f4653abdf96ee68d63503221000000006b483045022100d4f489641dd85084fe301cd186a4630e1301ae24e3e1c2e99a4ed06675bfd8e202203a9ad7c4c9e456f9d21b0e7c1e0210b65e5363f70a4d87cd27f39475cd0ab22d01210257682e6bebcd9c5a7735c3ea80c6454badbc3d2b0e9d86d875b455538b149fc0ffffffff0763798b137db5feb7ba5cef8de2c1234ccadd29effd0c2c97474f4af4c6218d000000006b483045022100c704edbdf075e29382303207c7f445a4f4d3779b70c7b4798f12a6d0c517b5df02205644c9f7f47910477e9e58971ccbcb80258959208c72b6ec95a21c59b23402420121022f55a3753a30d020a5e052592e1dc1b511968b4a91871debe6b9bc9bedc2f4bfffffffff0278500000000000001976a9148353defb1ecee68e5c21a99239e1ec041d675a8588ac50c30000000000001976a914700bcc46e4421238023727492f724d08c499673988ac00000000"
}

I was expecting perhaps a transaction ID but as the documentation for the API is lacking (or I can't find it more likely) I'm not sure what to expect. The payment is not executed by this command so perhaps I'm missing something.

TL;DR: How do I send bitcoin using Electrum from the command line?

Thanks

There is one more step to actually process the transaction, you have to broadcast it. What you have got is a signed transaction which you can save (& even send to someone else to broadcast).

The signed transaction can be broadcasted like this:

electrum payto <bitcoin_address> <amount> | electrum broadcast -

This will write the transaction to the chain. You can read more in the official documentation.


Where can I find RPC_User and RPC_Password for my Python Script? I'm still struggling with this to obtain "rpc_user" and "rpc_password" this is the Python Script

I did try others to fill in others network like Blockdaemon.com but it does not work, which is why I take off and leave it empty then I get the same error as per the snapshot below:

I have tried to find LocalHost to support this but it doesn't work even though via CMD and Ubuntu.
Any recommendation? Sorry again to inform I'm no expert in this as I'm a nerd who is still figuring out the way to solve this.  My GOAL is to able to Connect to any LocalHost for me to Post my Bitcoin Transaction.
Appreciate your guidance on this. Many thanks.

To use this library you need an instance of Bitcoin core!
If you start with Bitcoin I suggest you to run an instance of bitcoin core and understand how the config it. You can find a good start here!
In addition, to use the lib inside your question you can following the steps below:

Download Bitcoin core and run an instance of it, I suggest you to run Bitcoin core on testnet, because it is not a small instance of "real" bitcoin network
Config Bitcoin core with a conf that accepts the connection on RPC!
With the RPC username and RPC password, use your code to connect to the Bitcoin code RPC interface.

Good hacking!


Will the amount of "usable" Bitcoins eventually drop to zero? Let's assume that there is a non-zero probability that people lose their bitcoins, e.g. by forgetting their password. The amount of bitcoins these people possess will become "unusable" but still remain in the blockchain and contribute to the maximum quantity of 21.000.000 bitcoins.

Over time the amount of "usable" bitcoins would shrink more and more as people keep losing bitcoins. Will the amount of "usable" bitcoins eventually approach zero? What will happen then? Is there a mechanism to somehow recover lost bitcoins? At the moment I don't see such mechanism.

Lost bitcoin are protected by the same security that protects bitcoin in circulation or storage, hence lost coins are lost forever.

There are many ways of looking at this "dilemma", and its effects are different depending on the economic context, but coin loss/destruction is generally considered to contribute to the value of the remaining "usable" coinbase. Since the lost coins are permanently removed from circulation and become unusuable, the principle of Supply and Demand implies that the remaining usable coins will become more valuable.

In economics, this process is called deflation of money supply. It has the effect of increasing the value of each token. It is the opposite of inflation of money supply ("money printing"/quantitative easing) where additional tokens are created with the effect that each token's value is decreased as the pool of tokens grows in relation to available goods and services in the economy.

You might be interested in this detailed discussion: Inflation, Deflation, Money and Credit


If someone knows my bitcoin address, does this mean they can spend it or move it? What if I wrote down or saved a file with the address on and someone found it, can they take my coins?
How secure is it?

No. An address is designed to be given out so that people can send you money. You cannot spend Bitcoin by knowing an address, otherwise block explorers wouldn't be showing people's addresses. What is needed to spend Bitcoin are private keys. Those need to be kept secret and are never given out to anyone. One private key corresponds to one address.


Can payment from a P2SH address provide change to itself? In the gavinandresen Multisig Test test, could change have been redirected to the originating 3QJmV3qfvL9SuYo34YihAf3sRCW3qSinyC P2SH address for the multisig payments?

In Mastering Bitcoin by Andreas M. Antonopoulos, Chapter 5. Transactions the following statement is made, and I would like to know if it invalidate my question above: "Note that you are not able to put a P2SH inside a P2SH redeem script, because the P2SH specification is not recursive."

These two things are actually not related. There are no restrictions to address reuse in the protocol. You could get away with never using more than a single address ever (although that is not recommended especially for privacy reasons) and p2sh addresses are no exception there.

The redeem script encodes the conditions that have to be fulfilled in order to spend funds from an unspent transaction output (UTXO). What the sentence says, is that you cannot have a lock to another redeem script inside of a redeem script.


What are some of the risks of speculating on bitcoin value? Just like a commodity it is easy to buy and sell bitcoins. Current value is so much higher then it was just a few months ago it seems like a really great investment. Especially when you consider that there is a limited supply, and if bitcoins are widely adopted then the value could go up substantially.

However, looks can be deceiving in any investment, so what are some of the risks?

Volatility: The price of Bitcoins is fairly unpredictable. A speculator is basically trying to predict the future price of Bitcoins.

Security: A speculator generally has to trust his Bitcoins and currencies to an exchange, at least some of the time. That exchange could disappear or claim he transferred out his Bitcoins. When his Bitcoins are not in an exchange he has to store them in a wallet which is vulnerable to compromise.

Technology: Bitcoins could become obsolete overnight if some new, superior crypto-currency came out. This could start as a sharp drop faster than a speculator can react. He would then have to either take a big loss or risk a total loss.

Unknown Defect: There has already been one case where a software defect in the client forced the unwinding of many transactions. What other problems might pop up one day and negatively impact the speculator either directly (by causing him to lose Bitcoins) or indirectly (by causing his coins to lose value)?

Known Defect: A 51% attack, double-spend attack, or similar problem could cause the Bitcoin system to become unstable or could impact the speculator's transactions directly.

Legal: The legal status of Bitcoin trades and the tax implications are in many cases unknown and in all cases subject to change, particularly if Bitcoins become popular.

Physical: Since Bitcoins can be easily moved halfway around the world and are untraceable, if someone knows you hold a lot of Bitcoins, he could kidnap/rob you and physically compel you to transfer your entire stash of Bitcoins to him. This is much less traceable than currencies, and you may have a very hard time getting police to take you seriously. (You couldn't even prove that you had lost the coins as opposed to having transferred them to another wallet you control.)

Mistake: A speculator could make a typing mistake, especially while making a large number of transactions of different kinds, that results in a loss. A price or quantity could be entered incorrectly or someone else's Bitcoin address could be given as a destination for a withdrawal.


Cannot remote to regtest node with curl cmd - Empty reply from server Hi I'm new to rpc curl cmds and having some issues connecting to my regtest node.  I'm getting "empty reply from server" which makes me think it is connecting but something is misconfigured.
Looking through various threads here I found similar things but nothing that quite fit the bill, but apologies if this is something that has already been covered.
bitcoin.conf settings
# Options only for regtest
[regtest]
# datadir
datadir=/mnt/mydisk/regtest
# Listen for incoming connections on non-default port.(default: 8333 or testnet: 18333)
port=18444
# RPC allow all IPS (shouldn't have this on mainnet)
rpcallowip=0.0.0.0/0
# RPC bind IP
#rpcbind=192.168.86.30
# RPC port(default:8332 or testnet:18332)
rpcport=18443

my curl cmd returns
curl: (52) Empty reply from server

curl cmd
 curl --user xxxuser:xxxcookie --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getblockcount", "params": [] }' -H 'content-type: text/plain;'  http://192.168.86.30:18444/

I'm also seeing this in the debug.log but not sure what it means or how to fix
UPnP: ExternalIPAddress = XX.XXX.XX.XXX
AddLocal(XX.XXX.XX.XXX:18444,3)
AddPortMapping(18444, 18444, 192.168.86.30) failed with code 718 (ConflictInMappingEntry)
UPNP_DeletePortMapping() returned: 606

Also worth noting I have another regtest node and the 2 nodes are connected without issue.
Any help appreciated.

You are defining RPC port 18443 and attempting to connect to 18444 in your example.
There's no situation where you should attempt to rpcallowip to anything but localhost, don't get used to doing that or making systems which require it. There is no situation in which this is safe to do, even regtest can cause damage to your system.


Is creating a long password for my coinbase account enough to keep my bitcoins secure? I've made an account with coinbase and purchased some bitcoin. Only after to start reading people talk about getting hacked and how bitcoins are not secure unless you put them in a "wallet".To be frank this wallet stuff confuses me a bit, I rather just keep it simple and keep the coins directly in the place they go when I buy them, which I guess would be on the "exchange"? So I'm wondering If I create an incredibly long password for my coinbase account, Is this enough security to protect my bitcoins? Just "walletless" and in the hands of coinbase.  I realize if coinbase was hacked as a whole , there would be issues since they act as the bank basically. but aside from that is there really any risk leaving my bitcoin on their if I have like lets say a 45 character long password?

The long password will not help that much and is also likely difficult to enter. Much better enable 2 Factor Authentication with Coinbase (https://support.coinbase.com/customer/en/portal/articles/1658338-how-do-i-set-up-2-factor-authentication-) which gives you a second level of control.

If you have the wallet e.g. on the phone you have much more control on your funds and do not depend on the security implementations of Coinbase. Also does Coinbase have limits when moving funds which does not apply to your funds in your local wallet.

Often splitting funds in local and online wallets gives most flexibility and security so your eggs are not all in one basket.


Creating a multisig wallet with bcoin and receiving transactions I am trying to create a multisig wallet from two externally generated xpubs. The process I am taking is to create two multisig wallets with the two xpubs, add each others keys as shared keys and generating the multisigscript using keyrings. However, when I send testnet coins to the base58addr that I generate in the end, I do not see it coming to either of my wallets. Could someone kindly help me figure out where I am doing wrong? This is my code:

const wallet1_accountKey = "tpubDCe8iQEHFMvcm9WZsYZEd8h9dNvoDidS3y9EVkDzZZr59NcNF2n8ecfZWQkttDp6PWujaCUcXrptSoTKUuYjXp8fMKsz3wJvYpnpxsMQUbD"
const wallet2_accountKey = "tpubDDQHqrK6Xj7A9tfW2zkiZiBPs475QJ8EQ5obViboBxgA1BG5Ai1BnPqBWKTVf6ecEi8XoKK9WQP7GK5jYgdjaoegqBH1EvhVCx2PLc3Zgru"
const type='multisig'

const options_wallet1 = {
    ...
};

const options_wallet2 = {
    ...
};

const result1 = await walletClient.createWallet('wallet1', options_wallet1);
const result2 = await walletClient.createWallet('wallet2', options_wallet2);

// ADDING SHARED KEYS
const wallet1 = walletClient.wallet('wallet1');
const wallet2 = walletClient.wallet('wallet2');

const wallet1_account = await wallet1.getAccount('default');
const result3 = await wallet2.addSharedKey('default', wallet1_account.accountKey);

const wallet2_account = await wallet6.getAccount('default');
const result4 = await wallet1.addSharedKey('default', wallet2_account.accountKey);

// GENERATING P2SH WITH KEYRINGS
const wallet1_address = await wallet1.createAddress('default');
const wallet2_address = await wallet2.createAddress('default');
const ring1 = KeyRing.fromJSON(wallet1_address);
const ring2 = KeyRing.fromJSON(wallet2_address);
const pubKeys = [ring1.publicKey, ring2.publicKey];

const multiSigScript = Script.fromMultisig(m, n, pubKeys);
const base58addr = multiSigScript.getAddress().toBase58('testnet');

There may be a few misunderstandings around BIP32/BIP44 key derivation and bcoin wallet usage in particular. I re-wrote your script below to demonstrate how to use bcoin multisig wallets and manually derive multisig P2SH addresses from keys. If you run it, you should see all three output addresses are identical.

Here are a few things you need to know for this script to work:

To create a bcoin wallet from an xpub you must initialize the wallet as watch-only. Otherwise the account-key option is ignored, and a fresh master private key is generated for the wallet.
The public keys used in multisig scripts must be derived from the xpub (see BIP32 and BIP44). In this case, you need to derive the branch key (0=receive, 1=change)  and then from there derive the index key (0 in this case, incremented every time you need a new receive address)

Let me know if you have any other questions about bcoin!

'use strict';

const {WalletDB, HDPublicKey, Script} = require('bcoin');

const wdb = new WalletDB({
  network: 'testnet'
});

const key1 = 'tpubDCe8iQEHFMvcm9WZsYZEd8h9dNvoDidS3y9EVkDzZZr59NcNF2n8ec' +
             'fZWQkttDp6PWujaCUcXrptSoTKUuYjXp8fMKsz3wJvYpnpxsMQUbD';

const key2 = 'tpubDDQHqrK6Xj7A9tfW2zkiZiBPs475QJ8EQ5obViboBxgA1BG5Ai1BnP' +
             'qBWKTVf6ecEi8XoKK9WQP7GK5jYgdjaoegqBH1EvhVCx2PLc3Zgru';

(async() => {
  await wdb.open();

  // Create two watch-only multisig wallets
  const wallet1 = await wdb.create({
    m: 2,
    n: 2,
    watchOnly: true,
    accountKey: key1
  });

  const wallet2 = await wdb.create({
    m: 2,
    n: 2,
    watchOnly: true,
    accountKey: key2
  });

  // Add xpubs to each other's wallet's default account
  await wallet1.addSharedKey('default', key2);
  await wallet2.addSharedKey('default', key1);

  // Get receive address index=0 from each wallet
  const addr1 = await wallet1.receiveAddress();
  const addr2 = await wallet2.receiveAddress();

  // They will be the same
  console.log(addr1.toBase58('testnet'));
  console.log(addr2.toBase58('testnet'));

  // Now do it all manually...

  // Create HDPublicKey objects from xpubs
  const xpub1 = HDPublicKey.fromBase58(key1);
  const xpub2 = HDPublicKey.fromBase58(key2);

  // Derive public keys for each xpub (branch=0, index=0)
  const pubKey1 = xpub1.derive(0).derive(0);
  const pubKey2 = xpub2.derive(0).derive(0);

  // Construct multisig script with 2 pubkeys
  const script = Script.fromMultisig(
    2,
    2,
    [pubKey1.publicKey, pubKey2.publicKey]);

  // Create P2SH address from script
  const addr3 = script.getAddress().toString('testnet');

  // Will match the first two results
  console.log(addr3);
})();


The warpwallet challenge 2 here  you can find a public challenge aimed to brute force a brain wallet private key, derived from 8 char long [a-zA-Z0-9] passphrase with a salt of "a@b.c". Is it possible to adapt an hashing hardware to solve this? (Such as GPU)

Yes its doable, but you'd have to write your own custom implementation for scrypt and pbkdf2 hashing as warp wallet uses these 2 algorithms. If you can find a brute force tool for scrypt and pbkdf2 separately, you'd have to combine them somehow. Regardless, you'd have to code this up custom. That 20 BTC reward is worth 80k usd today.


Jump straight to the asset trading page on Ardor Ignis via a shared url link? Is there a way to jump directly to the asset trading page in Ardor without logging in? Just by using a shared url link.

Yes you can do it like this:

https://testardor.enchantaddress.com/index.html?account=ARDOR-XK4R-7VJU-6EQG-7R335&chain=IGNIS&page=asset_exchange&asset=16056551815000754623

Using the url parameters you can go directly to the page and asset.

Alot of the functionality is handled in the nrs.js file. Just search for "getUrlPara" and you'll see the various ways to get to a page via just a url without logging in.


Are there Ethereum API wrappers? I'm looking into developing some Go software on Ethereum and I'm wondering - are there any API wrappers around for Ethereum (something like BTCSuite's BTCRPCClient is for Bitcoin)? I know there is a whole Go Ethereum implementation, but I'm looking for more lightweight way of interacting just with the JSON RPC server, rather than interacting with the whole network directly.

Not yet.

We've just revamped the server side RPC internals in develop and are still ironing out some quirks. I can imagine we would soon-ish start working towards the directions of providing some Go client APIs, but we're not there yet. If you just need a few specific ones, they are relatively easy to implement (here's a few we needed for a hackathon last week https://github.com/gophergala2016/etherapis/blob/master/etherapis/geth/api.go).


Is Bitcoin a currency? This question seems to be asked every now and then when legal status of Bitcoin is discussed - Is Bitcoin a currency? What are the characteristics that would make it a currency, and what makes it different from the standard definition?

TL;DR Bitcoin already is a currency because it's a generally accepted medium of exchange among certain communities. As those communities grow and usage spreads to other communities, its strength as a currency solidifies.

This requires a little bit of history. I am not a numismatist, but I have studied this a little even before the advent of Bitcoin.

Currency is a set of things that are a generally accepted medium of exchange.

Throughout history, an accepted medium of exchange has been anything of value to both people involved in the transaction. Typically, these are physical goods that have some semblance of inherent usefulness and a degree of rarity. Also, there is typically a perceived finite supply of the thing. Lastly, the importance of portability is generally high: if it is cumbersome to carry enough of the thing to make daily purchases, it is less likely to be an acceptable medium of exchange because no one will want to carry it around with them!

So, I've set the stage for most world currencies: small, portable coins comprised of precious metals. The metals can be used in products and are rare in that it takes work to extract them from the earth. The supply is thus finite, until another deposit of the metal is discovered. That's when the overall value of the coin may drop compared to other things, but at its simplest explanation means that
the coin metal has become less rare.

This kind of coinage started organically. People could give each other a weight of metal and know what its value was to them. Eventually, as governments were established, governments would gather up all the metals they wanted by whatever means necessary, and then melt the metals in order to mint coins with an intended, consistent value because of their weight.

As the price of goods increased steadily, it was impractical for a person to carry a sack of coins, so someone contrived the bright idea of paper money, and later, a bank note.  These are simply a promise that a person can exchange that note for the coins related to it. Thus, this paper money or bank note used to be simply a proxy to more valuable coins or other forms of metal.

However, this is prone to interference by those who print the notes and the governments that oversee it all. Eventually, paper notes became backed by promises for coins and metals that didn't exist. So, the value of the notes in relation to the coins and metals decreased. Then banks stopped accepting notes in exchange for coins.

What resulted is called fiat currency, which has a value simply because some government declares it to have value. It actually more closely related to debt, but that's a complex subject for another question.

A chief problem of fiat currency is that a bank or a government can simply print more bank notes in order to create more money. This works in the short term, but any savvy person will realize the similarity of this to someone finding a new deposit of a metal. When there is suddenly more of something, what existed of that something is suddenly less valuable because it is less rare. This does not matter a whole lot when there is only one thing of value. When there are many things of value, e.g. silver, gold, platinum, diamonds, oil, other fiat currencies, the value of our something compared to those will be affected.

All of these things are usable as currency but some are more practical than others.

Bitcoin is similar, but more abstract. Bitcoin has no inherent usefulness: it's just data. It does have rarity: the supply is finite because only 21M coins can exist. The available supply is growing by the minute, but there will be a day when no more will be "found" there by halting its inflation in value. Instead, at that time, its value will begin to deflate as coins are permanently lost for one reason or another.

Bitcoin's inherent uselessness as a physical good -- data -- contributes to another factor: its portability. It's just data and we can sure store a lot of data in a small physical space. This property makes it almost infinitely portable. A billionaire could carry their life savings in their pocket on a Flash drive and no one else could have control of the physical thing that is their life savings.

Creating a currency when the physical thing has no inherent usefulness requires that initial participants assign a value to it. It's a fiat currency, but the value isn't controlled by any central authority. No central authority can create more of it. No central authority can destroy it. This is not to say that an authority cannot destroy it, because a government sure could pass laws to prohibit its exchange/possession/production.

In its infancy, Bitcoin has limited intra-economy value, that is, it has limited value as something that can be exchanged for payment for work or goods simply because not a lot of people have boldly decided to accept it with the hopes that they can spend it on something they need. This value grows daily as more businesses start and more people believe that they can spend what they accept in it.

Bitcoin at this stage is no different from arcade tokens, in-game currency, or Monopoly money used in schools to teach children how money works: it has a limited value to a limited audience. It is currency to those who participate in this limited audience, and its inherent value (not necessarily its value relative to other traditional currencies) grows as the audience grows.

To add another question to the original: How can the strength of Bitcoin as a currency grow? The answer is quite simple: use it! Find something to buy with it, find something to sell and accept it as payment. Keep this cycle going and get others involved.


Do all transactions have at least one output that contains at least one bitcoin address Do all transactions that are included in a valid block have to have at least one bitcoin address as part of their outputs (vout)?

I found this to be similar: Are Bitcoin transactions permitted to have no outputs (i.e. all inputs become transaction fee)? although not quite the same.

No.  A notable example of a pubkey script that doesn't typically include addresses or keys is the nulldata standard transaction type.  Examples of pubkey scripts that include public keys but not addresses are pay-to-pubkey (P2PK)[1] and "bare" multisig.

Although I'm not absolutely sure, I believe its allowed to have an empty pubkey script.  (That is, the compactSize uint that describes the size of the pubKey script is 0x00.)

Note: Bitcoin Core's getrawtransaction RPC, decodetransaction RPC, and other RPCs will display the public keys in P2PK, bare multisig, and redeem scripts as addresses---which can be a bit confusing.

[1] P2PK was formerly used for most coinbase transactions, but that usage has mostly disappeared on mainnet with pooled mining.  It's still a standard transaction type and quite common for coinbase transactions on testnet.


Using GPU mining with the Bitcoin Wallet After asking this question about using the Bitcoin wallet to mine, I am wondering how I can get my GPU involved with the mining work?

Is this possible? or this there other, non-pooling software that I can use to get the GPU of a macbook to perform blockchain validation (aka mining)?

You can use your GPU to mine, but it is going to mostly be a waste of time and energy now that there is specialized hardware (ASICs) to mine.

You need a piece of software that will allow you to mine with your GPU. The miner built into Bitcoin Core is only for CPU mining.

Check out this page on the wiki. The exact software you choose will depend on a number of factors including what make of GPU you have, your OS, etc.


Does a private key always generate the same public key and address? It seems like depending on the method you get different public keys and addresses when using bitcoin-ruby with the same private key. I am probably doing something wrong, but I am not sure where it is...

I can generate a private key, public key, and address using

def generate_address
  private_key, public_key = Bitcoin::generate_key
  address = Bitcoin::pubkey_to_address(public_key)
  [private_key, public_key, address]
end

And, as an example, this could generate:

priv_key= "9d524654045c891327a1dc0c329bcd42311b1767b81d7e997486e841ca5a2a87"
publ_key = "04353457464a32ede1b80fd7299f616320b52cc22796cd27d5b41594f418c2ea26dfeec97273f89b2d908a44fce981ff19f2e2de1408538bb0c0528992ce47f3be"
address = "n1693JDDu5ukbtNh2sHXdZSobKnVEpdtjL"

However, if I then put the private key into another function which generates the key details in a different way, I get a different address! Why is this?

def key_details(prikey)
  #returns prikey, prikey_hash58, pubkey_hash58, pubkey_uncompressed, address as a hash
  my_key = Bitcoin::Key.new(prikey)
  # binding.pry
  { prikey:prikey,
    prikey_base58:my_key.to_base58,
    pubkey_58:my_key.pub,
    pubkey: my_key.pub_uncompressed,
    address:my_key.addr
  }
end

The difference is that the first function uses uncompressed public keys , and the second function uses compressed public keys. Uncompressed public keys are 65 bytes , and compressed ones are 33 bytes.

For more information on compressed public keys see: What is a compressed Bitcoin key?


Mobile app for bitcoins? Is there a mobile app that I can use to buy/sell bit coins? Would it be useful if I create one?

There is a lot of applications allowing you to easily trade bitcoin on your mobile phone. Almost every bigger Bitcoin Exchange has one. Take a look at cex.io, bitfinex.com and many more, they do have mobile apps already. There are also decentralized exchanges with mobile applications too. If you check https://coinmarketcap.com/rankings/exchanges/ you will see a quite comprehensive list of exchanges that we have already.

Another thing is that there is no such thing as an app for trading Bitcoin without having proper infrastructure, the trading engine that can handle large volumes and real-time trading, agreements with banks, special permissions, and licenses so my simple answer would be - no.


How anonymous are Bitcoin transactions? I read some sources that say Bitcoin transactions are anonymous, some that say they are semi-anonymous, and some that say they are not anonymous at all.  In what ways are the transactions anonymous and in what ways are they not anonymous?

Technically the appropriate term is "pseudonymous" - imagine that your bitcoin address is like an email address or an online alias: how hard it is to trace to your actions depend largely on what you do with it.

There is, for example, a bitcoin address in my forum signature that would obviously be VERY traceable back to me. On the other hand if I install the client on a separate system which only connects to the internet through TOR and obtain my bitcoins by mining them from a pool like Eligius (no accounts/email necessary, they only ask for a bitcoin address) then it would be very difficult indeed to trace those funds to me.

And of course there are shades of gray in-between. As I said, think of it as being an email address and then consider how your actions with that bitcoin address can be tied to you. It's difficult but possible to make truly anonymous bitcoin transactions.


Are Bitcoin in Thailand illegal? I have read conflicting reports on whether Thailand declared Bitcoin illegal or not. What has happened and how did it affect Bitcoin commerce in Thailand?

To what degree are there restrictions? I.e. which out of the common actions (possession, personal transactions, mining, private trading and commercial trading) with bitcoin are illegal?

https://bitcoin.co.th/trading-suspended-due-to-bank-of-thailand-advisement/

The short version of that article direct from Bitcoin is...

Do not send/receive/mine Bitcoin if you are in Thailand.  Do not buy/sell to any one where the receiving/sending wallet is in Thailand and/or the product (virtual or real) is sent via Thailand.  Currency laws have not caught up to virtual currencies and how ( if it can be done ) it can be taxed. Bitcoin, as a group, has decided it is in the best interest of the virtual currency to try and stop trades to/from that country and ask people there to not mine ( it is really hard to stop someone from logging in to a pool and mining if they want to )

Bitcoin Co. Ltd. has currency exchange applications currently pending review with the Bank of Thailand


Where is the witness data stored in the raw block data I can see in BIP-141 where the merkle hash is stored.  And I think its clear that the witness data won't be streamed inline with the TXN data.  So I assume the witness data is simply thunked on to the end of the raw block.
Is this something so blatantly obvious that it doesn't need to be specified in a BIP or wiki anywhere, or did I just miss the mention?

If your question is about how witness data is transmitted to other peers in the P2P protocol, the right place to look is BIP-144; the P2P side of the segwit specification.
In short, the witness data is inserted after the transaction output data in every individual transaction, together with a special marker after the version number to indicate whether or not witness data is present. Full blocks then consist of the block header, a transaction counter, and a concatenation of all transaction (which include that witness data).
Note that this is not the only way that blocks are transmitted. BIP-152 (compact blocks) send blocks where the transactions are replaced with short hashes, anticipating that the receiver will already have those transactions (including their witness data).
As for how witness data is stored: that is an implementation detail that is up to the client software, and not specified in BIP documents. Bitcoin Core stores blocks using the same serialization as used in the P2P protocol, as described above.


How can one use multi signature transactions/addresses to improve the security of their services? Multi signature transactions and addresses are heralded to be a good way to improve security of various Bitcoin services. However, how should one go about using them in order to achieve that goal? For example, how would an owner of an exchange, a shop, or a private user would be able to gain the most out of using multi signature transactions and/or addresses?

Well, the theory is that you have a buyer, a seller, and an escrow holder. This is for transactions like Bitmit or OTC or Silk Road where the buyer and the seller do not trust one another enough to reliably complete the transaction. If you run the website and offer the goods, then you'd either need to just build a good enough rep that you don't need to offer escrow, or find a third party escrow provider to keep you honest. Once M-of-N gains traction in the client software, I could foresee business sprouting up just to handle Escrow.

So buyer pays Escrow his fee first, then buyer, seller, and escrow build a 2-of-3 multisig address and buyer dumps his funds in. Goods are transacted, and if buyer and seller are both happy then they sign a transaction together releasing the multisig funds to seller. Escrow agent doesn't need to lift a finger when there's no dispute.
When there is a dispute, buyer and seller each craft and sign the transaction they think should happen (normally "I get all the dough", but more complicated spends are possible too) and submit those to Escrow agent along with their evidence as to how the transaction happened. Escrow judges between them and signs the transaction he thinks should succeed. 2/3 signatures makes the transaction valid.

As to "how will the client software actually work" and "what will the GUI look like", that's a fine question! It appears as though crafting the GUI is the final major obstacle towards this becoming a more widespread transaction type. :3

I've been posting on /r/bitcoin and chatting with Ferroh and others, trying to work out just how to do it the hard way at the command line. :P