What would happend if a country were backed by its own cryptocurrency?

As this has not happend yet, the only thing we can do is "speculate" about the answer.
However, this may change in the near future, Estland is currently creating it's own cryptocurrency.
One of the key advantages for citizens of the country would be that they would have a currency which does NOT devalue / inflate like something as the dollar / Euro, since you can't just suddenly make another billion of them.
However this at the same time is also probably the reason why it will never work.
Countries can't for example "press" more money.
But, the cryptocurrency could also make life easier in the following ways,

Imagine for example if you as en r-resident could charge Estonian customers in estcoins,
pay your corporate taxes and public services in estcoins,
and estcoins is accepted as legal tender in the same way as euros in Estonia. If this actually happens, then there is no limit on how deeply integrated cryptocurrencies could become in everyday life.

Also, it would, if the coin is bitcoin based ( open ledger blockchain.) protect the citizens from their own government.
Meaning they can for example see and verify exactly where their money is going, due to the blockchain.


To join a mining pool go to their website and create an account. Connect the ASIC machines (which you already bought) to their server using the stratum link they give you.
The mining pool has its own bitcoin nodes which will be used for mining. There is no way to connect your node to the pool - they don't want to use it. Your bitcoin node is only used for your mining if you run your own pool.
Miners just do the work the pool asks them to do, without knowing which blocks they work on.
In theory miners could use their own bitcoin nodes for a couple things:

You could verify that the mining pool is mining on the longest public blockchain. If you detected that this is not the case then you could automatically switch to another pool. This would ensure that you never assist a pool in performing a 51% attack.
If the pool allows you to mine with getblocktemplate instead of the stratum protocol then you could control which transactions go into the blocks you mine (if the pool allows this). Your bitcoin node would give you transactions to put in the blocks.

But in practice noone is doing either of these things.


How to convert encrypted wallet.dat to decrypted? (Yes, I know the password)

The easiest way is to export your private keys using the dumpprivkey functionality.

  DumpPrivKey: returns the wallet-import-format (WIP) private key corresponding to an address. (But does not remove it from the wallet.) Bitcoin Developer Reference

Do this for each address that is storing bitcoin (use listreceivedbyaddress to view all addresses with funds)

  ListReceivedByAddress: lists the total number of bitcoins received by each address. Bitcoin Developer Reference

Then create a backup copy of your wallet.dat file and then remove it.  The next time bitcoin-qt runs it will create a new empty unencrypted wallet.  Now you can use importprivkey to restore your funds.

  ImportPrivKey: adds a private key to your wallet. The key should be formatted in the wallet import format created by the dumpprivkey RPC. Bitcoin Developer Reference


If you want to run full BCH node - then yes. Most of these 140Gb is the same for now as with BTC node though, but that's not going to help you in reducing space requirements.

You can always run your node pruned, with ~5-10Gb space requirement max.

If you intend to run both BCH and BTC nodes at the same time on same computer - the issue will be that they both require port 8333 open. Unless you have multiple IPv4 adresses or IPv6 subnet - you will have to choose only 1 node visible to the world.


If you have a mobile wallet, do you lose your coins when you lose your phone?

No, not necessarily. In fact, if you actually follow the instructions given by most wallet software, you won't lose your Bitcoin.

When you first setup a Bitcoin wallet, most modern wallet software will walk you through making backups of your wallet (which are not stored on your phone). Most will also force you to click through multiple dialogs of "I understand that not backing up means I can lose all of my coins" if you try to skip the backup process. If you have a backup, then you can restore your wallet on a new phone or on a computer with a different wallet software. If you do not have a backup, then yes, you will lose all of your Bitcoin.

Alternatively you could use a web wallet where the information necessary to spend your coins are stored on the internet with a third party. In this case, if you lose your phone, you won't lose your coins so long as you remember your login credentials. But I wouldn't recommend using a web wallet as they can cause many other security and privacy issues that can result in you losing all of your coins.


There is indeed a US Broker for Bitcoins.  Unfortunately, for now, they're still in private beta.  The company is called Buttercoin: https://www.buttercoin.com/  You can sign up for their private beta, but there's a pretty long waiting list right now.


what is "forming a coinbase transaction"?

The link you mentioned has a few code snippets, so I am assuming the code you want to write in C is the simple mining program. The python code can act as your pseudo code and very well write your mining program in C.

Alt coins which have been forked from bitcoin and do not have many changes in the mining algorithm can be very easily mined by the same methods described.

The most you would have to change is the hashing algorithm used which can be different from BTC's sha256.

When connecting with a mining pool,  it is generally advisable to use already existing mining softwares like cgminers wherein you just need to pass the stratum url and port (also  the hashing algorithhm in a few cases). A huge amount of code runs delegating the chunks of the mining problem to the miners connected to it.


How are transaction IDs generated and how are they then changed by transaction malleability?

The transaction ID is the SHA256d(signedTransaction) = SHA256(SHA256(signedTransaction)). Sha256d is SHA256 applied two times.

Example:
Let us consider the transaction with ID 844c00ca065bc26eb61bfee203df2f7bcbc72a6bb77697a32d2a98dad5941109. The hex encoding of this transaction is:

02000000019e8cc9f5c7e16bc11e6f4050fbdf925e5ea9e0d3c8b430bce4afc61fa7675c53000000006b483045022100efc6e04a4735465257c4f0ff51f9015c3806daebb390ceb1ae18402794a3192c02204616b6cd7c86321d896270d2758db2d245f0c14d60693711c1e891fa2ea5c1010121036a9946621a6428c3719cd992f32c5ebf1fec1c403e2f7796301fc000473bf2b6ffffffff03802b21000000000017a914f896d5607bc2b01309019104d9dd33fa76d79f538751cfa600000000001976a9145a45d570db268e085de17cb5b53d5dba5eeb855d88ac63890100000000001976a9148ae4ce7cbda181e6c2635d15e518dafbbabd5caa88ac00000000

You can check that the SHA256d for this signedTransaction is 091194d5da982a2da39776b76b2ac7cb7b2fdf03e2fe1bb66ec25b06ca004c84 on this page:
http://extranet.cryptomathic.com/hashcalc/index (remember to tick the 'Enter as hex' box) by flipping the endianness (Bitcoin uses small-endian representation of hex numbers/byte arrays), you get the expected result:

844c00ca065bc26eb61bfee203df2f7bcbc72a6bb77697a32d2a98dad5941109

Transaction malleability means that you can change the signedTransaction without invalidating it. So someone else has provided the signature but you can change the signed transaction in some way without invalidating the provided signature.

A Bitcoin transaction consists of different fields such as inputs, output amounts, output destinations etc. One of the fields is called scriptSig and this is where the signature goes.

It is possible to change the scriptSig field without invalidating the signature. The scriptSig field consists of instructions (opcodes) where a signature is considered valid if the execution of the scriptSig field followed by the execution of the scriptPubKey field (another field consisting opcodes) leaves the number 1 on top of the stack. The virtual machine that executes the opcodes is a stack machine.

For example you can add the op code OP_NOP (which does nothing) in front of the rest of the scriptSig without invalidating the signature. The signed transaction may still be picked up by miners but the transaction ID (once it is included on the blockchain) will be different than what the signer expects.

Segregated witness transactions solve this problem by removing the signature from the scriptSig field into a new field called the witness field and it also prevents any additional data from entering the scriptSig field thus preventing the malleability. The TXID of a segwit transaction is calculated the same way but it does not include the new field, the witness.


Can I use Armory without having the Blockchain in my laptop?

No. Armory requires you to download the entire blockchain. You cannot use pruning either as Armory requires the entire blockchain to be present in order for it to work properly.


LTC to BCC transaction shows confirm but still not recieved

LTC, BTC, and BCC (whatever that may be) are three different networks. When you send LTC to an address from a different network's wallet, they are received to that address on the Litecoin network.They don't magically turn into a different currency.

If you control the private keys corresponding to the recipient address, you may be able to recover the coins. Otherwise, you may want to get in touch with whomever controls the private keys of the recipient address and ask them if they can do you a solid.


How does a wallet get the public key from an address?

Perhaps you're confused by the phrasing "the wallet", as it's only the receiver's wallet who needs to know the public key, and he has it, because he created the address in the first place.

In what follows, I'm going to assume a standard 1... address (pay to pubkey hash). That's not the only type of address, but similar ressonings apply to every type of addresses.

In the normal workflow, there are two wallets involved. Let's call them Suzy (the sender) and Rudy (the receiver).

