What contributions have Blockstream developers made to the Bitcoin project? I’m spending a lot of time debating people about Bitcoin online these days. One issue that I encounter regularly is that my opposite colloquists are unaware of the contributions the Blockstream developers have added to the Bitcoin project since the company was founded.

My aim is twofold: I’d like to be able to simply link this question next time I read "Blockstream produces only vapour, and contributes nothing", and I think that the answer to this question deserves more visibility.

Please list what measurable contributions Blockstream developers have made to the Bitcoin project?

Disclosure: I'm a Blockstream co-founder

Major feature contributions to Bitcoin Core:

Greg Maxwell, Andrew Poelstra and myself (as well as several other contributors) worked on libsecp256k1, a well-tested library for efficient elliptic curve cryptography using the curve secp256k1. Bitcoin Core switched signing to it in 0.10 and verification in 0.12 (with a 5x speedup for signature validation as a result). This work also led to the discovery of CVE-2014-3570 (OpenSSL bignum squaring bug). Work on the library started as a hobby project of mine in 2013, but many optimizations, tests, correctness proofs, and automated verification were added after we could work on it full time.
I worked on headers-first synchronization (Bitcoin Core 0.10), a new mechanism for block chain downloading which downloads from multiple peers at once, and solved many of the problems with the earlier mechanism. The idea was first described by Greg Maxwell in 2012, but the implementation only got finished after starting at Blockstream.
Jorge Timon and Matt Corallo (as well as Cory Fields) worked on the creation of libbitcoinconsensus, a shared library built from the Bitcoin Core codebase that exposes part of the validation logic, and shipped with 0.10.

Besides that, we provided a large number of changes implementing numerous features, cleanups, optimizations, refactors, improvements, and general maintenance. When looking at the history of Bitcoin Core v0.12.0rc1 after august 1st 2014, 500 out of 2185 commits (23%; over 30% when including libsecp256k1) came from Blockstream employees and contractors. Most of these people were active in the project long before the creation of the company, as these same people were responsible for 866 out of the 4195 commits before august 1st 2014 (20%). These numbers exclude merges, to avoid favouring people with commit access to the repository.

We were also involved in several improvements not directly related to Bitcoin Core code changes:

BIP66 fixed a potential forking risk from the network that was caused by an inconsistency across platforms between OpenSSL versions and opened the door to non-OpenSSL based validation.
BIP68, BIP112, and BIP113 were proposed and first implemented by Mark Friedenbach to introduce relative locktimes and enforcement thereof, which are necessary for more efficient payment channel systems like Lightning.
Several generic blockchain technology improvements were discovered by us and implemented in our first technology demo sidechain Elements Alpha, including segregated witness, confidential transactions, Schnorr signatures and key tree signatures. Segregated witness is currently being worked on as a soft-fork for Bitcoin (BIP141 through BIP144), and includes script versioning which makes introducing things like Schnorr signatures in future softforks much easier.
Other proposed BIPs: BIP99 (consensus change best practices) by Jorge Timon, BIP103 (block size increases following technological growth) by me, BIP111 (NODE_BLOOM flag) by Matt Corallo, BIP9 (Version bits with timeout and delay) by me, Greg Maxwell and Rusty Russell (as well as Peter Todd).
Matt Corallo implemented and operates the Bitcoin relay network, providing low latency block propagation to various parties.

This list is by no means exhaustive, and I'm probably focusing mostly on contributions I participated in myself.


How can i bring my bitcoins back to me? I deposited bitcoins on an online investment. the record on my bitcoin wallet shows that it was indeed sent to the wallet address of the online investment. but my account on that online investment is still empty or zero. they didn't put my bitcoins on my account to that investment. what should I do. I want my bitcoins bring back to me. please help me.

Bitcoin transactions are not reversable. The only way for you to get your bitcoins returned is by convincing your business partner to send them back to you.


What's the easiest/fastest way to experiment with bitcoin-cli? I want to experiment with the bitcoin-cli in the easiest way.
I just installed bitcoin core and waiting for it to download the blockchain.
Is there a way meanwhile I can run bitcoind and/or bitcoin-cli, that doesn't require downloading the whole blockchain?
I guess running the test-net is a natural approach.
My main problem is: I don't see the bitcoind and bitcoin-cli executables anywhere on my system.
I'm running Ubuntu 16.04.1 LTS
and installed bitcoin core through the command line as described here:
http://bitzuma.com/posts/getting-started-with-bitcoin-core-on-ubuntu/

ultimately running bitcoin-qt from the command line.

Yes, you can run bitcoind with the -testnet option.  This starts a separate process that runs independently of the mainnet bitcoind.  You can control it with bitcoin-cli -testnet.

Note that you will have to download and verify the testnet blockchain before being able to do very much.  This also takes some time / bandwidth / disk space / CPU, though much less than for mainnet.  Depending on the speed of your CPU and Internet connection, it might also make the mainnet download take longer if they have to share resources.


How does NXT prevent blockchain bloat since it does so many different things with its blockchain? How does NXT prevent blockchain bloat since it has a built in message system and other features? Wouldn't the NXT blockchain grow to be really big in the future and pose a problem for people storing the blockchain as compared to other coins?

A special feature called Blockchain Shrinking is supposed to solve this problem.

Every year (or month) a new genesis block ("rolling genesis block") will be generated by every node. This block will contain only actual information (for example, only one depositing transaction instead of hundreds of them).

Blockchain Shrinking requires other features to be implemented too - Service Providers and Distributed Storage. These features are necessary because new nodes may need to make sure that a particular rolling genesis block is legitimate. This will be done by downloading and analysing all (or some) blockchains that existed before the most recent shrinking. Please, note that such blockchains will be stored only by some nodes that decided to do so (they will get extra payments for providing this service). There is still a possibility that none of the nodes will store the old information, in this case Nxt couldn't be called "100% trustless".


New params of chainparams.cpp. What put on them and how generate? What do these parameters do and what to insert there

        uint256S("00000fffffffffffffffffffffffffffffffffffffffffffffffffffffffffff"); //what this do ? end what put to here

        consensus.nRuleChangeActivationThreshold = 6048; // 75% of 8064 //what this do end what put ?
        consensus.nMinerConfirmationWindow = 8064; // nPowTargetTimespan / nPowTargetSpacing * 4  //what this do ?
        consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].bit = 28; //what this setting's do ?
        consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].nStartTime = 1199145601; // January 1, 2008
        consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].nTimeout = 1230767999; // December 31, 2008

        // Deployment of BIP68, BIP112, and BIP113.
        consensus.vDeployments[Consensus::DEPLOYMENT_CSV].bit = 0;
        consensus.vDeployments[Consensus::DEPLOYMENT_CSV].nStartTime = 1485561600; // January 28, 2017
        consensus.vDeployments[Consensus::DEPLOYMENT_CSV].nTimeout = 1517356801; // January 31st, 2018

        // Deployment of SegWit (BIP141, BIP143, and BIP147)
        consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].bit = 1;
        consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].nStartTime = 1485561600; // January 28, 2017
        consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].nTimeout = 1517356801; // January 31st, 2018

        // The best chain should have at least this much work.
        consensus.nMinimumChainWork = uint256S("0x000000000000000000000000000000000000000000000006805c7318ce2736c0"); //what this do end what put here ?

        // By default assume that the signatures in ancestors of this block are valid.
        consensus.defaultAssumeValid = uint256S("0x1673fa904a93848eca83d5ca82c7af974511a7e640e22edc2976420744f2e56a"); //1155631  //what this do ?

        nPruneAfterHeight = 100000;  //what this do ?

i need to reconfigure exist coin to new wallet but stuck on this param's.

For all who down vote question, i try find about this param info , but do not find anything, or you simple down vote what you do not understand ?

I understand it's start end time out time. But how it work's.

uint256S("00000fffffffffffffffffffffffffffffffffffffffffffffffffffffffffff"); //what this do ? end what put to here

The first line describes a minimum difficulty.

consensus.nRuleChangeActivationThreshold = 6048; // 75% of 8064 //what this do end what put ?
consensus.nMinerConfirmationWindow = 8064; // nPowTargetTimespan / nPowTargetSpacing * 4  //what this do ?

The next two lines say that rule changes require 75% agreement, measured across 4 retargeting periods.

consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].bit = 28; //what this setting's do ?
consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].nStartTime = 1199145601; // January 1, 2008
consensus.vDeployments[Consensus::DEPLOYMENT_TESTDUMMY].nTimeout = 1230767999; // December 31, 2008

// Deployment of BIP68, BIP112, and BIP113.
consensus.vDeployments[Consensus::DEPLOYMENT_CSV].bit = 0;
consensus.vDeployments[Consensus::DEPLOYMENT_CSV].nStartTime = 1485561600; // January 28, 2017
consensus.vDeployments[Consensus::DEPLOYMENT_CSV].nTimeout = 1517356801; // January 31st, 2018

// Deployment of SegWit (BIP141, BIP143, and BIP147)
consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].bit = 1;
consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].nStartTime = 1485561600; // January 28, 2017
consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].nTimeout = 1517356801; // January 31st, 2018

The next eleven lines describe the minimum and maximum times that three softforks can activate, and how they are to be signaled using version bits.

// The best chain should have at least this much work.
consensus.nMinimumChainWork = uint256S("0x000000000000000000000000000000000000000000000006805c7318ce2736c0"); //what this do end what put here ?

The next two lines specify the minimum amount of chain work that a client must have before it will consider itself synchronized.

// By default assume that the signatures in ancestors of this block are valid.
consensus.defaultAssumeValid = uint256S("0x1673fa904a93848eca83d5ca82c7af974511a7e640e22edc2976420744f2e56a"); //1155631  //what this do ?

The next two lines disables signature checks on blocks that are ancestors of the block specified by that block hash.

nPruneAfterHeight = 100000;  //what this do ?

The next two lines disable block pruning on blocks below a certain height. In Bitcoin, this is because most of the initial blocks are empty. This is documented in this commit.


Address Verification Failed / View on Tresor Address don't Match Using LTC wallet on new Trezor. On "Receive Payment" tab, clicking eyeball icon, the address shown on the Trezor does not match the address shown on screen.

What gives? Did I already get hacked?

Addresses on LTC transitioned to a new format right about this time.  You are probably looking at the same address on both the website and the LCD, but they are just in different formats.


