Sure, you can do this with CryptoCoinJS.

First download Node.js. Then do the following:

Make a new directory:

mkdir /tmp/myapp
cd /tmp/myapp

Initialize your app:

npm init

Then run:

npm install --save coinkey@1.1.0

Then run:

npm install --save coininfo@0.2.0

Create your js file:

touch app.js

Put the following:

var CoinKey = require('coinkey')
var ci = require('coininfo')

var amount = 10
//generate a bunch of Litecoin addresses
for (var i = 0; i < amount; ++i) {
  var ck = CoinKey.createRandom(ci('LTC').versions) //change LTC to BTC if you want Bitcoin
  console.log(ck.privateWif + ': ' + ck.publicAddress)
}

Run your script:

node app.js

Documentation for coinkey
Documentation for coininfo.

Hope this helps. If something doesn't work, let me know.


How do I download the blockchain from a specific height (409668)

This should make it for you: https://blockchair.com/bitcoin/block/409668

Hope it helps.


What is the difference between your address and your public keys

cited:

  A Bitcoin address is a 160-bit hash of the public portion of a public/private ECDSA keypair.

a picture may make it easier to understand how an address is generated from a public key;

Image provided under Creative Commons CC0 1.0 Universal Public Domain Dedication


For node > 0.13 is it a trigger the say to node, Hey, I'm a segwit transaction! check in Txinwitness!
For node < 0.13 Push ScriptSig inside and that's it, the transaction is ANYONE_CAN_SPEND

Almost exactly right.
Segwit validation code was added in Bitcoin Core 0.13.0, but mainnet activation logic was only added in 0.13.1. That means that 0.13.0 will not enforce these things on mainnet yet (and 0.13.1 will only do it for the part of the blockchain after block 477120).


Question about Python library coincurve/libsecp256k

Recoverable -> DER

Use recoverable_convert. (which calls secp256k1_ecdsa_sign_recoverable)

DER -> Recoverable

Use sign_recoverable. (which calls secp256k1_ecdsa_recoverable_signature_convert)

^^I couldn't find an easier way.


How do you generate a Ripple address and secret using the ripple-lib javascript library?

Yes, there's a nice script written by you.
https://github.com/stevenzeiler/ripple-wallet


You can use bitcoinjs-lib, a nodejs package which easily generates addresses. Apart from that it manages transaction signing and other useful stuff too which would help in development. You can check out their site (where there is a list of organisations, including blockchain.info, who use their package)

Bitcoinjs


Is this the way things actually happen?

Yes

  If yes, then my question is then why can't the full node simply do the following: (1) send its UTXO set to the SPV client; (2) SPV client then filters the UTXOs of its interest and put those UTXOs in its own UTXO set.

The UTXO set is large and a proof for every UTXO would be required. Proofs for every UTXO would be expensive to build and an extremely large amount of unnecessary data would be sent over the wire thus consuming network bandwidth that could be better used elsewhere.


Python: Why the addresses and keys generated by pywallet and bip32utils using the same 12 mnemonic words don't match?

Derivation paths.
wallet_bip39 is using m/44'/0'/0' while (if I looked at the right pywallet code) pywallet is using m/0'


Why do we need a mining speed above 4.3Ghash/s?