Rudy generates a private key x.
Rudy computes the public key corresonding to x, called P.
Rudy computes the addreds A corresponding to P by hashing it.
Rudy sends A to Suzy (by sending it in person, or putting it on a website, or showing it as a QR code, or ...).
Suzy constructs a transaction that contains an output addressed to A. Suzy has no clue what public key A corresponds to, but also doesn't care. This address really encodes "require a public key and a signature valid for that key, and the hash of the public key needs to be A".
Suzy broadcasts the transaction on the network, where it will be picked up by miners who put it in a block, finalizing the transfer.
Now when Rudy wants to spend the coins he received from Suzy, he needs to satisfy the condition that Suzy put in the transaction. This requires the public key P (as that's the only known public key whose hash is A), and a signature created using private key x (which is the only private key that can construct signatures that are valid for P). Thankfully, Rudy has both x and P, because he was the one who created them.


Open source wallets to host on our website

With all due respect, the first answer that you received to this question is wholly inaccurate.
'Bitcoin Core' is a client (not a library or a wallet).
You're looking for something like 'BTCPayServer', which is a completely autonomous, self-hosted wallet solution that requires a server to spin and allows you to control every aspect of your interaction with the source code on a granular level with as much fine tuning as you desire.
Here's the site: https://btcpayserver.org/
There's a live demo for you to play with along with a wealth of documentation.


From this blog post describing the timejacking attack:

  Each node internally maintains a counter that represents the network time. This is based on the median time of a node's peers which is sent in the version message when peers connect. The network time counter reverts to the system time however if the median time differs by more than 70 minutes from the system time. A very reasonable way to estimate the median network time.

So block timestamps are based on "network time" which is in turn one of:

The median time advertised by peers (if between ±70 minutes from system time)
System time

  The network time is used to validate new blocks. As a precaution, nodes reject any block timestamp that is greater than 2 hours from the current network time. Block timestamps that are earlier than the median time of the past 11 blocks are also rejected. This validation puts upper and lower bounds on the acceptable range of block timestamps.

So block timestamps are:

< 2 hours from "network time".
> median of last 11 blocks.

I have to refresh my error propagation lessons, but I guess this leads to an accuracy at around ±3 hours.

Of course this is just an upper bound on error, but the actual question remains: what is the real blockchain accuracy? (which is a very interesting question.) The only way to be sure is actually tracking it and comparing with a known perfect timestamp. I don't know if anyone has ever done that before and couldn't find any references.


Bitcoin has a huge incentive system to discourage a 51% attack. Bitcoin mining with CPUs is impractical. You have to use dedicated hardware that can only be used to mine Bitcoin and other coins that use the exact same algorithm.

So to acquire enough hashing power to launch a 51% attack on Bitcoin, you can't just rent computing power or buy CPUs. You have to invest in Bitcoin mining equipment. If you manage to harm Bitcoin significantly, you're just turning your expensive mining hardware into so many doorstops.


Connect mined blocks with various addresses

This isn't a complete answer but I might be able to point you in the right direction:

It seems like you have:

CBlockTemplate* CreateNewBlock(const CScript& scriptPubKeyIn)

So you're taking a CScript  as a parameter. Some additional relevant links.  I think you would either use that to create multiple outputs, or you would use

txNew.vout[1];

https://en.bitcoin.it/wiki/Transactions#general_format_.28inside_a_block.29_of_each_output_of_a_transaction_-_Txout
https://en.bitcoin.it/wiki/Script
https://dev.visucore.com/bitcoin/doxygen/script_8cpp.html
https://dev.visucore.com/bitcoin/doxygen/class_c_transaction.html
(and follow the links to CTxIn/CTxOut from there

Also see how they do it here:
 - https://dev.visucore.com/bitcoin/doxygen/miner__tests_8cpp_source.html


How does the rate of getwork requests correlate with the hashrate of a miner?

The standard getwork protocol forces the miner to send a new request every second. This means that if a miner takes longer than 1 second to check all nonces in a given getwork (2^32), it will be making a new request before it checks all values in a given request, thus giving you 1 getwork request per second regardless of the hashrate.

If the miner can solve the getwork faster than that, it would be making requests more often. In theory, you could use this formula to calculate the hashrate:

Hashrate = noncemax/time

Where time is the interval between the getwork requests and noncemax is the size of nonce field (2^32). However, this assumes no time delay due to the network lag and so forth, so it's an ideal scenario. Moreover, some miners discard unfinished work after submitting a share, so it would appear they are doing more work in your configuration than they actually are.

If you intend on using getwork extensions, specifically noncerange and rollntime, you could calculate the hashrate more accurately. Noncerange would change your noncemax to whatever size you set, and rollntime would allow you to measure time intervals greater than one second. However, not all miners support the extensions.


This question is another duplicate and already answered here by dooode:
Why is my transaction not getting confirmed and what can I do about it?

You have to stop/reverse the old Bitcoin transaction you created without confirmations:
Make a backup of your wallet.dat

Run bitcoind or bitcoin-qt with -zapwallettxes=1 option.

This makes the wallet "forget" any unconfirmed transactions, thus enabling you to reuse their inputs.
Create a new transaction to make your payment and add an appropriate fee this time.

You can now send the bitcoins where ever you want or you can send them all back to yourself.


I'm suppose to set rpcuser, and rpcpassword on bitcoin.conf file on .bitcoin folder. Right?

Kind of. rpcuser and rpcpassword have been deprecated in favor of cookie authentication (temporary username and password placed in the .cookie file) and rpcauth.

  Well, when I do so I still can call bitcoin-cli without prompting any password,

It's not supposed to. bitcoin-cli reads the data directory to get the information it needs. It will read your bitcoin.conf file for the username and password or it will use the .cookie file.

  the code does not work

Your code is completely wrong.

serverURL = 'http://' + rpcUser + ':' + rpcPassword + '@localhost:' + str(rpcPort)

This is incorrect; that's not how authentication works for this.

Bitcoin Core uses HTTP basic auth; the username and password are not part of the URL like that. Since you are using Python Requests, here is their documentation on using HTTP Basic Authentication: http://docs.python-requests.org/en/master/user/authentication/#basic-authentication


Is there a tutorial on how to set up a secure enviroment and use Electrum?

Here is check http://secure-bitcoin.blogspot.ru/, please leave a comment if you find any mistakes


nLocketime error PUSH TRANSACTION ERROR: 64: NON-FINAL

It's most likely because nLocktime is based on the "mediantime" of the previous block... not "exact" unix time.
Due to delays in finding a new block, it is not unusual for "mediantime" and "current time" to end up out of sync by quite a significant amount (1+ hr).
If you don't have access to a Bitcoin Node to check the getblockchaininfo command, then you can use this online API: https://chainquery.com/bitcoin-cli/getblockchaininfo
Check the "mediantime" value and compare with your "nLocktime". Once "mediantime" > "nLocktime", you should be able to broadcast without error.


How to specify ECDSA nonce used in bitcoin signing code?

ECDSA_do_sign() does not allow specifying the nonce. You can use ECDSA_do_sign_ex(), which needs extra arguments for (k*G).x and 1/k instead.

Bitcoin master recently switched to the libsecp256k1 library for signing, which always needs the nonce passed explicitly, and does not require precomputation of the x coordinate and inverse. See the code in Bitcoin Core for signing: https://github.com/bitcoin/bitcoin/blob/0a1d03ca5265293e6419b0ffb68d277da6b1d9a0/src/key.cpp#L75-L92

Disclaimer: I'm the author of libsecp256k1.


Naming Convention In Bitcoin Source Code

http://en.wikipedia.org/wiki/Hungarian_notation

C stands for Class
p for Pointer
f for Flag (boolean)
n for Number
sz for zero terminated string

These conventions are no longer mandatory when contributing to bitcoin core.

You might also read https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md


Can a Ledger Nano X hold multiple BitCoin Wallets?

Yes, you can have multiple bitcoin wallets in ledger nano x by adding a new account
All these accounts share the same seed, but have different derivation path


Two party payment channels, how to set one up?

what you are talking about is usually refered to as dual funded channels. This is a feature that did not make it into the current version of the Protocol (BOLT1.0). However it was agreed by the developers that it should become part of BOLT 1.1. Currenly C-lightning has most progress towards this feature.

There is a legacy feature push_msat which opens the channel from one side but allow you to already push funds to your friend. however you should not that these funds lost directly.

If you want to be able to receive funds on the Lightning network there are three options:
1. someone else opens  a channel withyou (for example when they want to send you money anyway)
2. You pay someone on the lightning network or buy something after you have opened channels
3. You use an onchain / off chain swapping service after you opened a channel but this puts requires and additional on chain transaction.


How do I fix Bitcoin-qt Error: "Cannot allocate memory bitcoin in ProcessMessage()"

This error has been showing up recently and it seems to me ( just my 2 cents here ) that it works down to 2 possible issues, the most common is physical memory in your system.  The more memory available to Bitcoin, the better as the block chain is getting to the point I almost need a new hard drive just for the block chain.  It helps if you have more than 2 Gig of ram, not how much space is left on the hard drive, although that can also cause cannot allocate memory errors on some systems.

Either way, start with this link, if your model is listed, look in to more memory and all that involves. If it isn't, look at what ones listed there are comparable to yours and consider upgrading to one that can have the memory upgraded later.

http://support.apple.com/kb/HT1270

The other option is to move your block chain information to a different folder and reopen Bitcoin and see how far it goes to download the block chain information.  If the second option ' magically ' clears it, it could be due to one of the alternate currencies based on Bitcoin and one of the peers sending erroneous block chain information.  If it does run in to an issue with 10 or more weeks left to update, then it is a memory issue.  Also, back up your wallet.dat file ( copy to some thing like btcwallet.dat ) on to a removable drive as it contains your ' basic wallet including password lock ' information and a new system could rebuild your current wallet with that one file.


With Mike Hearn quitting Bitcoin, what seems to be the future of bitcoinj?

Hopefully, bitcoinj will now be maintained by other people that based projects on it. From what I've read and the commit list it seems that Andreas Schildbach, who also initiated the Bitcoin Wallet for Android, now takes a leading role in maintaining of bitcoinj.


How many types of mining pool are exist for bitcoin or litecoin?

The pools are mostly distinguished by:

fees: how much the pool charges workers
size: the larger the pool, the smaller the variance of your payouts
payout style: pay per share, pay per last N shares, etc.
location: do they have a server near you (extra latency will mean less mining work accepted and a lower payout)

As you guessed, getwork, long poll, stratum, etc. are not types of pools, but rather types of protocols for getting mining work from the pools. Some pools support more than one type of protocol.

You can see a nice comparison of various BTC mining pools here:
https://en.bitcoin.it/wiki/Comparison_of_mining_pools


Without being continuously connected to the network, how can I protect from Double Spend attacks?

To essentially eliminate any risk due to double spending, the recommended level of confirmations is six.

For most transactions such as those to a bricks and mortar merchant, payment might be accepted immediately (with 0 confirmations), but that exposes the merchant to a small degree of double-spending risk.

A recommendation for merchants running their own node is to have the configuration where there are no incoming connection and to explicitly have an outgoing connection to a well-connected node.

Thus, properly configured this way, the merchant is not much at risk of double spending because either the transaction was broadcast and it reached the well-connected node that the merchant connects to or it didn't and the merchant doesn't know about it until communications from the party attempting to pay can be re-established with the outside world.

In that scenario, bitcoin fares no worse than any other merchant payment system as those require authorization from connected sources as well.

The amount of data to receive blockchain data is relatively little -- under 100MB per day.  Thus even a single dialup modem connection is all that would be needed and that node could then serve all other nodes connected locally.

Additionally, if mobile communications are present, the merchant could simply use mobile notification from a hosted service and not run using a node at all.

There is a business solution not a technical one to the specific scenario requested.  Just as a hotel will accept a check from a guest even when it doesn't have a guarantee that the check won't bounce, a merchant can accept a bitcoin transaction even when there are no communications by adding a layer above (e.g., verifying identification, getting approval to charge against a backup payment method using a credit card, not selling anything of high value during the communications outage, etc.)


Where can one trade AuroraCoins for Bitcoin?

Create an account on Mintpal, they have a direct trading market: AUR/BTC. From Mintpal you can withdraw it to your own wallet or where ever you want to have it.


Should an end-user download the whole blockchain? Or is a “lightweight” client sufficient?

For the MultiBit client:
(disclaimer: I am the lead dev)

1) as you are not running a full node, you are not helping relay transactions nor mining nor verifying blocks.

2) if an attacker can surround your network they can feed you spurious transactions and a fake but well formed alternate fork. (I guess this is true for bitcoind too).