Non indexing bitcoin and output lookup Using bitcoin's RPC and txindex=0 is it possible to tell the difference between an existing output being already spent and a non existing transaction output (or transaction id)? Looking at gettxout it's not enough as it would return empty data in both scenarios.

There’s functionally no distinction between an output which doesn’t exist, and one which hasn’t existed from the perspective of validation. The node never needs to consider this so by default it stores no information about it.


Why is Target < Blockhash? I am currently trying to validate a blocks hash against its target in python3:

This is a block in the Blockcypher testnet, and I am using this formula from the Bitcoin Wiki.

block_hash = '000055f67563d1c2cb141d06d52d2fca63ef457c553519aeb635a2643a9af0b1'
bits = '520159231'

target = hex(int(bits) * (2**(8 * (0x1b - 3))))
hash_ = hex(int(block_hash, 16))
print(target, hash_)
>>> 0x1f00ffff000000000000000000000000000000000000000000000000 0x55f67563d1c2cb141d06d52d2fca63ef457c553519aeb635a2643a9af0b1

if not target >= hash_:
    print('False)
else:
    print('True')
>>> False

Point is, that target is less than blockhash. But this should not be the case.
Can anyone help me?

Thank You for Your time.

If you convert the difficulty bits to hex you will get:
0x1F00FFFF

Coefficient = 0x00FFFF

Exponent = 1F = 31

Target = Coefficient * 2**( 8 * ( exponent-3 ) )

Target = 0xFFFF with 31 - 3 = 28 trailing NULL (0x00) bytes

Target:
0x0000FFFF00000000000000000000000000000000000000000000000000000000

Your Hash:
0x000055f67563d1c2cb141d06d52d2fca63ef457c553519aeb635a2643a9af0b1

So your POW fulfils the target.
Just to be sure, you might want to check endianness during your conversions between int/literal/hex types.


What's the point of the hash160 field in blockchain.info API? I've been wondering who/what could use the hash160 field of the blockchain.info API.

For example, for the address "1N3Xxt13zbDLU66aSBiMB7AjRW1UiUFAau", the hash160 value is e6d55202fe5e9e9e2973aab12bbb91db67948138, which is roughly the hex format of the address (00e6d55202fe5e9e9e2973aab12bbb91db6794813840292932).

As it seems truncated, it seems that we miss some bits of information.

Also, I've seen that the hash160 should be calculated differently, so why this value is present?

The information that the company displaying is correct, though there's no standard for displaying this to end users. You have unpacked the address and included the version byte and checksum as well in the string, note that only the hash160 is used in a pay to pubkey bitcoin script.

Base58Check    1N3Xxt13zbDLU66aSBiMB7AjRW1UiUFAau
Decoded        0x00e6d55202fe5e9e9e2973aab12bbb91db6794813840292932

Version Byte   0x00
Hash160        0xe6d55202fe5e9e9e2973aab12bbb91db67948138
Checksum       0x40292932


Why can't an intermediary Lightning node take (nearly) all fees? Consider a Lightning payment: Alice wants to pay 100 sat to Dave via two intermediary hops: Alice - Bob - Charlie - Dave. Both Bob and Charlie advertise a fee of 2 sat. Alice sends 104 sat to Bob, expecting him to forward 102 sat to Charlie. But Bob only forwards 101 sat. Then Charlie has a choice: either to fail the payment and get nothing, or forward it for just 1 sat. It seems that the economically rational choice is to forward anyway. If this is true, why first hops not always take nearly all fees for themselves?

Of course, due to onion routing, Bob doesn't know whether Charlie is the last hop. If Charlie is the ultimate recipient and he won't get the sum he expected, he won't reveal the preimage, and Bob will get nothing. But can such strategies be profitable on average, over many attempts?

Sure there might be some game theory involved but two things speak against it:

Bob does not know what the fee or the final payment amount  is. Of course he could make an educated guess. But maybe the final payment was 101.5 sats and Charlie was supposed to forward for 500msat. Charlie would now even have to add 500msat to fulfill her 101.5 amt to forward.
It is currently differently implemented. Nodes will just not forward if the amount they reicieve minus the amount they are supposed to forward is below their fees. So if Bob would mess with the onions later nodes would currently automatically fail with insufficient fee error message. This of course could be abused for denial of service attacks.


What is the Alert system in the bitcoin protocol? How does it work? I understand Bitcoin has an alert system. Can someone explain what it is, how does it work, and what was it designed for?

TL;DR:

  As @Alex Waters has stated, it's a centralised alert system to allow
  people to shutdown their clients in response to a threat to the
  overall Bitcoin network, pending a client patch to resolve the issue.
  This was intended as a short term measure to counter-act perceived
  problems in growing the software.

This thread on the forum has some interesting information about it (I've fixed the links to cover the moved forum):

  Yes, it appeared in version 3.11. Here's the thread discussing it:

  "Development of alert system"
  https://bitcointalk.org/index.php?topic=898.0;all

  But I think Satoshi took it out of recent builds, to avoid accusations
  that he was a point of central control (because his key would be used
  to sign the alert). If I can find the reference to that announcement,
  I'll post it.

  edit: here's the announcement about the removal of "safe mode". It's
  not clear to me whether the alert itself was removed, or whether the
  ability to have the alert shut down transaction processing was
  removed:

  Removed safe mode (0.3.19)
  https://bitcointalk.org/smf/index.php?topic=2228

Clearly, Satoshi intended it to be a centralised mechanism to issue alerts that would result in clients stopping transactions (not block generation). This would act as an effective mechanism to cause clients to upgrade as a result of a bug, but a naive interpretation is that it is also a good way to shutdown an economy.

Anyone can build a standard client and replace the key requirement with one of their own, thus negating the efficacy of a system-wide shutdown due to a compromised key. Essentially, this would cause a fragmentation of the standard client as nodes seek to protect themselves from external compromise.

Satoshi notes this himself in this comment:

  It can't do arbitrary actions remotely.  Maybe some of you are
  responding to other posters who suggested the alert system should do
  more?

  If there is an alert, the following json-rpc methods return an error:
  sendtoaddress getbalance getreceivedbyaddress getreceivedbylabel
  listreceivedbyaddress listreceivedbylabel

  The remaining 14 methods function as normal.

  I believe the safer option should be enabled by default.  If you want
  your server to keep trading and ignore an alert saying the money its
  receiving might be like the money from the overflow bug, then you can
  use the switch and not blame anyone else if you lose your money.

  Worst case if you leave alerts enabled, your site stops trading until
  you upgrade or add the -disablesafemode switch.

  Getting surprised by some temporary down time when your node would
  otherwise be at risk is better than getting surprised by a thief
  draining all your inventory.

  Someday when we haven't found any new bugs for a long time and it has
  been thoroughly security reviewed without finding anything, this can
  be scaled back.  I'm not arguing that this is the permanent way of
  things forever.  It's still beta software.

Given the ongoing backlash of misunderstanding over the concept, it appears that it was decided to remove the feature and rely instead on detecting a dodgy blockchain that is longer than the longest valid one:

  Removed "safe mode" alerts "safe mode" alerts was a temporary
  measure after the 0.3.9 overflow bug.  We can say all we want that
  users can just run with "-disablesafemode", but it's better just not
  to have it for the sake of appearances.  It was never intended as a
  long term feature.  Safe mode can still be triggered by seeing a
  longer (greater total PoW) invalid block chain.

  Builds:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/


Why is your Bitcoin balance displayed on paper wallets? Sites like bitaddress.org and Blockchain.info where you can print out a paper wallet also show your current Bitcoin balance on your paper wallet. But your balance is something that is constantly changing, so why would it be printed on a paper wallet?

The balance of an address only changes if you send bitcoins into or from it. Paper wallets are usually intended to be swiped only once, so you should not have outgoing transactions while the paper wallet is still valid. You could add coins to it, as a sort of piggy bank, but there are also use cases where the amount will be fixed.

So, if the paper wallet is intended to be used with a fixed balance, it can be printed on it for convenience; if not and an amount is printed anyway, it can simply be ignored.


How many Secp256k1 signatures exist for a piece of data? ECDSA signatures are not deterministic. That is, random information is used in calculating the signature for a piece of data. Approximately how many unique signatures exist for a piece of data?

Another way this question might be phrased is: if I continually sign the same piece of data using random multiples of the generator point then how many signatures (on average) will I have to generate before finding a duplicate signature?

And finally, if instead I start with a random multiple of the generator kG and then sign using (k+1)G, then (k+2)G, ... then will I ever produce the same signature?

Approximately how many unique signatures exist for a piece of data?

something like 2^256 (slightly less)

  will I have to generate before finding a duplicate signature?

It depends of the quality of you random generator. You must use "true" random generators, not pseudo-random.

  then will I ever produce the same signature?

Are you going to live eternally? The sun will go out by the time of when you repeat the signature. By the way: you can take value of 'k' as a function of your 'privateKey' and 'data-2-sign'
See https://bitcointalk.org/index.php?topic=727918.0 for more info

By the way. The signature itself is 512 bits. R and S (256 bits each). Your private key can be recovered when you sign different data with the same 'k'. In this case 'R' value will be the same for both signatures. And 'S' value will differ.


How do wallets work? It may seem like a vague question, but what I understand so far is, you have a public key (address) which people can send coins too, and then you have the private key which you need to send coins to someone else.
My question is, how does the program itself work?
Does it create a public key based of private? maybe on the wallet.dat file? How would you be prevented from getting a private key if you have the public key? and what stops someone from looping over a bunch of private keys to find one with some coins in?

Does it create a public key based of private?

Yes, a cryptographic routine exists that computes the public key from the private key.

maybe on the wallet.dat file?

All modern wallet software generates keys derministically from some sort of master key, or seed phrase. That master key is stored in the wallet, and all other private keys are derived from it, and the public keys are derived from that. For every new receive address, a distinct key is used. The fact that they're all computed from one piece of data means that a backup of your wallet allows generation of all future addresses - even the ones created after the backup was made.

How would you be prevented from getting a private key if you have the public key?

Cryptography. The function to compute the public key from the private is fairly efficient in one direction (~50 microseconds on a modern desktop CPU), but the best known algorithm for going the other way around (Pollard's rho) would take around 300 trillion times the age of the universe on the same computer. With many computers it becomes faster of course, but even billions of times faster isn't remotely close to being able to realistically break any key. The security is based on the assumed hardness of a number theoretical problem, the elliptic curve discrete logarithm problem (ECDLP).

and what stops someone from looping over a bunch of private keys to find one with some coins in?

There are 115792089237316195423570985008687907852837564279074904382605163141518161494336 valid private keys (that's the actual number). Attempts to brute force them are futile due to the sheer number. The duration I gave above doesn't rely on brute force - it uses a much more efficient algorithm. Brute force would be 600 trillion trillion trillion times slower still.


Is there any way to contact the makers of bitcoin qt and bitcoin core? Would like to talk to the makers of bitcoin qt and bitcoin core. I have googled but cant find an email address or a way of contact!

It's open source software by many independently cooperating developers. The name is now Bitcoin Core, where bitcoin-qt is the GUI application.

Discussions happen on many forums and media, so it depends a little on what kind of message you want to send them.

"Official" website: https://bitcoincore.org/ and http://bitcoin.org

All others I mention here are public media where many people participate, including some of the Core developers (not always by their real name). Always be wary of fake user IDs.

Stackexchange: you found it already
IRC: #bitcoin, #bitcoin-dev, ...
Forum: http://bitcointalk.org
Reddit: http://reddit.com/r/bitcoin

Be careful that there are a lot of companies and groups with confusing names or even purposely misleading names, trying to give themselves credibility.


Insight API: txs json shows only 10 tx? I have an Insight API Server running, it's fully synced and working. I would like to get a json to receive every tx within a block.

On https://github.com/bitpay/insight-api it says I have to use:

Transactions by Block
  /insight-api/txs/?block=HASH
  /insight-api/txs/?block=00000000fa6cf7367e50ad14eb0ca4737131f256fc4c5841fd3c3f140140e6b6

For example we take block #301453. This block has 725 transactions.

https://insight.bitpay.com/block/00000000000000004dff81aadf782cceb8a2d082f0f255472791c8bb2984e958

If I use the api to get the json file with this link:

http://localhost:3001/insight-api/txs/?block=00000000000000004dff81aadf782cceb8a2d082f0f255472791c8bb2984e958

... then it shows the first 10 transactions only (numbers 0 - 9). But there are 725 tx in this block.

It looks like the number 10 are those addresses are the first who are displayed. If i scroll further down, more transactions appear. But why does the json request only show 10 txs?

How can I get ALL transactions in this block - as the documentations mentions?

You have two options.

Option 1:
The returned json includes a "pageTotal":'some number'.
You can create a for-loop to loop through all the pages with API calls.

Let assume there are two pages aka "pageTotal":2

To fetch the first page, append parameter [&pageNum=0] to the end
Example usage:

http://localhost:3001/insight-api/txs/?block=00000000000000004dff81aadf782cceb8a2d082f0f255472791c8bb2984e958&pageNum=0

To fetch the second page, add param [&pageNum=1]
Example usage:

http://localhost:3001/insight-api/txs/?block=00000000000000004dff81aadf782cceb8a2d082f0f255472791c8bb2984e958&pageNum=1

Option 2:
Modify transactions.js , 'var pageLength' on Line 253.
The default is 'var pageLength = 10;'
Unsure if there are consequences by doing this, but I assume it should be fine.


Bitpay unused address - has balance So, I have a wallet - and the balance is incorrect.

I have looked into it a bunch and finally tracked down what I think is the issue.

If I view all of the addresses used in my wallet I see a list of Addresses with balance and unused addresses.

The problem is that one of the "unused addresses" actually has a balance.

The address is: 1HYMfJhgiprZ3n1oHKiSZ1n2e85Cyn7HAe

How can I make bitpay "use" this address again?

I have tried the following:
  - Clear wallet cache
  - Scan addresses for fund
  - Restoring wallet to another device

I thought I could try importing that address into electrum - but I cannot figure out how to get the private key for that address out of bitpay wallet.

Any advice?

Bitpay/Copay use Hierarchical Deterministic wallets so you can find all the adresses that has been generated from your root private key (seed recovery phrase)

Here is a guide with more information: https://github.com/OmniLayer/omniwallet/wiki/Finding-and-Exporting-your-private-key-from-Bitpay-Copay


Is it possible to figure out whether two addresses are in the same wallet? I'm wondering, if I sent some bitcoins from one of my own addresses to another address in my wallet, will it be possible for someone to figure out that both addresses are in the same wallet? Or can I claim the other address is not my own and no one can find out?

It is possible to tell that two addresses are in the same wallet if they both appear as an input of a transaction. This indicates that one person owns both of them as they can spend both of them.

It is also quite likely that when you are sending a transaction that has one neat input (say, 1BTC), and one not so neat (say, 0.59721364BTC), that the latter is most likely a change left over from a transaction you sent to someone and is being sent to another address you own from the same wallet. This claim could be possibly deniable, but should be true in most cases.


OP_RETURN transaction doesn't go to the blockchain I created transaction with OP_RETURN adding some information. Even though transaction hash created successfully, the transaction doesn't go to blockchain properly. Could you please help me to do this transaction properly?

"scriptPubKey":

{

"asm": "OP_RETURN 726173656c6140676d61696c2e636f6d7e39383732363733383834",

"hex": "6a1b726173656c6140676d61696c2e636f6d7e39383732363733383834",

"type": "nonstandard"

}

Can you give the full transaction, and decode it?

The default client nodes will not broadcast your transaction because it is not standard. That may be the problem. If it is mined into a block, however, they would not refuse that block just because it had non-standard transactions, because the transaction would be valid even though it might not be standard. For more on this, you may find the below questions helpful.

Which scripts are currently considered standard and therefore actually propagated?.
What node implementations and mining pools relay and process 'non-standard' scripts?.

That might not even be the problem, though. It could be signed incorrectly. You should make sure that the OP_RETURN output was included before the transaction was signed. You can verify that the signature of the transaction is valid using the code in this question: How to verify ECDSA of a sample litecoin tx using pycoin?.


Sending Bitcoin between paper wallet and hardware wallet offline Good morning, I'm just beginning this journey into crypto currencies. Right now, I've got my Bitcoin in a wallet at Coinbase.  I'd like to keep my Bitcoin in a paper wallet. I think from Coinbase to my paper wallet is pretty straight forward.  I need my paper wallet's public key and send the Bitcoin from Coinbase to the Paper Wallet. So now I go on line and buy something with my Bitcoin. I'd like to transfer just the amount of my purchase from the paper wallet to a hardware wallet while off line and then connect the hardware wallet to the internet to complete a purchase. I'm thinking this would be the way to keep my money safe from hackers. Am I able to do this?  Thank you so much in advance for any help.

I'd like to transfer just the amount of my purchase from the paper wallet to a hardware wallet while off line and then connect the hardware wallet to the internet to complete a purchase. I'm thinking this would be the way to keep my money safe from hackers. Am I able to do this?

Not quite, but you're close! I'll explain a couple things about paper wallets, that should make it more clear to you:

A paper wallet is a private key that is stored physically, instead of digitally. So in order to perform functions such as signing a transaction to move the bitcoins, you will need to input that private key into some wallet software that is capable of this.

With most hardware wallets, this means you'll have to input the private key into the wallet software running on a computer that the hardware wallet is plugged into.

Important to understand is that there are two ways of importing a paper wallet: just importing the key, and sweeping the key. Importing the key means your wallet will make a copy of it, so now the key exists in your software wallet, as well as the physical paper wallet. Sweeping the key means the wallet software will import the key, and then immediately initiate a transaction to move the entire balance of the paper wallet to a new address that only the hardware wallet controls.

In almost every situation, you should sweep the key. This is because it isn't possible to "transfer just the amount of my purchase from the paper wallet to a hardware wallet". When any bitcoin transaction is initiated, the ENTIRE balance of an address is moved. The amount being transacted is sent to the recipient, and whatever extra was in the paper wallet will be moved to a new 'change address' that your wallet software automatically creates and controls. For more info on this, look up 'bitcoin change address'.

So if you import your key into wallet software, spend half the bitcoin, and then check your paper wallet balance, it will be zero. The other half of your btc will be found in an address that your wallet software controls, so if you'd like to keep those coins in cold storage, you'll need to send them to a NEW paper wallet.


Computer Advice to Meet Bitcoin Core Requirements I am interested in running bitcoin core to help support the network and also get more involved in bitcoin. I read the minimum requirements here that say:

Desktop or laptop hardware running recent versions of Windows, Mac OS
X, or Linux.
350 gigabytes of free disk space, accessible at a minimum read/write
speed of 100 MB/s.
2 gigabytes of memory (RAM)
A broadband Internet connection with upload speeds of at least 400
kilobits (50 kilobytes) per second
An unmetered connection, a connection with high upload limits, or a
connection you regularly monitor to ensure it doesn’t exceed its
upload limits. It’s common for full nodes on high-speed connections to
use 200 gigabytes upload or more a month. Download usage is around 20
gigabytes a month, plus around an additional 340 gigabytes the first
time you start your node.
6 hours a day that your full node can be left running. (You can do
other things with your computer while running a full node.) More hours
would be better, and best of all would be if you can run your node
continuously.

As I suspected, my current machine (MacBook Air, lol) is not going to work. It looks like I only have 61 gigs of 120 available disk space. Although I have some programming experience, I really don't know a lot about computers. I think I would like to get something a little more powerful, so I can run bitcoin core and also some other projects that require a better machine. I honestly don't even know how to check the read/write speed (processor?) or what an unmetered connection is. Does anyone have advice for shopping for a machine that can meet these requirements? Does not need to be a mac.

As I suspected, my current machine (MacBook Air, lol) is not going to work.

That really depends on what model you're talking about. Modern Macbook Airs are definitely powerful enough.

It looks like I only have 61 gigs of 120 available disk space.

That's more than enough for running Bitcoin Core in pruned mode.
When pruning is enabled, old blocks are deleted from disk a while after they've been verified. This disables some functionality, but is equally secure - everything is still fully validated, just not kept forever. It doesn't interfere with normal functions.

I honestly don't even know how to check the read/write speed.

It's the speed of the disk. All new disks can do more 100 MB/sec, but for initial synchronization (the time your node needs to validate all of history) an SSD will be a lot faster than a spinning hard drive. Don't use an external drive connected through USB - such hardware is not designed for the kind of heavy database load Bitcoin Core causes.

an unmetered connection

That just means you want to make sure you don't pay per megabyte for your internet connection. Bitcoin Core will be downloading several 100 GBs of data from peers (all old blocks), so if you have to pay for that, you may want to reconsider.


Ripple XRP value and market capitalization I'm interested to know why Ripple's value and market cap are increasing?

This is a 'utility system' that seems to counter price appreciation models/expectations (at least in my mind), yet XRP is appreciating...?

I'm confused by how this can happen?

Disclosure. I'm a litecoin guy (possibly part of the problem), and I don't mind the recent XRP events (only curious about what I am seeing here). ;)

It comes down to XRP's actual or perceived utility, then speculating on XRP's future; most seem to be bullish so there's price appreciation. Since XRP will act as a connecting joint between ALL currency pairs within the Ripple network, XRP will maintain its usefulness and in fact probably become more useful as time goes on and new bridges are made across previously isolated markets. XRP will help to lubricate the engine of the Ripple protocol. As long as the protocol is being used more each day and is "healthy", which it currently is, the price of XRP "should" increase along with it – just as a motor needs lubricating oil to maintain it.

There's also a chance it might become a sort of "reserve" currency in the future, assuming success of the Ripple protocol.


How to run docker cointainer from kylemanna/docker-bitcoind on testnet I have a bitcoin.conf.
It looks like this:

testnet=1
server=1
rpcuser=Ulysseys
rpcpassword=YourrrPassword
rpctimeout=30
rpcport=8332

Now I try to run a container from this image:

Create volume:

$ docker volume create --name=bitcoind-data

Create container:

docker run -v bitcoind-data:/bitcoin --name=bitcoind-node -d \
        -p 8333:8333 \
        -p 127.0.0.1:8332:8332 \
        -v /path/to/bitcoin.conf:/bitcoin/.bitcoin/bitcoin.conf \
        kylemanna/bitcoind -testnet

I go inside my container and check with bitcoin-cli getinfo:

{
  "version": 140200,
  "protocolversion": 70015,
  "walletversion": 130000,
  "balance": 0.00000000,
  "blocks": 0,
  "timeoffset": 0,
  "connections": 0,
  "proxy": "",
  "difficulty": 1,
  "testnet": true,
  "keypoololdest": 1503649077,
  "keypoolsize": 100,
  "paytxfee": 0.00000000,
  "relayfee": 0.00001000,
  "errors": ""
}

Testnet=true so that's okay but I don't see any log of data (docker logs container-name). Also my docker volume is still 17MB and 0 blocks.

What am I doing wrong?

When I load my bitcoin.conf in my bitcoin-qt on macosx it becomes green but remains on 'pending' to get the blockchain.

Is there something wrong with my config or is it maybe blocked on my network?

Adding printtoconsole=1 to you bitcoin.conf will activate log output to the console. With this docker logs container will show the log.


How do the nodes divide after a hard fork? Soft Fork? After a hard fork, what happens to the full nodes? Say 11,000 BTC full nodes existed prior to the fork. Do all 11,000 end up supporting both BCH and BTC? Or does BCH start building it's own network of nodes. Not asking about miners, just about full nodes (although, it will help if you can address the mining nodes as well).

Also, in the softfork scenario, I believe the 11,000 nodes are divided - say 7000 support the softfork (e.g. Segwit) and the remaining 4000 do not. In that case, how do transactions remain legit between the supporters and non supporters.

After a hard fork, what happens to the full nodes? Say 11,000 BTC full nodes existed prior to the fork. Do all 11,000 end up supporting both BCH and BTC? Or does BCH start building it's own network of nodes. Not asking about miners, just about full nodes (although, it will help if you can address the mining nodes as well).

A hard fork means that a new set of consensus rules is being used which splits the blockchain into a blockchain following the old rules and a blockchain following the new rules. There is no "in between" for a node to follow both rules and nodes are not typically equipped to simultaneously support two blockchains.

In the event of a hard fork, the nodes which support the new rules and the hard fork's activation rules will separate from the nodes which do not support the new rules. They become their own network and have their own blockchain. This applies to all full nodes, which miners are a subset of.

So in your example, none of the nodes will support both BCH and BTC unless they were specifically designed to do so. The standard behavior (i.e. nodes using Bitcoin Core for BTC or Bitcoin ABC for BCH) is to only support one chain whose consensus rules are hard coded. Some of those 11,000 nodes will have the BCH rules so they will split from the other nodes which do not have the BCH nodes.

  Also, in the softfork scenario, I believe the 11,000 nodes are divided - say 7000 support the softfork (e.g. Segwit) and the remaining 4000 do not. In that case, how do transactions remain legit between the supporters and non supporters.

A soft fork is backwards compatible with old nodes. It must be designed in a way such that old nodes will not be kicked off of the network after the activation of the soft fork. So for soft forks, the soft fork was designed so that transactions under the new rules are also valid under the old rules. For segwit, this is done by stripping out the segwit specific components which are completely new so that non-segwit nodes are able to parse and validate the transactions.

In a soft fork, there is no chain split and all 11,000 nodes are still using BTC and following the same blockchain.


Are sockets kept open when connections are made? The bitcoin protocol says that any given node is connected to at least 8 other nodes. Does that mean that when a client connects to a node and learns about new peers... will the client keep the socket open and wait on recv? Or does it just record the new peers and closes the sockets and opens a new connection when there is new data to be received or sent?

The bitcoin protocol says that any given node is connected to at least 8 other nodes.

Right.

  Does that mean that when a client connects to a node and learns about new peers... will the client keep the socket open and wait on recv?

No, since this is about connection between peer nodes, not about clients.

  Or does it just record the new peers and closes the sockets and opens a new connection when there is new data to be received or sent?

Nodes try to retain at least eight connections to peer nodes so that they can track the flow of new transactions and blocks on the network. Establishing a reliable set of stable connections to at least eight peer nodes is the objective here.


How to check if one transactions is from the same wallet (public key) as a previous one I wonder how to figure out whether one Bitcoin transaction is from the same wallet (public key) as any previous transaction in order to proof the ownership of a wallet.

If the transaction in question consumes inputs that were locked to a bitcoin address that has been previously used, then it would be easy to tell that the payment came from the same wallet. After all, the payment came 'from the same address' as a previous payment.
However, re-using addresses is not best practices. Doing so is very bad for your privacy, just consider the premise of this question to understand why! There is no reason to re-use addresses and thus allow someone to see your financial history (ie, all of the other transactions you've made from that address).
Thankfully, modern wallets are built to never re-use addresses. Further, addresses from the same wallet are indistinguishable from random addresses, there is no public information included in the address/transaction that links them together. This is by design: you wouldn't want someone to be able to determine your entire wallet balance, after receiving a single transaction from you.


Neither cgminer nor BFGminer detect my Zeusminer Blizzard. (Ubuntu/Linux/Mint) I'm having trouble getting my Zeusminer Blizzard running; neither cgminer nor BFGminer detect it. Here are the results of lsusb:
Bus 001 Device 025: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
[...]

bfgminer -d? -D says this. The relevant line, I think, is
 [2014-07-15 09:33:03] lowlevel_scan: Found usb device at usb:001:025 (path=(null), vid=10c4, pid=ea60, manuf=Silicon Labs, prod=CP2102 USB to UART Bridge Controller, serial=0001)

And here is how I start up BFG: /home/me/crypto/bfgminer/bfgminer -S zeus:/dev/ttyUSB25 --set zeus:clock=340 --o stratum+tcp://mypool.com:6030 -u myuser -p mypass
I've also tried -S zeus:auto, /dev/tty25 and /dev/ttyS25 (because both of those files exist in my /dev directory, so I gave them a try), and detecting devices from the menu in BFG (which has actually worked for me in the past, but alas not this time). I made sure to compile it with the --enable-scrypt option.
I've determined that it's Device 025 by unplugging it and plugging it back in.
Any help or hints, anything to try, would be greatly appreciated; I'm eager to get my Zeusminer working and have been banging my head against a wall for a day trying. I also tried the version of cgminer that comes with it, with the same results.
Update: I'm using Bfgminer 4.4.0, which is the most recent, compiled from github yesterday. I compiled with --enable-script.
Update2: Using the new command line arguments from Mathias711 below, the Zeusminer is finally detected, but throws errors and does not hash. The errors are:
ZUS 0aa: Comms error (werr=1)
 [2014-07-15 22:52:40] ZUS 0aa: Failed to reopen on /dev/ttyUSB0
 [2014-07-15 22:52:40] ZUS 0aa failure, attempting to reinitialize
 [2014-07-15 22:52:40] ZUS 0aa: Failed to reopen on /dev/ttyUSB0
 [2014-07-15 22:52:40] ZUS 0aa failure, disabling!
 [2014-07-15 22:52:40] ZUS 0aa being disabled

Those are using /home/me/crypto/bfgminer/bfgminer --scrypt -S zeusminer:all --set zeusminer:clock=340 -o stratum+tcp://myreu.nut2pools.com:6030 -u me -p pass It actually does hash a tiny bit, but I can't tell if that's a display error or what.
Update 3: Solved!

The first problem was the command I was starting it with. "zeus" is no longer a valid option; in newer versions of BFG, it's "zeusminer". The final, working command in BFGminer 4.4.1 is /home/me/crypto/bfgminer/bfgminer --scrypt -S zeusminer:all --set zeusminer:clock=340 -o stratum+tcp://myreu.nut2pools.com:6030 -u me -p pass.

The second issue, the one that caused the list of errors above, was a bad power supply. I decided to try it with a power supply that I knew was good, and as soon as I plugged it in the errors stopped and it began to hash. It's pretty scary that it was running for hours with a bad power supply; I've had that ruin entire computers.

I've read reports of other people getting bad power supplies with their Blizzards, too. Combined with my own experiences on this one, if I ever buy another, the power supply is going right in the trash.

There are a few things that might be going wrong.

First, are you sure that your user has rights to read and write the serial port?  (There are plenty of tutorials online about how to do this.)  You can check if that is the problem by running (temporarily) as root.  If it starts to work, then you can go back and sort out how to give your user rights to the serial port.

Second, your command line looks like it may be wrong.   I say "may" because it depends on whose version of bfgminer you are running with.   My recommendation is to get the official one from the Github site and build it.   Assuming that is the one you have, then you need to call the miners zeusminer instead of just zeus.   You should also be using -o to define your pool, not --set.

Third, you need to tell bfgminer to operate in scrypt mode, or it will default to SHA256 mode.  This is done by adding the --scrypt command line option.

Try this command line :

sudo /home/me/crypto/bfgminer/bfgminer --scrypt -S zeusminer:all --set zeusminer:clock=340 -o stratum+tcp://mypool.com:6030 -u myuser -p mypass

I just fired up two Blizzard using a command line very similar to this.  (The only difference is I use the -O option to pass my user name and password together.)


10 days, still no confirmation. Will this ever get confirmed Hello StackExchange users,

I've been waiting for 10 days now for my transaction to confirm, and it still hasn't.
Can anyone please tell me if there is something I can do, or what the status of my transaction is?
All I know is this https://blockchain.info/address/3QG9MtXed7gJXAoLfMGFH2comrhN84hVk4
- But I don't understand much about it...

Thanks alot for any feedback and have a nice day.

Your fees are 17 sat/byte which is very low. I’d recommend using the “replace by fee” feature to accelerate the confirmation speed.


What happens to witness blocks? What happens to witness blocks after they are broadcast to other witness nodes? Are they kept or forgotten after some blocks?

Pruned nodes forget blocks after a while after processing. However, this is independent from whether those blocks have a witness.

SegWit does permit a half-pruned state, where witnesses are removed but the rest of the block is kept. That state is enough to serve lightweight nodes (which don't care about witnesses), but not enough to serve other full nodes. As far as I know, no full node software has implemented that half-pruned state.


What can be done to mitigate the risk of a Finney-attack? Related Question: Would a reduced block generation time make the Finney attack more difficult?

I understand that the Finney-attack is the main reason why accepting a zero-confirmation transaction should be avoided for transactions of significant value or at on-demand websites that "ship" instantly.

Suppose a merchant needs to accept transactions near-instantly - what can he do to mitigate the risk of this specific kind of attack without relying on any third-party (escrow-like) service? Are there any practical strategies like checking large pools for the transaction, systematically delaying the acceptance of the transaction, etc. that actually work? What could be changed within the Bitcoin-client to lessen the likelihood of this attack-vector?

The key to understanding why the Finney attack isn't really that big of a deal is understanding the business case for accepting 0/unconfirmed transactions. An online merchant doesn't usually have to accept such transactions since they probably do batch-shipping anyway. It's not required from an integration standpoint since the API includes many options to simply not return transactions without confirmations. The only business case that requires the acceptance of 0/unconfirmed transactions is when your customer is standing directly in front of you and won't be around for 10+ minutes. In such cases, a Finney attack isn't feasible and here's why:

Imagine I'm a scammer wanting to use the Finney attack against you, the honest merchant. I've spent a few grand and bought myself 3 GH/s worth of Radeon 5830 rigs. This number isn't arbitrarily chosen, I specifically picked it to make for easy math - 3 GH/s will net you about 1 block per month at current difficulties. Given that actual brick-and-mortar stores are closed for about 8 hours per night on average, this means that 1/3 of my found blocks will occur outside of business hours so on average I get a chance to double-spend with a Finney attack every 45 days.

Now as with all mining, there's no telling when you'll hit that lucky block so if I'm dead set on executing this attack I have to stay hypervigilant because once every 45 days I'll get an alarm of some sort telling me to go spend money at my target's store. I have to get there quickly because if I don't make my purchase and remotely trigger the release of the block fast enough, that block will get solved by some other miner and I'll lose my chance. So let's say on average it takes me 5 minutes to get somewhere, pick something and make a big purchase - I've got a 50% chance of failure, so now I'm able to execute my attack about once every 90 days.

Mining isn't cheap - my 3 GH/s setup draws something like 2 kilowatts, add in another 800 watts or so for cooling and at my local electricity costs it runs me about $8 a day to try for this attack. Multiply this by the 90 days it takes on average for me to be successful and I have to be successful to the tune of $710 just to break even. I'd make better money mining! Keep in mind that I've spent 16 hours a day every day for three months waiting for that alarm to go off too, so even if I double-spend $1420 (double my costs) I still only make $236.67 per month for my trouble - 49.3 cents per hour.

Oh and once you've made the purchase there's still the gap between then and releasing the block. If a block is found during that window, you've actually spent that money now. This particular attack is not without risk.

So there's something of an answer - not how to mitigate the attack but why the attack doesn't really matter. Online merchants don't need to accept 0 confirmation transactions since your stuff probably won't ship within 10 minutes anyway and brick-and-mortar merchants add a delay to the transaction process that makes the attack unfeasible. Even without the delay, the transaction would have to be positively huge to make any sort of profit and the attacker still stands a large risk of actually spending the money anyway. I don't really see this taking off.


Is Bitcoin's value the same, country to country? If not, which valuation is correct? Does a bitcoin have the same value in every country? Is it not like real money that we use in real life? Does it have a different value in every country?

Things only have value if you can get stuff with it.  The value of a bitcoin is dependent on supply and demand and how much the BTC-currency exchanges are exchanging for, so it does not necessarily have the same value in a all countries.


How do I check the checksum of a Bitcoin address? I'm working on a Bitcoin ATM. We want to detect addresses that are entered incorrectly.

There's a checksum on Bitcoin addresses - but how can we check it?

The way Bitcoin checks a public address is using what is called Base58Check. While the Bitcoin Wiki covers Base58Check, I'll outline how it works in both abstract and technical terms.

The whole idea of Base58Check is to prevent invalid addresses. This is done by adding digits to the start (00) and end of the Base58 value (4 bytes of double SHA256 hash).

Add 00 to the start of Base58 value ie 00 + BASE58 ==> 00BASE58
Checksum = 1st 8 digits from SHA256(SHA256(00BASE58))

BASE58Check = (00)(BASE58_SHA256RIPEMD160_HEXADECIMAL_VALUE)(CHECKSUM) (parenthesis for visualisation only, all other data is correct in size, ie CHECKSUM = 8 chars)

The best way to visualize all this is with The Piachu's App


How is a proof-of-stake block mined at the block level, and how does it accomplish it's goals? I've seen many broad overviews of proof-of-stake mining, and descriptions, but I have not seen any good description of what goes into actually mining and verifying a proof-of-stake block, and how it accomplishes what people say. What are the technical details of this?

Proof-of-stake mining is similar to Proof-of-work at a technical level. It involves a sort of lottery, similar to proof-of-work, but the difficult of this lottery is weighted depending on how many coins you are staking. The overall process for "attempting" to mine a PoS block is like so:

Add a coinbase transaction, and a staking transaction (in most coins, must be hardcoded as the second transaction)
Prepare block normally, with transactions from network etc
Compute the PoS "kernel"
Compute the "staking difficulty", which is the base difficulty, reduced by a ratio of how many coins you are staking (or in PoS version 1.0's case, the coinage of your coins)
Compare the kernel's hash against the staking difficulty
If the hash meets the difficulty then continue, otherwise go back to step 1 trying other UTXOs in your wallet that are suitable for staking
Now you have a valid PoS block. The final step is to sign the block header, proving that you own the staking transaction from step 1.

Now I'll try to go into a bit more depth.

First, the staking transaction is a special transaction that is not possible on the normal Bitcoin blockchain. It includes the concept of negative fees. Because all stakers know the reward, they add this reward to this transaction, meaning that there are more output coins than input coins. This kind of transaction is only valid in a staking context.

Next, the PoS kernel. This is a bit complicated, but the important part is that nothing in it can be easily changed in the context of this block. In the case of blackcoin, the kernel consists of "stake modifier"(I'll explain that in a bit), current block's timestamp, and data from the "txPrev". The txPrev is the transaction of the output which is spent by the staking transaction(ie, the input to the staking transaction). The data pulled from the txPrev includes blocktime, transaction time, hash, and output number (vout 'n').

Because the txPrev data has already been confirmed in the blockchain, it is immutable. The only piece of data that is mutable is the current blocktime. The current blocktime in PoS coins is actually masked though (ie, the bottom bits are set to 0), so that there is very little entropy that can be had by making minor modifications to it. And the blocktime can not be beyond certain network drift limits, or not all nodes will accept the block. Finally the stake modifier is a value generated by taking some entropy bits from the previous (iirc) 64 blocks and hashing it together to form a relatively random number. It's primary purpose is to make computing future block's (beyond the next block) kernel difficult.

Finally, all the data for the kernel is hashed together. The staking difficulty is computed simply. It takes the standard difficulty from Bitcoin, but makes it so that this difficulty is for 1 coin. If you stake 2 coins, then it's only half the difficulty. For 4 coins only a quarter of the difficulty, etc. There are some restrictions to this. In order to prevent someone from being able to control the network for a chain of blocks with a large number of coins, there is a limit to the amount of staking coins, and thus there is a limit on how much the base difficulty can be reduced by.

Finally, a signature is made, proving that the staking transaction actually belongs to the person creating this block. The signature itself goes into the blockheader so that the signature is part of the blockhash.

All of this put together causes the following effects:

PoS block "mining" does involve hashing and difficulty like PoW, but there are very few mechanisms to change the hash that is given, and so no matter how much computing power you have, it won't help any
The stake modifier prevents predicting which block you will be able to successfully stake, because it adds a lot of uncontrollable entropy to the kernel hash
The more coins you stake, the better chance you have at successfully creating a block, because of the weighted difficulty
In case the network gets stuck due to a sudden drop in the number of people staking, the low-entropy version of the blocktime will eventually allow new kernel hashes to be generated given enough time, giving stakers left on the network a chance to have a successful PoS block

I published this in a blog post, but figured it would fit the QA format of here well and help more people when searching for this answer


Why am I not getting payments on my bitcoind on an amazon ec2 instance? I have an amazon ec2 instance running a web server, MySQL server, and bitcoin daemon on ubuntu 14.04, and I ran ./bitcoind getnewaddress and the output was an address. I sent a few cents worth of bitcoin to that address, and I have been doing ./bitcoind getbalance for a few hours and still there is no balance.

Wondering if I needed to send to a particular accoutn instead of the main bitcoin daemon, I also sent a few cents to an address generated by ./bitcoind getnewaddress debug (just a test name) and did ./bitcoind getbalance debug. I have found nothing, I am not sure what the issue is. Port 8333 is open on the amazon vm, so I don't think the issue is there. bitcoind's rpc interface is running on port 8432 as specified by rpcport=8432 in ~/.bitcoin/bitcoin.conf. Any idea why I am not getting payments? I think there have been enough confirmations, I believe the number required is 6 required by default. I will check soon to make sure that there have been that many confirmations.

Your client needs to be fully synchronized for your transactions to show up, otherwise it's not aware that these transactions ever took place.


Advice on running two wallets please Could anyone tell me please if it is possible to run two versions of the Bitcoin qt client independently on the same pc?

The reason I ask is that I wish to make a bitcoin gift to someone on a USB memory stick.

So I run a fresh wallet, send some Bitcoin to it, then move the whole thing onto a USB stick for the other person to use at some point in time.

Does that sound sensible or is there a better way of doing this?

I already have and run my own wallet.

The person concerned doesn't have a pc of their own at the present time. Any help much appreciated.

You don't need to be running two wallets at the same time. Funds can be received while offline. Do the following:

Create a backup of your current wallet.
While Bitcoin-QT is NOT running, remove your wallet from the Bitcoin-QT folder.
Start Bitcoin-QT and create a new wallet.
Copy a receiving address from the new wallet to somewhere.
Close Bitcoin-QT and move the new wallet to the USB stick.
Restore your Wallet backup, and start Bitcoin-QT
Send the amount to be gifted to the receiving address you saved before.


how to get private key from passpharase in php? i have a passpharase bitcoin, but i don't know how to get private key from my passpharase. I tried using blockchain and electrum and it worked. but here what I need is to find the private key using php.

please help me how to find the private key?

if you have mnemonic seed phrase
use offline
https://iancoleman.io/bip39/


getblocktemplate returns out of memory I tried on a few different machines, vps etc. Also, few different altcoin litecoin included. Most were with 4 GB of ram, if this matters.

Every time when I enter the command getblocktemplate , I get return error message -7 "out of memory".

This prevents me from mining the coins in a pool.

Does anyone have any idea, why do I get these errors, and what to do to fix them?

It was the masternodes syncing.
Once I created a masternode and synced it, the getblocktemplate started returning normally.


Why is my Bitcoin private key so much shorter than my PGP private key? My PGP key takes up a huge, multi-line block of text, but my Bitcoin private key is just a small string. Yet both are considered extremely secure. Why is my PGP private key so long?

GPG keys are usually RSA keys.
RSA keys are based on the difficulty of the factorization. Keys are usually 2048 or 4098 bits.

Bitcoin uses ECDSA (Elliptic Curve Digital Signature Algorithm), where keys are usually smaller. Bitcoin uses the curve secp256k1 where keys are 256bits.

Roughly, an RSA key with 2048 bits offer similar security then a 256 bit ECDSA key.
Both offer more or less 128bit of "symmetric" security.

With newer versions of GPG you can also generate and use EC keys (nist-P, ed25519 or secp256k1)


Cryptocompare Api - understanding API return values I have come across the API from cryptocompare.com which fetches data from various exchanges.

I do not understand the some values returned from the API call

https://min-api.cryptocompare.com/data/pricemultifull?fsyms=BTC&tsyms=INR&e=Unocoin

Questions

Difference between LASTVOLUME and LASTVOLUMETO
Difference between VOLUME24HOUR and VOLUME24HOURTO
Difference between TOTALVOLUME24H and TOTALVOLUME24HTO

{
    "RAW": {
"BTC": {
    "INR": {
        "TYPE": "2",
        "MARKET": "Unocoin",
        "FROMSYMBOL": "BTC",
        "TOSYMBOL": "INR",
        "FLAGS": "2",
        "PRICE": 847591,
        "LASTUPDATE": 1512451304,
        "LASTVOLUME": 0.00139926,
        "LASTVOLUMETO": 1186.00018266,
        "LASTTRADEID": "478501",
        "VOLUME24HOUR": 75.19298754,
        "VOLUME24HOURTO": 61956574.46784429,
        "OPEN24HOUR": 837298,
        "HIGH24HOUR": 860506,
        "LOW24HOUR": 491500,
        "CHANGE24HOUR": 10293,
        "CHANGEPCT24HOUR": 1.2293114279503832,
        "CHANGEDAY": 0,
        "CHANGEPCTDAY": 0,
        "SUPPLY": 16720800,
        "MKTCAP": 14172399592800,
        "TOTALVOLUME24H": 319738.400426581,
        "TOTALVOLUME24HTO": 271005614230.93204
    }
}
    },
    "DISPLAY": {
"BTC": {
    "INR": {
        "FROMSYMBOL": "Ƀ",
        "TOSYMBOL": "₹",
        "MARKET": "Unocoin",
        "PRICE": "₹ 847,591.0",
        "LASTUPDATE": "Just now",
        "LASTVOLUME": "Ƀ 0.001399",
        "LASTVOLUMETO": "₹ 1,186.00",
        "LASTTRADEID": "478501",
        "VOLUME24HOUR": "Ƀ 75.19",
        "VOLUME24HOURTO": "₹ 61,956,574.5",
        "OPEN24HOUR": "₹ 837,298.0",
        "HIGH24HOUR": "₹ 860,506.0",
        "LOW24HOUR": "₹ 491,500.0",
        "CHANGE24HOUR": "₹ 10,293",
        "CHANGEPCT24HOUR": "1.23",
        "CHANGEDAY": "₹ 0",
        "CHANGEPCTDAY": "0",
        "SUPPLY": "Ƀ 16,720,800.0",
        "MKTCAP": "₹ 14,172.40 B",
        "TOTALVOLUME24H": "Ƀ 319.74 K",
        "TOTALVOLUME24HTO": "₹ 271.01 B"
    }
}
    }
}

VOLUME...TO shows the volume made in INR, and without TO shows volume made in bitcoins.

As one bitcoin is around 750 000 INR, a volume made of 75 bitcoins in last 24 hours is equivalent to volume made  of 61956574 in INR currency.


Bitcoin wallet service discontinued I was using Ninki as my wallet, however, the service got discontinued therefore I cant access it how would I go to recover my bitcoin or is it completely lost? Please help id really appreciate it

I was using Ninki as my wallet, however, the service got discontinued

Yikes, sorry mate.

  I cant access it how would I go to recover my bitcoin or is it completely lost?

Well, it depends. If you have a backup of the wallet, or a mnemoic seed phrase, you might be good to get your Bitcoins back. If Ninki does not let you do this, or you do not have one of these, your screwed.

You are not the only person facing this. Many wallets and exchanges close, taking their customers Bitcoins with them.


What does script operation "OP_IFDUP" do? According to the wiki page, OP_IFDUP will duplicate the top of the stack "if the input is true or false".  It seems to me that everything is true or false when interpreted as a boolean.

According to the source code:

case OP_IFDUP:
    [...]
    valtype vch = stacktop(-1);
    if (CastToBool(vch))
        stack.push_back(vch);

That suggests the wiki is incorrect.  What would be a better way of wording it, and what is the operation for?

It duplicates the top stack item if the top stack item is not 0 and not negative 0. I'm not sure where this would be useful.


Which Bitcoin developers are referred to as saying that "users have no say in the system's core development" Genjix wrote about this in two recent posts. Here's one.

  Some developers argue that with the issues being highly complex, that
  users have no say in the system’s core development

And the other:

  Other developers disagree with giving this information away and feel
  like you as users should trust their judgement

Are there public expressions of some core developers that object to public scrutiny and participation in the decision-making process? Who, of the core team, has issued such opinions?

You misunderstand what the developers are saying. They are not saying that they object to pubic scrutiny and participation. They are saying that being a user of Bitcoin does not somehow specially qualify you to comment on the design or implementation of the Bitcoin system.


Is there a type of signature that will be valid in a transaction with multiple inputs/outputs that are unknown at the time of signing? Alice is the owner of input_a (txid: xxxyyyzzz). Can Alice do a transaction that will entirely spend input_a (txid: xxxyyyzzz) minus fees to Bob (outout_a pkh: 1aaabbbccc) that can later be picked up by someone else and merge it into another transaction that spends 9 other different inputs (input_b, input_c...k) to 9 other different outputs? Alice needs to do the signature without being aware of which the rest 9 inputs / outputs are, nor the signatures for them.

Anyone knows a trick that could make this happen?

I think there is no "trick" :-) Maybe I don't fully understand your logic with "later by someone else". But maybe this helps you to get along:
I would think about a smart contract with CHECKSEQUENCEVERIFY, where you have a condition, that get's redefined, when a certain time has passed (after a specific amount of blocks have been mined). A very short idea could be this (baseline idea, no real code!):

OP_IF
   OP_DUP OP_HASH160 [PUBKEYHASH Alice] OP_EQUALVERIFY OP_CHECKSIG
OP_ELSE
   [blocks to pass] OP_CHECKSEQUENCEVERIFY OP_DROP
   OP_DUP OP_HASH160 [PUBKEYHASH "someone else"] OP_EQUALVERIFY OP_CHECKSIG
OP_ENDIF

This translates into this logic:
Alice can spend the tx anytime, but when a certain amount of blocks happened, then someone else can spend the tx.

It wouldn't matter, from "where" someone else spends the tx, if it is a single transaction with one input (aka Alice' Satoshis), or with many inputs from other tx. The spending condition for "someone else" is independant from the tx, in which it appears.

There is no wallet I'm aware of, that allows to realise the above condition via a graphical interface. It would have to be handcrafted... (aka "coded").

===================

Update after comments section has been worked through (28 March 2018)

Understanding your point corectly, you want to extend an existing tx with additional tx. To my knowledge there is no wallet which allows to do this. With the help of some command line tools one can get to the goal. A standard tx looks like this:

VERSION
TX_IN COUNT (e.g. 9 input structures)
 TX_IN[0]
  TX_IN[0] prev TX hash, OutPoint index, Script Length, Script Sig, Sequence
 TX_IN[1]
  TX_IN[1] prev TX hash, OutPoint index, Script Length, Script Sig, Sequence
 TX_IN[n]
  TX_IN[n] prev TX hash, OutPoint index, Script Length, Script Sig, Sequence

TX_OUT COUNT (e.g. 9 output structures)
 TX_OUT[0]
  TX_OUT[0] Value, PK_Script, pk_script
 TX_OUT[1]
  TX_OUT[1] Value, PK_Script, pk_script
 TX_OUT[n]
  TX_OUT[n] Value, PK_Script, pk_script
LOCK_TIME

So if the unsigned tx from Alice needs to go into this structure (of someone else), there are three things to get it correct:

you need to extract the V_in and V_Out from Alice transaction
need to integrate these parts in the model above, and update the
TX_IN and TX_Out counters
then the "someone else" would have to sign the tx...

The signing will be the complex part for someone else, cause somehow each input is signed with the corresponding privkey. So Alice would have to trust "someone else", and provide her privkey... If the privkey is not provided, the signature would stay invalid, and could not be sent into the network.

In general I was thinking, why one would do such an effort? For sure to save fees... As @willtech explained, exchanges collect many inputs into a single transaction, and then they have their corresponding privkey.

To get around this signing problem for Alice, one could think of a multisig. Then she doesn't need to provide her privkey to anyone.


What exactly is collecting transactions? From this post, I get some sense of how bitcoin works:

  What exactly is Mining?

Some dots I can't connect are related to how collecting transaction works:

Where to collect? Are these collected transactions always be
authentic (i.e. the user intended to perform such transaction with
promised transaction fees.)?
I can't see how a block ensures the collected transactions are
faithfully represented. can't they be distort by a miner?

Thank you for shedding some lights.

The miner "collects" transactions just by listening on the peer-to-peer gossip network where nodes send transactions to one another.

Every transaction has a digital signature which proves that this specific transaction was authorized by the owner of the funds (specifically, the person who knows the private key corresponding to the address where the funds were previously held).  You can't change the amount, destination, or fee of the transaction without invalidating the signature.  So the miner doesn't have to trust that all received transactions are valid; she can (and must) actually verify the signatures.

There's no guarantee that all transactions sent over the gossip network are "authentic", but as noted above any inauthentic transactions would be immediately detected and ignored, due to the signature being invalid.  Moreover, nodes that send such transactions get banned by their peers - this isn't strictly necessary for security (since everybody is verifying signatures anyway) but just helps keep those nodes from wasting everyone's time and bandwidth.

Likewise, when a miner produces a block, other miners (and every other node on the network) will check that the block meets all requirements of the Bitcoin protocol.  One of these requirements is that every transaction in the block has valid signatures.  So if our miner tries to "distort" transactions, their signatures will be invalid, and so her block will be considered invalid by other miners.  This means that when they produce their own blocks, nobody will list her block as the "previous", meaning that it won't end up as part of the block chain in the long run.  This in turn means that she won't get the 12.5 BTC block reward, nor the transaction fees associated with her block.  So trying to mess with transactions in the block won't work, and carries a severe penalty besides.


Working with the Bitcoin network protocol I am very interested in the p2p protocol used by Bitcoin clients. There are some excellent answers here that describe the way clients connect to the network.

How does the bitcoin client determine the first IP address to connect?
Peer to Peer: Methods of Finding Peers

I want to replicate the peer-to-peer network only without participating in the crypto-currency part. This is for an experiment on peer to peer discovery.

So, can you please show me some code instructions to set-up such a network?

This is a good start point to understand better the code related to peers discovery and management: https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp
I can't help you directly writing such a code for you but Bitcoin p2p is very similar to bittorrent one or similar. The greatness in Bitcoin is properly the fact that it has such (crypto)currency functionalities, so why should you use the Bitcoin protocol to create a p2p app which has no interest of using the main feature of the original code?
I think there are different code bases more suitable for your research.


"Sipa" definition? (old terminology, circa 2011-12) Vanitygen refers to "Sipa" format here:

  Currently, it is difficult to import the private key into bitcoin.
  Sipa's showwallet branch has a new command called "importprivkey" that
  accepts the base-58 encoded private key.  Vanitygen has been tested to
  work with that version of bitcoin.

I remember this term being thrown around when I was relatively new to Bitcoin, probably around the same time as the Vanitygen quote was made. There's a conflicting references to sipa format, it seems, for example, Multibit uses Sipa in place of WIF, whereas the aforementioned quote makes no sense in that context. BitcoinTalk seems to suggest Sipa = Base58 WIF

What, exactly, does the term Sipa refer to? (EDIT: And where did the term come from?)

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.


What happens to a miner's work when they restart? I am studying the bitcoin internals and especially the proof-of-work. The proof-of-work is based on the mathematical problem that we have to compute from an input that produces a hash with a certain leading substring, I think the substring should start with a certain amount of zeroes.

We hash the current input with SHA-256 so we need to compute 2^256. Now my question is, we hash the previous block chain's hash with transactions and the nonce? Is it anything else including in the hash? Furthermore, if the first try is not successful the nonce is changed as a result to compute a new hash?

A few more questions:
a) If we start adding transactions to a block and another block is created before our block, what happens to our work? We start mining from the beginning or we continue mining with our remaining transactions?
b) Moreover, can we include blocks with 0 transactions to the block chain?

Now my question is, we hash the previous block chain's hash with transactions and the nonce?

We can look at the form of a block here.

The information that is actually hashed include the version, previous block hash, the merkle root of the transactions the miner has included in the block, the current time, the target difficulty of the block, and the 32bit nonce. The rest of the information here is infered.

There's more information about the block format on the wiki.

  Furthermore, if the first try is not successful the nonce is changed as a result to compute a new hash?

The nonce is incremented until the 32bit space is exhausted, at which point the header is modified to give a different work for the miner. At the present time this may happen many times a second.

  If we start adding transactions to a block and another block is created before our block, what happens to our work?

The current work is discarded, and the miner starts working on top of the highest block the know about.

  Moreover, can we include blocks with 0 transactions to the block chain?

No, a block must contain one transaction containing the miners reward, which can be any value up the limit of the current block reward, at the time of writing this is 25BTC. 1 transaction blocks are quite common, as they're less likely to be orphaned (another is created while the minted block is making it's way across the network).


How is an address beginning with a 3 valid? The Bitcoin Dark Wallet project is accepting donations to address 32wRDBezxnazSBxMrMqLWqD1ajwEqnDnMc. How is this a valid address? I thought that all Bitcoin public addresses start with 1.

According to the List of address prefixes, an address beginning with 3 is Bitcoin script hash. This means that transactions sent to this address are handled differently than normal transactions.


Are there public LN nodes that have some gRPC LND API endpoints accessible for 3rd parties? My lnd node died but I'm doing some research on lightning channels. So I'm rebuilding a new btc/lnd node, but in the meantime: are there open nodes that I can access, especially for SubscribeChannelGraph?

Update:
I found this repo that pretty much had everything I needed. It's a modular implementation of the BOLT specification in NodeJS, meant exactly for uses cases like mine.

https://github.com/altangent/lntools

As far as I know there are no open nodes anywhere. But I have not been searching for them. Generally you don't need a full node / a full implementation to get the data from the lnd command subscribechannelgraph.

Basically you will only need to reimplement BOLT 07 ( https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md ) to listen to the gossip protocol.

However since the transport layer in BOLT 08 is encrypted via the noise protocol framework you will also have to reimplement this in order to be able to connect to a peer. Only your peers can be queried for the network graph from BOLT 07. The only other BOLT that you need is BOLT 01 which describes the message format of peer messages.

Implementing these allows you to interact with the peer to peer network and get information about the channel graph without the necessity to implement a full lightning node or even run a Bitcoin node. In fact you don't even need any of the Bitcoin techstack (just ecdsa for your static node key and strong authentication within BOLT 08)

I might make the network graph available via my lightning node next weekend if I remember to do so. Then there would be an open api command to query for this data. Hope that answer helped.


HD Wallet Child Private Key Derivation Function I was trying to understand the specs on CKD function from both the bip32 standard and Mastering Bitcoin book, I couldn't understand how a private key is derived from the left side of the extended key.

The book just says the right side becomes the chain code and the left side becomes the private key, after some research online I read someone using terms like tweaks and modulus n,  G which are confusing me since they were not mentioned in the book and not so much in the specification itself.

Please help me clarify on how exactly a private key is derived from the left side of output, and the relationship with all those non mentioned parts like the modulus n (Which  n?), tweak (??), multiply by G ( What's G?) since all these terms are not well documented.

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

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

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


Imported bitcoin address to block-chain un-spendable I imported a bitcoin address to my block-chain wallet. The bitcoin shows as un-spendable in the wallet. The address was used previously by me and worked fine. How do i fix the problem to make the spendable.

Assuming this is a standard P2PKH/P2WPKH address, your wallet will need knowledge of the private key that was used to derive this address, in order to spend the funds locked to it.

Addresses are public info, so when you 'import an address' to a wallet, that just means you have instructed the wallet to watch that address, and report back the apparent balance of it. Anyone can do this with any address, since they are public knowledge.

In order to spend those funds, you would need to 'import a private key' to your wallet (and then ensure that your wallet derives the correct address from that key, eg, segwit vs legacy addresses). Your wallet will then be able to use this private key to create a signature on a transaction that spends those funds.


I got sent funds but cannot get them I got sent funds but I do not have enough space on my computer to update bitcoin core and therefore the funds will not come is there anyway to cancel the transaction.  The website I got the funds from said they cannot cancel so can I cancel.

It is difficult to cancel a Bitcoin transaction after it's been sent, and it cannot be done by the recipient, only by the sender.  If the transaction has been confirmed, cancellation becomes impossible.

However, the funds are not lost.  They will be waiting in the address until you claim them.  You can either eventually finish installing and syncing Bitcoin Core (possibly on another computer), or you can import your wallet.dat file into some other software with lower resource requirements, and you will be able to spend your funds then.


Connecting to a node and opening a channel What is the difference between connecting to a node and opening a channel with a node in the lightning network? What are the events happen when I just connect to a node?

When you connect to a node in the lightning network, you are opening a network connection to that node. You begin exchanging messages about the lightning network and can gather information such as other open channels, other nodes that can be connected to, etc. This information can help you build a better channel graph and decide whether you want to open a channel with this node or with some other node.

Once you have connected to a node, you can open a channel with it. Opening a channel requires creating a Bitcoin transaction, broadcasting it to the Bitcoin network, and waiting for it to become confirmed. When you open a channel, you must also be connected to the other node as you need to send information about the channel, such as channel updates, to that node.


How can I recover the missing end of my private key? I found this paper among my old stuff.
What can you do with it?
Is there any way to fill in the missing part?

TL;DR:
You don't need to bruteforce anything here (at least almost), and can recover the missing last 7 characters on an average PC at home within less than 1 second using a simple Python script!
In detail:
In your picture there are 7 characters missing at the end of the private key (figured out by comparing with a test-printout using the same HTML file).
Yes, it is correct that this key format is using Base58 alphabet and therefore there are 58 possibilities per character, so for 7 characters you would need to try 58^7 possibilities (which would be about 2 trillions) in theory, but all these considerations are missing an important fact:
When such a private key (the format is called WIF short for Wallet Import Format, see also the reference documentation here) is encoded, at the end (after the actual private key) 4 bytes are added as a checksum. So if these 4 bytes are missing (at the end) you can calculate it from the rest.
Second: in your picture it looks like your private key starts with an L. This indicates that the Bitcoin address is based on a compressed public key. Don't worry, this is a technical detail, but this helps you further:
Private keys for compressed pubkeys have another special byte added after the key (and before the checksum), namely a fixed 0x01 (see also in the reference documenation for WIF).
This means that the last 5 bytes of a WIF encoded private key (starting with L or K) are either static or can be computed from the rest.
So you are very lucky that the last 7 characters are missing (and not the first 7, because then you really would need to bruteforce 2 trillion possibilities).
What to do with this information:
If we apply this knowledge now to base58 we see that only a single character is missing and then we can calculate the rest.
Reasoning: first: a single base58 character carries ~5.85799 = log2(58) bits of information and second: we don't need the last 40 bits (4 bytes checksum + 1 static byte for compressed key are 5 bytes = 40 bits).
So, if only 6 characters would be missing at the end (6 * 5.85799.. = 35.14794) we not need to bruteforce anything, because this would be still less than the 40 bits we don't need.
Conclusion:
As you are missing 7 characters we just need to bruteforce one single character (and this means just 58 attempts, not 2 trillions).
So we just attempt to add one of the 58 characters from the bas58 alphabet. For each attempt we calculate the full base58 string by adding the static compressed key flag byte (0x01) and after that the checksum and simply compare it with the rest of the key you have. If it matches it is a valid candidate.
At the end of these 58 attempts you will end up with 2 or 3 (at most) valid private key candidates, and just need to check these 3 keys, to see which one belongs to your address.
The Reddit user /u/dooglus/ (not me) pointed out exactly this in the first place in his comment on your post and he also added a snippet of Python code which does exactly I've described above.
Don't trust anybody, don't hand out your key to any stranger!
Now take your time, learn what the Python script below does (don't trust me or any strangers) and when you feel safe, copy the Python snippet from /u/dooglus/'s comment, save it in a text-file named complete-wif.py on a safe computer. After that take the computer offline and run the Python script by typing this into a commandline:
python3 complete-wif.py L...-your-private-key-goes-here...yhub
and it will print 2 or 3 completed WIF private keys in less than 1 second.
Appendix:
For reference, I appended the Python script but it's not my work, all credits go to /u/dooglus/. I just can confirm that it does what I described above (but ask others to confirm this and try it with other private keys before you trust it with your real private key):
#!/usr/bin/env python3

import base58, sys

partial = sys.argv[1]

if len(partial) != 45:
    print("partial key should be 45 characters")
    sys.exit(1)

results = {}
for c in '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz':
    wif = base58.b58encode_check(base58.b58decode(partial + c*7)[:33] + b'\x01').decode('ascii')
    if wif[:45] == partial: results[wif] = True

for k in results.keys(): print(k)


How can I measure outstanding debt? How much "stored value" is in Ripple at any given moment? Is there any way to measure how much stored value is in Ripple at any given moment?

I read that that people who are risk averse won't store cash in Ripple for long periods of time, and will redeem their IOUs right away.  Since the nature of transactions is for someone to "pay later" that makes me think there will always be stored value in the system.  Based on that:

How many IOUs (outstanding debt) has been issued at a given time? (stored value)
What is the average duration of a transaction (network wide, per gateway, etc)

How can I query for this data in raw format (or graphically)?

You can issue the account_lines command to a Ripple server to find out what credit lines have been extended by or to an account.

For example, you can use this websocket test page to issue websocket queries. Set the location to wss://s1.ripple.com:51233, click use secure, and then connect.

Then paste this in the Message window:
{ "command" : "account_lines", "account" : "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B" }

This pulls the credit lines that Bitstamp has. You'll see entries like this:

     {
        "account" : "rrpNnNLKrartuEqfJGpqyDwPj1AFPg9vn1",
        "balance" : "-501.64408854616",
        "currency" : "BTC",
        "limit" : "0",
        "limit_peer" : "10000",
        "quality_in" : 0,
        "quality_out" : 0
     },

This means that Bitstamp owes rrpNnNLKrartuEqfJGpqyDwPj1AFPg9vn1 501.64 BTC (Bitcoins) and that user has extended them a credit limit of 10,000 Bitcoins.


if nobody is mining then there will not be bitcoins generating anymore and verifying bitcoins ? what will happen if there will be nobody in the world to mine. then there will be no future to bitcoin??
and also if nobody is mining then there will not be bitcoins generating anymore and verifying bitcoins ?

Correct. Mining activity has several goals including:

Generating new bitcoins (until 21 million bitcoins).
Verifying new transactions and persisting them in the Bitcoin system (in Bitcoin block-chain).

Mining is crucial for the Bitcoin system and therefore the Bitcoin system provides the incentive (Bitcoin reward) for everybody that participates in mining. The security of Bitcoin is directly dependent to the computing power of network's miners.

One question that may exist in this context is "Why may miners stop mining?". Miners may stop mining because of a decrease in Bitcoin value. The miners' reward is a constant count of bitcoins (currently 25 bitcoins, which is halved every 4 years). If the value of Bitcoin decreases, the reward for the miners will decrease equivalently, too.

The worry would be that Bitcoin gets caught in a "Death spiral".

  This leads to the possibility of a death spiral in which loss of
  confidence in Bitcoin could cause the Bitcoin price to go down, a
  falling price lowers the incentive to mine and the equilibrium mining
  rate, lower mining rate leads to the currency being easier to subvert,
  and this leads to a further loss of confidence in the currency.


Exchange Confirmation Requirements What does the minimum confirmations required for a deposit mean for the security of exchanges? For example, Coinbase requires 3 confirmations for Bitcoin deposits. Suppose an adversary deposits 10 bitcoins into an exchange and has his account credited.

What stops an adversary from mining a private chain with a transaction that conflicts with his previous deposit transaction. What would this mean for the exchange? Would the user have the ability to sell the Bitcoins credited to his account and defraud the exchange?

Coinbase probably requires even more confirmations for a deposit of that high a value. According to https://www.crypto51.app at this moment, it would cost some $600,000 to attack the Bitcoin blockchain for one hour. That means sustaining a 51% attack and potentially (not definitely) double-spending a deposit to Coinbase that had several confirmations.

If you are a merchant that accepts Bitcoin you must take this risk into account given the value of the transaction. A $1000 deposit to Coinbase is probably safe after three confirmations, because it would cost so much more than $1000 to reverse three blocks.


What is a good hardware for a lightning network node? What is the hardware setup you use for your LN node? Is a Raspberry Pi 3 enough for testing and playing with small amount of funds?

Lightning itself is a pretty lightweight protocol and can easily be run on a raspi 3. However without neutrino a lightning node needs to have access to a Bitcoin full node. Most people seem to run the Bitcoin node on the same machine as the lightning node. While a raspi3 can run both the processor is a little week to verify the entire blockchain. So expect a long time (couple of weeks) for initial blockchain sync or run a remote Bitcoin node.


How can I check a public master address balance? I have an extended public key, I need to check it's balance (I have no connection to wallet), is there a third party service for that ?
Edit: This is not a bitcoin address. This generates multiple new addresses each time and I want a method to check the total balance given only the master public key .

You probably mean extended key. There are extended public keys (xpub) and extended private keys (xpriv).

An example xpub would be:

  xpub6CUGRUonZSQ4TWtTMmzXdrXDtypWKiKrhko4egpiMZbpiaQL2jkwSB1icqYh2cfDfVxdx4df189oLKnC5fSwqPfgyP3hooxujYzAu3fDVmz

They always start with xpub or xpriv.

You could use  https://blockchain.info/xpub/ or goochain.net or Electrum as a view-only wallet.


BTC-e funding/withdrawal methods. Anybody tried any of these? When one tries to deposit or withdraw, a dropdown list shows several choices, including Perfect Money, MoneyPolo, and OKPAY (and some other ones, including various cellphone-related ones with high fees, which I'm not interested in). If I'm not wrong, Mt. Gox supported OKPAY too, back in the day.

Has anybody tried any of these three and is willing to share their experience? (MoneyPolo and OKPAY are both owned by Mayzus, apparently, but I don't know what differences are there between them).

Also, if anyone knows there's another SE site where this question would be more likely to be answered, or somewhere else where I can find this info, it would be really helpful too.

I am using perfectmoney there for funding there and it goes always instant to get credit my account balance, i think that is nice method to use there.


Are Ripple IOUs fungible? If you hold an IOU from a gateway for $1,000, there's a good chance
  you'll be able to pay that to nearly anyone at very close to face
  value. If you have an IOU from some random guy for $1,000, you may not
  be able to find any payment path to people you want to pay and no
  payment path to a gateway if you want to cash out.

Isnt that a huge flaw in the system? That the one $1,000 can has less value than the other $1,000, based on who the debtor is. The whole power of Bitcoin is that all coins have equal value, and to preserve that philosophy they will never allow tainted-coins.

But with Ripple it looks like my wallet can show $1000, but based on the 'taint' its real value can be as low as $50.

That's just reality. IOUs will be valued differently depending on who you got them from.

You probably value $100 in cash higher than the fact that your friend Joe owes you $100. You can use the cash right away while you have to wait for Joe to pay you back or you could transfer that debt to some common friend of you and Joe's (a friend who is fine with Joe owing him $100).

Now compare it to having $100 in a bank account at your local bank (i.e your local bank owes you $100). You'll probably value that a bit higher than having Joe owe you $100 since it is easier to instantly transfer it to your friends that have accounts at the same bank.