You assume that there exists (exactly?) one block for each work unit. This is not true, there are many variables (timestamp, nonce, transactions in a block, extranonce inside the block's coinbase transaction, ...), and all of them influence the block's hash. Each hash has a chance (as of October 2013) of less than 1 in a billion billion (1.15*10^18 to be precise) to be below the difficulty target.

Each miner searches a different part of the search space (which is, for all intents and purposes, infinitely large), hoping to find a valid block before anyone else does, but there is no "progress" to be made: every attempt has exactly the same chance as any other attempt. The nonce in the block header is just a way of making a particular group of attemps faster to search through.


The result of bitcoin-cli getpeerinfo command

so, I checked my router whether the port number(48302, 44660) is opened or not but, no any port is currently open.

They don't appear open because those ports are not always open listening for incoming connections. Rather those ports are bound to temporarily by the forwarding software which then initiates the connection to your computer. As soon as the connection to the peer closes, so will that port.

What you see with that is like the ports that your browser uses to connect to remote web servers. When you have your browser open, a port is opened. But if you port scan your own computer, you won't see those ports. You can see what ports are active and connected to other servers by using the netstat -nap command.


Transaction Puzzles, Awareness and Questions

How would people (likely power users) even be aware that these funds were out there, and available to be redeemed if they solved the puzzles.

As you mentioned, it could be that either the creator of the UTXO publicized it, or someone parsing through blockchain data discovered it (and perhaps then publicized it). In the case of the hash collision bounties, see this bitcointalk thread.

What does it mean in the second photo when it says "Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else".

If the 'puzzle' to be solved does not involve a zero-knowledge proof, then for the duration of time that the transaction is published to the network but not yet confirmed, anyone watching the mempool would be able to take the scriptsig and attach it to their own transaction, spending the UTXO to an address they control instead.
For example, if there were a UTXO spendable by providing just the number '4' as the scriptsig, then anyone watching the mempool would be able to observe this, and until a transaction spending that UTXO is included in a block, anyone could just create their own transaction with '4' as the scriptsig, to try to claim it first.
The way around this would be to not broadcast the transaction, but instead mine a block which includes the transaction yourself. That way, the zero-knowledge-proof-less scriptsig would never be public knowledge, before the transaction is confirmed.

What kind of wallet or software would a power user claiming these funds be using?

I would guess that to claim really unique puzzle UTXOs you would need to write some simple software to create the transaction for you.


Blockchain transaction goes missing when searched from a few sites

The transaction still shows on blockchain.info:
https://blockchain.info/tx/fd82fb9711afc48623fa13fa3963121f88160afe56fc968feaf02e5f73e7b764

You can never be sure a transaction is completely dropped because every node maintains its own mempool with potentially different rules for dropping transactions. And you never know, it may be confirmed any time despite the fee. cex.io who sent it is the only ones (other than miners) who can do anything about it anyway, so perhaps contact them, but likely you will just have to wait.

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


What can be the reason to change transaction ID?

I think What is transaction malleability will answer most of it. But to summarize it in terms of your actual questions:

  the reasons why transaction ID can be changed?

Because someone can create another transaction (= different transaction message) that accomplishes the same thing as yours, while reusing your signatures.

The reason the signatures can be reused in a different message is because the signatures don't sign themselves. They don't sign themselves because that would require a dependency loop (the transaction message depends on the signature, and the signature signs the transaction message), which would be impossible to sign for.

The question is then what can be changed in a signature that doesn't invalidate it. The known ways for doing so are listed in BIP62 (which aimed to prevent some of them, but was retracted - it still gives a good overview).

  Who can change this ID (I assume a miner who mined a block)?

Anyone who relays your transaction (including miners), as they see your transaction but have the ability to produce a modified version and relay that one faster than someone else.

  What field in the transaction message can be changed to warrant the change of txId?

The scriptSig field in the transactions' inputs. It contains the ECDSA signatures, but also redeemscripts, public keys, and various other information needed to prove a spend was authorized.

With BIP141 (Segregated Witness), these issues are avoided by making the signatures not affect the txid anymore. Instead, they are stored in a separate field (called the witness) which is only necessary to prove a transaction's validity, and does not contribute to its effect.


What drives the price of bitcoin, in other words, what makes it go up or down?

"The price" is established through supply and demand, by definition.

Speculators might temporarily skew supply or demand after reading some news or predicting/anticipating some event. Or simply by rumours and herd mentality (more often than not).

What those speculators react to you'd have to ask them and doesn't sound like an on topic question here. It's not related to Bitcoin anyway, as it's the same for any other market.

One likely upcoming drop in supply is coming around 2016-07-26 when the block reward is going to halve again.


To restore a backed up wallet.dat file, you need to replace it manually.

Just overwrite the one in your data directory (see https://en.bitcoin.it/wiki/Data_directory to find it for your platform).

Opening the file with Bitcoin-Qt means you're trying to process a payment request; it's not for opening a wallet.


Deterministic wallet and address generation

Well, it's a deterministic wallet. There is a function f which for every n∈ℕ returns the nth address that will be produced.

An address is basically a hash of a public key (we can neglect the rest it's comprised of but it's deterministic as well).

You can get a public key from a private key deterministically.

Every 256 bit number is a private key.

So your wallet just needs to make 256 bit numbers deterministically and do calculations to get to addresses deterministically.

This can easily be done by picking a hash function which outputs 256 bit – let's choose sha256 – and a salt λ. A salt is just something that's added to the input of a hash function.

If your wallet knows λ, it can generate a practically arbitrary amount of bitcoin addresses.

g(n) for every n∈ℕ can be defined as g(n) := sha256sum(λ.n) where . is the concatenation operator. g(n) is the nth private key.

If you use a Linux computer, just open the terminal and type in:

echo "aR3Ba9raAi1" | sha256sum
echo "aR3Ba9raAi2" | sha256sum
echo "aR3Ba9raAi3" | sha256sum
echo "aR3Ba9raAi4" | sha256sum
echo "aR3Ba9raAi5" | sha256sum
echo "aR3Ba9raAi6" | sha256sum
.
.
.

aR3Ba9raAi is λ. The last digit of the parameter echo gets is n but of course it can be more than 1 digit.

Via the output you get:

g(1) = 49fc13b53bf8cbc8607c121066a974f5c803aee04629e11696946f93b16825a6
g(2) = 9462e18f435684eb8bf5008f8e7c717729fbfa505554ef4b3325a3eccc807519
g(3) = d7bde9e8c19959b0abaa5c476a3fc7a4eacf713fe78c9e2a66ac202419ddbf6f
g(4) = d08ddf753bb37b853407f1451334bb042d93ee2179c01244a019229a32fe9c03
g(5) = 4291513728b1a0d96b72df35bafa1f78db1ceaf135d874a3d8e5353aa9408893
g(6) = e04aba61558daaa532d252397e5d5467c8dd64552f987e54245ab759dd0517cb
.
.
.

Those would be the private keys. They are the same on every machine as long as λ stays the same. No between your machines is necessary after they all know λ. g(n) is deterministic and so is everything else afterwards on the way of generating an address. So f(n) can be calculated from g(n).

Of course that's only an example to show you the basic principle behind deterministic address generation. It's strongly simplified and major steps for generating addresses are omitted. This answer should only show you that something can be calculated the same way on different machines without the need of them being able to communicate with each other.

This is also great because everything you need to recover an HD wallet is a seed. You don't need the entire history of what's been generated from the seed because it can be generated the exact same way again.


Blockchain.info does not track the testnet, but blockexplorer.com does. In fact the API you're using was originally from blockexplorer.com, and blockchain.info simply adopted it.

wget -O - http://blockexplorer.com/testnet/q/getblockcount 2> /dev/null

or shorter

curl http://blockexplorer.com/testnet/q/getblockcount


You need a bank account in Guyana for people to deposit money. Then you need a server to run the exchange. For the software you can check the answer to this question: Is there an open source Bitcoin exchange?

If you don't want to run you own server you can look at this: http://www.buttercoin.com/#/


How to get latest 50 transactions for a BCH address?

you can search to find it. there are a lot of API,s which help you.
as an example try https://explorer.bitcoin.com/bch.


Reading transactions from blk*.dat files

Yes, it is possible.

According to Order of transactions within a block, transactions within a block must be listed in the "correct" order: a transaction may only spend outputs of transactions listed earlier in the same block, or in previous blocks.

However, blocks do not necessarily appear in the blk*.dat files in their proper order, but rather in the order in which they were downloaded.  If A,B are two blocks, and the prevBlockHash of B is the hash of A, it's still possible that B appears before A in the file.  In that case, a valid transaction may reference outputs from a transaction that appears later in the file, though earlier in the block chain.

It's also worth noting that blk*.dat can contain orphaned blocks.  So you may find two different transactions in the blk*.dat files that spend the same input.  You'll then have to determine which of them is in a block that is part of the longest chain (measured by total work), and which is on an orphan side chain.


Why does Litecoin have lower transaction fee than Bitcoin?

Litecoin's blockspace supply is greater:

Litecoin's block interval is a fourth of Bitcoin's at 2.5 minutes
SegWit is activated, limiting blocks to 4MB weight instead of 1MB size. With leisurely adoption of the new segwit transaction format this would eventually allow a capacity equivalent of blocks with ~1.7-2.3 MB size.

Litecoin's blockspace demand is much lower:

Bitcoin does about 250k transactions per day with the mempool never completely flushing out, Litecoin has just slightly over 19k, while it could do about 2,000k.

Bitcoin is operating with demand exhausting the supply continuously, thus finding actually a price for blockspace. In the past months we've seen feerates move between 1 and 540 satoshi/byte. Now that the latest hype has cooled down slightly, we can observe a daily and weekly cycle, under the week going from ~8 to ~400 satoshi/byte, dropping down to as low as 2 satoshi/byte on weekends.

On the other hand, Litecoin is operating with demand at approximately 1% of the supply. Miners appear to be observing a hard coded minimum fee of
100 litoshi/B.


Why my bitcoin trading on coinbase.com is not in blockchain?

Trades within exchanges do not occur on the blockchain. That would severely bloat the blockchain and produce a lot of unnecessary transactions. These trades are simply done by updating your account's balance within the service's internal database. You are not actually sent Bitcoin and there is no way to prove that you own that much Bitcoin except by showing your account.

The addresses that an exchange gives you are not your addresses. They are addresses to the exchanges wallet and once you send Bitcoin to that address, they will update your account's balance in their internal database system. The exchange is holding your Bitcoin for you, and they can do whatever they want with it. It isn't really yours until you choose to withdraw the Bitcoin. When you withdraw, you likely won't be sent Bitcoin from "your" addresses either, but rather from other addresses in the exchange's wallet and often times your withdrawal will be part of the same transaction as other people's withdrawals.


Do transactions happen in an already mined block or a block yet to be mined?

A new block is constructed using transactions from the queue of pending transactions.  The miner repeatedly hashes the data until the result meets the network difficulty level.  The local bitcoin node then broadcasts the block to the network.  The process then repeats with the next set of pending transactions.

The miner gets the block fee as well as all transaction fees for the transactions included in the block.  Note that the miner receives nothing if the block is orphaned because another miner broadcast his block first.  In the case of a pool, the fees are divided among all of the miners in the pool.

Each block contains a coinbase address and this is the address that receives the fees.  The miner can set this address to anything he wants.

Satoshi started the process by releasing the genesis block, which is the initial block in the block chain.


How to create your own bitcoin mining software?

Yes, it is possible

Take an editor (notepad.exe is good one)
Write a program
Compile and test it
Thats all. Profit!


Is it possible to use bitcoin core on Mac OS Sierra saving the data on the network drive?

Core (more specific levelDB, the database library used) does not support network drives.
Also, the UTXO access (chainstate) must be as fast as possible and should run on an internal drive, ideally an SSD.

If you need to reduce/transfer disk usage, there are two main possibilities:

Pruning

Add prune=550 to you bitcoin.conf (or startup with -prune=550) to reduce the kept block data to a minimum. Your node will still do full validation but does not server old historical blocks to other peers.

Symlinks

Symlink the blocks directory is possible. Check https://en.bitcoin.it/wiki/Data_directory#Transferability


This was described as showing the difference between transaction fees and the bitcoin miners income from block rewards.

So if a Block has 25 BTC generated and 1 BTC of fees, the network deficit would be 24 BTC.  The amount in USDs is calculated at the spot rate at the time.


Programming a solution to know when a Bitcoin Address has stored a target amount

A rough solution:

If the account is in your wallet, you can use:

bitcoind getreceivedbyaddress "ADDRESS"

to get the amount of bitcoins received by ADDRESS. You can put that line inside an infinite loop. You could create a shell program which stores the result in a variable every 30 seconds (using sleep) and compare it to the previous value. If you subtract the values and find a difference above a threshold you can make the script alert you.

I can be more specific if you tell me your preferences (Python, Linux shell...)


What's relationship to each address other in Bitcoin Core?

Is there any relationship to each address? Like based on seedphase? or Just literally making 'random' address?

It depends.

In old versions of Bitcoin Core, addresses were just randomly generated and the private keys stored in wallet.dat.

Newer wallets that implement BIP32 derive all of the wallet private keys from one master private key.

  If so, an attacker can hack the other address if knows one of private key?

If an attacker knows your 12 seed words, they can derive the private keys in your wallet and steal all of your coins, but this is no worse than an attacker having your wallet.dat.


Are there Bitcoin addresses with an odd number of transactions?

I suppose that, normally, people spend their bitcoins soon and/or use several addresses (each one for 1 or few transaction); the following addresses shows an exception, which I, finally, found.

https://blockchain.info/address/126b9vwrfEYH6NehYmUCTjAga4Dg8UocAQ


From the website:

Update 28. April
BTC withdrawals are now enabled.
All withdrawals will be done manually within 24 Hours.

Your password must be reset with the following link: reset password

For support please use our Ticket-System


How to Obtain Bitcoin Gold Without Using Coinomi

Regarding Coinbase, they do not support Bitcoin Gold right now, but there is a possibility they will in the future.

The Nano Ledger split procedure is for if you had Bitcoin in their wallet during the fork.
You can't use it to claim Bitcoin Gold from an external private key.
So for the time being you can't claim Bitcoin Gold with your Ledger Nano.

However, you can use one of the wallets listed under Bitcoin Gold official webpage if you trust them.
Honestly, I wouldn't trust all the wallets they endorse since after the two major incidents that happened a while ago.

Incident 1 - One of the wallet provider they endorsed turned out to be malicious.
Incident 2 - Their official wallet got compromised.

As of now I only deem Coinomi, Ledger and Trezor as the trustworthy wallets for BTG.


Is there a bitcoin mining program that works with multple devices, and adds the collective satoshis together?

I am assuming you are referring to pool mining since you mentioned "payout threshold".
You can simply connect all your computers/mining devices to the same mining pool as workers, and the pool will count each worker towards your shares/efforts.


Sounds like a watching wallet, but you need to save the wallet file as well as you're saving spv file. As per documentation


How many BTC were seized in relation to the shutdown of Silk Road?

According to this New York Times article of October 3, 2013:

  Investigators believe Mr. Ulbricht collected commissions of more than 600,000 bitcoins, the equivalent of $80 million, which they are trying to gain access to. So far, the authorities have seized 26,000 bitcoins, worth about $3.6 million, from escrow accounts into which Silk Road buyers placed funds.


Exporting private key from Bitcoin Core to claim my BCH on Exodus

Hi there have you tried these steps?

How do I claim Bitcoin Cash?

UPDATE:

As of OCTOBER 12, 2017, Bitcoin Cash has been enabled in Exodus 1.36.0 so you can now send Bitcoin Cash to Exodus. To download the latest version, please go here:

http://support.exodus.io/article/27-how-do-i-upgrade-exodus

Below are the instructions on how to claim Bitcoin Cash if you had Bitcoin on July 31st, 2017.

Important: This will not work unless you are updated to the latest version of Exodus.

To claim your Bitcoin Cash inside of Exodus click on the help section then scroll all the way to the bottom of the help section to find the section titled; "How Do I claim my Bitcoin Cash." When you open that help section you will see a green button to start the process on claiming your Bitcoin Cash.

Step 1: Click on the Help button on the left side of Exodus. (Scroll down for Step 2)

Step 2: Scroll all the way to the bottom of the help section and find the help article titled "How do I claim my Bitcoin Cash?" - Click on that to expand it. (Scroll down for Step 3)

Step 3: Read the text to tell you a little about the process then click the green button to begin to claim your Bitcoin Cash. (Scroll down for Step 4)

Step 4: Exodus tells you the process is starting and gives you some information and a warning to be sure you are sending your Bitcoin Cash to a trusted source. Click the Blue Continue button. (Scroll down for Step 5)

Step 5: Exodus now asks you for your Bitcoin Cash address to know where you want your Bitcoin Cash sent. If you're updated to Exodus 1.36.0, you can now acquire your own Bitcoin Cash address. Feel free to input your Exodus BCH address to send it there or send it to any other Bitcoin Cash wallet of your choice. (Scroll down for Step 6)

Step 6: Exodus will now check your wallet and count up all your available Bitcoin Cash to send out. Depending on how many transactions you have - this process takes about 10 minutes. Click the blue "Check My Wallet Now" button to begin. (Scroll down for Step 7)

Step 7: Exodus now tells you the total amount of Bitcoin Cash you have to send out and also gives you the network mining fee this transaction will cost to send out. Because Bitcoin Cash blocks today are a bit slower this transaction could take 1-2 hours to confirm. If everything looks good click the red "Send" button. (Scroll down for Step 8)

Step 8: Your Bitcoin Cash has been sent! You can click on the blue "View TX" button to monitor the status of your transaction. Remember Bitcoin Cash today can take 1-2 hours to confirm so be patient while you monitor your receiving address.

How do I claim Bitcoin Cash?

UPDATE:

As of OCTOBER 12, 2017, Bitcoin Cash has been enabled in Exodus 1.36.0 so you can now send Bitcoin Cash to Exodus. To download the latest version, please go here:

http://support.exodus.io/article/27-how-do-i-upgrade-exodus

Below are the instructions on how to claim Bitcoin Cash if you had Bitcoin on July 31st, 2017.

Important: This will not work unless you are updated to the latest version of Exodus.

To claim your Bitcoin Cash inside of Exodus click on the help section then scroll all the way to the bottom of the help section to find the section titled; "How Do I claim my Bitcoin Cash." When you open that help section you will see a green button to start the process on claiming your Bitcoin Cash.

Step 1: Click on the Help button on the left side of Exodus. (Scroll down for Step 2)

Step 2: Scroll all the way to the bottom of the help section and find the help article titled "How do I claim my Bitcoin Cash?" - Click on that to expand it. (Scroll down for Step 3)

Step 3: Read the text to tell you a little about the process then click the green button to begin to claim your Bitcoin Cash. (Scroll down for Step 4)

Step 4: Exodus tells you the process is starting and gives you some information and a warning to be sure you are sending your Bitcoin Cash to a trusted source. Click the Blue Continue button. (Scroll down for Step 5)

Step 5: Exodus now asks you for your Bitcoin Cash address to know where you want your Bitcoin Cash sent. If you're updated to Exodus 1.36.0, you can now acquire your own Bitcoin Cash address. Feel free to input your Exodus BCH address to send it there or send it to any other Bitcoin Cash wallet of your choice. (Scroll down for Step 6)

Step 6: Exodus will now check your wallet and count up all your available Bitcoin Cash to send out. Depending on how many transactions you have - this process takes about 10 minutes. Click the blue "Check My Wallet Now" button to begin. (Scroll down for Step 7)

Step 7: Exodus now tells you the total amount of Bitcoin Cash you have to send out and also gives you the network mining fee this transaction will cost to send out. Because Bitcoin Cash blocks today are a bit slower this transaction could take 1-2 hours to confirm. If everything looks good click the red "Send" button. (Scroll down for Step 8)

Step 8: Your Bitcoin Cash has been sent! You can click on the blue "View TX" button to monitor the status of your transaction. Remember Bitcoin Cash today can take 1-2 hours to confirm so be patient while you monitor your receiving address.


Are there two versions of the armory webpage?

https://bitcoinarmory.com is Armory's original webpage when it was maintained by Armory Technologies Inc. (ATI) They still control that webpage but it is currently unmaintained.

After ATI stopped maintaining Armory, the open source community picked it up with one of ATI's former employees taking the lead maintainer role. The website for the open source community fork of Armory is https://btcarmory.com.

You should be using https://btcarmory.com because that website is still maintained and the software that is listed there is also maintained.


Can I prioritize my transaction in Bitcoin?

That is one of the purposes of transaction fees.

Since block space is finite, miners will select transactions with the best Feerate or fee/kB ratio. Of course, this is variable based on volume of transactions and the market rates.

See Fee Rates | Transaction fees


Could it be possible to secure transactions against double-spending with other utxos?

This is a creative idea, but I see one massive issue with it:

While it works to stop malicious double spends, it does so by making participating transactions 'One try or die'. Malicious double-spends are punished, but so are normal transaction failures.

Consider what would happen if a user used this technique to make a payment, but for whatever reason, they set the fee-rate too low. Now their transaction will not confirm for a long time, in fact it may never confirm if there is a sufficient volume of transactions paying higher fee-rates.

So now the poor user that owns any UTXO used in that transaction may never be able to attempt to spend it again, since doing so would put their other 'insurance' UTXO at risk of being claimed. This is a obviously a massive issue.

I think that it may also even create incentives for other nodes and miners to censor transaction propagation/confirmation, in hopes of seeing conflicting transactions published at a later date.

Any wallet implementing this would have to strictly enforce a policy of no address reuse. Otherwise, after successfully completing the 'insured against a double spend' transaction, the user's BTC stored at the insurance address will still be at risk! An attacker could send a small amount of BTC to the address that the original payment was sent from, and then a naive wallet implementation might use that new UTXO as input to a new payment. This would create a second valid signature, that could be used to claim the insurance UTXO.

Another issue: we should expect that services receiving payments would want to use this, but users would not (doing so would just cost them more tx fees, after all). Why is this an issue?

Consider what would happen if you arrived at a retailer that required such a transaction: you would have to create an 'insurance' UTXO that relates to some other UTXO you own. In order for that insurance UTXO to take effect, you will have to wait for a confirmation! So now we are still stuck waiting for a confirmation anyways.

I don't think building off of an unconfirmed insurance UTXO makes much sense, what is to stop someone from double spending the insurance UTXO? It is the same 'issue' we had in the first place. Creating insurance UTXOs ad infinitum is clearly not a good solution.

Alternatively, the user could prepare and get confirmation for insurance UTXOs in advance, but what is their incentive? To appease a retailer, at risk of losing the insurance UTXO if something goes wrong?

Perhaps I am missing something in my critique, so I'm interested to see if someone smarter can see ways it could work (or not). Neat idea, anyways.


To run bitcoin core testnet on Ubuntu 16.04

After having installed Bitcoin core on your machine, run the following command to start synchronising the testnet blockchain
bitcoind -testnet -daemon
The synchronisation starts as a daemon and runs in the background, you can issue the following the command to see the progress
tailf ~/.bitcoin/testnet3/debug.log
To access the command line apis , just add the -testnet parameter
bitcoin-cli -testnet getinfo
Update: The RPC getinfo is deprecated, use getblockchaininfo for it to work with the latest version
bitcoin-cli -testnet getblockchaininfo


"Sipa" definition? (old terminology, circa 2011-12)

Sipa is the alias of Pieter Wuille, a Bitcoin Core developer. It just happens that he had a feature branch for the rpc command importprivkey, and people just referred to it as the "sipa" format. It's just something that has hung around in vanitygen and a few places on the Bitcointalk forum, it's not in common use anywhere else. The format being talked about is just base58check encoding with a version prefix differentiating compressed and uncompressed point usage.

This format is today most commonly known as WIF (Wallet Import Format), and also the format used in the MultiBit classic export.


Running two bitcoin instances on a linux server, can't get peers on second instance

You'll want to add either addnode=<ipaddress> or connect=<ipaddress> to the bitcoin.conf of the node that is not working, where <ipaddress> equals the 127.0.0.1

These can also be command line flags (e.g., bitcoind -connect=127.0.0.1).

The difference between addnode and connect is explained like this (attributed to 'Noodle' on Freenode):

  Quick Primer on addnode vs connect

  Let's say for instance you use addnode=4.2.2.4
  addnode will connect you to and tell you about the nodes connected to 4.2.2.4.  In addition it will tellthe other nodes connected to it that you exist so they can connect to you.
  connect will not do the above when you 'connect' to it.
  It will only connect you to 4.2.2.4 and no one else
  So if you're behind a firewall, or have other problems
  finding nodes, add some using 'addnode'.
  If you want to stay private, use 'connect' to only connect to "trusted" nodes.
  If you run multiple nodes on a LAN, there's no need for
  all of them to open lots of connections.  Instead 'connect' them all to one node that is port forwarded and has lots of connections.


Why is Bitcoin so susceptible to credit card fraud?

Bitcoin strongly enforces two concepts - high anonymity and no chargebacks.

Because of high anonymity, it is nearly impossible to be 100% certain who you are sending Bitcoins to. In the end, the Bitcoin address is just an arbitrary string of characters.

Because of no chargebacks, once you send someone Bitcoins, they are irreversibly theirs (assuming no double-spends and no 51% attack). You can't later recall the money you sent this way.

When someone would buy Bitcoins with a credit card, they could wait until the coins appear in their wallet, and then claim that their credit card was stolen used by someone else to purchase Bitcoins without their intent. They could get away with their chargeback claims, as it would be impossible for the seller to prove that they sold the coins legitimately to the person. Moreover, the seller wouldn't be able to get their Bitcons back due to "no chargebacks" rules.

What makes it different from services like iTunes and the like, is that the value of the Bitcoins is close to how much it costs the seller to aquire and sell them, whereas iTunes' costs are marginal. For example, buying a 1$ song from iTunes would mean that they have to probably spend less than a penny processing everything and providing you content (logging transaction, letting you download the song, etc), whereas if you send 1$ in Bitcoins, you are sending about 1$ worth of goods. When iTunes gets charged back, they lose a penny and can still sell the song any amount of times. When a Bitcoin seller gets charged back, they lose a dollar and can't sell the same coins again.

Bitcoins can't be copied and distributed to multiple people at marginal cost, that's what makes chargebacks so costly for any potential sellers.


What happens between submitting a transaction to the network and it being confirmed?

Some miner will mine the next block. No one knows which one it will be. For transactions to be included in a block within a reasonable period of time, pretty much all miners have to know about pretty much all transactions.

You don't know who is currently mining and maybe you're on a bad internet connection so you don't want to send your transaction to every single miner in the world, just in case that is the one who will build the next block. You merely have to send your transaction to a single node in the Bitcoin network. If it's valid and contains a reasonable fee, it'll be automatically propagated through the network and find its way to all miners.

So to answer your first quesiton: It didn't just go to a single miner. You can be pretty sure all miners know about it.

Miners don't tell others which transactions they are trying to get into the next block. This changes with really, really often, for every big miner. They by the way are working on many blocks at the same time, hoping to succeed with one.

Once a transaction has been included in a block, you can find out who made that block. Let's say your transaction ID is ccb5133b45fbca133936ab059377d4a5e4078a48b98349c8beb99c2cee529716. Head over to https://blockchain.info and enter it. You'll be shown that it's included in block 446059 ("Included In Blocks"). Click on that number and you'll be shown that block. There is a field called "Relayed By" whose value in this case is "BitFury". So you know the block was probably made by BitFury.


What is the Design of Bitcoin storage?
  where is the data of UTXOs for each wallet is maintained?

There's no need for every wallet to use the same storage format. The precise details of the storage format may be proprietary secrets or may be undocumented other than in the source code for that specific wallet.

This question could only be answered with some certainty for a specific version of a specific wallet.

  How is [the blockchain] stored ... across the network?

Every full node keeps a complete separate copy.

Lightweight nodes (SPV etc nodes) each maintain a pruned copy of the blockchain that only contains blocks with unspent transaction outputs.

  How is [the blockchain] ... shared across the network?

That is a rather separate question, there's probably an answer already here for that. Its probably described in Nakamoto's original whitepaper which is easy to find.

See also

How are transactions broadcast to the rest of the network?
https://en.bitcoin.it/wiki/Network
https://en.bitcoin.it/wiki/Protocol_documentation

which contains information of this sort:


Actually, yes, this is possible. However, your payment output might get split or combined with other payment outputs in later payments. Therefore, the graph will be less linear than you suggest:

    C ↴       ↱ H
A → B → D → E → G
          ↳ F

So, A would be sent to B, then B + C would produce D, D would be split up to E and F, E would further be split up to G and H.
B would be a 100% child of A, D, E, F, G and H only 50% (if A and C were the same size).

This would get much more complicated over time where many outputs get combined and split and so forth, but you could actually continue to track this forever. The issue is actually not with the tracing of funds, but with the proving that funds were indeed stolen. If you are more interested in this, you might find this related question useful: What are tainted coins exactly?


Where can I find the Bitcoin white paper in plain text markdown format?


Where does one find documentation for the MtGox trade API?

Here is their documentation for their http based api and here is their documentation for the websockets based one.

There are many wrappers in many languages already written.

Ruby
Node.js
Python

just to name a few


Why does Account Controls not work on the Ardor parent chain but only for child chains?

According to NXT wiki:

  In Ardor, only child chain transactions can be phased. Therefore, when account control is set for an account, it can no longer submit Ardor chain transactions.

In other words: account locked for child chain is locked for Ardor chain to.

See for details: Account_Control


Formula for calculating daily mining earnings

Let X be hashes per second, and Y be the difficulty. Let Z be the Log base 1-1/(2^32*Y) of 1/2. Z is how many hashes it will take you to find a block, on average. Let A be the current block reward (it's currently 25). Let B be the number of seconds in a 24-hour day: 86,400. You will earn, on average, A*X*B/Z bitcoins per day.


How to check the balance of a person when his public keys are different on different input transactions?

Contrary to popular belief, Bitcoin does not use an accounts system with balances nor do addresses actually exist on a technical level.

A transaction spends transaction outputs and it creates transaction outputs. It directly references which transaction outputs it is spending, so when verifying a transaction, you just need to lookup what the previous transaction output is. There is no need to know any balances (except that of the transaction output which is provided in the output itself) nor anything else about the wallet of the sender(s).


the client's 'invalidateblock' debugging command - possible prevention against majority attack?

If there’s a case of a majority hashrate, human intervention of a single instance can not prevent something that continuous and ongoing. The amount of coordination required to keep the network in consensus would be impossible to obtain if this were a solution.

If Bitcoin fails, it’s time to move on rather than patching it up.


Is there any tool to extract the bitcoin transaction network from the blockchain?

BlockChain::BlockChain ( QObject* parent ) : QFile ( parent ), blkFile ( START_BLOCK )
{
  connect ( this, SIGNAL ( block ( const QByteArray& ) ), parent, SLOT ( block ( const QByteArray& ) ) );
  connect ( this, SIGNAL ( doneFile ( ) ), parent, SLOT ( doneFile ( ) ) );
  QTimer::singleShot ( 0, this, SLOT ( start ( ) ) );
}

void BlockChain::start ( )
{
  setFileName ( blkFileName ( blkFile++ ) );
  if ( !open ( QIODevice::ReadOnly ) )
  {
    _trace ( QString ( "cant open [%1]" ).arg ( fileName ( ) ) );
    emit block ( QByteArray ( ) );
    deleteLater ( );
  }
  else
  {
    _trace ( QString ( "processing [%1]" ).arg ( fileName ( ) ) );
    QTimer::singleShot ( 0, this, SLOT ( next ( ) ) );
  }
}

void BlockChain::next ( )
{
  if ( pos ( ) < size ( ) )
  {
    quint32 magic;
    quint32 sz ( read ( (char*)&magic, 4 ) );
    while ( !magic && pos ( ) < size ( ) - 4 )
      read ( (char*)&magic, 4 );
    xassert ( ( ( magic == MAGIC_ID ) || !magic ) && ( sz == 4 ) );
    if ( magic )
    {
      read ( (char*)&sz, 4 );
      emit block ( read ( sz ) );
      QTimer::singleShot ( 0, this, SLOT ( next ( ) ) );
      return;
    }
  }
  close ( );
  emit doneFile ( );
  QTimer::singleShot ( 0, this, SLOT ( start ( ) ) );
}

const QString BlockChain::blkFileName ( const int i ) const
{
  return
    ( i < 10 ) ? QString ( DATA_ROOT "\\blk0000%1.dat" ).arg ( i ) :
    ( i < 100 ) ? QString ( DATA_ROOT "\\blk000%1.dat" ).arg ( i ) :
    QString ( DATA_ROOT "\\blk00%1.dat" ).arg ( i );
}


How many nodes would one typically check to determine the longest chain?

Each node acts independently, the Bitcoin protocol is designed so that you do not have to trust any other nodes to verify the state of the network.

If your node hears about a new block at the chain-tip, it will check to see if the block is valid according to the network's rules. Assuming the block is valid, it will be added to your local copy of the blockchain.

If your node later hears about a longer (valid) chain that doesn't include the block you just added, then you would 'reorganize' the last couple blocks, in order to create what you now know to be the longest chain. The previously accepted block would be discarded, and become what is commonly referred to as an 'orphan block'.

By this mechanism and the related game theory, the network's nodes are able to maintain consensus around the blockchain's history. The more confirmations a block has (ie blocks mined on top of it), the more certain one can be that it will not be 'reorganized', meaning the payment is more permanently included in the blockchain.


How to manually disconnect a peer from peergroup?

Simply:

peer.close();

Peer.java extends PeerSocketHandler.java, which is the class that defines the close() method, so maybe that's why you weren't seeing it. It would also probably be easier to find if it were called disconnect().


A node can publish any block at any time. How? How to publish?

Let's assume that you are solo-mining.
If you are a miner you need to run a Bitcoin Full-Node for example Bitcoin Core. If you do this you are a full part of the Bitcoin network.
If you mine a block, you do the following steps:

Putting transaction together and verify them
Doing the Proof-of-Work (Calculating the nounce until the first characters are zeros).
Adding stuff like coinbase and timestamps
Profit from the reward and transaction fees

If this is done you broadcast the block to all nodes in the network the same way as broadcast a transaction. This means that all nodes are receiving this block. They are also checking it like if your block matches the difficulty and if the transaction are valid. Then they are adding it to their own local copy of the blockchain.

The nodes are broadcasting the blocks and transactions under each other. That's how peer to peer work. You should take a look at this


Running the bitcoin-core software creates a 'full node', it does this by fully validating the current state of the network. Once in sync with the network, the BTC balance shown by the software can be assumed correct.
Looking up the balance on a blockchain explorer service's website can provide some assurance that what you're seeing on your node is indeed correct, but its also kind of like asking someone else to do some math for you, when in fact you've already computed the answer yourself. Why trust the other person, you've already independently arrived at the answer.
Note that each address in a wallet is unrelated to any other address in that wallet. So if you receive funds to address X, then you'll have to look up address X to see the balance of address X. If you're also received funds to address Y, they won't be shown if you look up address X. Likewise, if you haven't received funds to address Z, then looking up address Z will not give any information about any other addresses in the wallet (you won't see the balance of address X or address Y).
To see a list of unspent UTXOs and their associated addresses, you can run the following command: bitcoin-cli listunspent. If you look up those addresses using a block explorer, the balance of each address should be correctly displayed.
NOTE: using a block explorer is very bad for your privacy. The block explorer service will learn which addresses you are interested in, as will every other service involved in serving you that data (your ISP, local network admin, etc). Using the tor network to look up addresses with a block explorer would be preferable, to help preserve privacy. Some block explorers even offer a .onion hidden-service site mirror, to allow users to retain privacy.


How can I make Bitcoin start with a simple `bitcoind` in the terminal?

The answer above is correct but doesn't explain anything to the user as to why they can't just type bitcoind in the first place. This doesn't help people at all and future people will just follow this blindly.

To understand why some commands can be typed in without the full path you must understand the $PATH environment variable. A very good writeup on it was done here http://www.linfo.org/path_env_var.html.

A short explination is that $PATH lets you define what paths on your computer are searched for executable files. You can see what the current searched paths are by typing echo $PATH into your terminal. Here is an example from mine.

echo $PATH
/Users/mschuett/Uber/phacility/arcanist/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/mschuett/bin:/usr/local/bin

Each directory is separated by a : and if a path at /Users/mschuett/bin and /usr/local/bin both included a binary called test-command it would always use the test command found in /Users/mschuett/bin since it comes first in the $PATH string. To add more directories to your $PATH you can simply write..

export $PATH=$PATH:/opt/bitcoin/bin

Now all executables at this path are available without typing the full path. To see what path an executable is being run from you can use which bitcoind and it will output the full path that is used when you run bitcoind.

Hope this helps actually explain what is going on.


Could mining calculations be used to crack private key?

No.  The math involved in cracking a private key uses a completely different set of mathematics and source data.  There is no benefit in reusing one for the other.

There is a conspiracy theory going around about the SHA hashes being a big rainbow table for "The Russians" but that crackpot theory has no basis in mathematics or applied usage.  I hope people keep talking about it so I can buy BTC while they are still cheap.  FUD (Fear, uncertainty, doubt) are good to keep BTC's price low while before the market value becomes what it should be.

To be more specific, SHA hashing (mining) is a different set of math used for the ECDSA secp256k1 encryption that in the private key.

Now that ASICs are used, it's impossible to dynamically re-wire the hardware for such a purpose.  In theory FPGA can be reprogrammed for this, and so can GPU/CPUs.

You could keep all your BTC in one address, or you could diversify your risk by keeping BTC in many different accounts (addresses) knowing full well that this will increase your transaction size and therefore your transaction fee.  The choice (to some extent) is yours


How do i install bitcoind on my redhat linux server?

git clone git://github.com/bitcoin/bitcoin.git
cd bitcoin/src/
make -f makefile.unix
sudo cp bitcoind /usr/local/bin


How to get confirmations for incoming transactions?

Calling bitcoin-cli listunspent 0 9999999 "[\"someLocalAddress\",\"someOtherLocalAddress\"]" will provide you with the exact number of confirmations for every transaction to these addresses so you will not need to perform all these iterations.

Replacing 9999999 with what you consider in your application to be a confirmed transaction will only return the unconfirmed transactions, which is more effective if you already keep track of the confirmed transactions in your database.


Everybody has a public and private key.

Everybody is able to generate any number of private keys ("randomly") and derive a public key from it.

If A sends bitcoins to B:
B is generating an address and sends it to A

B forms an address out of the public key itself derived from a "randomly" generated private key.

This addresses are generated for each transaction.

Ideally yes, unfortunately (privacy-wise) it's a decision made by the sender. Sending twice to the same address is possible.

A need to sign something with his private key and B's address

This something is, basically, the transaction itself.
EDIT: To answer the question title :-)

What is physically an address in bitcoin

Some bytes either stored on your hard disk or in memory, which are part of a transaction and which are to be interpreted as a script describing what conditions should be met to spend the coins "next to" this address.


How do other nodes know my balance with LN?

The two channel owners have cooperatively locked up a sum of Bitcoin in a 2-of-2 multisig address.

The only thing that they can do, is to renegotiate how much each of their balance shares is. This is what happens when they send funds in Lightning: the sender offers to increase the balance share of the recipient and at the cost of reducing their own.

Likewise, when you attempt a multi-hop payment, you offer a conditional smart contract to your channel partner. Your channel partner gets to increase their channel balance share at your cost, when they prove to you that they have forwarded the sent sum to the recipient.

Since the sum of the two balance shares can never exceed the channel capacity, nobody can ever send more money than their balance share: Their channel partner would simply deny the payment attempt.


I need to import a private key - what is the entire process? [Electrum]

The entire process is as follows: (these instructions are correct for Electrum v3.0.6)

Install Electrum. The installation methods vary but, the official download is here. On some varieties of Linux it is in the default distro repository.
Run Electrum.

Choose Automatically Connect and click on Next.
Name your wallet if you like or accept the default and click on Next.
Select Standard Wallet and click on Next.
Select Create a new seed and click on Next.
Select Segwit and click on Next.
Securely, privately and accurately store your seed. This is your wallet backup. If it is lost all your BTC is gone permanently. Click on Next.
Type your seed in the box and click on Next to verify you have it correctly.
Set a good password that you will never forget. This must be secure to ensure your wallet cannot be stolen. Click on Next.
Your wallet is setup.

With Electrum setup and running, go to View -> Show console.
Click on the Console tab.
Using the instructions from here:

Type (or copy and paste) at the >> prompt key = 'your_key' and press Enter (leave the single quotes in).
Type (or copy and paste) at the >> prompt txin_type, secret, compressed = bitcoin.deserialize_privkey(key) and press Enter.
Type (or copy and paste) at the >> prompt wif2 = bitcoin.serialize_privkey(secret, compressed, 'p2wpkh-p2sh') and press Enter.
Type (or copy and paste) at the >> prompt print(wif2) and press Enter.

Highlight and copy the one-line string that is output (make sure you do not get any extra spaces) in your clipboard or, write it down.
Click on Wallet -> Private Keys -> Sweep
Paste the string you copied into the big box. The address that is pre-filled in starting (as of writing) with bc1 is one of your many receiving addresses. The balance will be transferred to that address.
Click on Sweep and follow the prompts (I didn't proceed to actually do this step - when I originally tested I used completely different steps to 'Import, not Sweep' just to prove it worked and not take the balance).
This will create a Bitcoin transaction transferring the balance to your own address.
Wait for at least 1 confirmations.

Done!

If you just want to import the address to make sure it is correct without trying to sweep you need different steps.


How to Call JSON-RPC SendToAddress when the Wallet is Encrypted?

Not in the current code. The way it works now, you have to make two RPC calls -- one to unlock the wallet for a period of time (walletpassphrase) and one to do the transaction (sendtoaddress). You can follow up with a command to lock the wallet immediately, if desired (walletlock).

  walletpassphrase <passphrase> <timeout>
  Stores the wallet decryption key in memory for <timeout> seconds.

  walletlock
  Removes the wallet encryption key from memory, locking the wallet.
  After calling this method, you will need to call walletpassphrase again
  before being able to call any methods which require the wallet to be unlocked.


Best place to read about the algorithms and protocols underlying bitcoin?

Bitcoin: A Peer-to-Peer Electronic Cash System

by: Satoshi Nakamoto

That would be a good place to start.


Can "Confidential Addresses" preserve user privacy?

A lot of these terms end up being confusing and a little non descriptive. In the "elements project" nomenclature a confidential address is an encoding of a P2PKH key which includes the necessary information to make a confidential transaction, one which uses range proofs to blind the monetary units. There's nothing confidential about the address itself, it's functionally just a public key as normal.

Objectively range proofs used in this way aren't enough to provide significant privacy in an overall system, and come at a very large size and computational cost to verify. They can potentially increase privacy, and increase the utility of other technologies such as CoinJoin, but they are not a solution in of themselves.

By hiding the values in transactions they can obscure some of the uses of privacy-violating technology such as exchange front running where transactions on the network reveal potentially market moving behavior. They can also improve the usability of transactions which mix unlike outputs together such as CoinJoin, where you no longer need to be as careful about making sure sizes are the same to obscure information leakage.

It has been demonstrated in the ZCash network that any situation where a user is able to choose between cheap, and private, they will opt for the cheapest possible option no matter what. For systems like zk-SNARKS and range proofs this dramatically reduces the effectiveness of the system overall, as there's less obscurity in which to hide. Range proofs also have this properly, regrettably, unless the choice to use them is removed.

In short, it's very difficult to determine if these technologies have a use in the real world.


How to access Blockchain remotely for statistics study?

As you mention in your comments, blockchain.info can provide this information.

You can get a raw block in JSON format using the /rawblock/ links, for example:
https://blockchain.info/rawblock/0000000000000000008d49f25f7dd5d3704575a348e030a1d2e5f396b3e80516

Then you can also get it as the hex-encoded raw block by adding ?format=hex to the url:
https://blockchain.info/rawblock/0000000000000000008d49f25f7dd5d3704575a348e030a1d2e5f396b3e80516?format=hex

Hope that's what you are after :)

EDIT: Oh, just re-read your comment, you want just the headers? In that case you probably can't use blockchain.info, you could try BlockCyhper instead:

For example: https://api.blockcypher.com/v1/btc/main/blocks/294322

You can find more info about their API here: https://www.blockcypher.com/dev/bitcoin/#blockchain-api


relating the UTXO set to the total supply of bitcoins

This is an apple : oranges comparison. The size "Number of Unspent Transaction Outputs" set is independent from the number of bitcoins in existence.

An unspent transaction output might be for a fraction of a bitcoin (some number of satoshis) yet it still counts as one unspent transaction output, a member of a very large set (over 55 million UTXO's according to the chart provided).

To put this in other terms, suppose every single UTXO was spent into a single bitcoin address. (It will never happen, this just a thought experiment)  Then that address would hold all the bitcoins in existence, (a bit more than 17,100,000) and then there would only be one member in the "Unspent Transaction Output" set.


Recovering private key when someone uses the same k twice in ECDSA signatures

Here is a fun thing about ECDSA signatures: you can always replace s with -s (mod N) and the signature is still valid.  So when you are deducing the k value, it is possible that someone else flipped the sign of s and you will have to undo it.  So, you have to make a list of candidates for k (kandidates?) and then select whichever one actually works.  A good list of k candidates would be:

(z1 - z2) / (s1 - s2)
(z1 - z2) / (s1 + s2)
(z1 - z2) / (-s1 - s2)
(z1 - z2) / (-s1 + s2)

I like to use the Ruby ECDSA gem to play around with this kind of stuff.  Here is the code I wrote which successfully finds the private key for the first input data you gave:

require 'ecdsa'

public_key_hex = '02a50eb66887d03fe186b608f477d99bc7631c56e64bb3af7dc97e71b917c5b364'
msghash1_hex = '01b125d18422cdfa7b153f5bcf5b01927cf59791d1d9810009c70cd37b14f4e6'
msghash2_hex = '339ff7b1ced3a45c988b3e4e239ea745db3b2b3fda6208134691bd2e4a37d6e1'
sig1_hex = '304402200861cce1da15fc2dd79f1164c4f7b3e6c1526e7e8d85716578689ca9a5dc349d02206cf26e2776f7c94cafcee05cc810471ddca16fa864d13d57bee1c06ce39a3188'
sig2_hex = '304402200861cce1da15fc2dd79f1164c4f7b3e6c1526e7e8d85716578689ca9a5dc349d02204ba75bdda43b3aab84b895cfd9ef13a477182657faaf286a7b0d25f0cb9a7de2'

group = ECDSA::Group::Secp256k1

def hex_to_binary(str)
  str.scan(/../).map(&:hex).pack('C*')
end

public_key_str = hex_to_binary(public_key_hex)
public_key = ECDSA::Format::PointOctetString.decode(public_key_str, group)

puts 'public key x: %#x' % public_key.x
puts 'public key y: %#x' % public_key.y

msghash1 = hex_to_binary(msghash1_hex)
msghash2 = hex_to_binary(msghash2_hex)
sig1 = ECDSA::Format::SignatureDerString.decode(hex_to_binary(sig1_hex))
sig2 = ECDSA::Format::SignatureDerString.decode(hex_to_binary(sig2_hex))

raise 'R values are not the same' if sig1.r != sig2.r

r = sig1.r
puts 'sig r: %#x' % r
puts 'sig1 s: %#x' % sig1.s
puts 'sig2 s: %#x' % sig2.s

sig1_valid = ECDSA.valid_signature?(public_key, msghash1, sig1)
sig2_valid = ECDSA.valid_signature?(public_key, msghash2, sig2)
puts "sig1 valid: #{sig1_valid}"
puts "sig2 valid: #{sig2_valid}"

# Step 1: k = (z1 - z2)/(s1 - s2)
field = ECDSA::PrimeField.new(group.order)
z1 = ECDSA::Format::IntegerOctetString.decode(msghash1)
z2 = ECDSA::Format::IntegerOctetString.decode(msghash2)

k_candidates = [
  field.mod((z1 - z2) * field.inverse(sig1.s - sig2.s)),
  field.mod((z1 - z2) * field.inverse(sig1.s + sig2.s)),
  field.mod((z1 - z2) * field.inverse(-sig1.s - sig2.s)),
  field.mod((z1 - z2) * field.inverse(-sig1.s + sig2.s)),
]

private_key = nil
k_candidates.each do |k|
  next unless group.new_point(k).x == r
  private_key_maybe = field.mod(field.mod(sig1.s * k - z1) * field.inverse(r))
  if public_key == group.new_point(private_key_maybe)
    private_key = private_key_maybe
  end
end

puts 'private key: %#x' % private_key

The output of the program is:

public key x: 0xa50eb66887d03fe186b608f477d99bc7631c56e64bb3af7dc97e71b917c5b364
public key y: 0x7954da3444d33b8d1f90a0d7168b2f158a2c96db46733286619fccaafbaca6bc
sig r: 0x861cce1da15fc2dd79f1164c4f7b3e6c1526e7e8d85716578689ca9a5dc349d
sig1 s: 0x6cf26e2776f7c94cafcee05cc810471ddca16fa864d13d57bee1c06ce39a3188
sig2 s: 0x4ba75bdda43b3aab84b895cfd9ef13a477182657faaf286a7b0d25f0cb9a7de2
sig1 valid: true
sig2 valid: true
private key: 0xe773cf35fce567d0622203c28f67478a3361bae7e6eb4366b50e1d27eb1ed82e


Why is bitcoind removing keys from keypool?

The keypool is ordered, not just a set of keys being watched. This allows for addresses to be given out in derivation order, as well as maintaining the gap limit. When an address is used, all keys that come before it will also be marked as used. This is done to ensure that already used addresses are not accidentally reused.
So when you give out and use a random address in the range, you end up having all of the previous keys in the range be marked as used.
Removing keys from the keypool is purely for giving addresses out to the user and to be able to generate further addresses. It does not effect the watching behavior; keys removed from the keypool will still be watched.
The reason that you see a performance hit is because removing from the keypool deletes a record from the database in addition to writing several scripst to the database. Furthermore, if the keypool size drops below the configured keypool size due to these removals, the keypool will be refilled which will involve additional database writes. These all acquire a lock on the wallet which prevents other threads from accessing the wallet, and writing all of this data (especially tens of thousands of keys) can take a long time.
To avoid this problem, I highly suggest giving out addresses in order, not randomly. Otherwise you may not want to add the keys to the keypool although that means that you will lose the keypool refilling to keep the range full.


No, it's not possible. With the exception of Script commands, nothing in the blockchain is executed by Bitcoin Core: it's just data. Scripts are only able to do things like hashing and arithmetic, so it's hard to imagine any sort of Script-based malware.

It's conceivable that malware (once delivered to your computer via other means) could use the blockchain to download additional malware or transmit signals to infected machines, but it seems like it'd be way more trouble than it's worth to me. (if you have any sort of Bitcoin-informed malware, the most profitable thing to do would almost certainly be to steal the user's bitcoins, not use the blockchain for clandestine messages)


How do Lightning channels interact with the blockchain?

Does opening a channel mean that a 2-to-2 multisig address (3xxxx) is created?

Yes. But it's not always a 3... address. Such addresses must be segwit, and there are two types: nested (3... address) and native (bech32 addresses, bc1..).

  And then both parties put money into the address?

For now, only one party puts money into the address. But ideally both will be able to in the future. This is only done for simplicity right now.

  What if someone pays money to the address on main chain while the channel is open?

It doesn't matter because Bitcoin does not use a balances or accounts system. Spending Bitcoin means that you are spending from a previous transaction output. So the commitment and closing transactions in a channel will refer to a specific transaction output. That output is completely unaffected by additional payments to an address. Likewise such payments will not effect the channel state.

  Does closing a channel mean that a transaction is made which splits the money based on agreement

Yes. The money is split according to the most recent channel state, i.e. the balance of each party.


Will I need to keep track of my old private keys forever?

I think the core of the problem is that we call base58-encoded public key hashes "addresses", no matter whether people are willing to accept payments to them.

In my opinion, they are just identifiers for a public key - something internal in Bitcoin's technology. Humans shouldn't ever see them, unless they are debugging.

Satoshi originally didn't intend to use the current base58 addresses as "payment destination" - he thought pay-to-IP (where the public key was negotiated on the spot) would be the common way of doing transactions. The pay-to-pubkeyhash-via-P2P was only added later for cases where the receiver was offline. Pay-to-IP had several problems, and became obsolete, but it had a lot of advantages compared to what we have now. I think the solution is going back to something like that, like a pay-to-URI where again keys are negotiated at the time of the transaction. It means you're always sure the key used is still active, private keys don't need to be retained forever, no key is ever reused (better for Bitcoin's privacy model) and you instantly get support for attaching messages or refund information to transactions.

Of course, people will probably keep the private keys anyway, for example in an archive wallet like mentioned in other answers to this questions. But in my opinion, it shouldn't be a disaster when people don't.


What languages can I write plugins for c-lightning in?

Plugins can be written in any language as long as a client library for that language exists.

The command line API and the Plugins communicate with lightningd over a unix domain socket using JSON RPC 2.0.

As far as I know no Java / Scala lib exists. I have started creating one at this pull request: https://github.com/ElementsProject/lightning/pull/2223

also it makes sense to look at the python plugin lib to see how the format of the JSON RPC 2.0 is used. Check out: https://github.com/ElementsProject/lightning/blob/master/contrib/pylightning/lightning/plugin.py which is really just a client lib talking to the UNIX Domain socket and parsing / dispatching the JSON RPC responses. So as soon as you create this in Java / Scala you should be able to create as many plugins as you wish. You could build upon my pull request (though I have started with the client library for the standard API)


How is it possible to detect system wide segmentation?

What happened in the March 2013 fork was that two different versions of the bitcoin client disagreed about what a valid block was. You could look for a block reorg, but that will only show up when the fork is fixed. How could you detect a hard fork as soon as it happens?
Well, you could run 5 different versions of the bitcoin client at once, then figure out when they get out of sync for a few minutes. That's when you know there's a version-specific fork. I should note that this is mainly aimed at getting the client fixed faster, not protecting a merchant.
Detecting being out of sync
You could write a program that polled all of clients looking for their latest block.
Psuedocode:
run on each node
  block number = node.getblockcount()
  latest block = node.getblockbycount(block number)
  latest block hash = latest block['hash']

Oh, by the way, this requires the getblock patch.
Now, if these differ for more than a minute or so (and you're not still in the initial syncing phase) then you might have a hard fork.
Making sure you have a good connection to the network
Let's say that you had a 0.8 client that was only connected to 0.7 clients. Even though it would have accepted the blocks in the March fork, it never even hears about them, meaning we won't detect the fork.
I'm not sure how to solve this. Perhaps upping MAX_OUTBOUND_CONNECTIONS ?
Preventing false alerts
If network conditions were really bad, then it's possible that one client would receive a new block, but the others wouldn't. You should use addnode to make them all talk to each other.


Do miners keep a "balance" of how much each public key has?

The notion of accounts is for human convenience. The system doesn't care that you think of all the coins accessible by the same private key as a single account.

Instead, miners keep an efficiently organized database of all UTXOs (unspent transaction outputs). When a miner validates a transaction, it checks that each input corresponds to a valid UTXO.

There's no need to keep the UTXO database in memory. Storing it on disk is fine as long as it is efficiently indexed. Since it's kept for precisely for this purpose, it is efficiently indexed for this purpose.


Create a transaction which sends bitcoin to the address it's being sent from?

Transactions don't send from address to address.

Transactions spend specific coins ("transaction outputs") and create new coins as a result. Every coin has an amount and an owner (identified by its address).

While it's possible to define the "balance" of an address as the sum of the values of all coins with that address as owner, this is not how the system works internally. Addresses are just an authentication mechanism to make sure coins can't be spent without proving ownership. In particular, a transaction that sends coins "back to the same address" is in no way different from one that doesn't. It's still spending a coin and creating a new one - just one that happens to have the same owner. In order to spend a coin you need to prove you own it.


Save transaction space with economic Scripts

Yes, that would save space. However, there are two ways in which your scripts are different.

It checks if there is a value that hashes to the hash of x at the beginning,
It performs the operation in step 1 whether we're executing branch 1 or 2.

Your first script can be rewritten like so to fix that:

OP_NOTIF
  <key A> OP_CHECKSIGVERIFY
  OP_0
OP_ELSE
  OP_1
OP_ENDIF
OP_SWAP
<key B> OP_CHECKSIG
OP_IF
  OP_SHA256 <hash of secret x> OP_EQUAL
OP_ENDIF

Space savings

Each public key is 34 bytes (33 bytes for compressed key plus 1 for data push). Blocks are about 617k at the moment, and the total fees for a block are about 0.223 BTC. Each public key therefore costs:

34 / 617000 * 0.223 * 1e8 = 1228 satoshis

A small amount, but it would add up over time.


View historic USD prices when transactions were made

I was also looking for similar solution and have come up with a manual one.

Note: you need to know the Bitcoin address of the sender and receiver, or transaction hash. let us suppose we know a bitcoin wallet address

  3BtSyeNf24tEXkEYKiMmDjM98W7Yqudh3w

and it belongs to person A, following steps can be executed to know about the transaction details

Step 1: Goto www.blockchain.info and enter the respective address into website's search bar.

Step 2: resulting page will show transaction details which are as follows

      a. Transactions performed = 2
      b. Total Received = 0.02608688 BTC
      c. Final balance = 0 BTC

[explanation: Respective Address had two Transactions, 1st. it received 0.02608688 and it spent complete amount because its remaining balance is 0 BTC. Each transactions is explained below.]

Step 3: Evaluating transactions

      a. **First Transaction** hash is
         0d704a15bd8d56812dff9d067c0510afb4185190d2816513dd8eca777b7ec72c
      b. This transaction was confirmed at 2017-10-09 16:08:56
      c. Using historic Bitcoin price reference at coindesk.com/price/,it
         was found that at that moment 1 BTC was equal to 4722 USD.
      d. Hence, first transaction shows that person A received 123 USD
         worth of bitcoin. (0.02609 BTC * 4722 USD = 123 USD)

      e. **Second Transaction** hash is
         fe5bd13f81d26166937efc472f8a30090e7f30e721517ad212bc06e48f8e1e96
      f. This transaction was confirmed at 2017-10-15 16:05:17
      g. Using historic Bitcoin price reference at coindesk.com/price/,it
         was found that at that moment 1 BTC was equal to 5700 USD.
      h. Hence, Second transaction shows that person A transfered
         accumulated BTC for 148 USD .
         (0.02609 BTC * 5700 USD = 148 USD).

Step 3: Net difference

      a. Person A gained 20% in 6 days (one perspective)
      b. Net worth of holding is zero because wallet holds 0 BTC

I hope i cleared some of the confusion.


This looks like plain old bad luck.

P2pool is a small pool and 3 weeks is a short time. With current hashpower at pools this is like measuring BTCGuild for less than 12 hours. BTCGuild can have bad luck for 12 hours, and P2pool can have bad luck for 3 weeks.

That said, all pools underperform on average when compared to a simple expected income. That's because of orphaned blocks, typically 1 to 2 percent. And if you count stale/rejected shares in the hashrate, then it will underperform even more. But if income from transaction fees is not included in that expected average, then that may even out the orphans and stale work.


You can create fake transactions and blocks including fake transactions all day long if you want. Your problem would be getting other people to accept those blocks and they won't because they can very easily see that it contains fake (better word: invalid) transaction(s) and simply disregard those blocks completely.

The first invalid block wil never be accepted by any non-accomplice so it doesn't matter how many blocks are put on top of that, they won't be accepted either.


Is there a reason SatoshiDice & BitLotto use 0.00543210 BTC, and not 1 satoshi, to customize pay-to addresses?

Well, what that is called is a hack.  It is a hack to make the system work in a way that is wasn't meant to work.

By definition, hacks aren't thought out very well and often aren't the optimum method -- if not outright flawed.  But they do in many instances, fix the immediate need.

In most every bet to BitLotto and SatoshiDICE there is an output address for change.  These services can't know if that change was meant to be the alternate pay-to address or if it was just the change.   One Satoshi would be a bad choice for this "special indicator" as that happens naturally quite often.  An amount that doesn't occur very often would be an amount like "0.00543210".  The frequency of change being 0.00543210 is much, much lower than it being 0.00000001 BTC.

But the chance is not zero.  If I have a coin with 0.25543210 BTC on it and I sent a 0.25 wager, I'll get back 0.00543210 as change.  Since that change is for an address in my own wallet, then even though SatoshiDICE might send the winnings to that change address I'll still receive them.  But the normal mode for these services is to always pay back to a sending (input) address, so returning to the change address frequently becomes a service issue as it is harder to understand how it works.   So ideally, this special number is one that wouldn't normally get be used for change.

But if instead I had actually made both a payment of 0.00543210 to someone and a bet to SatoshiDICE in the exact same transaction, then the winnings would go to that someone and not back to me.  If I know that 0.00543210 is of special significance with SatoshiDICE I'll know to never make a transaction with that amount in it when I'm also including a SatoshiDICE bet.  If the number were something else, like 0.00814271, that also would be infrequently used naturally, but it also wouldn't be one that I would recognize and might accidentally be an amount I would pay in this hypothetical bet statement that I combine with real-world payments.

So I'm going to come to the conclusion that to eliminate even the extremely rare chance that the payout goes to the wrong party, these services chose an easily recognizable amount so that it might save a person from making that mistake.  This amount would also preferable be a low value so that it doesn't suck too much betting capacity from the bettor's wallet with each use.

What is an amount that serves both those aims?  0.00543210.


Block Broadcasting - Unsolicited Block Push

We can find all instances in the code where the client will send a block message by searching for PushMessage("block". This is the only match:

void static ProcessGetData(CNode* pfrom)
{
[...]
    pfrom->PushMessage("block", block);

(Source.)

This means that the standard client only ever sends a block message when specifically asked for it. That incoming getdata message is probably triggered in turn by sending the remote node an inv message. (Though that's not necessary - you can ask for a block that the other node hasn't advertised.) This is the code that sends inventory messages:

//
// Message: inventory
//
vector<CInv> vInv;
vector<CInv> vInvWait;
{
    LOCK(pto->cs_inventory);
    vInv.reserve(pto->vInventoryToSend.size());
    vInvWait.reserve(pto->vInventoryToSend.size());
    BOOST_FOREACH(const CInv& inv, pto->vInventoryToSend)
    {
        // If the other node already knows the message, don't send
        if (pto->setInventoryKnown.count(inv))
            continue;

        // trickle out tx inv to protect privacy
        [...]

        // returns true if remote node hasn't seen it
        if (pto->setInventoryKnown.insert(inv).second)
        {
            // Add to the list of inventory messages to send
            vInv.push_back(inv);
            // If there's 1000 inventory messages queued up, send them
            // (Protocol limit is 50000 at a time.)
            if (vInv.size() >= 1000)
            {
                pto->PushMessage("inv", vInv);
                vInv.clear();
            }
        }
    }
    pto->vInventoryToSend = vInvWait;
}
// Send any that are left over.
if (!vInv.empty())
    pto->PushMessage("inv", vInv);

(Source.)

(pto represents the remote node in the above code.)

So the page you're looking at describes a behavior that you could implement, and that other clients will accept, but it doesn't describe the current core client behavior.


I don't have an answer to your question directly, but it's worth pointing out that anything other than 32 x 0.1btc inputs and 32 x 0.1btc outputs provides worse anonymity. Even having 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.3, 0.1, 0.1 gives away some information that likely 2 of the inputs were 0.1btc above a number divisible by 0.3. Maybe there's a peak on a benefit/cost curve, but it's still a trade-off against privacy. There are other solutions outside of Bitcoin (that vastly improved on the concepts of coinjoin) like MimbeWimble which do what it sounds like you want in terms of cheap coinjoining, but with other benefits too, that Bitcoin is unable to implement because of its design


blockchain.info does not want to import my bcc private key

Never mind, I used btc.com wallet instead of blockchain.com.
btc.com worked fine!


It is safer from some things, but not others.

For instance, let's say you don't have your Mycelium seed backed up (which you should do), and you drop your phone in the toilet.  This could cause a loss of funds, if your phone no longer functions.  You won't have this problem with Coinbase.  Someone could also stop you at gunpoint on the street, and demand you transfer your phone's bitcoin to them.  If you don't have access to your Coinbase funds from your phone, this type of robbery won't work.

On the other hand, Coinbase can freeze the money you store with them (both fiat and bitcoin) for basically any reason.  This would usually be at the request of a government or another financial institution.  When an online service holds your bitcoin, it's best to think of it at their bitcoin, and you just have an agreement to be able to spend it.  That agreement can change, and there's not much you can do about it.

Different types of wallets mitigate different risks, and in different ways.  It's not as simple as one being "safer" than the other.  I wrote about this a lot more in a different answer, if you care to read it.


How many CPU's work on blockchain today?

I last recently did this calculation:
An Antminer S9 uses 1,2kW power, which is 1,2 KiloWattHours (kWh). If we multiply with 24 and with 365 I get around 1000kwh. At Blockchain.info there was end of November 10,445,729,472 GH/s, or 10’445’729 TH/s. Divided by the power of an Antminer S9 with 13 TH/s, I’d need 800’000 Antminer S9. They would consume 10’000 KWh, and if I need 800’000, I get 8’000’000’000 KWh, which is  8’000’000 MWh (Mega Watt hours), is 8’000 GWh (Giga Watt hours). Not all are using S9, so it might be a bit higher...

Compare this to a water cooker, or a hair dryer, which uses 2kw. Instead of making tea, or drying your hairs, consider mining a bit!

In summary this means, on the other side of the power plug must be a power system which can supply ~1000 MegaWatts. This is the range of large industrial systems like carbon or atomic power supplies. Or even better, 500 wind power turbines at 2MW.

I cannot predict the future in 2020, but this would be a bit too much...


It's the choice of whatever is doing the display how it wants to display the information the Ripple network provides.

The original transaction is provided. This contains the source account, the destination account, the maximum amount the transaction could pay (the "destination amount"), the maximum amount the sender was willing to pay (the "send maximum"), and an indication that partial payments were allowed (the "partial payment" flag).

In addition, the transaction metadata is provided. This contains the transaction result code which, if not success, indicates no payment at all was made. If the payment was able to be made completely, no "DeliveredAmount" field will be present in the metadata, indicating that the destination amount was in fact delivered to the destination. If the payment was in fact a partial payment, a "DeliveredAmount" field will be present, indicating the amount paid to the destination.

The metadata also contains the other consequences of the transaction. This would include reducing the balance of the sender, crediting and debiting market makers involves in the transaction, reducing or removing offers the payment used, and so on.

Some gateways do not credit partial payments automatically. It is not a good idea to make a partial payment unless there's a good reason to do so and you know the recipient wants or expects partial payments.


Latency of connections between nodes matters when mining because, essentially, a valid block found that reaches the highest number of peers first wins that block height.

For example, if miners Alpha and Beta both find within a few milliseconds of each other, their incentive to push that block around to connected clients as quickly as possible is that they get their block on the chain first and thus are able to claim the reward.

More technically, if we're currently at block height 10, and miners are hashing to find a solution that will become block 11, and Alpha and Beta both find a block, they can both claim it to be block 11. However, it only actually becomes block 11 when 51% of nodes believe that a certain block is the 11^th block. The other block, the valid block that lost the exposure contest, becomes an orphaned block, and gets pruned when the height 12 blocks start coming in.


What problems exist with the alt coin Namecoin and what can be done to fix them?

First, NMC is not worthless, it have a value and is traded on bitparking ( https://exchange.bitparking.com/main )  and btc-e ( https://btc-e.com/exchange ), with decent daily trading volume; people saying nmc is worthless are just people wanting to attract you to other altchains( most of them being scams imo ) .

Second, namecoin is an opensource network, it cant really die as long as people use it.
 Also, namecoin is the oldest and most serious alternative coin ( altchain ) to bitcoin.
 NMC price have gone down with merged mining ( increased supply ), but merged mining also made namecoin very secure and long lasting.
 As long as someone will maintain the software ( https://github.com/namecoin/namecoin ) namecoin will rock as the oldest and best altchain.

Real issues are :

possibility to store small files in the blockchain, could lead to increased blockchain size ( see https://bitcointalk.org/index.php?topic=145278.0 and https://github.com/runn1ng/namecoin-files )
small community, not enough tools, websites, graphical client . . . )


What prevents miners from mining more bitcoin after 21million btc?

The Bitcoin protocol allows block authors to create a limited amount of new bitcoins in the outputs of the coinbase-transaction (which also collects the transactions fees) in each block. The amount of the so called block subsidy is limited by the consensus rules.1 Creating more than the allowed amount makes a block invalid to other Bitcoin nodes.

Each full node unilaterally enforces the consensus rules. This means that while a miner would be able to create a block that breaks the consensus rules, every other full node in the network would recognize it as invalid, drop the block, and ban the peer that sent it to them.

A change in the consensus rules that allows blocks that were previously considered invalid is called a hardfork. Hard forks require social consensus of the complete ecosystem or will cause a split of the network as each node operator determines for themselves which software to run. Even if a majority of the hashrate and a majority of the network's nodes hardforked to a new version of the Bitcoin protocol that allowed blocks with a higher block reward, the remaining nodes enforcing the original consensus rules would consider it invalid and continue to follow their own rules. Therefore, an intolerant minority may be able to veto a hardfork, especially if this minority has a significant share of the economic weight. If the economic majority prefers the original rules, miners following the hardforked chain may find it difficult to sell their mining reward. This is essentially what happened in the case of the SegWit2x hardfork attempt.

In the case that both protocol versions have some economic support, a persistent fork may be calved in the form of an airdropped altcoin. This is essentially what happened in the cases of Bitcoin Cash spinning out from Bitcoin, and Bitcoin Cash calving Bitcoin SV.

1
The block subsidy started at 50 bitcoin per block and halves every 210,000 blocks. We're currently in the third era where miners are allowed to create 12.5 bitcoin per block. Having recently passed block 600,000, more than 18,000,000 bitcoins have been found already, and the next halving to 6.25 bitcoins per block is coming up at block 630,000 in spring 2020.


How do you answer the question "Why 10 mins?" for beginners?

Block time is a tradeoff between:

Network propagation time
Amount of work wasted due to chain splits (miners continuing to work on the last block before becoming aware a new one was found)


Identifying the type of wallet that's being used?

No, you cannot identify what wallet software was used to create an address. This is impossible to do as all addresses are the same type of data.


How to configure bitcoind to wait for X confirmations to make the payment submitted

You could use the listunspent RPC command. It takes a parameter which allows you to filter out UTXOs which have less than X confirmations.
Example (from the manpage):
bitcoin-cli listunspent 6 9999999 "[\"bc1INVALIDq09vm5lfy0j5reeulh4x5752q25uqqvz34hufd\",\"bc1INVALIDq02ad21edsxd23d32dfgqqsz4vv4nmtfzuklhy3\"]"


Is it possible to increase the prune size and get bitcoind to pull previous blocks?

Bitcoin Core doesn't have such a feature. The prune depth controls how many blocks are kept, and you can change that (-prune=N option on the command line or prune=N in bitcoin.conf), but once a block is pruned, it is gone. If you want to add blocks back, for now you'll need to resync from scratch.
There is no technical reason for this; it's perfectly feasible to implement a mode where desired old blocks are refetched and inserted into the blocks datadir again, but this simply isn't implemented at this point.


Why bitcoind does not respect rpcbind for testnet?

I still have no idea as to WHY this is happening. But changing config to this:

[main]
# Allow JSON-RPC connections from, by default only localhost are allowed
rpcbind=127.0.0.1
rpcbind=10.18.0.1
rpcallowip=127.0.0.1
rpcallowip=10.18.0.0/24

[test]
# Use the test chain
testnet=1

rpcbind=127.0.0.1
rpcbind=10.18.0.1
rpcallowip=127.0.0.1
rpcallowip=10.18.0.0/24

Solved the issue

admin@az-bitcoind:~$ sudo netstat -natp | grep 8332
tcp        0      0 10.18.0.1:8332          0.0.0.0:*               LISTEN      566/bitcoind
tcp        0      0 127.0.0.1:8332          0.0.0.0:*               LISTEN      566/bitcoind
tcp        0      0 10.18.0.1:18332         0.0.0.0:*               LISTEN      567/bitcoind
tcp        0      0 127.0.0.1:18332         0.0.0.0:*               LISTEN      567/bitcoind

No idea why I have to duplicate this settings. I assumed that as long as [main] or [test] are not specified, all config options apply in general


Read the "value" being redeemed in a Bitcoin P2SH Script

Inputs do not reference the value of the UTXO they spend. You need to look up the spent UTXO to find the value. Usually, this information is available to a node via the UTXO set, or can be looked up by inspecting the transaction that created the UTXO.


I think that it shows "booooo" when a share is rejected, and "yay!!!" when a share is accepted.

In x/y (z%)

x is the number of accepted shares
y is the number of total shares submitted (accepted+rejected)
z is x/y as a percentage (the percent that are accepted)

  Why do I see a 'Yay' with a 70% match, and a 'Booo' with a 75% match?

Because you had a success which raised you to a 70% success rate, and later (after a few more successes) had a rejection which lowered you to a 75% success rate.

(BTW, I hope you know that mining any SHA256 or Scrypt coin on a CPU is almost certain to cost you more than it can earn you)


RPC connection fails after too many queries

I haven't had this issue before and I've been spamming my RPC pretty hard.

Does your bitcoind already contain the whole blockchain or is it still updating?

There's a debug.log and db.log in the bitcoind data directory, I guess those will tell you what's wrong.


Unless we can see exactly where the bots are operating and exactly how the propagate their transactions, we'll never know exactly how one bot wins over another on addresses where the private key is known. However, we can guess on how they win:

These bots are run by miners. As soon as they get a transaction that outputs to a known address, they immediately create a transaction that spends the output to one of their addresses. If they happen to mine that block, the output is theirs. If not, they can still propagate the transaction and hope to get the output anyway.
The bots run on really well-connected nodes. Multiple bots spending the same output is essentially a double-spend. In a double-spending situation, the better connected and faster propagating will win (in the absence of the above). It's possible someone has direct connections to the most well connected nodes and can propagate such transactions very quickly.

My guess is on #1, though it's hard to say for sure. If it is #2, it's possible it's a well known website like blockchain.info.

Basically, we're speculating, but you, as an independent node without any special relationships to miners or large nodes, stand no chance of winning over either #1 or #2.


What would happen if there were two "disjoined" versions of bitcoin with the same popularity?

That is what is considered a hard fork, assuming that both halves have their reasons to not change it's versions and that previous blocks in the blockchain are considered valid in both clients then we will have 2 types of coins.

Coins generated before the fork (A) will be freely double spendable transactions using this kind of inputs will be accepted by both groups of miners and considered valid.
Coins generated after the fork (B, C), non double spendable and transaction that use this kind of coins will be accepted by only one of groups the other will discard it.

As long as you mix A with only B or C in your transactions they will be accepted by half of the miners, you could not mix B and C as you client will have only one blockhain.

Services and clients that are connected to the network will be using chain B or C, even swapping and having reorgs of really large portions of the chain if the client considers valid both chains, but on a given time a client can only have one chain or the other.

In such scenario clients and merchants will choose B or C for whatever reasons and get a client modified to only allow B or C blocks, that will disable double spending attacks agains the same merchant (but will still allow to double spend between merchants using different chains).
Maybe new clients will be created to block all transactions using A coins.

Anyway, in real life this would not matter, if such an event happens for more than a couple of hours, the fork and double spending problems will crash bitcoin value, merchants will disconnect from the network and stop accepting bitcoins and miners will have no reason to continue mining B or C, it would be better for them to start a new coin altogether (Bitcoin 2  and Bitcoin^2) than continue working on that.


What do I change in my config to access my local NXT NRS Server/Client from another computer on my local LAN?

what I did was the following, create a nxt.properties file in the conf/ directory and put this in the file:

This basically makes your NXT NRS server publicly available on your local lan or via the internet if your looking to setup a public server.

# Hosts from which to allow http/json API requests, if enabled. Set to * to allow all.
# Can also specify networks in CIDR notation, e.g. 192.168.1.0/24.
#nxt.allowedBotHosts=127.0.0.1; localhost; [0:0:0:0:0:0:0:1];
nxt.allowedBotHosts=*; localhost; [0:0:0:0:0:0:0:1];

# Host interface on which to listen for http/json API request, default localhost only.
# Set to 0.0.0.0 to allow the API server to accept requests from all network interfaces.
#nxt.apiServerHost=127.0.0.1
nxt.apiServerHost=0.0.0.0

# Hosts from which to allow NRS user interface requests, if enabled. Set to * to allow all.
#nxt.allowedUserHosts=127.0.0.1; localhost; [0:0:0:0:0:0:0:1];
nxt.allowedUserHosts=*; localhost; [0:0:0:0:0:0:0:1];

# Host interface for NRS user interface server, default localhost only.
# Set to 0.0.0.0 to allow the UI to be accessed on all network interfaces.
#nxt.uiServerHost=127.0.0.1
nxt.uiServerHost=0.0.0.0


Why does Bitcoin use ECDSA, instead of plain old hashing, to secure transaction outputs?

You must reveal the secret in order to spend the output, else there is no way other users could verify that your hash is indeed the correct one. Once you reveal that secret, anybody could attempt to create a competing transaction which spends to a different output - miners in particular would be able to confirm this transaction into a block and ignore your own.
The purpose of using ECDSA is so that a transaction which spends some output is signed by the private key corresponding to a public key, but without ever needing to reveal the private key. Nobody can attempt to create a competing transaction to spend this because they require the private key to do so. You cannot create a digital signature with only knowledge of the public key, but you can verify that the signature is correct using only the transaction and the public key.


Is the transaction within Genesis block spendable?

Are the transactions added to the genesis block spendable, just like any other transactions from other blocks, or is that an unspendable coinbase transaction.

Transactions aren't spendable; transaction outputs are.

  Is the transaction within the Genesis block spendable, provided the corresponding private key of the bitcoin recipient is found?

The single transaction output in Bitcoin's genesis block is not spendable. It is not known whether this was an intentional choice by the system's creator, or an accident. Regardless, the reasons why currently don't matter, as no Bitcoin full node software would accept such a spend.

  If I fork the Bitcoin code, and generate my own genesis block. Can I use the private key/public key I used as bitcoin recipient of the transactions hard-coded with the genesis block?

In your own software you can enforce whatever rules you like.


Bitcoin transactions reserve more coins than needed

It's due to confirmation times and there's nothing you can do about it. Until a payment confirms, its outputs are not spendable because you cannot be sure the payment will in fact confirm. This includes the "change" outputs from a transaction. You could try to keep a large pool of available unspent outputs available.

Update: The behavior you're describing is not unusual. Until a transaction gets included in a block, it's stuck at zero confirmations. Each payment you make takes one or more of your unspent outputs and consumes it, producing a new unspent output back to you for the "change".

Say you have two unspent outputs, one for 1 Bitcoin and one for 0.4 Bitcoins and you need to make a payment of 1.2 Bitcoins to someone. You make a payment that takes in both your unspent outputs, sends 1.2 Bitcoins to the recipient, and the remaining 0.2 Bitcoins back to you. At the moment, the only Bitcoins you have are that 0.2 Bitcoin "change" output, and it's not yet confirmed.


Freebsd Bitcoind doesn't read config correctly

I don't know exacly how, but I got it working.
I do know that I used export LC_ALL=en_US.UTF-8 but I am not sure that is the reason it works.

I still have the same error with the -conf paramter. Even when permissions are 777.

I know this isn't a perfect answer. But my bitcoind server works now.


The fee is variable over time.  As the supply dwindles, the relative value of each XRP will be higher, so the transaction fee will get lower.  They'll never really run out.

https://ripple.com/wiki/Transaction_Fee