3) MultiBit does not keep a database of unspent transaction outputs so importing an arbitrary key is slow.

4) you ARE downloading the full blocks and parsing them (though not storing the full blocks) so you can keep up to date with blockchain reorgs and such like.

5) an unconfirmed transaction cannot be verified by checking all the inputs are unspent and thus you cannot rely on it until it is confirmed. A full node can check everything about the transaction. Only when it appears in a block (on the main chain) can you have any confidence in it.

6) not actually related to architecture but important for security: only the beta MultiBit code has encrypted wallets.

7) compared to bitcoind, the lightweight clients have less manpower working on them. If you want to use bitcoin in, say, a company environment then bitcoind would be the safer option.

In summary: there are a few limitations caused by not having access to the full block chain locally but for everyday use they should not hinder you too much. Factors more to do with what the devs have managed to implement (or not) probably make a bigger difference.


Running both bitcoind and bitcoin-qt for use with lightning

There's no particular issues with running both the daemon and the QT using the same data directory, you're also protected against running them both at once due to locking. Most versions, especially within a single major release, are compatible so there's no burning concern about keeping them exactly in sync with one another.


How do deterministic wallets know how many keys to generate?

You've hit upon an important issue, and one that there isn't a perfect solution to.

Your thin client (most clients that use deterministic wallets are thin clients, but not all) goes through the following process:

Generate an address.
Look at the blockchain, and see if it has a balance.
Repeat with next address, unless the addresses we've checked have had a balance of zero for a long time.

The number of empty addresses you're willing to check before giving up is called the gap limit.

The gap limit can't be too low, or there's a possibility that someone will backup from a wallet seed and not see all of their money. (If this happens to you, increase the gap limit and try again.) It also can't be too high, or you'll waste resources on the servers handling Electrum queries.

Your suggested scenario is actually the easiest to solve, because if each of those addresses has a transaction associated with it in the blockchain, the client knows that it showed that address to you at some point, and will keep searching.


The Trezor doesn't actually only derive at specific derivation paths. Rather it has to be given a derivation path, and the Trezor web wallet software only uses predefined ones. However you can use another tool that connects to the Trezor and specify your own derivation paths.

Trezor has a command line tool as part of their python library that you can use. See https://github.com/trezor/python-trezor/blob/master/docs/OPTIONS.rst. You should be able to use that to construct a transaction that uses the addresses that you want.


If you want to see all bitcoin transactions for a given address, coming to or going from, then you need to actually look through the block chain. Fortunately our good friends at blockchain.info have given us a nice api to do just that.


Three months is about the useful life of an ASIC miner. The cost of all practical mining (not including wasteful mining done by botnets and the like) tends to equal the value of all practical mining. So an approximate rule of thumb for the cost of an attack is the value of all Bitcoins mined in three months. Since the block reward is currently 25 BTC, Bitcoins are around $700, and a block is mined around every 10 minutes, you're looking at roughly $200 million. Using existing equipment is impractical -- you need ASICs.


Does the newly created transaction needs to be propagated to ALL
  nodes in the network in order to be validated?

No. The nodes relay valid transactions to each other. In corner case you can send your transaction directly to miner node. No one will have this transaction until it included in block


You can assign an alias to your node. The als is what is being depicted in node explorers. It is a regular utf8 string. Nowerdays there are a lot of icons as characters in utf8 encoded strings. For example ⚡.
So in lnd and in clightning (apparently both have the same Syntax) you could add the following line to your config file:

alias=⚡my node name with icons⚡

After restarting your node and waiting until the gossip protocol has propagated your new alias you will be able to see it on node explorers.


How are Bitcoin Signed Messages generated?

The message that is signed is prepended with

"\x18Bitcoin Signed Message:\n" + compactSizeEncoding( len(message) )

\x18 is Python syntax for unicode character 0x18. This new text string is then converted into a byte array by interpreting the string as UTF8. This will give you the correct hash preimage which is:

SHA256(SHA256(utf8.to_bytes("\x18Bitcoin Signed Message:\n" + compactSizeEnc( len(message) + message )) =
559766ea41f2bc4125e5449200dbf7e902b724b66104820ca5b7fc59f30a19e0

You can see a Python code example here. The function msg_magic generates the hash preimage from the message. This Python code example does not correctly implement compactSizeEnc, however. So it only works with a message length up to 253 bytes.

The correct way of handling compactSizeEncoding is documented here.


Can somebody provide me with the $price per GHps in mining since the old CPU days til present pre-orders?

There isn't really a good way of measuring that in the early days. When CPU mining was actually doable, people would just use hardware they had. It didn't necessarily "cost" them anything. Even with GPU mining it's hard to estimate GH/s/$ because these weren't made for mining.


I am still unable to withdraw my bitcoins that were deposited before their September 2012 security breach.  Therefore BitFloor is technically insolvent.

They are registered with FinCEN as a money-service business in the U.S.  Thus I assume they are not immune to U.S. courts and U.S. bankruptcy laws.

They are one judgement away from having their bank funds frozen by a creditor, likely forcing BitFloor to declare bankruptcy.  If that happens, your funds might be used for paying out to legal costs, paying for the receiver, and then whatever is left for payment to all remaining unsecured creditors such as yourself, proportionate to the amount owed (i.e., "pennies on the dollar").

http://bitcointalk.org/index.php?topic=112069.msg1218947#msg1218947

I like BitFloor and I'ld like to see them succeed, but continuing to operate an exchange while insolvent is a move that is irresponsible and shows disrespect to its customers, current and prior.


I'll address your points individually:

Bitcoin mining in the future will be supported by transaction fees rather than the block reward, see this question for more details: What will happen to mining after the 20 999 999th Bitcoin?
Not sure what you mean here, why would an increasing difficulty lead to only one miner? If people stopped mining, the difficulty would go back down again because the hash rate would have decreased, so there's an equilibrium point based on how profitable mining is at any one time
The difficulty is just an algorithm which is based on the time taken to mine the last 2016 blocks (technically only 2015, because of a bug, but that doesn't matter). So everyone agrees on the difficulty, everyone can calculate the current difficulty by looking at the blockchain. No one person sets the difficulty, everyone does.
Scaling is an issue which is a big topic at the moment, because yeah the blockchain is getting very large. But please note that it's possible to run a pruned node which only stores some of the most recent blocks and doesn't all the way back to the genesis block. Full nodes never use this historical data anyway other than when serving brand new nodes with blocks to get them up and running, and when rebuilding their UTXO set, which normally is only done once when the node first starts and doesn't need to be done again.


Transaction unconfirmed, send with Multibit HD, too low fee

As you have alread realised the Bitcoin mempool is currently (since the last 7 days) full of high-fee paying transactions.

Unfortunately I do NOT expect the number of transactions paying such high fees to drop significantly during the following days/weeks. But eventually with some luck when not so many new high-fee paying transactions are broadcasted your transaction may be confirmed.

MultiBit does not support replace-by-fee (RBF) as far as I know. Therefore you cannot do much more than sit and wait. If your transaction is not confirmed within around 1-2 weeks, then the network will drop if from the mempool and you can broadcast a new transaction with a higher fee.


How does copying main stack prevent malformed unlocking scripts vulnerabilities?

you can find explanation here:
https://bitcointalk.org/index.php?topic=5095376.msg49150302#msg49150302

  the issue was actually with OP_RETURN. What OP_RETURN used to do is it would skip to the end of the script so whatever was on the stack was interpreted for the final script result. So what you could do was create a scriptSig that was just

OP_TRUE OP_RETURN

  which would push true to the stack and skip the rest of the script (which included the scriptPubKey at this time). The interpreter would see that at the end of script execution a true was left on the stack so it would say that the script passed. Obviously this is bad because the nothing in the scriptPubKey was evaluated so none of the spending conditions were actually met.

  In fixing this bug, Satoshi disabled many other opcodes, changed OP_RETURN to always cause script execution to fail, and separated the execution of the scriptSig and the scriptPubKey so that the scriptPubKey is always executed.


The chainActive variable stores the best known block chain. But this is essentially just the chain of block headers, not the actual blocks themselves. To load the actual block from disk, use the ReadBlockFromDisk() function. But, be aware that this is an expensive function to use, it does not return immediately.

chainActive[0] or chainActive.Genesis() [1]

Gives the genesis block header.

chainActive[chainActive.Height()] or chainActive.Tip() [2]

Gives the header for the most recent block in the active chain.

chainActive[chainActive.Height()-10]

Gives the block header for the block with 10 blocks built on top of it.

Use any of these CBlockIndex pointers as below to get the block.

CBlock block;
if (ReadBlockFromDisk(block, pindex)) {
    // do something
}


When using bitcoin-cli I get an error regarding fallback fees when trying to send regtest Bitcoin. How do I resolve this?

bitcoind uses transactions it relays (and later see as mined) to estimate the feerate to set for transactions its wallet creates.
On regtest, you don't relay then mine enough transactions so bitcoind's estimation buckets are not filled enough to give a reliable estimate. Without such an estimate the wallet, out of safety, prefer not to create any transaction unless you explicitly tell it what fee to use when fee estimation isn't available.
This "fall back feerate" can be set up at bitcoind's startup with the fallbackfee startup option, expressed in BTC/kB.

   -fallbackfee=<amt>

         A fee rate (in BTC/kB) that will be used when fee estimation has
         insufficient data. 0 to entirely disable  the  fallbackfee  fea‐
         ture.  (default: 0.00)

Alternatively, crafting transactions on different nodes of your regtest network and getting them mined will result in estimation buckets to be filled.


Migrate from Bitcoin Core Wallet to somewhere else before sync completed

Following these 3 easy steps helped me:

Download & Install Electrum
Extract your private key from Bitcoin Core Wallet
Import your wallet using the private key


Generated a transaction id but not seen on blockchain

High S value error indicates that a signature in your transaction doesn't adhere to BIP-62, i.e. that your signature is non-default. This is the same issue that has been levered in many of the past transaction malleability problems. This could happen for example if you use a very old version of your wallet software.

If your transaction hasn't propagated in the network, you should be able to create a new transaction with the same inputs. It might have been malleated and broadcasted with a different signature though, which would give it a different transaction id. If that's the case you should be able to find it by looking at the addresses of your inputs.


Run bitcoin with the parameter -datadir=C:\New\Dir

E.g. create a shortcut and change "target" to "C:\Program Files (x86)\Bitcoin\bitcoin-qt.exe" -datadir=C:\BitcoinData


Both people said they work for bitcoin

Some people lie.

  Is there any possibility that I can trace this money?

Criminals often try to make that difficult for you. It is unlikely that anyone can trace exactly where your money went.

  Is there not honarable people/organisation ...

There are but

  ... who can get my money back?

Part of the design of Bitcoin and other cryptocurrencies is to make it hard to track transactions to real people.

What you have done is the equivalent of putting banknotes in an envelope and posting it to a post-office box address in a foreign country where such boxes can be rented without presenting any ID.

You should report the crime to your local police. You would be wise to assume your money is lost.


Does a Vanity Address reduce the randomness / entropy of the private key? Is there cryptographic proof?

Vanity Addresses only reduce the apparent randomness of a public key. The underlying private key is still just as random as always, as the private key does not have any special characteristics (it does not have a special pattern in front or anything like that). A given public key is as likely to be generated by a private key from range 0-10, as for 1000000-1000010 and the like.

If knowing some given pattern would make it more likely that one would be able to find the private key, then since every public key is known when coins are spent then vanity address or not, it would be just as easy to steal one's coins.


What is the "zeitgeist attack"? Does it affect all blockchain technologies?

This is a 51% attack where the attacker sets the block timestamps artificially to lower the difficulty, allowing him to profit more coins than his hash rate would warrant. It works because the difficulty adjustment formula is based purely on timestamps that can be chosen quite freely by the attacker. In particular, the timestamps are not required to be in increasing order. ArtForz explains the attack in detail here.

This attack was used against the new Geist Geld block chain. Geist Geld difficulty adjusts every 16 blocks making the chain particularly vulnerable against this attack. An attacker targeting Bitcoin would have to mine a full set of 2016 blocks at the current difficulty before starting to get any benefit compared to a "normal" 51% attack.


What is a transaction's step-by-step life cycle?

The lifetime of a transaction would be something like this:

You start with a client, a wallet that contains your keypairs, and some unspent transactions (you get those from other people or through mining).
You create a new transaction spending some of your unspent Bitcoins, sign it with your private keys. Your client will store a copy of it.
Your client starts to broadcast the new transaction through the Bitcoin Network. As far as I remember it doesn't broadcast it to every peer, but to every 8th peer in order to protect your anonymity. Every minute the client will also broadcast all transactions it knows about to one of its peers, which would also include your new transaction.
Every client that receives your transaction scrutinizes it - they check whether the signature is okay, whether there are any errors, and whether you are trying to perform a double-spend. If your transaction fails any of the criteria, it is ignored by the client entirely. Otherwise the client keeps a note of the transaction in temporary memory.
All the clients that know about your transaction follow a similar route of broadcasting as you did - send it to 1/8 peers, and then to one peer every minute. They will also not broadcast your transaction if its fee is too small at a given time (which varies on the amount of transactions to be included in a block and so forth). Generally, if you don't pay fees, you get punished with slow transaction broadcast rate right here.
Eventually your transaction reaches some mining pools and the recipients of the transactions. The latter will see the new transaction in their wallets and store a copy of it indefinitely, but it will appear as 0 confirmations. The mining pools will see it as a new transaction and (most likely) will include it in every block they try to create. They will store a local copy of the temporary blocks and give out the corresponding work to solve to their miners.
The miners don't know anything about your transaction, other than with one or more transaction it hashes to a given merkle root. Their job is to crunch numbers, not to check for block validity, as that's a task for the pool.
Eventually your transaction is included in a block that gets solved. It gets broadcasted proudly through the Bitcoin network and everyone keeps a note of it from now on (to know if some new transaction conflicts with it in a double-spend attempt). Now your transaction has 1 confirmations.
The block creation process continues, and as more and more blocks build atop the block your transaction gets included, it gains more confirmations. Eventually reaching 6 and more confirmations, it is considered fully confirmed.
The transaction finishes its live cycle once it is spent by another transaction, meaning that its outputs can be forgotten from the "unspent" memory and disregarded for any other attempts to spend them. It will, however, remain in the blockchain for as long as people will keep track of the full chain.

There are a few complications during 51% attacks and so forth, but this is the main flow of a standard transaction.


The current BIP process is defined in BIP-2. An author drafting a new BIP leaves the BIP number in the preamble marked as XXXX. A BIP editor  assigns a number to that BIP when the draft phase is complete. The number is chosen by the BIP editor, while generally one of the next higher numbers is assigned. Some number ranges might be reserved to allow BIPs with a common theme to have similar numbers. The current BIP editor is Luke Dashjr.


Does segregated witness allow to securely create LN channel opening transactions?

Are these two problems effectively solved with segregated witness?

One is; one is not.  Specifically:

  (1) The anchor transation id required for the commitment input will only be known once the anchor is signed.

Segwit fixes this.  If the anchor transaction contains only segwit inputs, then its transaction identify (txid) does not change when signatures are added.  This allows other transactions (such as the Lightning commitment transaction) to refer to its outputs regardless of whether or not it has been signed.

  (2) The anchor transaction can be malleated by either party before entering the blockchain, rendering the commitment input unusable.

Segwit does not fix this specific problem, but it does fix an important related problem.  As the paper you cite says, "The last of these is particularly pernicious, as BIP62 doesn't solve it: signatories can always re-sign a transaction, hence altering its transaction ID."

The anchor transaction is created with inputs each user unilaterally controls (or shares control with a third-party to the Lightning channel currently being opened, an irrelevant detail to this discussion).  Because of this, each user has the ability to create a full double spend of their part of the anchor transaction; if that double spend is what's included in the block chain, then any children of earlier versions of the transaction (such as the commitment transactions) are invalid.

The important related problem segwit does solve is useful to Lightning and required by other smart contract protocols.  A payment in a payment channel (including Lightning) uses multisig to require both parties sign the payment under regular circumstances, called 2-of-2 multisig. Because signatures sign all of the non-signature data in a transaction (normal SIGHASH_ALL) but are currently included when generating the txid, either party can unilaterally malleate a transaction by changing his signature.

But with segwit, all non-signature data in a transaction is still signed but the signatures are not covered by the txid, so neither party can unilaterally change the txid without invaliding the other party's (or parties) signature or signatures.  In other words, it requires both 2-of-2 to change a txid or, more generically for m-of-n, segwit requires at least m participants to change the txid.

This simplifies the design of Lightning-style Hashed TimeLock Contracts (HTLCs) and also improves the privacy of outsourcing channel enforcement, but is not required for Lightning.  However, it is required for some other smart contract protocols that use sequences of transactions.  For example, a Spillman-style payment channel would be secure using segwit but today it is vulnerable to malleability.


What is the highest recorded difficulty in the main net?

As at 9th May 2012, the highest recorded difficult has been:

1,888,786.705353 first reached August 01, 2011.

Blocks 139,104 through 141,119:

http://blockexplorer.com/b/139104
Bitcoin Difficulty History


How to start working with blk*.dat data?

You can use Bitcoin-ABE

https://github.com/bitcoin-abe/bitcoin-abe

There are various options, I used the sqlite export to get a local SQL database with blocks, tx, outputs etc.


Allocation Unit Size (AUS) when formatting drive

Blocks are stored in large contiguous files (gigabytes), and are effectively append only, so they don’t really make any sort of impact on performance.

The high write cycle is in a several gigabyte leveldb database, but this is heavily write cached. Performance is almost always single core limited on any sort of fast storage given sufficient memory, rather than any other other factor.

You’ll only see storage as a factor when using magnetic media or excruciatingly slow flash storage like a SD card.


Coinbase balance 0.00089623 BTC help to get it out!

From memory it may be free (or cheaper) to send the bitcoins to another user's Coinbase.com account, so one option may be to get a friend to withdraw them for you when they withdraw their own balance. It's a lot of bother though for what's currently worth only about $5.

An alternative option (a better one, in my view) is to leave them there and hope that they increase in value or that the fees decrease, and instead spend your time on more productive activities.


A) Not sure if there is a way to do this with the core client. You could do list all your transactions and search through them yourself (see listtransactions).

B) To get the scriptPubKey, you could make a dummy transaction to your multisig address, decode it, and the scriptPubKey will be in the resulting JSON.

To get the redeemScript, use validateaddress to get the public keys (or get them any other way). Then do:

./bitcoin-cli createmultisig 2 '["0233201f4bc6df77f61affdc0b9a8e13c286050b8203453af3788bb3db781d8003", "020c13c8562c579fa79d78fd6dde15924b615c5c5c0904241ac311eb3954377ea0"]'

This will return something like this:

{
    "address" : "3N5ntrDQAv7M4xqdjnpvzWfpogHnRvtMBm4",
    "redeemScript" : "52210233201f4bc6df77f61affdc0b9a8e13c286050b8203453af3788bb3db781d800321020c13c8562c579fa79d78fd6dde15924b615c5c5c0904241ac311eb3954377ea052ae"
}


Is there any benefit to increasing the maximum orphan tx in bitcoind?

Is there any benefit to the bitcoin community by preserving a larger
  number of orphan tx

What kind of benefit/profit/etc can gain the community by the increased mempool for orphan transactions on one node? Literally, none.

  or am I just wasting memory?

This is your donation to the network.


Do you have to download the entire bitcoin blockchain for bitcoin core pruned mode to take effect?

Pruning saves disk space, but you still need to download the whole blockchain, prune mode works on the fly, once your node has downloaded the block data and validated the blocks/transactions in it, it throws away the old data that it no longer needs, but in order to revalidate all old blocks


You are trying to use a mainnet encoded address on testnet. That is not valid. You need to use a testnet encoded address.

The testnet form of the address you are trying to use is 2MvX28fMpoipKxqaxo6pN1CH4QjB5t9qpr8.


Why are Sphinx forward messages not used in Lightning's onion packets?

Questions like these are always leading to an opinionated response and are a little bit tough to answer. I will give it a shot though.

First of all I think youelf already answered your question to an important degree. Forwarding messages via the SPHINX protocol yield the possibility of message length attacks.

I think Another reason was the goal to be simple in the beginning. I know there is a lot of discussion to extend onion routing to HORNET which would create a connection oriented encrypted communication layer on top of the lightning network and routing protocol. This obviously yield some advantages but also complexity and possibilities to introduce exploits.
Let us remember that sphinx mix format was created to send and receive messages / emails and we "abuse" it for lightning. So I guess we liked at the core feature we needed.

I think the main reason for using the EOB field in spontaneous payments is that it was easy to implement this in the current system without too many changes. But to be sure roasbeef might give the exact reason.


Where are my bitcoins after wallet removal

These two events

removing your wallet from Multibit
observing zero balance in your Blockchain.info wallet

are extremely unlikely to be related. You can see that the transaction went through and has several dozen confirmations.

If your Blockchain.info wallet is appearing empty, you may want to contact Blockchain.info for resolution.


How do mining pool payout methods affect the cost of executing a block withholding attack?

Generally, the higher the variance for the miners of a reward method, the higher the cost of sabotage attacks (and I think also the potential profit of lie-in-wait).

In PPS there is no variance; and the cost for sabotage is negligible, it is merely the reward of 1 share.

In a typical method with no risk absorption and moderate variance, withholding a block means you lose your portion of its reward, which is h/H, your portion of the pool hashrate.

If you take an extremely high-variance reward method such as "pay per last 10 shares", withholding blocks means losing 10% of the reward, since if you submit a block then by definition you have a share in the last 10 shares, no matter your hashrate.

And of course, when solo mining, block withholding means losing all of your mining reward.

A block finder bonus is added multiplicatively to the other costs. For example in PPL10S with 20% finder bonus, when withholding you lose both the 20% bonus and 10% of the distributed 80%, for a total cost of 28%. However, finder bonus is a poor way to combat block withholding because it creates a lot of variance.


The mining difficulty directly reflects the amount of computing power that the Bitcoin network has. This is adjusted on a periodic basis so that the average block solution time is 10 minutes (Bitcoin clients recalculate the difficulty every 2016 blocks). The difficulty can go up or down depending on how much effort people are putting into mining.

More information about difficulty can be found on the Bitcoin wiki.


Does rpcpassword need to be non-obvious in bitcoind?

By default the RPC interface is only exposed to localhost (127.0.0.1 and ::1), not to the world. In that setting, you need an RPC password only to protect against untrusted local users on your system (unless you're somehow tunneling the RPC port 8332 out).

That said, why do you have an rpcpassword at all? If you're only going to use bitcoin-cli for example you don't need one since version 0.12 (see https://bitcoin.org/en/release/v0.12.0#rpc-random-cookie-rpc-authentication). If you need for having external applications to to bitcoind, rpcauth is preferred over rpcpassword.

There is certainly no need to restart syncing.


Unless I'm misunderstanding you. You just need to track the multi-currency balances inside your own gateway. There are a number of ways you could do this but without more information its difficult to help.
We recently built a Ripple based solution which keeps track fiat and virtual deposits using Ripple and you might be able to build or purchase something similar.
I hope this helps.


A wallet is a collection of private keys that correspond to addresses you control; you can spend the coins that are credited to those addresses.

The "New" button creates a new private key (within the same wallet!) and shows you the address, so that you can ask someone else to send coins there.  You could reuse an address that someone else had already sent coins to, but this means that both senders would gain information about your financial activities (since all transactions are public).  Using a fresh address helps your privacy.

The "New" button doesn't affect existing private keys in any way.  Previous receiving addresses remain active and usable, and you can browse them in the address book.


Either of these solutions would work.

If you mix it first to a previously unused address or send it directly to the merchant via the service (ignoring the issue of timeouts on a merchant terminal if they have such a feature) the effect is the same.

The only thing to make sure is any change does not go back into an address which has not been via a coin sharing service. This will cause a link-back to your previous transactions.

The easiest way to avoid this is to have two separate wallets, one which is only been mixed and one which has not.


To generate a P2WSH address, you need to have some script. The most easiest one you can use is a multisig script. You can do this with the addmultisigaddress. If you do something like

addmultisigaddress 1 '["37Ju7oTbPfe5qNAHYiAKfdTtVvCSP3TTdL"]' "" "bech32"

you should get a P2WSH address.


Updating old BitCoin-QT Core client V0.7 - 2017 Approach?

edit: [removed a part about upgrading. Lower part still remains relevant I think, so I think I will keep it there.]

I don't know of any place where you can download the latest compatible blockchain, but more importantly you should never want to do so! If you download it from some shady site, what guarantees would you have that the chain has not been tampered with, or that it will contain trojans, keyloggers or the like, which could lead to loss of funds/time. Just install the bitcoin client of your choice and let it download the blockchain through its connected nodes. It can verify the contents and make sure you are on the right chain.


Is it possible to change to protocol, mine lots of blocks offline, and then change it back?

Such an attack is not possible:

The protocol contains a rule how to calculate the difficulty to succeed in mining a new transaction block. This difficulty expresses in the form that a hash must fulfil (number of leading zeroes) in order for other network participants to accept it as valid.

There is no other way to arrive faster at a hash that fulfils the difficulty requirements than to try out as many as possible as fast as possible.

Now, you could easily reduce the difficulty requirement in your client's protocol and mine thousands of blocks every second, but these blocks would not be accepted by the other network participants. Firstly, of course, because you don't fulfill the difficulty and secondly, because the length of the blockchain is measured not in the number of blocks, but in the combined difficulty of the blocks.


Paper wallet vs wallet.dat on memory stick for long term storage?

Paper wallet:

pros:

easy to store
easy to create
provide the same amount of security as the fiat money does
you don't need to worry about viruses
valid for a long time

cons:

easy to be misplaced
if you cannot provide phisical security, it is more likely useless

wallet.dat on pendrive

pros:

none, in my opinion

cons:

easy to be misplaced
pendrive can become corrupted in the next few years, due to hardware deterioration
it can easly be stolen or copied
again, you need to provide phisical security
wallet.dat format can change over time, thus making your data hard to recover (depends on the future decision of devs)


Both the block reward and the fees are collected via a "coinbase transaction", which is the first transaction in the block.  It has no inputs, and the total value of its outputs is allowed to equal the sum of the block reward plus all the fees from the block.  The miner can then set the outputs of this transaction to pay the total to their own address(es).

In particular, it is not necessary for the miner to explicitly list which fees are being collected from which transactions.  It's assumed that all fees from all transactions in the block can be collected, so this determines the allowable amount for the coinbase transaction.

The "after 100 blocks" rule is enforced by requiring that none of the next 100 blocks is allowed to contain a transaction which spends this block's coinbase transaction.  I guess it's a matter of semantics whether the reward "happens" with this block or 100 blocks later.


P2Pool Payout Addresses vs Worker Addresses

Through trial and experience, I can now answer this question myself. I decided to NOT use a payout address for my p2pool command line, and only used dash core wallet reception addresses for my worker names, but each worker address is address+difficultNumber. It's working fine and reporting well in the p2pool web page, whereas it wasn't reporting things before using the above initial scheme. It looks like this arrangement will be more profitable than the previous one too.


This occurs because Bitcoin Core's coin selection algorithm tries to have a minimum change of 0.01 BTC. Fees are subtracted from the change output so the result is that the change output has a lower value, but before fees, it will try to for the change output to be at least 0.01 BTC.
As we can see in your transaction, the change before fees is approximately 0.01 BTC. Presumably it is actually over that because you have obfuscated the last several digits. Then the transaction fee was subtracted from the change output to get the final change output value that you have.

The reason that there is a minimum change is so to avoid creating very small change outputs. Small change outputs can be detrimental to the user's wallet and to the network as a whole. Those small change outputs result in the wallet having more UTXOs, which means that for future transactions, require more UTXOs to spend. Furthermore, small values can quickly become uneconomical outputs when the feerate rises. If lots of small change outputs were being created, a wallet could end up having a significant portion of its UTXOs be unspendable when fees are high.
Additionally, by having a minimum change target, the coin selection algorithm will tend to consolidate and sweep up smaller UTXOs. This behavior is, in general, good for the wallet and good for the network. It reduces the number of UTXOs globally, reduces the number of UTXOs that the wallet needs to handle and keep track of, and makes it less likely that UTXOs in the wallet will become uneconomical in high fee events.

In general, coin selection is a hard problem which needs to balance several factors. It is not just what the fees are for the transaction right now, nor is it necessarily just about the user of the wallet in that moment. Coin selection needs to consider the cost of spending outputs in the future and how its behavior will effect the selection of UTXOs in a future transaction. Coin selection needs to balance the health of the network and the performance of the user's wallet.


Are there any places where should not use compressed public keys?

There is no one advantage to use uncompressed key vs compressed.
So, there is no one place in code where uncompressed key is allowed and compressed key is disallowed


Why is bitcoin-qt not launching?  Using linuxmint-12-lisa

There is a bin folder that contains the binary. There are two folders in that folder, "32" and "64". You have to know what type of system your mint/computer is. It either a 32 bit system or 64 bit system. If you click on on a 32 bitcoin-qt on a 64 bit computer it will not start and vice versa.


What is an extended fingerprint (xfp) and how does it differ from an xpub?

The fingerprint of a public key is defined in BIP 32 as the first 4 bytes of the RIPEMD160 hash of the SHA256 hash of the public key. The fingerprint of a particular xpub can be gotten from that xpub, but this is not useful information.

What the Coldcard wants is the fingerprint of the master xpub. It wants the fingerprint of the key at derivation path m. This is because the Coldcard uses BIP 174 PSBTs. In particular, a PSBT can include the derivation path for a public key involved in an input in the PSBT. This derivation path will also include the master fingerprint so that the particular signer (e.g. hardware wallet) for that public key can be identified.

The master fingerprint provided does not need to be the actual master fingerprint. It just needs to be a fingerprint that will be present in the PSBT when the coldcard signs it. This way the coldcard will be able to know which xpub to use to derive a particular public key so that it can verify that the input is a multisig that it recognizes.


In Elliptic Curve Addition, where does the second point come from?

In elliptic curve cryptography, participants need to agree on certain parameters. For example, you need to agree on which curve to use.

One of those parameters is called the base point generator, it is a point on the curve.

  You do EC multiplication with the private key to get the public key

Correct, PubKey = PrivKey*G = G+G+G+... PrivKey times where G is the agreed-upon generator. Does this clarify things?

You can see its definition in SEC 2 in section 2.7.1.


Is it possible to buy half of a full bitcoin?

No, you can transfer fractions of bitcoins easily. From the Myths section of the Wiki:

One Bitcoin is divisible down to eight decimal places. There are really 2,099,999,997,690,000 (just over 2 quadrillion) maximum possible atomic units in the bitcoin system.
The value of "1 BTC" represents 100,000,000 of these. In other words, each bitcoin is divisible by up to 108.
As the value of the unit of 1 BTC grew too large to be useful for day to day transactions, people started dealing in smaller units, such as milli-bitcoins (mBTC) or micro-bitcoins (μBTC).


How does Market cap and daily movement affect a Crypto stock , do these numbers mean much?

To clarify the definitions for you:

Market cap => The total money invested into a coin (or stock). This is the sum of peoples perceived value of the coin and the amount of coins i.e. MK = Coin Value * No. of coins in supply. To answer your question, coins do not have limits on market caps (in other words the perceived value of the coin is unlimited).

Mineable limits => This is probably referring to A. The automatic mining difficulty adjustment of a coin and B. the hard limit on supply of the coins. Both of these are to prevent inflation of the coin. Inflation occurs on coins while they are mineable but usually small and steady and usually decreasing inflation (like Bitcoins block halving).

With regards to trading/investing, it may be wiser to analyse the market cap of the coin rather than the coin value. If you believe it is a worthy idea to invest in then for you to make a good return you would require a balance of 1. Small enough market cap that has potential to multiply 2. Coin supply is regulated by mining to prevent runaway inflation (premined can be risky) 3. The hard limit on the coin is reasonable. Just remember that the coins with the biggest market caps may be considered more trusted/reliable.


retrieving an original data from a hash: is it reliable?

Normally, one of the purposes of hashing a string (such as a transaction) is summarizing the data to save the size because of the space limitation.

No, that would be a compression function. Hash functions are not compression functions, there is no reversing a hash. The point of a hash is to get a unique representation of the data that is the same size for any farbitrary length data.

  If this proposition is true, now assume we need to read the original data and so we need to extract the exact original data (with all details).

No, that is false. You cannot get the original data back.

  And if we cannot retrieve the original data from a hashed value, how hashed data can help us for validating an original data?

If you have the original data and a hash of it (calculated at a different time or by someone else), you can hash the original data and check that the hash matches the hash you were given.


Say, for example, if one use the bitcoin core as its wallet, while sending one's first transaction, will his/her IP be somehow revealed at that instance?

In theory, it is possible, but in practice, no. IP addresses are not in transactions or blocks in any way.

  Has anyone tried to run bitcoin core in a VPN/TOR setting or environment?

Yes. Bitcoin Core has options for using the TOR SOCKS5 proxy and has had this capability for a long time.


Usage of PkScript as a part of Inputs of a Transaction

This is additional information displayed by blockchain.com, and not part of the transaction data (for the transaction being viewed).

The PkScript is the locking script set by the previous transactions that created the outputs being used as inputs for the selected transaction. The selected transaction does not include this information, only a reference to it (in the form of the previous output txid + vout).

Blockchain.com uses this reference to lookup the PkScript from the previous transaction, and displays it alongside the scriptSig and witness data here.

The PkScript is used to ensure that the transaction is valid - it is also known as a locking script, and is a Bitcoin Script program that sets the requirements for the output to be spent. For example, a p2pkh locking script sets the requirement to "the input must be signed with a private key for which the public key's HASH160 equals the HASH160 in the locking script".

The input's scriptSig (and witness, in segwit transactions) is fed to the locking script as input. If the program evaluates to true, the scripts are valid. If it evaluates to anything else, it is invalid.


Why is no security lost by using 32-byte public keys in Schnorr signatures instead of 33?

From the (very recently updated) bip-schnorr draft:

  Implicit Y coordinates are not a reduction in security when expressed as the number of elliptic curve operations an attacker is expected to perform to compute the secret key. An attacker can normalize any given public key to a point whose Y coordinate is a quadratic residue by negating the point if necessary. This is just a subtraction of field elements and not an elliptic curve operation.

The idea is that if somehow using implicit Y coordinates was less secure, then an attacker would always use it - even in a the protocol version that has explicit Y coordinates. The attacker would take the full public key, strip the Y coordinate, run his (presumably faster) implicit-Y ECDLP solver on it to find the private key, and if the actual point corresponding to that key is the opposite of what he wants, flip the private key.

This proves that the ECDLP problem's hardness cannot meaningfully be impacted by removing the Y coordinates.


Research how to construct replace by fee transactions. E.g. Samurai wallet has it integrated.  Or wait for a month and your transaction will be dropped from the memory pool.


Coinbase.com has merchant tools that allow non-profits et al. to accept donations.


what happens to spent bitcoins gained from a block of a soon to be dropped chain as a result of a fork?

all coinbase transactions are timelocked from when they are mined, so they are not spendable for a few days i believe. by that time, the block is near impossible to reverse and you can spend the new coins.


what is the difference between OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY

OP_CHECKMULTISIG, OP_CHECKSIG, OP_EQUAL all put true or false on the stack. This means you could use them with an OP_IF or similar, it doesn't have to immediately end execution if its false. OP_VERIFY will, as you quoted, mark the transaction as invalid of the top stack element isn't true, but you may not want to, you may want to perform some additional logic before that.


This is what I would do:

Find/borrow an android device (from a friend, relative, co-worker, etc)
Install the Bitcoin software you used to have
Restore the wallet from the seed (when restoring from a seed, in most cases the password isn't needed, because you can set a new password after the restoration of the seed)
Make a new transaction and transfer all bitcoins to the new wallet address on iOS/OSx

Caution! The seed is the most important thing you have. Don't show/give the seed to anyone because they can recreate the wallet!


k is kilo and refers to 1,000. 500k are 500,000. This can have a lot of use cases, sometimes one wants to sell 500k Bitcoin (unlikely) and sometimes users refer to exchange rates in Satoshi: 500k Satoshi basicly mean you can buy something at the rate of 0.005 Bitcoin (0.00500000).

2Bytes are two units of digital information. It tells you how much space is required to store two characters like OK on a disk or in memory. 2 Bytes can be broken down into 16 Bit of plain binary information. I'm not sure in which context this could be related to anything Bitcoin-specific. Maybe you add an example reference.


How to connect to blockchain via a "rig" miner?

What you have here are components for a rig. They are not "rigged" yet, ie, not connected, not structured to work yet.  The main components for a mining rig such as you show are:

PC motherboard (there seems to be one in the 3rd picture, the one
with a large circular heatsink with fan & intel label) so this is in
fact the core component of a 'Personal Computer - you already have
it.
Graphical Processing Units or GPU's (you have 4  Sapphire Radeon units of some model)
Power Supply or Supplies (you show one, visible in the first 3 pictures)
The frame to physically hold the components in place.

The bottom picture also shows a Raspberry Pi connected to a small relay board, which while not strictly necessary, would be used to help reset the rig (https://cryptomining-blog.com/tag/raspberry-pi-3-relay-control/)

Step-by-Step instructions would depend on exactly what blockchain you wanted to mine, and the exact models of the components you are using, but in essence, you run a computer (the PC motherboard or 'mainboard') which gives mining work to the GPU's (usually connected to the mainboard via PCI-e cables).
The mainboard will be running some mining software (cgminer, bfgminer or similar) on top of the OS (Linux or Windows usually) and "connecting to the blockchain" you mine by communicating with a mining pool, which itself is running a full node on the blockchain's P2P network.


No, your earnings are related to how much hashing power you contribute to the network, not your share of the pool's hashing power.

Said differently, if you were mining solo and providing an infinite amount of time, the earnings would be the same (minus the fees). Pools only exist to give you more frequent, smaller revenue.


Your balance is kept in the cloud, specifically in the block chain.

Your wallet does not contain any balance info but just a private key that you can use to unlock the funds inside the block chain.

This means that it doesn't matter that you backup your wallet.dat file before your client is fully synched. Since it only contains your private keys, and not the balance itself.

So yes, after a full synch is completed, those coins will appear in your wallet. As long as you have your wallet.dat file, with the private keys associated to your address, you can access your funds.


Does Blockstream have a revenue model that can only exist in a small block environment?

As far as I know, they don't have an explicit business model published anywhere. We do know that they are working on:

Side chains - a two-way peg that has fixed transfers of value from bitcoin to a sidechain and back.
Lightning network - a network of transactions that can be updated relatively quickly (seconds, theoretically) and provably given if the transaction is published on the blockchain.

Both these things are innovations, but how they will make a profit off them is not clear. That said, both these innovations potentially could be more useful if transactions on bitcoin proper were more costly. For both, that would be because transactions on a side chain or lightning network can be potentially cheaper and thus more utilized. That is in theory. Neither of these things are public or even built. Most of the accusation is in theory. Only the Blockstream people know the business model and given that they're a startup with no profits, I wouldn't be surprised if they pivot a few times before they actually find a business model that works for them. This may or may not involve profiting from the innovations above.

Essentially, there is no clear revenue model so the statement about blockstream is mostly speculative.


How to get statistics about Bitcoin users?

The closest thing I'm aware of is RowIT's Bitcoin Stats Page which counts listening hosts, unique IPs and several other statistics which come closer to, but still does not directly equal, a count of users. It is, at least, less likely for one user to run a client from two IP addresses than to simply run two clients from the same address, so unique IP statistics might be somewhat more useful to you.

Realistically, Bitcoin was explicitly created with privacy in mind, so as much data mining as we are capable of, there are certain statistics you're simply unlikely to ever lay hands on.


Can I buy or sell with bitcoins offline?

Take a look at Bitcoin apps available for your mobile phone. Several are recommended in answers to question Can I send bitcoins with my mobile phone?. Look for apps that offer some kind of offline mode.

For instance, the highly recommended Bitcoin Wallet app for Android mentions in its feature list, "Enter transactions while offline, will be executed when online".


Gaming the "off-by-one" bug (difficulty re-target based on 2015 instead of 2016 block time span)?

The attack allows a group of miners with more than 50% of the network's computational power to change difficulty arbitrarily.

When difficulty is adjusted, only the times of the first and last blocks in a retarget period (i.e., the first and last blocks with a certain difficulty) are considered. This attack works by manipulating the timestamp of one of these two blocks.

Blocks are considered valid if their time is greater than the median of the last 11 blocks and less than currentTime + 2 hours, so it's legal for an attacker to create a new version of an old block with a time far in the future. If this is the first block in a retarget period, then the difficulty will quadruple after that period. If it's the last block, then the difficulty will be divided by four. (Difficulty adjustments are limited to *4 or /4.)

Note that it is not possible to do these major changes with recent blocks because the time would be more than two hours in the future. It needs to be done with historical blocks, and then the attacker needs to re-do all blocks that come after that block. So this attack is only possible when you have a lot more computational power than the legitimate network.

This would not be as big of a problem if there was a block of overlap between the retarget periods. Instead of using the first and last block in a retarget period, use the last block of the old difficulty and the last block of the new difficulty. Then the attacker will still be able to mess with one retarget period, but it will be corrected in the next retarget period.

I think a better solution would be to look at every block in a retarget period plus maybe some blocks before the period. It just seems like a bad idea to give certain blocks "special powers".

A discouraged block is considered valid (it adds confirmations to transactions, blocks after it will also be valid, etc.), but your node refuses to relay it or build future blocks onto it. If most of the network is discouraging a block, then it will almost certainly be replaced. Even a minority discouraging a block will hurt the block's chances. It is very unprofitable for a miner to discourage a block when most of the network is not, though.

(Thanks to gmaxwell for explaining this attack to me.)


What is the largest number of blocks a transaction has ever waited for confirmation?

This is not a full answer, but a partial answer somebody may use as a stepping stone to craft a complete answer.

E.g. blockchain.info shows both "received time" and the time of the block a transaction was included in.

It appears to me that the "11 minutes" in the "Included in Blocks" time for this transaction corresponds to the difference between "Received Time" and "Block time" of the first confirmation.

If this information is available on blockchain.info's API, someone could parse all transactions to find the maximum.

By additionally evaluating the fee of a transaction in comparison to fee levels at that time, and confirmation times of each input of the transaction, the additional constraints of this question could be addressed as well.


Were there any Bitcoin based prediction markets for the Brexit referendum?

There is at least one market I am aware of that covered the event although the contract language seemed to focus on the UK actually leaving the EU (which does not happen immediately) by a certain date rather than the referendum vote itself.

The prediction market below and every fiat prediction market I saw before the referendum vote predicted the "stay" votes were win. Although the polls were close, it appears that both the polls and prediction markets (that predicted the stay votes would prevail) were wrong on the referendum result.

"Long shares will resolve at m฿10 and short shares at m฿0 if the exit of the United Kingdom from the European Union is effective in 2016 or 2017."

https://www.predictious.com/politics/brexit-2017/leave

Hivemind is the most well known Bitcoin prediction market now in development.
http://bitcoinhivemind.com/

Here are a few more Ethereum DAPPs (which may accept the Bitcoin currency) in various stages of development:

https://www.augur.net/

https://groupgnosis.com/dapp/#/markets


Very good question. Today I created a page at my pool for this purpose: http://bitminter.com/test

You don't get paid without registering and entering a name and password. But it is useful for the purposes you stated in the question. Just click the "test start" button. You need Java installed, and of course GPU drivers with OpenCL support if that's what you want to test.

PS: Thanks for the idea for this.


In Proof-of-Stake, can the same miner mine a block multiple times in a row?

Can the same miner / address / person be chosen to create multiple blocks in a row

Yes, a single entity can mine multiple blocks in a row with no ill effect.

  are there some mechanisms preventing [multiple blocks in a row from one entity] from happening?

The sybil problem makes this fundamentally impossible; if there was a way to stop a person from pretending to be multiple entities at once, proof of stake and proof of work would not need to exist in the first place. In a naive attempt at this if you prevent a specific key from signing two blocks in a row, then the user would simple split their money into multiple keys.

  How is the next miner selected in various Proof-of-Stake block creation algorithms?

In some implementations of proof of stake the selection is simply based on the previous block hash as a random oracle. ECDSA signatures can have a practically indefinite amount of permutations which allows a user in the network to simply sign repeatedly until the next "random" selection is also them, amplifying their income or ability to warp the network. This is commonly known as stake grinding.

In an attempt to fix this other implementations use either a block hash from a long time ago, or the hash of some period of blocks in the past. The intention of this is that an attacker would supposedly need to control all of the blocks in that period (or be extraordinarily lucky) in order to be able to re-sign and jump ahead with their new control.

There's other selection methods in existence but the enormous number of implementations make it extremely hard to research for this question, however they are likely variations on the same concept in some way. There's some more discussion of the general problems of proof of stake available for digestion in pos.pdf.


What's the sense of how lightning network is performing?

Yes, as of writing, there is an overwhelmingly positive sense of how things are performing thus far - more than 800 nodes with 1600 channels are already on the main net, and micro transactions exchanged more than ~40.000 USD.
It is unclear what you mean by "the solution which BTC has been waiting for". Who is BTC? The community, using bitcoins?

The solution can be SEGWIT, Lightning, SCHNORR sigs, Smart contracts ... ??

Maybe you talk about blocksize, or the fee peak problem in December, which has been discussed in several channels, with many politics involved. This peak has meanwhile reduced to normal values, and doesn't exist anymore (see here). There is also a common sense, that with future lightning adoption this will not re-occur.

I want to stress the point, that lightning is on mainnet, but at a very, very early stage. It is not recommended to be used by newbies, it is more for experts to see behaviour in real world (after extensive tests in test environments).


The BIP39 English wordlist contains 2048 entries so, since words can be repeated, you need to try (corrected) 2048 ^ 4  combinations which is 117,592,186,044,416 different phrases to try. If you could test a million guesses a second, that would take up to 204 days.
The first stage of testing would be that the checksum condition is met. This ought to be fast. I imagine the second phase involves using the phrase to generate some reasonable number of HD addresses and checking against a local copy of the blockchain to see if any generated addresses appear in any transaction outputs.
Some wallets  use a different wordlist - I think Electrum is one. Obviously you need to use the right wordlist for your wallet or attempted recovery is a complete waste of time.
There are tools that can help with this, one is btcrecover. I would use this sort of tool only on a new airgapped computer that has no WiFi, Bluetooth, Ethernet or other networking capability.
Obviously you need to be extremely careful about where and how you obtain this sort of tools. There must be many fake or maliciously altered copies around that send your recovery phrase to a thief (before or after recovery).
There is the option of adding a user passphrase to the recovery phrase. If you did use that and can't remember anything about it, I doubt the wallet is recoverable.

Useful resources

BIP39 - including implementations in numerous programming languages
bip39 checksum python


Setting up a basic test transaction for p2p donation web app - API recommendation

In case anyone else faces this decision I decided to go with the Blockchain.info API (https://blockchain.info/).

Primary factors:

Easy to use ruby gem and interface - I was able to create wallets and transactions through invoking a few simple methods within my Sinatra app
Blockchain.info provide and utilise a stable wallet, recipient address which is easier and more intuitive to work with when starting out (e.g. easy to track senders and recipients against IDs)

Drawbacks:

I couldn't find a way to link in the Testnet blockchain so had to experiment with real Bitcoins
I was totally reliant on the Blockchain.info wallet and transaction structure. This was fine for a prototype/ experiment but for an actual MVP you would want to be able to integrate a wide range of wallet providers.


Where to find last x hour/minute trading volume for a given coin

cryptocompare has the utility you need.

Go to Coins at the top, find your coin
Analysis
Change the bar graph at the bottom to display by Hour
Use the interface to see the volume per second

If this is too unwieldy, cryptocompare does have an api and a useful npm package to play around with.


This sounds like your operating system thinks that your wallet file is supposed to be opened by Adobe Reader.  Adobe Reader will not know what to do with this file, so you'll get that error.  Try opening the file directly from a Bitcoin wallet, or change your operating system to recognize wallet files (.dat) as Bitcoin wallet files, and not documents.  If you are using Windows, try this: http://windows.microsoft.com/en-us/windows/set-program-access-computer-defaults#1TC=windows-7


The gist of the reusable payment code BIP is that you can gain some measure of address privacy by combining BIP32 (hierarchical deterministic wallets) with Diffie-Hellman key exchange. To understand what this means, let's figure out what the current situation of bitcoin wallets is.

Originally, in the reference client, bitcoin wallets simply generated random numbers for private keys, which in turn created a bunch of random addresses. This worked great for sending and receiving, but for privacy, it's not so great. If you publish your address, for example, everyone knows exactly how much you're receiving to that address since the blockchain is a public ledger.

Next came along Deterministic Wallets from Armory. This allowed a single seed to generate a virtually infinite number of addresses. That is, you can generate a single wallet from 256 bits (or less) and get as many addresses as you need. This allowed people to send Armory watch-only wallets to each other and get paid that way. Much better for privacy since you're generally only supposed to use new addresses, but once someone is in possession of your watch-only wallet, they know all the transactions in and out of that wallet. Better than it being public, of course, but still something to be desired when it comes to financial privacy, if, say, your employer was paying you via an Armory watch-only wallet, they know exactly how much of that has been moved and so on.

Then came HD wallets (hierarchical deterministic wallets) which allow you to have multiple levels of wallets from a single seed. Now you can send one person one watch-only wallet (xpub in BIP32 parlance) and another person another watch-only wallet and they won't know anything about what the other one is doing. Again, better for privacy, but now you have to give out different watch-only wallets to everyone you're dealing with, which can get messy.

Reusable Payment Codes is essentially a single code (essentially an xpub from BIP32) that you can publish that creates a new wallet when combined with any other HD wallet. This works via Diffie-Hellman key exchange where the sender uses the xprv from their HD Wallet and combine that with the receiver's xpub to come up with essentially a wallet that only the receiver can open but both the sender and receiver can determine the addresses of. As part of the key exchange, the sender has to send the receiver their xpub so the payments can be bi-directional. If you need a refund, for instance, the Payment Code is symmetric so a wallet going the other way can be deterministically be known to both sides. A refund can be sent to the payment code without crazy work-arounds that typify the current bitcoin landscape.

Reusable Payment Codes are essentially a way to identify yourself without leaking any information about how much was received by or sent to that payment code. Addresses, deterministic wallets and HD wallets all do not have this ability.


How the BTC-e could dive to 102 points (from 700) and the recover back to 700

It simply is someone with a lot of coins, who sold on the open market and depressed the price (temporarily).  It was an economically unwise decision, since they missed out on the fair market value as you saw.

This is one example of how the Powerful Elite can Thwart Cryptocurrencies.


What is the motivation for miners to include all recent transactions in a block?

Miners have a long-term investment in the health of the Bitcoin network. If Bitcoin collapses, then their expensive ASICs are worthless. Miners particularly need Bitcoins to remain valuable over the long term because their hardware produces Bitcoins over time.

If nobody includes transactions in blocks, then Bitcoins would be useless and therefore worthless. That would hurt the miners' long-term investment.

If this ever became a problem, transactions would just wind up with higher fees to encourage miners to include them. Right now, enough miners will include a transaction with a miniscule fee that there's no point in paying more.


You can always create raw transactions and sign them offline. However I think you mean a more user friendly way of doing this. The only full node software that I know of which supports offline signing in the GUI is Armory.

Another option is electrum but it's not a full node client.


Can exist bitcoin network with all nodes behind NAT?

Sure. Both the Bitcoin client and many SOHO routers support UPnP. Failing that, Bitcoin users could set up port forwarding.

  Or bitcoin client will try to make UDP/TCP hole punching connection?

No, it won't do that.

  If its mandatory for some miner to have public IP address?

Generally, mining pools will have a public IP address. There's no reason why you couldn't set up a mining pool server behind NAT and use port forwarding to make it public, but it would be a very strange way to set things up.


Difference between scrypt and sha-256 mining?

are both these two algorithms different from each other?

Yes. Different algorithms with different (invention) purposes: SHA256's goal was to be extremely hard to be collided, while Scrypt aimed to be a RAM and CPU heavy algorithm.

  I read somewhere that this two algorithm is used for the different cryptocurrency. if that's true. then why?

Consider Bitcoin and Bitcoin Cash. Bitcoin Cash's hashrate is ~90% lower than Bitcoin's. However, profit maximizing miners switch to Bitcoin Cash when it's more profitable, and then jump back to Bitcoin. This causes Bitcoin Cash block times to be unstable, between 3 minutes and 60 minutes. If your coin uses a different kind of PoW, then that's not possible. Of course, you can improve the coin's difficulty algorithm to overcome these issues (DogeCoin is a little SHA256 coin, but its difficulty algorithm "DigiShield" is pretty great), however Litecoin prefers to use a different solution: to have a different PoW.

  which one is efficient as compared to another one.

SHA256 in terms of energy and Hash / unit time.


How is RonPaulCoin different from Bitcoin/Litecoin?

RonPaulCoin uses Scrypt (like Litecoin). It is a Litecoin clone that only differs in the specifications:

Limit: 2.1 Million
Block time: 2 minutes
Reward schedule: 1 RPC per block, halving every four years.
Difficulty retargeting: Every 48 blocks (~96 minutes) with a maximum difficulty shift of 11%.


Hardened Keys vs Normal Keys - A Simpler Explanation

A non-hardened private key is derived using the equations shown below. Here small case letter represents private keys and large case represents public keys. G is the generator point, c is the chain code and i is the index number of the key generated. Kpar and cpar together represent the extended public key. kpar and cpar together represents the extended privat key.

k(i) = kpar + hash(Kpar, cpar, i)
rearranging you get, kpar = k(i) - hash(Kpar, cpar, i)

Now, let us say the attacker gets his hands on k(i) and xpub. You can generate public keys without the need of private keys using the xpub with the following equation: K(i) = Kpar + hash(Kpar, cpar, i)*G (check why this equation holds below in Appendix). The attacker is going to increment the index (i) in a loop until it generates the public key associated with k(i). When K(i) = k(i) * G the attacker knows the index number.

Thus with the index in his hand, he can just calculate the kpar from the equation kpar = k(i) - hash(Kpar, cpar, i).

Hardened keys prevent this by using the equation: k(i) = kpar + hash(kpar, cpar, i). So, although you get your hands on the xpub and the k(i), you will not be able to reverse engineer kpar as that variable is in the hash function which is one-way.

Appendix:

we saw above that k(i) = kpar + hash(Kpar, cpar, i)
=> k(i) *G = kpar*g + hash(Kpar, cpar, i)*G
=> K(i) = Kpar + hash(Kpar, cpar, i)*G


There seems to be a fundamental misunderstanding of how blockchains work. There is no hashing and hiding of transactions. Transactions are identified by their hashes and the hash is stored in a block, along with the transaction. There is no need for "unhashing" to see transaction details, the details are all there.


Is my cgminer (scrypt) working / Mining on middlecoin pool

I think your main issue is that your hash rate (speed, essentially) is extremely low. You're averaging about 3Kh/s. For comparison, most mid-range miners are running around 5-600Kh/s, and if you run a mining tool on your Google Nexus 7 tablet or Nexus 4 cell phone you can get around 2Kh/s which is very close to what you're getting.

I can't really help you with this without knowing what kind of hardware you have that you're trying to run this on, but take your video card model and search google for "cgminer settings" with your model after that to see what you can find.


I paid in bitcoin, now I'm owed a refund. Can I demand it in bitcoin too?

I am not a lawyer, but...

The Coinage Act of 1965, Section 31 U.S.C. 5103, entitled "Legal tender," states: "United States coins and currency... are legal tender for all debts, public charges, taxes, and dues."

In the USA all monetary debts can be paid in US dollars.

Second, while bitcoin is legally a payment method in the US, it does not have legal status as a currency. In the eyes of the law it's almost certain that the company will only be required to send you the original USD price of the item that you paid, regardless of the method of transfer. Legally speaking, you paid dollars through bitcoin, and the firm will return your USD, using the bitcoin payment method if you so wish. They also won't have to refund any expenses you incurred to get the money to them, like driving money, bid/ask spread you paid to buy BTC, PayPal fees, etc.

Btw, the original price was listed in US dollars, right? Not BTC.

I'd love to hear a small claims judge berate you for trying to, how can we say this,
enjoy risk-free speculative gains through the abuse of company refund policies.

Indeed if this unethical method worked, I could always use BTC to buy something with a money back guarantee, and if BTC went up a lot, just ask for my BTC back and cash in! If BTC didn't rise, I'd just keep the goods I'd originally bought, or maybe ask for my refund in US dollars, Swiss francs, gold bullion, IMF special drawing rights, or maybe even hugs...


What bitcoin mining software is easy to use and start mining immediately with a pool & new ASIC boards?

I would argue BitMinter client is the easiest miner. You go to bitminter.com and click the "start engine" button to start it. You may have to go by java.com and install Java if you don't have it already.

Once the window pops up click "devices" -> "probe all ports" in the pulldown menus to detect connected FPGAs and ASICs. Then click the "start engine" button to start mining.

There will be an update soon to support BFL (Butterfly Labs) ASICs.

If you want to mine on Avalon it has a builtin computer with mining software preinstalled.

disclaimer: I am the author of BitMinter client.


What is the weight of a block that contains no pay-to-witness scripts?

The witness serialization format only applies to transactions that have witnesses. If a transaction does not have witnesses, then its witness serialization format is the non-witness serialization format.

From BIP 144:

  If the witness is empty, the old serialization format should be used.