What are QR codes and How do you use them as request payment from Wallet? What are QR codes ?

How do you use the QR code for payment function on the wallet ?

When would you use it ?

When using bitcoin to pay at the point-of-sale or for a face-to-face transaction, there is the problem of how to communicate the Bitcoin address to be paid in a way that the person paying can use.

A bitcoin address is just data, but it is between 27 and 34 characters so that is way to much info to expect the person paying to have to manually type in.

A QR code can easily represent this amount of data in a machine-readable manner and do so reliably.  The QR code can contain other information as well -- such as an amount and a message and other fields as well -- thanks to a URI scheme for Bitcoin.

So with a mobile, a convenient way to pass that data is for the payment recipient (e.g., a merchant) to display a QR code with the Bitcoin address for the transaction, and then for the person paying to scan that QR code to obtain the bitcoin address.

A mobile app called Barcode scanner from ZXing is the most widely used app on Android for this.

If you are paying using the Blockchain for Android mobile app, then that app will let you touch the QR code button to launch the Barcode scanner app.  When the scan is complete, the Bitcoin address field (and amount field if the QR code contained the amount) will then be populated with the data from the QR code.  The person paying then hits send and the bitcoin transaction gets created and broadcasted by the mobile app.  Web-based wallets (e.g., Instawallet.org) can use a QR code as well, except the user may need manually do a paste of the clipboard contents after scanning.

The merchant or trader might use the same mobile app (e.g., Blockchain for Android) which has a built-in method to create and display the QR code for the customer to send payment to which occurs in just one step.  Many clients (including Bitcoin-Qt), EWallets and payment processors such as BitPay and WalletBit will show a QR code (or a method to get the QR code displayed) for receiving payment.

For those wishing to create a QR code manually can do so using a web-based service such as Wolfram Alpha or several other methods.  This does introduce a vulnerability however in that the provider of the QR code could detect that this is a Bitcoin address and maliciously interject another address that the provider controls -- thus directing the consumer to pay the wrong address.  So using only a trustworthy source to generate the QR codes is recommended.


What does Bitcoin policy language offer the developer that Miniscript doesn't? What is the difference between Bitcoin policy language and Miniscript? I understand that policy language compiles to Miniscript and Miniscript compiles to Bitcoin Script. This is also a great resource on Miniscript: http://bitcoin.sipa.be/miniscript/ But I know very little about policy language and there doesn't seem to be too many resources on it online.

When would I use policy language rather than Miniscript? What does policy language offer that Miniscript doesn't? What are the key differences between them?

Correction: As James points out below Miniscript does not compile to Script. Ivy is a smart contracting language that compiles to Script. http://diyhpl.us/wiki/transcripts/noded-podcast/2019-05-11-andrew-poelstra-miniscript/

Both answers by James C. and sanket1729 are very good, but I wanted to give a very high-level answer:

Miniscript is an intermediate more structured representation for actual Bitcoin Scripts. It is useful as a toolbox because it simplifies static analysis of scripts, and things like generic signing.

The policy language is intended to simplify designing Scripts for humans.

The fact that Miniscript has a textual notation that looks similar to the policy language is probably confusing, but it is not primarily intended to be written by humans. The textual form exists to permit including Miniscript expressions inside output descriptors, and easily communicate them. To actually construct a Miniscript expressio  for a particular purpose, you'd generally use the policy language and compile it.


What happend with BCH SV and BCH ABC I hope I ask in the right place. Since both are have same source. So, what's going on with BCH? Why before the hard fork the price is sky rocketing but after the fork. It sink like a sinking boat?

Looks like ABC win this rally. ABC have more hash power and more supporters.

I like this approach to explain:

  BTC = real Bitcoin

  BTCC = real fake

  Bitcoin BCH = fake fake Bitcoin

  BCHSV = real (?) fake fake Bitcoin

  BCHABC = fake (?) fake fake Bitcoin

https://twitter.com/FedericoTenga/status/1063430370308354048


What's the minimum setup to mine a block alone? What's the minimum setup that you guys know, that can, today, mine at least 1 block alone, without the use of mining pools?
I know I wouldn't be able to afford it, but just by curiosity...

In hopes of making this a useful answer in the long run, I will show how one can answer this question in general, then give an example using today's values.

Let d be the current Bitcoin difficulty, which can be found, for example, with the getdifficulty command in Bitcoin Core, or from any of a number of sites by searching Google for "bitcoin difficulty".  The average number of hashes needed to mine one block is then h = 232d.

Suppose you have mining equipment with a total hash rate of r hashes per second.  The time M needed to mine one block is of course random.  Since each hash is effectively an independent trial of mining a block, all of which have the same very small probability of success, and those trials are executed very rapidly, the distribution of M is well approximated by an exponential distribution with rate r/h Hz.  As such, the probability p of mining at least one block within some fixed time t seconds is p = P(M < t) = 1 − e−tr/h.  If you choose values for t and p, you can solve for r to determine what hash rate you would need to have probability p of mining a block within t seconds.

You can then look at a page such as https://en.bitcoin.it/wiki/Mining_hardware_comparison which lists the hash rate of various mining hardware, and decide how many units of your favorite miner you would need to achieve that hash rate.

As an example, suppose you want a 50% chance of mining a block within 30 days. As of right now the difficulty level is d =  39 603 666 252. Taking p = 1/2 and t = 60*60*24*30 = 2 592 000, you find

  r = 45 486 834 753 298

or about 45 Thash/sec.  Let us suppose you wanted to standardize on the ASICMiner BE Prisma, which, according to the page linked above, generates 1.4 THash/sec, draws 1.1 kW of electrical power, and costs US $600.  You would need roughly 32 such devices, at a total cost of US $19 200.  You would use 35.2 kW of electricity.  (By contrast, electricity service to single family homes in the US is often a maximum of 24 kW (100 A at 240 V).)  At a typical electricity cost of US $0.10 per kWh, that would cost you US $3.50 per hour, or US $2 520 per month.

This assumes that the mining difficulty does not increase significantly over the course of the month, which is not a good assumption (it typically increases every 14 days or so).  The expected mining rewards from this setup would continue to decrease as the difficulty increases over time.


Is mining bad for the CPU? I've started to mine some Primecoin on a couple of spare VPS's, and it's turning out to be profitable. I'm also mining a bit on my laptop when I'm not using it (e.g. during lunch break).

Will mining wear down (or have any other adverse effects on) the CPU over time? Does the number of cores used during mining (I'm using 2/4) affect this at all?

Its mostly the heat...if it is running quite hot, which most laptops tend to do, it IS damaging the CPU. Try a good cooling mat if you really want to do it.
Also, using 2 of 4 cores WILL run cooler than using all 4. But I guess I could repeat everyone else' advice: "Mining is no longer profitable on the CPU, don't do it." (Even though I do a little bit.)


Do Lightning Channels have to be resolved before a certain time? I seem to remember that Lightning channels could remain open indefinitely with the introduction of CLTV. Yet, I'm confronted with claims that they time out and coins are lost when they do.

This seems wrong, as when channels time out they should send back the money, and as I said above, I thought they could remain open. What is it?

I seem to remember that Lightning channels could remain open indefinitely with the introduction of CLTV

I think instead of "CLTV" you mean "CSV" (as in OP_CSV, BIP112).  As far as I know, nobody claimed that OP_CLTV would allow HLTC-style (Lightning) payment channels to stay open indefinitely, but that was definitely a claim of OP_CSV.

An additional prerequisite for indefinitely-kept open channels is segregated witness or another malleability fix.

Although it's a bit difficult to know what is confusing you without reading the source quote and context, I suspect that you're confusing the (1) dispute period for a unilateral spend with (2) a timeout.

When one party to a Lightning channel broadcasts either the current channel state or a previous channel state, there begins a dispute period where the other party can submit evidence proving that the channel was not closed in its current state (that is, it was closed fraudulently).  That evidence is cryptographic evidence that can be submitted to miners, who can add it to the blockchain and have it accepted by full nodes if the evidence is valid.

The dispute period is an arbitrary length of time from the point where one party attempts to close the channel by broadcasting a transaction.  However, there's no point at which either party is required to close a channel, so it's correct to say that channels can remain open indefinitely.  There is no timeout on the channel itself---there's just a timeout whose clock starts when one party decides to start closing the channel.


Wallet is encrypted and currently locked, How can get unencrypted (unlocked) it? Wallet is encrypted and currently locked, How can I unencrypted the wallet to unlock?
Because of my Bitcoin wallet not getting synchronising currently, so I could not get bitcoin balance on one of my address in wallet.

I do not want to rain on your parade, but this may be hard to do. These wallets are made with the idea that outsiders will not get into them.

You could try to brute force the login, but it may take longer than a lifespan to break. However, here is something that you may consider. If you have a known rule-set for your password generation, you can substantially eliminate the possibilities in your brute force attack.

I am speculating that your passwords are complex, but there may be hope here based on the fact that password generation is not truly random. Because of this fact, there are rules that you (as the password generator) or a program like keepass (as the password generator) usually follow.

We really need more information to make an informed suggestion, but let me give you a couple scenarios.

If you create your own passwords:

Do you use spaces? Usually this is a yes or no for most people.
Is there a special character that you tend to focus on? Does it occur at a particular place (i.e. at the end)
Do you use words or phrases or is it always random?
What is the range of characters in your passwords? (i.e. Always type 6-10 characters).

If you use a generator for your passwords, there may be rulesets in place that help you eliminate possibilities:

Look at the number of characters allowed.
Are letters, upper case, lower case, numbers etc. required?
Are special characters allowed?

After you have answered this, and similar questions, you can begin to chip away at the total possible entries. So let us say you force at least one number and one capital letter and one special symbol and is 10 characters in length. Now, you can eliminate all possibilities that do not follow that pattern. You will not use brute force for any 9 character string, anything without a symbol, etc. Your possible result set can be reduced substantially because you inherently know the algorithm you use for password generation.

A goldmine for you is the eliminate the possibilities on a particular character in the string. Commonly, people will start or end a password with similar rules. For example, they put a $ at the beginning. Now you have reduced the search by a power factor. Keep this up with rules that you know would have been enforced and your set gets even smaller.

Now that your result set is reduced, work will be involved. Find a program to brute force a wallet, or utilize a script that you create to brute force. Most have APIs associated with them (i.e. https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list).

Technically, there are tools that will help with this process, (See: Forgot wallet encryption password, are any brute force tools available? ) so you may be able to find something useful there. Otherwise, if you cannot get a hold of those tools, pitch it to some computer science students at the local university to create such an app for a project :-) It would take a little bit to code and I am not sure of your programming abilities, but it would be very possible.

Good luck and I hope you get your wallet back!


Unexplained fee in electrum to localbitcoins transaction Unexplained fee in electrum to localbitcoins transaction. How to avoid this in future? I was trying to make a transaction from electrum to localbitcoins 120$, paid 57$ fee for the transaction.

https://www.blockchain.com/btc/address/38Q5TNhLdbZzKfnHVmdFgLXxaoTMipJgjp

This transaction had more than 50 inputs resulting in a bigger virtual size so had to pay more fees.
Tx: https://btc.bitaps.com/dea92494d9f5e22bfc5834963a161e906735cd04cefbd3b82ec390fceff1626a/38Q5TNhLdbZzKfnHVmdFgLXxaoTMipJgjp
Virtual size: 4003
Fee rate used: 60 sat/vByte
Total fees: 240180 sats or 0.0024 BTC
BTCUSD right now: 24000
Fees in USD: 57

How to avoid this in future?

Consolidate UTXOs when there are very less transactions in mempool and use fee rate 1-5 sat/vByte
You can also manually select inputs used for a transaction in Electrum Wallet.
If you had done the consolidation of UTXOs when mempool had less transactions and used fee rate 5 sat/vByte:
Fee for consolidation transaction: 0.0002 BTC (5 USD)
Fee for spending UTXO after consolidation assuming it had 1 input and 2 outputs with virtual size 150 (60 sat/vByte): 0.0001 BTC (2.5 USD)
You can read this answer to know more about UTXO consolidation: https://bitcoin.stackexchange.com/a/100440/


Script to import multiple priv keys in Electrum DuckDuckGo turns up nothing of interest. How to import multiple priv keys in Electrum from a file using Electrum console or shell script, for all derivable valid BTC addresses? (1,3,bc1)

Eventually I would like to pipe the output of one script directly into an import script.

The file is in format:

BTC Pattern: <pattern>
BTC Address: <bitcoin address beginning with one>
BTC Privkey: <bitcoin address beginning with five>
...

First of all get rid of all that junk. One priv key per line is all you need. So use grep privkey filename|cut -d":" -f2 > clean-file.txt. Then call this  python script with that file as an argument:

import sys
from electrum import bitcoin
f = open(sys.argv[1], "r")
for privkey in f:
    privkey=privkey.strip()
    orig_format,secret,compressed=bitcoin.deserialize_privkey( privkey)
    formats = [ bitcoin.serialize_privkey( secret, False, "p2pkh"), bitcoin.serialize_privkey( secret, True, "p2pkh"), bitcoin.serialize_privkey( secret, True, "p2wpkh"), bitcoin.serialize_privkey( secret, True, "p2wpkh-p2sh") ]
    for thing in formats:
        print(thing)

It'll output all the private keys in the various formats.


When you need to validate a transaction is in a block So after getting here, I have forgotten why you even want to validate a transaction is in a block, and how exactly this works. Wondering if one could explain

In what situation you want to validate a transaction is in a block.
How you find the block that the transaction could be in.

That link says here:

  Consider, for example, an SPV node that is interested in incoming payments to an address contained in its wallet. The SPV node will establish a bloom filter (see [bloom_filters]) on its connections to peers to limit the transactions received to only those containing addresses of interest. When a peer sees a transaction that matches the bloom filter, it will send that block using a merkleblock message. The merkleblock message contains the block header as well as a merkle path that links the transaction of interest to the merkle root in the block. The SPV node can use this merkle path to connect the transaction to the block and verify that the transaction is included in the block. The SPV node also uses the block header to link the block to the rest of the blockchain. The combination of these two links, between the transaction and block, and between the block and blockchain, proves that the transaction is recorded in the blockchain. All in all, the SPV node will have received less than a kilobyte of data for the block header and merkle path, an amount of data that is more than a thousand times less than a full block (about 1 megabyte currently).

I still don't understand why you need to verify the transaction is in the block, some questions that come up are:

The relevance that specific block has to you. Even if you verify it's part of some block, I don't see why you care it's from that block.
So you prove that it's recorded in the blockchain. I don't see how this means it's valid.

All of this info is relevant to the operation of a light-wallet, which does not fully validate the blockchain, but instead validates the longest chain of block headers, and any transactions that are relevant to that light-wallet.

  In what situation you want to validate a transaction is in a block.

Simply: to ensure that a payment you have sent, received, or are otherwise interested in has been included in the Blockchain record. If someone pays you a huge sum of Bitcoin, you'll probably want to be sure that payment was actually legit!

  How you find the block that the transaction could be in.

The text you quoted from Mastering Bitcoin has the answer: a full-node peer will use your bloom filter to provide you with transaction info relevant to your wallet.

  The relevance that specific block has to you. Even if you verify it's part of some block, I don't see why you care it's from that block.

In order to verify the transaction is included, you will need to know which block it is in. This will allow your wallet to calculate the cryptographic proofs (using the merkle root that is in the header) that let it verify a transaction has occurred on the network in a trust-minimized way.

There is no way to similarly know that a transaction is included in the blockchain record, without knowing the specific block you need to check the cryptographic proofs against.

  So you prove that it's recorded in the blockchain. I don't see how this means it's valid.

Only valid transactions can be recorded in the blockchain history, though as a light-wallet, you are trusting that the network of full nodes is otherwise validating all blocks and transactions, to ensure no invalid data is included in the chain. As long as the full nodes are doing their job, invalid transactions cannot be included in the chain. Any miner that attempts to include an invalid transaction in a block, will see that block dropped by the network's nodes for being invalid.


Building Bitcoin from Source on MAC OSX 10.9 so I'm trying to get bitcoind running on my Mac and I cloned the source code from github. What I tried doing:

brew install autoconf automake berkeley-db4 boost miniupnpc openssl pkg-config protobuf qt libtool
git clone https://github.com/bitcoin/bitcoin.git
make

But then I get an error:

***No targets specified and no makefile found.

However, I'm looking and I see Makefile.am Any Ideas on what to do?

As explained in the file doc/build-osx.md, before running make, you first need to run ./autogen.sh and ./configure.


Tracking outgoing transactions & malleability attack What is the best way (in terms of security or resources) to track my outgoing transactions through the RPC API?

I would like to be able to track them down using their tx id and also to have a fallback mechanism for when my outgoing transaction's id changes as a result of a malleability attack.

I personally would look for newly spent outputs as opposed to TXIDs.  The outputs get spent the exact same way in a malleability attack.

So create a hash based off of the inputs into the transaction, and when a TX comes in calculate that internal hash and check off of that.


How to get the wallet address of my own LND node? I have set up a lighting node using LND time ago, now I would like to send more BTC to it.

How can I get the wallet address of my LND node?

Use lncli h to view a list of all the available commands.

lncli newaddress will give you a new address for the wallet. You must specify the address type: either p2wkh (pay to witness key hash), or np2wkh (nested pay to witness key hash). For example, lncli newaddress p2wkh.

(Running lnd v0.6.0-beta)


Is segwit2x really called off? Is the segwit2x called off for sure for now?
I see there is still 53.9% intention as of 15th Nov for Segwit2x (Source)
I know this is not sure that it is called off forever, but I just want to know whether it will happen anytime soon as the NYA agreement of making segwit2x on block 494784

Well it's not sure whether it's completely off the table, but they have indeed called it off for now:

"Segwit2x hardfork has been called off! Common sense prevails"

You can see some things in this article: https://www.coindesk.com/relief-disbelief-bitcoin-reacts-sudden-2x-suspension/

And this is the message they sent out: https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-November/000685.html

Cheers,

David


how to create Watching Address from available xPub key Watch-only wallet can only receive payments but not spend the available coins. I am using bitcoinj (in Java).

Can anyone please tell me that How to create watching addresses from available xPub key? where wallet can receive payments? and how to check the list of watching addresses which are related to that particular xPub key. Thanks in Advance

For generating addresses from extended public key for watch-only wallet, First of all you need to first create the watch-only wallet by that extended public key. and then you can simply derive the addresses from that one by one.

Sample code is shown below:

// Specify the Network Parameters for mainnet or testnet
NetworkParameters params = NetworkParameters.prodNet();

// Provide the public key from which you want to derive addresses
String xPub = "xpub6Cw8YA6Mko3xfkYpMQDZjGjgDTWUrJr87NBSiDPXqcmcSJTgxLXm3VCw3iQs4iC5ZrwpY3M21a43DZmiMzDXWzzhF1n7yxSXDnEHjJN6jwK";

// Create watching wallet, with the help of Wallet class
Wallet wallet = Wallet.fromWatchingKeyB58(params, xPub, DeterministicHierarchy.BIP32_STANDARDISATION_TIME_SECS);

// Print the very first derived address from provided public key
System.out.println("Receiving Address : " + wallet.currentReceiveAddress());

The Output will be :

1L23PHmL38qjqbs75doB1VTSL3CKPwkPbC

You can get the public key from https://iancoleman.io/bip39/ and its all particular derived addresses. You can compare your first generated address from there, to make sure that you are getting correct addresses.

If you want to fetch first 20 or 30 Addresses then you can use given line in a loop. Provide loop limit upto 20 or 30 (which you want).

// Run this statement in a loop, where i is the loop variable.
System.out.println(i + " : " + wallet.freshReceiveAddress());

You can again compare these addresses from https://iancoleman.io/bip39/

Good Luck!


How soon does bitcoind incorporate locally solved blocks into its 'getwork' output? If one sends a solved block to bitcoind server using getmemorypool or getwork, and right after that requests a new block using the same API call, what will the server respond with? Assuming the data is correct, will bitcoind immediately create a new block to be solved with prev block field corresponding to the hash of the recently submitted work, or will it wait for the block to be accepted by its peers first?

Bitcoin won't wait for its peers: your block will be considered the latest block in the chain once it has been processed. I'm not sure whether it's safe to say that the second RPC call will always reflect the existence of the new block, though, since Bitcoin is threaded and things might not be done in the exact order you expect.


Why can't a Bitcoin fork take over? According to this question's answers, the difficulty is entirely a result of previous info on a blockchain:

How is difficulty calculated?

So why can't someone simply fork an earlier state of Bitcoin's blockhain, back when the difficulty was far less, and simply pretend it always took a long time to solve an easy (by now) hash problem, ie simulate a bitcoin world where no ASIC were released etc.

According to that chain, the hash rate would be low and thus a perfectly valid chain could be made with fake transactions, mined in secret many years into the future.

If Bitcoin modes really simply consider the longest chain the valid one, wouldn't this totally bork the whole Bitcoin ecosystem? I hope that "longestt chain" actually means "most proof of work" rather than "most blocks"!

I hope that "longestt chain" actually means "most proof of work" rather than "most blocks"!

It is exactly that: the "longest chain" is the one with the most work, not the largest block height.

If it wasn't like that, then an attack like the one you described could work.


How do nodes verify backwards incompatible blocks? When you start the initial block download with the latest versions of Bitcoin Core, how does your node know that old blocks were valid according to different rules prior to soft forks?

Old blocks in the chain are still valid under the current consensus rules.
In a broad sense, this is because the code will be written to enact rule changes at specific block heights, and thus older blocks will not be subject to said new rules.
To put it differently: the consensus ruleset doesn't just cover what new blocks are supposed to look like, they also cover what the historical valid chain looks like!
Sometimes, specific exceptions are written in, such as is the case with BIP 30.


Does Eltoo eliminate the need to watch the blockchain/implement Watchtowers Reading Blockstream's introduction article on Eltoo and one paragraph says:

  [..] in eltoo all participants share a common set of transactions, unlike LN-penalty, which requires asymmetry in which participant has access to which transactions, in order to tailor the reaction to the misbehaving party. This change eliminates what we call toxic information in Lightning. Toxic information comes from transactions belonging to outdated states, which if leaked will result in the loss of funds. This happens not only if a party misbehaves, but also if a node forgets about an update (e.g., when being restored from a backup). With eltoo this is no longer possible because only agreed-upon states can be settled (i.e., eltoo is penalty-less).

What this seems to imply to me is that it's not possible to broadcast an old channel state and have it accepted by the network, and this would seem to greatly simplify some design issues we're dealing with today. I strongly feel like I'm misunderstanding something here and would love to get clarification from someone more knowledgeable. Thanks

With eltoo you can publish old state and the Bitcoin network will accept it. (As every state is a valid and signed transaction.)

Let me recall the key idea of eltoo in short (if it's too short read the full paper it is well described there. Also I hope I remember the details correctly) :
You can imagine states in eltoo encoded as a linked list of time locked update transactions. Each comes together with a settlement transaction which spends the update transaction  and encods the current state. any state can be forked with a later state (within the time lock). This happens by Sorenson the update transaction with a larger update transaction preventing the precis settlement transaction to be mined. these states are known to both parties. If the state is not forked the update transaction can be settled by the settlement transactions (which are child's of the update transaction and part of the protocol)

That being said there is no need for a penalty as the tricked party can just enforce the newest state on chain if the fraudulent party tried to publish an older state.

The party still needs to monitor what happens on chain as the forking is only possible within a time lock and afterwards if the settlement tx is not published. So watchtower services might also be useful in eltoo.

One side note on the ability to omit the punishment. Peter Todd criticized the missing penalty as the game theory now encourages one to publish old state. Either the other side catches it and corrects it or you win. This would basically lead to ask stats eventually being written on chain. So even though eltoo works without penalty it might very well include one. This would however make the protocol asymmetrical again as I believe it is currently unknown how toascribe blame. This in turn would mitigate many of the advantages of eltoo


How does the wallet know which outputs are available with LevelDB So, I found that in the original Bitcoin client there was a member variable vSpent in the class CWalletTX, however it appears that this is no longer the case in the new version. I know that the new Bitcoin client uses UTXO DB to store the unspent transactions. My question is that since LevelDB is a key-value database, and the UTXO key is derived from transaction outpoint, how does the client find the Txs that belongs to the wallet owner? Does it iterate over all unspent transactions and find those containing the public key of the receiver?

The wallet is to a large extent separate from the rest of the node software. One of the reasons for this is because of the (slow) progress towards a working SPV mode. This means the wallet cannot depend on access to the UTXO set, as it won't be available in non-validating nodes.

However, it isn't needed. The wallet maintains an index of all input prevouts inside the wallet. Every output that is seen in a block, is to a wallet address, and which is not in this index as the input for another wallet transaction, is spendable.


Will deflation destroy Bitcoin? With the limited total quantity of bitcoins, and people losing their wallets constantly decreasing that number, won't rampant deflation destroy Bitcoin?

There are two potential ways in which monetary deflation can impact a currency:

1.  Usability

Most modern currencies have a minimum unit, such as the penny in the United States, or the yen in Japan.  If these currencies existed in only finite quantities, then as the economy grew and/or physical money was lost, there might eventually be too few of these units in circulation to allow normal commerce.  Imagine if, for example, the U.S. dollar became so rare that you could buy a car with a single U.S. penny.  How would you buy a loaf of bread?

Bitcoin, however, does not have this problem because unlike the physical currencies of most countries, bitcoins are infinitely divisible.  Even if only one bitcoin remained, it would be sufficient to run a substantial economy on, based on the ability to use tiny fractions of it like the Satoshi.  If even the Satoshi were to become too highly valued/unavailable for commerce, the Bitcoin protocol could be updated to allow even smaller denominations.  So the usability of bitcoins is safe from the effects of deflation.

2. Broader economic consequences from deflation

Many economists believe that deflation is bad for an economy because people will be less likely to invest their money if they can "earn" increased value simply by holding on to it.  Why buy something today, the argument goes, if you could buy it for half as much in a few months time?  Also, taking out loans becomes very difficult, because to be practical they have to have negative interest rates and then why would anyone loan out money in the first place?

However, there is good reason to believe that deflation might not have such a negative effect on Bitcoin.  For one, Bitcoin is unlikely to become the only currency in the world economy, so investments, loans, etc. can simply be denominated in another currency.  But even more importantly there are several concrete examples from history of strictly deflationary currencies.

For example, the Iraqi "Swiss" dinar was a currency that ceased being printed after the first Gulf War, and was left in use only by the Kurdish regions of the country.  With a finite number of "Swiss" dinars in existence, and some being lost or damaged over time, this left the currency in precisely the same state as Bitcoin.  Since it was no longer backed by a government, many economists expected the currency and its economy to collapse.  Instead, the Kurdish economy continued largely as normal for 13 years, and the "Swiss" dinar even appreciated against the "Saddam" dinar that was meant to replace it.

Rick Falkvinge also raises another excellent point regarding deflationary economies.  If, as economists expect, people would decline to buy something today as opposed to next year for half price, then it should be the case that no one ever buys computers, right?  But in fact, the computer industry thrives despite this continued trend of "whatever something costs today, it will cost a fraction of that within a few years".

Ultimately, this is a question for economists to duke out, and you can find more information about how different economic schools approach the problem here.  Suffice it to say, this cannot be considered a crippling fault in Bitcoin as a technology.


Electrum Linux run without sudoers installation How to easy run Electrum wallet without its installation on Linux?

I want to run it from a single user account with no sudo. It is possible?

You have two options:

Install pyqt5 as root. Then, as an unprivileged user, simply download, verify the gpg sig and untar the electrum tarball download and execute run_electrum in the directory that gets created. Most dependencies are included with the tarball so this is all you will have to do.
Another option is to use the appimage version. Just make it executable and run it. It contains all dependencies. This is recommended if you don't have python 3.6 available for your distro.


Can you make a water heater by mining Bitcoin? I read somewhere that you can actually cut down your heating bills by using bitcoin mining based water heaters or air heaters . Is that possible? Can someone give detailed economics on this ?

More or less... computer chips produce heat, so sure, it is theoretically possible. First you should know that, compared to a heat pump, a miner's efficiency is zero: heat is the byproduct, not the main goal, so it would take much more energy for the same amount of heating than a decent electric heat pump. But since you are generating Bitcoin in the process, we hope it pays off (wouldn't cut down your bills, would increase it instead, but you would have Bitcoins to pay for the increase, hopefully).

The management of the setup and the economics would be hard: an AntMiner S9 consumes 1200W (and consequentially, can heat water by this same amount). You would have to replace the casing and air cooling system with a kind of water cooling system, using water from your hot water tank as cooling fluid.

Then there is the problem: if you water gets to the desired hot temperature, it won't serve anymore as a good cooling fluid. Then you have two options: if you live in a place where bitcoin mining pays off the electric bill, you can mechanically switch the cooling fluid from the hot water tank to an alternative water circuit, this one designed to dissipate the excess heat (an ordinary PC water cooler radiator, for instance), so that you won't have shut down your miner.

On the other hand, if bitcoin mining is economically unsustainable per se, you would have to shut down the miner when the water is hot. In this case, you would have to be sure that the cost of operating the miner minus the bitcoin it produces is lower than operating a regular heat pump (which is more energy efficient, as I said). Not to mention the cost of equipment and installation and R&D to get everything right is much higher with a miner than with a heat pump designed for this purpose.


Are there any post BTC halving hashrate prediction markets? Are there any futures markets that allow predictions of post BTC halving network hashrate?

No obvious place that has this bet right now, but you can create a bet at bitbet. Note that you bet at your own risk, there's no actual guarantee that you'd get your bitcoins if you win.


listreceivedbyaddress missing transactions after restore After restoring wallet from wallet.dat balance is identical,

but listreceivedbyaddress 0 do not have the transactions associated with wallet.

listunspent 0 show all the transactions, but it will not list anymore after spending.

is it a bug? or do i have to perform some special scan? rescanblockchain found all the transactions, but they are still missing in the listreceivedbyaddress.

EDIT #1

Is there a way to get all the transactions associated with specific address, what will get accurate result from blockchain? Was supposed to be bellow command what is not working sometimes.

listreceivedbyaddress 0 true true {ADDRESS}

EDIT #2

Output of getaddressinfo {ADDRESS} differences between recent, and backup wallet:

+  "solvable": true,
+  "desc": "sh(wpkh([6f8c0001/0'/0'/306']034e{SCRAMBLED_LONG_CODE}e50f))#ejlphmc0",
+  "ischange": true,
-  "hdmasterkeyid": "f9248{SCRAMBLED_LONG_CODE}53587b4",
+  "hdmasterfingerprint": "6f8c0001",
   "labels": [
-    {
-      "name": "default_wallet",
-      "purpose": "receive"
-    }
   ]

I've had the same issue after restoring from wallet.dat. It's probably a bug described in https://github.com/bitcoin/bitcoin/issues/20293. Possible way to fix it is by setting an empty label to the address that became change:
bitcoin-cli setlabel "{address}" ""


how exactly does solving nounce verify the transaction How exactly does solving nounce verify the transaction. or how are both of them interrelated.how does my transaction gets verified.

Simply, it doesn't. The hashing puzzle is only needed for all nodes to agree on a common value. Once a block is found it is propagated through the network.
If the nounce is valid AND if the transactions in the blocks are valid then the block is accepted into the blockchain.
A transaction is valid if:

each transaction input matches a previous transaction output.
they are reedemed by their legitimate owners
the sum of values of all transaction outputs is less than or equal to the sum of the values of all inputs.

This verification is performed by bitcoin nodes. A miner is not incentivized to include invalid transactions in their blocks as they will invalidate the entire block (thus preventing the miners to obtain the coinbase reward).


Is there a site (or formula) that easily calculates returns using difficulty / hash rate? I'm just a novelty miner, looking to be cool and do my part to decentralize. Not looking for a return on my investment.

However if I'm going to spend $100 or so I'd like to calculate how my options will fare. Any sites that have no affiliation to hardware, just calculate returns on current difficulty & a hash rate that I specify?

Have a look at coinwarz.com - it list's alot of crypto currencies, difficulty and includes a calculator to measure ROI when considering mining.


Testnet: mandatory-script-verify-flag-failed when doing OP_RETURN For some reason I keep getting error: {"code":-25,"message":"Missing inputs"}

EDIT: Updating error now that the full testnet blockchain is downloaded

"code":-26,"message":"16: mandatory-script-verify-flag-failed (Operation not valid with the current stack size)

I am not sure why I am getting this error. Can someone help me debug or point me in the right direction ?  Using TESTNET3

0100000002f739b61642740a6f9b24859a30cf5f248722e9dd8f38f981e5d8a7c1f16354350100000000ffffffff0a31a52da8f2fc706d15025810eca7b6bfa53bdabcc5feefc5d55e1d2f728a170000000000ffffffff0290333200000000001976a9141ce00dca082ca1215c9e5a7a3237d267124fea3288ac00000000000000001a6a1857485920546573746e65742067697665206d65207061696e00000000

{
"Version": "1",
"LockTime": "0",
"Vin": [
    {
        "TxId": "355463f1c1a7d8e581f9388fdde92287245fcf309a85249b6f0a744216b639f7",
        "Vout": "1",
        "ScriptSig": {
            "Asm": "",
            "Hex": ""
        },
        "CoinBase": null,
        "Sequence": "4294967295"
    },
    {
        "TxId": "178a722f1d5ed5c5effec5bcda3ba5bfb6a7ec105802156d70fcf2a82da5310a",
        "Vout": "0",
        "ScriptSig": {
            "Asm": "",
            "Hex": ""
        },
        "CoinBase": null,
        "Sequence": "4294967295"
    }
],
"Vout": [
    {
        "Value": 0.0329,
        "N": 0,
        "ScriptPubKey": {
            "Asm": "OP_DUP OP_HASH160 1ce00dca082ca1215c9e5a7a3237d267124fea32 OP_EQUALVERIFY OP_CHECKSIG",
            "Hex": "76a9141ce00dca082ca1215c9e5a7a3237d267124fea3288ac",
            "ReqSigs": 1,
            "Type": "pubkeyhash",
            "Addresses": [
                "mi9dcxfvGTsDCs46UZXXYQ8JH5MLcGxMxz"
            ]
        }
    },
    {
        "Value": 0,
        "N": 1,
        "ScriptPubKey": {
            "Asm": "OP_RETURN 57485920546573746e65742067697665206d65207061696e",
            "Hex": "6a1857485920546573746e65742067697665206d65207061696e",
            "ReqSigs": 0,
            "Type": "nulldata",
            "Addresses": null
        }
    }
],
"TxId": "998221ecf0e85c1b3f1e06fbdfd5bb6b2957c244fcdbb8a2e2a8ad9b3270d440"

}


Hardened address generation with BIP44 watch-only wallet with xpub I am puzzled by the hardened key derivation from a watch-only BIP44 wallet.

Let me first explain what I am trying to do.

I am implementing a 2-of-3 multisig scheme
I am using Bcoin node and wallet
All 3 keys are externally generated
I want to use Bcoin watch-only wallet

ts to create addresses and scripts

This is what I have done so far:

Created 3 xprv keys and xpubs keys using this tool here
I used custome path m/44'/0'/0' to have hardened keys because Bcoin wallet requires BIP44 hardened keys
I created 3 watch-only wallets using the xpub keys.
Then I added each of the keys as shared keys to each other (I only really have to do this for one wallet)

The code is as below:

const HSM_accountKey = "xpub_HSM...."
const IC_accountKey = "xpub_IC..."
const Paper_accountKey = "xpub_Paper..."

const result_wallet_HSM = await walletClient.createWallet('wallet_HSM', options_wallet);
const result_wallet_IC = await walletClient.createWallet('wallet_IC', options_wallet);
const result_wallet_Paper = await walletClient.createWallet('wallet_Paper', options_wallet);

const wallet_IC_account = await wallet_IC.getAccount('default');
const wallet_Paper_account = await wallet_Paper.getAccount('default');
const result_addkey1 = await wallet_HSM.addSharedKey('default', wallet_IC_account.accountKey);
const result_addkey2 = await wallet_HSM.addSharedKey('default', wallet_Paper_account.accountKey);

Now I have created a watch-only 2-of-3 multisig wallet.
What I want to do now is to create addresses. I do not want to derive more child extended keys. I only need one derivation level.
Now I want to create multisig addresses for my users.

// Create addresses from each wallet
const wallet_HSM_address = await wallet_HSM.createAddress('default');
const wallet_IC_address = await wallet_IC.createAddress('default');
const wallet_Paper_address = await wallet_Paper.createAddress('default');

// Keyrings for script generation
const keyring_HSM = KeyRing.fromJSON(wallet_HSM_address);
const keyring_IC = KeyRing.fromJSON(wallet_IC_address);
const keyring_Paper = KeyRing.fromJSON(wallet_Paper_address);

//Get the pubkeys from each wallet
const pubKeys = [keyring_HSM.publicKey, keyring_HSM.publicKey, keyring_Paper.publicKey];

const multiSigScript = Script.fromMultisig(m, n, pubKeys);
const receivingAddress = multiSigScript.getAddress().toBase58(network);

I have a feeling that I am going about this step in a round-about way but you get what I am trying to do.

To re-state, what I want to do now is to create individual receiving addresses for my users and the corresponding P2SH scripts.

Now, this is what I need help understanding.

According to BIP32, you cannot derive hardened public keys with CDKpub. You need the xprv to derive child keys.
However, from what I have done, I can derive child public keys. I have sent tesetnet coins to these addresses (receivingAddress in the code above) and they work. The wallet receives coins.
How then, was the watch-only wallet able to create hardened child public keys? I did not input xprv to the wallet.
Or, is it that I am NOT creating hardened child public keys when I used the path m/44'/0'/0'?
Is the receivingAddress I am creating in the above code not a hardened one? Meaning that if someone is able to find the child private keys of one user and the xpub, they will be able to derive all the chile private keys?

My apologies for the long question. I am a bit confused as to how the wallets are able to create child public keys without having any private key in the wallet.

Thank you.

You are not deriving hardened child keys. You cannot derive hardened keys from an xpub. Just because the xpub itself is hardened does not mean that its children are.


What will happen when a collision in SHA256 be found? Would the protocol migrate to another Hash Algorithm inmediatly?
What would be the next? SHA3 or BLAKE 2?

No hash function has ever been broken in a way that would be meaningfully have an impact to Bitcoin. It’s not even a consideration, other than  for OP_SHA1 which has no non-academic usage in Bitcoin.


Bitcoin Core - When is fAllowWitness evaluated to true? In Bitcoin Core, when is fAllowWitness evaluated to true?

transaction.h

const bool fAllowWitness = !(s.GetVersion() & SERIALIZE_TRANSACTION_NO_WITNESS);

In particular, I cant figure out the value of s.GetVersion()

Thank you

Doing a grep on SERIALIZE_TRANSACTION_NO_WITNESS shows that it's ORed with PROTOCOL_VERSION when creating a CDataStream object for example. This is the first clue that the no witness flag is to be found along with the version protocol.

A little more digging shows that this define is used when building a Tx message in lines 1105-1126 of net_processing.cpp (v0.15.0.1):

        else if (inv.type == MSG_TX || inv.type == MSG_WITNESS_TX)
        {
            // Send stream from relay memory
            bool push = false;
            auto mi = mapRelay.find(inv.hash);
            int nSendFlags = (inv.type == MSG_TX ? SERIALIZE_TRANSACTION_NO_WITNESS : 0);
            if (mi != mapRelay.end()) {
                connman.PushMessage(pfrom, msgMaker.Make(nSendFlags, NetMsgType::TX, *mi->second));
                push = true;
            } else if (pfrom->timeLastMempoolReq) {
                auto txinfo = mempool.info(inv.hash);
                // To protect privacy, do not answer getdata using the mempool when
                // that TX couldn't have been INVed in reply to a MEMPOOL request.
                if (txinfo.tx && txinfo.nTime <= pfrom->timeLastMempoolReq) {
                    connman.PushMessage(pfrom, msgMaker.Make(nSendFlags, NetMsgType::TX, *txinfo.tx));
                    push = true;
                }
            }
            if (!push) {
                vNotFound.push_back(inv);
            }
        }

The above code shows that the int variable nSendFlags may contain the no witness flag. Later, msgMaker.Make will use this variable to create the Tx message as shown in line  1119:

                    connman.PushMessage(pfrom, msgMaker.Make(nSendFlags, NetMsgType::TX, *txinfo.tx));

You can then follow the serialization by looking at the class CNetMsgMaker in netmessagemaker.h which itself uses CVectorWriter to serialize the data.

To summarize, the GetVersion() value is built using the protocol version optionally ORed with the SERIALIZE_TRANSACTION_NO_WITNESS. This value is never sent over the wire. It's used only to control the serialization of the Tx message.


If I sent Bitcoins to family in Europe, would they be able to convert it to physical cash? I am interested in buying bitcoins to easily and quickly send money to family in Bulgaria. Would they have to convert it to euros and only be able to make online purchases? Or is there some way they could get physical cash from converting their bitcoins?

When bitcoins are converted to local currency (EUR, USD, BGN, etc.) and you want to take control of them yourself (as opposed to it being stored as that currency in the exchange you're using), they typically are sent to your bank account. From there, you could easily withdraw the money as cash. There's nothing that would make them have euros but only be able to spend them online.

One place to trade the bitcoins for various local currencies is LocalBitcoins. You might also see if Mt.Gox has options to transfer to bank accounts in Bulgaria.

You and/or your family should research the available options, and how they compare to more traditional international money transfers and choose what works for you. While the bitcoin transaction itself has only a tiny fee, buying and selling might be more trouble and expense than it's worth.


Write down bitcoins on a piece of paper I am a newbie when it comes to bitcoin. I am using the default bitcoint client and I have some bitcoins in my wallet. How can i write them down and give it to some one and then the person how can they use them

Is this possible ?

Here's a simple way to do it:

On bitaddress.org, use the "Paper Wallet" tab and create 1 address
Using your Bitcoin client, send an amount of bitcoins to the Bitcoin Address on the paper wallet
Print the paper wallet and give it to your friend
Tell your friend to create a wallet at My Wallet. He can then use the "import from paper wallet" feature and simply scan the QR code to import the bitcoins.

Please note that when handing over a private key "offline" like this both you and the receiver will have access to the funds if you keep a copy of the private key. The receiver has to trust you to not take advantage of that before he has had the chance to move the funds.

bitaddress.org by the way is a client side tool so you are not trusting them with your money, though you might want to read this: Should I trust bitaddress.org?


Serialized transaction bigger than the actual transaction object? CVE-2013-4627 I'm surveying old Bitcoin DoS vectors and came across CVE-2013-4267, for which there appears to be little public information available. This thread should shed some light on this CVE.

There's a description in this blog post:

  Transactions are also first deserialized in order to be parsed, but they are stored “as is” in a temporary cache called MapRelay, and forwarded without being serialized again. I really don’t know why this is done. But the point is that the storage of messages as they are received leads to the possibility that an attacker creates messages much bigger than the actual transaction object contained, which, when stored in MapRelay memory, can be used to exhaust the memory of a node.

There is also this relevant thread which appears to say the network was under attack using this vector.

Based on the transaction serialization and deserialization code in ~v0.8.2, it looks like the attack may have been: add large amount of random data at the end of a valid serialized transaction. The deserializer finds what it looks for (the valid blob prefix), but appears to ignore what comes after. If a serialized transaction with random data at the end of the transaction is sent to the victim node, it will be deserialized, passed to the mem-pool and then placed in mapRelay in its full size (and then possibly forwarded further, which seems like a pretty powerful attack vector).

So: was the attack described by CVE-2013-4267 based on adding random data at the end of (valid) serialized transaction data?

Yes. The attack was adding junk to the end of otherwise valid transactions to cause the junk to get relayed around. (as an aside, if we hadn't fixed that, segwit would have been easier to deploy...)


Is it possible to make a paper wallet out of a bitcoin-qt wallet? I have a single bitcoin address with all my savings on it. I want to make a paper backup for precaution (as if my hard drive somehow exploded) with that specific address. Is that possible?

Keep in mind that I want a physical backup but at the same time I want to be able to manage the wallet from bitcoin-qt.

Right now, that's not supported. You can try (see user2194702's answer), but if you don't know the exact workings of the wallet, you're very likely to shoot yourself in the foot.

For example, Bitcoin-Qt will send change to a new address every time you create a transaction, and in general does not follow the "balance per address" concept but a "balance per wallet". This improves the privacy of the system (for you, but also for others), but complicates backups. In particular, you cannot backup a wallet by just making a backup of a single key.

HD Wallets (hierarchical deterministic wallets, see BIP32) are intended to overcome this problem, by making sure you can backup a wallet by only making a backup of a single seed that is used to derive all keys. This is planned to be implemented in Bitcoin-Qt, but not yet available.


What happens if segwit node receives blocks from legacy node? Scenario: segwit node receives all blocks from legacy node without segwit support, eg using --connect parameter.

The legacy node stores/forwards max 1Mb blocks, so the extra segwit data logically could not be transferred to the segwit node.

how will the segwit node view segwit transactions?   Will it see them as anyonecanspend, like the legacy node?

Sometime later, the segwit node is allowed to connect to the main network.

What will the segwit node do?  Will it download blocks for which it is missing segwit data?   Or will it just have a "wrong" view of the blockchain?

If the latter, isn't that a problem?

SegWit nodes simply won't download blocks from non-SegWit peers. Preferential peering tries to make sure outgoing connections go to other SegWit peers, but even if not, downloading of blocks only happens from compatible peers.

If we receive a block from a peer which claims to be SegWit compatible, but it lacks witnesses, it will be treated as if the block were invalid, and the peer who gave it will be banned and/or disconnected.


LoadBlockIndexDB: transaction index disabled I'm trying to run bitcoind on a Raspberry Pi 3 but I'm stuck on an error. The raspberry has a Hdd for storage with a fully indexed blockchain that was synced on my laptop and than copied to the Hdd (txindex=1).

When calling the log file I get this message:

Side note: I also did a reindex-chainstate=1 afterwords, but I still got this issue.

transaction index disabled is logged when the txindex=1 or -txindex flag is not set. If it was once indexed, and you don't pass that flag, then bitcoind will prevent you from accidentally rebuilding the database without the indexes unless you explicitly tell it to with -reindex. Check your bitcoin.conf file and the startup script. Alternatively, try adding -txindex to /etc/systemd/system/bitcoind.service where bitcoind is called:

ExecStart=/usr/local/bin/bitcoind -txindex -daemon -conf=/home/bitcoin/.bitcoin/bitcoin.conf -pid=/home/bitcoin/.bitcoin/bitcoind.pid


Different fee rate units - sat/vB, sat perkw, sat perkb While reading documentation of C-Lightning I found this in section about making onchain transactions with the wallet (funding and withdrawing the wallet):

feerate  is  an optional feerate to use. It can be one of the strings
urgent (aim for next block), normal (next 4 blocks or so) or slow
(next 100 blocks or so) to use lightningd's internal estimates: normal
is the default. Otherwise, feerate is a number, with an optional
suffix: perkw means the number is  interpreted  as
satoshi-per-kilosipa  (weight), and perkb means it is interpreted
bitcoind-style as satoshi-per-kilobyte. Omitting the suffix is
equivalent to perkb.

I am used to sats/vB as this is used by most wallets I know and also by e.g. blockstream.info explorer. What would be equivalent of, lets say, 20 sat/vB in perkw and perkb units?
My understanding is that 1 sat/vB = 1000 perkw, so 20 sat/vB would be 20000 perkw. Is this correct?

No, one vbyte [vB] is equal to four weightunits [wu]. The people working on C-Lightning use "sipa" interchangeably for a weightunit.
1,000 sat/kvB = 1 sat/vB
1 sat/vB = 0.25 sat/wu
0.25 sat/wu = 250 sat/kwu
20 sat/vB = 5,000 sat/kwu
Also see: Is there a difference between bytes and virtual bytes (vbytes)?


Is there some client like Bitcoin core, but which highly compresses the blockchain? I have been using Bitcoin Core for some months. I need a fully fledged client as I want to help the Bitcoin network. But the blockchain is so huge. I'd love to see some other client, which highly compresses it.

The Bitcoin blockchain is mostly comprised of signatures (mostly non-compressible) and hashes (non-compressible), there's some space to be gained by eliminating redundancies due to people re-using addresses but it doesn't seem to be worth the implementation cost. Using gzip -9 and zpaq -method 5 on the block files for example saves only about 20% of the total size, using a compression system with knowledge of the Bitcoin block format would do a slightly better job, but that's the sort of ballpark you would expect to see.

128M  blk00318.dat
101M  blk00318.dat.gz (30 seconds)
95M   blk00318.dat.zpaq (5 minutes)

Even a 25% or 30% reduction in the size of the chain wouldn't allow for many more people to be able to run full storage nodes, the current growth rate (2GB per month for 400KB average blocks) would make it uneconomical again in a couple of months.

If you want to run a fully validating node to have a secure wallet or view of basic block chain data in small space, Bitcoin Core 0.11.0 does have a prune mode which can run with as little as 1.5GB of consumption- but it won't be contributing to the network at when this option is set, and your wallet use will be slightly more constrained than normal. Beyond that there's little in the way of other full storage nodes with more compact disk footprints, at least for now, pruned nodes should be made significantly more useful to the network in the future.


Download Bitcoin, Etherium, Ripple rates 1min candles is there any possibility to download archive with rates for Bitcoin, Etherium, Ripple VS USD?
I need 1m ... 1w candles.
I would like to find such service and download it on daily basis.

A lot of exchanges have a limit on how many candles that can be returned per request.
If you can't be arsed to do several requests.

You can use:
https://cryptowat.ch/docs/api#ohlc

Example usage 1:

Fetch from GDAX - BTC/USD, 1-min OHLC candlestick after the date and time 19.12.17 00:00:00

https://api.cryptowat.ch/markets/gdax/btcusd/ohlc?periods=60&after=1513641600

Example usage 2:

Fetch from Bitfinex - XRP/USD, 1-week OHLC candlestick after the date and time 01.12.17 00:00:00

https://api.cryptowat.ch/markets/bitfinex/xrpusd/ohlc?periods=604800&after=1512000000

You can use https://www.epochconverter.com/ to convert the Unix Time stamp to human readable format.

Also btw, I found some archives here: https://api.bitcoincharts.com/v1/csv/ that might be of interest.


What happens to bitcoin transactions that are unconfirmed during the hard fork? So I've just moved my bitcoins out of Coinbase into my own wallet in anticipation of the hard fork as they will only support BTC (and not BCC) afterwards.

It's been about 6-7 hours and it still is in Pending. On their help site(https://support.coinbase.com/customer/en/portal/articles/593836), there is a message saying "Partially Degraded Service: In advance of the upcoming potential hard fork, we are processing a large volume of outgoing Bitcoin transactions. Recent or new outgoing BTC transactions may be delayed by up to 12+ hours as we process this backlog."

So I'm hoping that 3 days is enough to get my transaction but I'm wondering, at the time of the hard fork, what will happen to the transactions that are midway though? Would it be different if the transaction has had no confirmations vs if it already has a few confirmations but just not the 6 for it to be fully confirmed?

Will they end up in the new wallet address for both the BCC and BTC network? Will they end up in the new wallet address for only BTC and BCC will still be in the old address?

If the transactions are still unconfirmed after the hard fork has occurred, you will only receive the coins on your Bitcoin wallet, not the Bitcoin Cash wallet. In that case, Coinbase still holds all of your Bitcoin Cash coins.


How does the new database design used by Bitcrust work? I've recently learned about a new Bitcoin node implementation in Rust called Bitcrust. They state that they have found a novel way of storing the Bitcoin blockchain as a "Spend tree" instead of tracking the UTXO set and claim to have significantly improved the performance of database interactions that way.

Can someone explain how the Bitcrust-db achieves that?

My understanding after a quick look at the code is that they use this sequential scan of stacked records of spends only for the recent 3 blocks (https://github.com/tomasvdw/bitcrust/blob/556375ccfaa81ca241b25f7b5b7f00fb97d5bd6b/src/store/spend_tree/record.rs#L296)

If the sequential scan did not find a match (if the input is from older blocks), they use this huge 2^58-bit bitmap, that is sparsely mapped to sparse files (if the filesystem does not support sparse files, they will use 16GB of storage for each 'range' that contains at least one bit set)

the code that uses 58-bit index:
https://github.com/tomasvdw/bitcrust/blob/556375ccfaa81ca241b25f7b5b7f00fb97d5bd6b/src/store/spend_index.rs#L67 (more exactly, a 52-bit index to a map of U64 values)

the 'hash' variable there does not contain a true hash, it is just a mapping of the internal storage indexes to 58-bit value: https://github.com/tomasvdw/bitcrust/blob/556375ccfaa81ca241b25f7b5b7f00fb97d5bd6b/src/store/spend_tree/record.rs#L168


Birthday attack on P2SH The Segwit Benefits document has this to say about P2SH security for base transactions:

  Multisig payments currently use P2SH which is secured by the 160-bit HASH160 algorithm (RIPEMD of SHA256). However, if one of the signers wishes to steal all the funds, they can find a collision between a valid address as part of a multisig script and a script that simply pays them all the funds with only 80-bits (280) worth of work, which is already within the realm of possibility for an extremely well-resourced attacker. (For comparison, at a sustained 1 exahash/second, the Bitcoin mining network does 80-bits worth of work every two weeks)

It then goes on to state:

  Segwit resolves this by using HASH160 only for payments direct to a single public key (where this sort of attack is useless) ... [my emphasis]

Why does this document seem to imply that the birthday attack only works for multisig P2SH and then only for one of the signers?

It seems this attack works for anybody who sees the P2SH output on the block chain and decides to start hashing. If an attacker can generate an alternative redemption script that happens to hash to the value given in a P2SH output, s/he can make the redemption script do anything.

Am I misreading the document or misunderstanding the nature of the birthday attack?

Why does this document seem to imply that the birthday attack only works for multisig P2SH and then only for one of the signers?

The birthday attack (to the best of my knowledge) requires that the P2SH address is constructed from a script which involves both a key of the victim and the attacker. That is typically only the case for multisig, but is not technically restricted to it. It does not apply to single-key scenarios.

  If an attacker can generate an alternative redemption script that happens to hash to the value given in a P2SH output

That is called a preimage search, not a collision search.

Preimage search: given a hash H, find X such that Hash(X) = H.
Collision search: find an X and a Y, such that X != Y and Hash(X) = Hash(Y).

A preimage search for a 160-bit hash function needs 2160 steps. A collision search however only needs 280 steps.

  Am I misreading the document or misunderstanding the nature of the birthday attack?

I believe you are. I'll start with explaining a simplified (infeasible) attack in a 2-of-2 multisig situation, and then optimize it and generalize.

Example

Say you (A) and me (B) are engaging in a 2-of-2 escrow. This means that someone (possibly one of us) is going to send money to a 2-of-2 multisig script, requiring that both of us agree before it can be spent.

In order to do so, we must first agree on what that script is going to be. You have revealed your public key A to me, and are waiting for me to respond with mine.

Instead of just giving you the key B, I generate a huge list of 280 public keys, all of which I know the private key for.

For each of those keys K, I compute:

Hash160(A-and-K)
Hash160(B-and-K)

I put all the A-and-K hashes in one list L1, and all of the B-and-K hashes in a list L2. I sort both lists. Then I go through both lists, and find a hash that exists in both in a single iteration. This is the critical point. It is likely that such a collision exists, because even though there are only 280 entries in each list, there are 2160 combinations of entries. Each of those has a 2-160 chance to be a collision. This is also the explanation of the Birthday Paradox, and such an attack is therefore called a birthday attack.

So, say I have found a hash that occurs in both lists. Say that K1 is the key that generated the hash in L1, and K2 is the key that generated the hash in L2. In other words, Hash160(A-and-K1) = Hash160(B-and-K2).

Now I just tell you that my key is K1. You cannot disprove that, as in fact, K1 is a completely valid key of mine. You happily accept that, and we both agree on using the script A-and-K1. We construct the address Hash160(A-and-K1), which I already know is identical to Hash160(B-and-K2).

We hand out that P2SH address, and the payer sends money to that hash's address.

Once funds have been sent there, I can spend them without your cooperation.

The requirements for spending a P2SH outputs are:

(1) a redeemscript whose hash equals the Hash160 in the P2SH address
(2) inputs to that redeemscript that make it evaluate to true.

For (1) I can use the B-and-K2 script, and for (2) I can simply sign with both B and K2, both of which I have the private keys for.

Making it practical

In practice, the above attack is not feasible, because the lists L1 and L2 are too large to store (much less sort them) for current day hardware. However, cycle-detection algorithms can be used to find a K1 and K2 such that Hash160(A-and-K1) = Hash160(B-and-K2) in 280 steps without ever fully storing or sorting the lists L1 and L2.

Generalizing

The attack can also be generalized for other scripts where multiple people are involved, as long as the attacker has an influence over the chosen script.

Mitigation

SegWit does no longer have a 160-bit script hash system. It still uses 160-bit hashes for the single key case (for efficiency reasons), as the birthday attack does not apply to them. Instead it introduces P2WSH, which uses 256-bit script hashes. The birthday attack still applies there, but requires 2128 steps rather than 280. 2128 is considered infeasible to attack in the short to medium term. Furthermore, it is the security target for Bitcoin in general (including forging signatures), doing more is not very valuable.

Why is this not an issue for single-key addresses?

In the case where no input from the attacker goes into the creation of the address being stolen from, this attack doesn't work.

All the attacker has in this case is an address. He can't insert variance into it to produce 2160 combinations out of 280 attempts. The only thing that works here is a preimage attack, which needs 2160 iterations for a 160-bit hash.


How do you get back the private keys you used, after you deploy your wallet with a 12 word seed? If I change computers and use the 12 word seed to use my wallet, how will the client know which private key I used in the previous computer?

A long sequence of private keys can be computed from the seed in a standard way.  The new client will import those keys for your use, while computing the corresponding addresses and checking the block chain to see which ones have been used.  When it finds many keys in a row that haven't been used (perhaps several hundred; this number may be configurable in your client), it assumes it has found all the keys in the sequence that you actually used, and stops.


Why doc says importing private keys is so dangerous? There are a lot of applications when someone would like to import a private key. However in wiki documentation they say it is very dangerous: https://en.bitcoin.it/wiki/How_to_import_private_keys

  WARNING Before reading this page, users should note that messing with
  ECDSA private keys is very dangerous and can result in losing
  bitcoins, even long after the import. It is recommended that outside
  of self-generated vanity addresses, users should never import (or
  export) private keys.

and

  Note that importing a key to bitcoind and/or Bitcoin-Qt may be
  dangerous and is not recommended unless you understand the full
  details of how it works.

Why is it that dangerous and what are the alternatives if you are using cold storage, a paper wallet or generating vanity addresses?

Related: Why so many warnings about importing private keys? (but it is about warnings on blockchain.info and not bitcoind). I'm not sure if the warnings are due to the same reason.

Key import by itself (from a trusted source of keys, such as your own cold storage or backups) isn't a dangerous thing. However, the vast number of ways one can cause problems for themselves through key import leads to these warnings.

Many such warnings appear to address more complex situations beyond bitcoind's scope. In this case, there can be many situations in which a weak key (e.g. from a brainwallet with bad password), or leaked key (suspicious origin, or generated by someone else) might be imported into bitcoind.

For example, the following may happen (with sample keys, of course):

5KVFiYbW5qbFfuDwrhPdsA3ALH3PmrEdQnQrpDWrqpygncbpPY4 is generated insecurely someplace (used on a physical coin, or otherwise bad origin), translating to address 1CD2nyv22gAGs8GAsdNa1rW3KinkCHgTFd.
User imports 5KVFiYbW5qbFfuDwrhPdsA3ALH3PmrEdQnQrpDWrqpygncbpPY4 and uses it in their wallet, as 1CD2nyv22gAGs8GAsdNa1rW3KinkCHgTFd in the UI.
Dumpster-diver digs up improperly-erased hard disk owned by FooPhysicalCoinForge, digs up 5KVFiYbW5qbFfuDwrhPdsA3ALH3PmrEdQnQrpDWrqpygncbpPY4 and sweeps it. Even if the address had 1 BTC on it originally and received 20BTC more, the attacker now has access to all of the funds received to it and currently spendable.


Bitcoin Core on Windows get wallet address I have recently downloaded and installed the Bitcoin core software for Windows. It is still currently syncing at 10.89%. I am unable to find the wallet address anywhere in the application itself. If you could please point out what I am missing here. Do I have to wait until the sync is complete or can I retrieve my wallet address and begin receiving some transactions.

I am unable to find the wallet address anywhere in the application itself.

Little confusion here, there is no one wallet <==> one address.

Your wallet is handling many keys, hence many addresses. You could see addresses as invoices (it has been proposed to rename them to "invoice addresses" btw).

You can (security-wise) but should not (privacy-wise) reuse such invoice addresses.

  If you could please point out what I am missing here.

Assuming you run bitcoin-qt. In order to receive coins, go to the Receive tab and click on request payment.

You will be given a fresh new invoice address.


How do you import an xprv using descriptors and importmulti? I have figured out how to import an xpub, but when i use getdescriptorinfo on an xprv:

getdescriptorinfo "wpkh(xprvA1Gpa5TRogN9eRoBFZLAEKjfvxzXTZpNpuJ9WXvTsRT3ZoW1EFnrAXji4aYPAktDc5ZYgAcS8XH5npiUdVztxdyrig2rZvNsrTEbhz1x2KQ/*)"

it returns

{
  "descriptor": "wpkh(xpub6EGAyazKe3vSruseMasAbTgQUzq1s2YEC8DkJvL5Rkz2Sbq9mo76iL4Buq1opb9EeNfB2DzqeCuuDMcpx2ZTkcJdnp24Sa8Qo7CgwfbGrD1/*)#2p7j3v7x",
  "isrange": true,
  "issolvable": true,
  "hasprivatekeys": true
}

The descriptor is an xpub? Why? It sees that the key has private keys. If I use this descriptor with importmulti and specify a range will it import the private keys and addresses? I was expecting getdescriptorinfo to return an xprv. If this is not how you import an xprv then how do you?

getdescriptorinfo always returns the non-private key from of the descriptor (security precaution).

From the commands help text:

"descriptor" :  (string) The descriptor in canonical form, without private keys


How much anonymity do mining pools provide? How much anonymity does an average mining pool provide to the user (securing your email, other personal information)? What is the best pool to use if you want to remain anonymous, and which is the worst?

Eligius is the most anonymous pool I know of, as it doesn't require registration. Quoted from the Bitcoin wiki: "To use it, a miner merely needs to be directed to mining.eligius.st on port 8337, with the username set to a valid bitcoin address (which receives the payout). No registration is needed."

Pools I'm aware of that have been hacked include nofeemining.com (userids, passwords and emailed were published to the web - the administrator didn't actually notify users of the extent of this. The pool has since closed), ozco.in (this was treated very seriously), and abcpool.co (some balances stolen, but treated seriously). However, if anything, the likelyhood of a being hacked again is probably less than some of other mining websites that haven't yet been compromised.

Given that most pools require little more than an email address (and you can create an anonymous email address easily enough on various websites), a user can choose to remain reasonably anonymous with minimal effort.

Perhaps the biggest risk to user anonymity is through your IP address - if you provided personal details to an untrustworthy website, say dodgyexample.com, and then mined "anonymously" at a theoretical site dodgymining.com, your IP address could be used to link the accounts details as being owned by the same person.

Further to the above, the payouts you receive through a pool may be linked back to you through the Bitcoin blockchain, depending on where you spend your bitcoins and whether you have shifted them between wallet addresses before you spend them. This is unlikely though, as you will most likely spend your bitcoins somewhere that the malicious individual cannot link back to you.

See also: How can one remain relatively anonymous while using Bitcoin?


Does adding more miners create more bitcoin? I was on another forum and the claim was made that the miners using new technology GPUs are flooding in and because of this there will be more bitcoin produced.  My understanding of block rewards is it's like a horserace between miners (or group of miners) to solve the blocks and the 1st to solve gets all of the reward.
Who is correct?

I was on another forum and the claim was made that the miners using new technology GPUs

GPU mining has been obsolete for Bitcoin mining since around 2014. All mining these days is done using custom chips specifically designed for Bitcoin mining. It is orders of magnitude more power-efficient.

and because of this there will be more bitcoin produced.

Bitcoin has a fixed inflation schedule: 1 block every 10 minutes, and every block currently permits a subsidy 6.25 BTC (a number that halves every 4 years). The difficulty of producing a block goes up (or down) automatically as hashrate is added (or removed). This has a slight delay, so if the hashrate is continuously increasing, blocks will be produced slightly faster than 1 per 10 minutes, as the difficulty will always be slightly behind. This does increase the rate of inflation while it lasts, making the total supply be permanently ahead of schedule. However, due to exponentially decreasing subsidy, the limit is and remains approximately 21 million, regardless of block production speed.

My understanding of block rewards is it's like a horserace between miners (or group of miners) to solve the blocks and the 1st to solve gets all of the reward.
Who is correct?

Block mining is like a lottery, where every hash tried is one ticket. The lottery is always sold out, so there will be always one winner. There is a new lottery on average every 10 minutes.
It is not like a race; a race would imply that the fastest miner always wins. This is not true, everyone wins approximately proportional to what percentage of the network rate they have.


What would happen if you tried to follow two Bitcoin blockchains from the same computer? This will probably sound stupid but what would happen if you create an entirely new Bitcoin block chain and run it on the same computer. How does a node know which version of the Bitcoin block chain to talk to? Does each block chain have a unique identifier?

Bitcoin is programmed to accept the most proof-of-work chain, which is many times also the longest chain. Every new block added to the blockchain references the previous block with its hash. Based on your question, there are a number of cases that I have come up with and how your new 'forked' blockchain will react.

You run the same software that Bitcoin is currently working on: your software will automatically accept blocks from other peers and add it to the genesis block. This will bring you to the current Bitcoin blockchain
You change the genesis block, but use the same DNS seeding: when the peers will send you new blocks, the previous block hash reference in block 1 will not match your new genesis block header hash and hence that block cannot be added. This you have now generated a completely new chain.
You fork the blockchain but change rules at certain point: This is how Bitcoin Cash was created. From a particular block height they increased the block size to more than 1MB, which resulted in the original Bitcoin nodes rejecting the newly generated blocks. So you now have a different chain from a particular height.


Generating private keys in Java I'm looking for a way to generate private keys in Java. I'd like to make this a standalone program, so I'd rather not use a library like bitcoinj. From my research I've only seen people recommend using bitcoinj. Has anyone created anything like this? Thanks.

Most private keys are essentially just random numbers, so if all you want is a private key, you just need to use a high-entropy random function to generate your private key that's 256 bits.

Converting those bits into something a normal bitcoin wallet can understand (like WIF) is a little trickier, but the process is spelled out here. I'm recapping the actual process here so you can use the Java library java.security.MessageDigest for SHA256 and you can use this code snippet to convert to Base58.

1 - Take a private key

0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D

2 - Add a 0x80 byte in front of it for mainnet addresses or 0xef for testnet addresses. Also add a 0x01 byte at the end if the private key will correspond to a compressed public key

800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D

3 - Perform SHA-256 hash on the extended key

8147786C4D15106333BF278D71DADAF1079EF2D2440A4DDE37D747DED5403592

4 - Perform SHA-256 hash on result of SHA-256 hash

507A5B8DFED0FC6FE8801743720CEDEC06AA5C6FCA72B07C49964492FB98A714

5 - Take the first 4 bytes of the second SHA-256 hash, this is the checksum

507A5B8D

6 - Add the 4 checksum bytes from point 5 at the end of the extended key from point 2

800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D507A5B8D

7 - Convert the result from a byte string into a base58 string using Base58Check encoding. This is the Wallet Import Format

5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ


What hashing speed does my hardware have? I'm checking this page to know what hashing speed my hardware has. But there's no explanation about the acronyms.

For my Core 2 Quad Q9650, what's the expected hashing speed?

From Wiki:Mining hardware comparison: Core 2 Quad Q9650 - 18.67 Mhash/s . With current price and difficulty factor there is no point in using CPU for mining because the profit won't cover the cost of hardware or electricity. For example with current difficulty it will take you 8 years on average to uncover block and earn 50 BTC or 1/2 BTC a month if mining from a pool.

Today everyone uses video cards to mine e.g. ATI 5970 has about 800 Mhash/s, which is about 43 times faster then your CPU. Bitcoin network adjusts difficulty factor so bitcoin production rate would stay roughly the same, about 50 bitcoins per 10 minutes. CPU mining can do only a small part of total workload therefore you would receive on average a very small part of the reward.


Does any university accept bitcoin to take course fee? Which universities of the World accept bitcoins to take their course fee? Can it be done by bitcoins? I need to know it as I am planning to take some courses for higher education from an reported University.

University of Cumbria, a British University, is the first Public University accepting bitcoin in the UK for two of its courses. “Certificate of Achievement in Sustainable Exchange”, will be taught at Cumbria’s London campus, and the “Postgraduate Certificate in Sustainable Leadership”, which will take place at the Lake District campus. http://www.independent.co.uk/student/news/cumbria-becomes-first-public-university-in-the-world-to-accept-bitcoin-in-tuition-fees-9074700.html

Other options globally include the University of Nicosia in Cyprus (http://www.unic.ac.cy/news-and-events/73/unic-to-be-the-first-university-in-the-world-to-accept-bitcoin/112831#.UuFCG9LnaUk) and there are unsubstantiated rumors that Novi Sad in Serbia takes them as well.


Is the transaction pool global or local? I can't find anything in the web about that topic.
Do all the miners have one global pool filled with transactions, i. e. Miner 1 takes Transaction 1 into his candidate block, so Transaction 1 won't be in the transaction pool anymore.
Or does each miner has a local pool filled with transactions, so that each miner can take Transaction 1 into his transaction pool.

If my question is unclear, I will try to describe it better.
I hope someone knows a good reference to that topic.

Do all the miners have one global pool filled with transactions

Different full nodes have a different version of the mempool. Transactions are broadcasted to the bitcoin network on a best effort basis. If a transaction never reaches a node, it would not include it in the mempool. It would not learn about this transaction until it is included in the block by another miner.

  Miner 1 takes Transaction 1 into his candidate block, so Transaction 1 won't be in the transaction pool anymore, Or does each miner has a local pool filled with transactions, so that each miner can take Transaction 1 into his transaction pool.

The second part is correct. Every miner creates their own candidate blocks using transactions from their own mempool. In case a miner is affiliated to a managed pool, the pool operator creates a block template (by including the transactions) and sends the header to the respective miners that are attached to the pool.


What does "Nonstandard output" mean on Tradeblock transaction page? I tried to send bitcoin but the recipient hasn't received it.

The trade block page shows "Nonstandard output" under outputs as shown in the link below:

Tradeblock page for transaction

I used an Electrum wallet and the transaction seemed to confirm as the usual green tick appeared next to it in the transaction history. However my balance was 0BTC and the text "not enough funds" appeared in the bottom left corner.

What's going on? How do I either get my money to the recipient or back to me?

A bitcoin address that starts with bc1 is a bech32 address. It is possible that Tradblock hasn't been updated to cater for this type of address.

Other Blockchain explorers show the transaction as confirmed.


How does the Bitcoin client check for double spend? When the Bitcoin client looks at the input of a transaction, it know the hash of the previous transaction from which the funds are coming, however then, how does it know that this output has not been spent already? Does it need to scan the whole blocklist for another transaction spending that same output? Isn't that very inefficient?

Bitcoin-Qt marks outputs as spent in the database once they are spent. To check whether an input's prev-out is spent, Bitcoin just needs to look up the transaction and check whether the output is marked spent.

Other ways of doing it are to have a set of all unspent outputs and check whether the prev-out is in this set (future versions of Bitcoin will do something like this), or to index inputs by their prev-outs.


What exactly were the novel contributions of Bitcoin? When Satoshi Nakamoto published the original white paper describing the Bitcoin protocol, they referenced Hashcash and B-money. B-money is a proposal for an electronic cash protocol, similar to Bitcoin. Hashcash is the proof-of-work algorithm used in Bitcoin.

P2P, digital signatures, proof-of-work and electronic cash protocols existed before Bitcoin. What exactly were the novel contributions of the Bitcoin protocol?

b-money proposes to pay for money minting by means of proof-of-work. The minted money then has the value of the expended computational power.
For value transfers it either relied on a synchronous unjammable channel and arbitration, or on a set of trusted servers that had to be regularly audited by the other network participants.

In other words, b-money used POW to create monetary scarcity with manual supervision.

Bitcoin instead introduced the use of proof-of-work to create scarcity in the truth source: By electing only one network participant to extend the blockchain through the mining lottery, Bitcoin manages to forgo arbitration or trusted servers, yet manages to create convergent synchronization of the network's state in an asynchronous manner.


How to retrieve POST data that contains JSON I have never used JSON before and am trying to retrieve the values POSTed to my site from coinbase. But I have no idea how to.

Information about the IPN and callback can be found here: https://coinbase.com/docs/merchant_tools/callbacks

To be more specific, what I understand so far is that I can use json_decode($jsonData); to turn the JSON data into PHP data. But how do I set the variable $jsonData?

This is the response that is supposed to be sent:

{"order":{"id":null,"created_at":null,"status":"new","total_btc":
{"cents":100000000,"currency_iso":"BTC"},"total_native":
{"cents":2263,"currency_iso":"USD"},"custom":"123456789","button":
{"type":"buy_now","name":"Test Item","description":null,"id":null},"transaction":
{"hash":"4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b","confirmations":0}}}

$data = json_decode(file_get_contents('php://input'), TRUE);
$text = print_r($data,true);
file_put_contents('coinbase.txt', $text);

This actually sends the following information to a text file:

Array
(
    [order] => Array
        (
            [id] =>
            [created_at] =>
            [status] => new
            [total_btc] => Array
                (
                    [cents] => 100000000
                    [currency_iso] => BTC
                )

            [total_native] => Array
                (
                    [cents] => 2270
                    [currency_iso] => USD
                )

            [custom] => 123456789
            [button] => Array
                (
                    [type] => buy_now
                    [name] => Test Item
                    [description] =>
                    [id] =>
                )

            [transaction] => Array
                (
                    [hash] => 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
                    [confirmations] => 0
                )

        )

)


How to stop another bitcoind service? I created two bitcoind service in my server.
First using default configuration, and second use new configuration.
I am able to stop first bitcoind using bitcoin-cli stop, but the second bitcoind still running. How to safely stop the second bitcoind without forcing to kill it ?

bitcoin-cli has a -datadir option so you can specify the data directory of your other bitcoind instance. It will use that parameter to read the bitcoin.conf and .cookie files in the other data directory so that it can connect to the other bitcoind instance. With that parameter, you can send RPC commands to it, including the stop command.

Alternatively, you can stop bitcoind by finding its PID (using ps) and the kill command. kill be default uses SIGTERM so bitcoind will actually safely shutdown by going through its shutdown process.


How much do nodes get from blocks, including fees? I am trying to evaluate how much one could earn as pool owner/solo miner if bitcoin really appreciates in price. To get a number i try to get a figure how much one mined block generates in for example a month, week, year.

How much fees does one mined block generates actually in a given timeframe?
What percentage of that is from the block reward, and what percentage is from fees?

1) Fees are very block-dependent but recently have normally been in the 0.25 - 0.5BTC range

2) A mined block currently gives 25BTC + fees.  From the above, fees are coming in around 1-2% of the total block reward


Is it possible to get information about forks in the blockchain? I don't know if "fork" is the right word here, but I know that two blocks can be mined around the same time, creating more than one competing block at a certain level of the blockchain.

Is it possible to get information for about these competing blocks from bitcoind?


How did Silk Road work when it came to delivering product anonymously? A lot of times, people say Bitcoin is anonymous, but I know most transactions can be easily traced using IPs that used ewallets and by making connection with other bitcoin addresses. So with that in mind, I'm curious if someone had bought something on Silk Road (or any other place) - wouldn't they need to have that product delivered eventually to some address where they could pick it up? How did that affect anonymity? Or were drop off locations used or something? I'm just curious how that worked.  Any ideas?

Regarding bitcoins, all the funds were mixed using various techniques to prevent coin tracking. It is propably better to not use a web wallet in this case. Using the Tor network allowed to prevent being tracked by IP. Although you might think bitcoin is not 100% anonymous, it is anonymous enough so that no scammer/hacker/thief has ever been caught using only the blockchain.

To my knowledge products were compressed and sent to the customers' home address in letters. Apparently that's not a problem for small orders.


Isn't an encrypted wallet.dat automatically a "watch-only" wallet? I have encrypted my wallet.dat outside of this computer. Now I store my wallet.dat on this computer.
If I open it in Bitcoin Core, I can view the balance but not spend it (without entering the decryption passphrase).
Doesn't this make an encrypted wallet.dat a "watch-only" wallet? Can't I simply safely keep this on my PC and use the RPC API to check on the balance to make sure that it still contains my coins?
Basically: What is the difference between an encrypted wallet and a "watch-only" wallet? Why would I make a "watch-only" wallet when the encrypted wallet apparently has the same functionality, and is as secure?

An encrypted wallet may be cracked if its password is weak with enough budget and computing power, while a watch-only wallet doesn't give any information other than the address and what can be derived from the address.


Which parameters in the Bitcoin Core config file need to be set correctly prior to IBD? The majority of the parameters in the Bitcoin Core config file can be changed during or after IBD (Initial Blockchain Download) with no complications.

However, there are some parameters in the config file where it is important that you set them correctly prior to IBD. If you don't you will either have to restart IBD or it will greatly increase the time for IBD to complete.

Some parameters that need to be set correctly prior to IBD are testnet, regtest, prune and txindex as discussed here. Are there any others?

To my knowledge, the only parameters that have to be set before an initial block download are the regtest and testnet options.

Anything else, including txindex, can be altered later, although it may cost you a reindex or reindex-chainstate to enable functionality like a txindex if done after the block download has started.

Other parameters such as those governing the RPC, peers, and wallets can be quickly updated at any point.


Is there any way by which we can see when was last time or which was the block that was created just before bitcoin adjusted its latest difficulty? I guess if we start doing mathematical calculation then we can easily find exjact block no which was formed just before difficulty was adjusted. But is there anyway around like by using RPC by which we can find it out?

I don't know a way to get this directly through the RPC without looking at multiple blocks and comparing them, but the math formula is easy:

floor(current_number_of_blocks / 2016) * 2016 - 1

The floor function rounds a number down to an integer value; it's available in most programming languages, although it's sometimes named something to do with integers (e.g. int()).  The number 2,016 is the number of blocks in a retarget period (the time between difficulty changes).

Here's an example command:

bitcoin-cli getblockchaininfo | jq '.blocks / 2016 | floor * 2016 - 1'
524159

As requested, as of this writing, block 524,159 is the last block before the difficulty change.  To get the first block with the new difficulty, remove the -1 (so block 524,160 in this example).

The command used in the above example is jq.


How to generate Ed25519 public key from private key using libsodium? Not all crypto currencies are using secp256k1 technology for keypair generation and digital signatures. Curve25519 technology (frequently used to support ECDH key exchanges) is being used by a few other cryptocurrencies. Ed25519 cryptography (meant to support EdDSA functionality) and Curve25519 cryptography are closely related through transformations and the trend is to start with Ed25519 keys and transform them to Curve25519 key pairs.

Been using this reference as a source of eight ED25519_SECRET_KEYS and corresponding ED25519_PUBLIC_KEYS to use as test vectors for applying Ed25519 package implementations.

Got floodyberry/ed25519-donna to function as expected. However, I could not compute the ED25519_CURVE25519_PUBLIC_KEYS from the reference using ed25519-donna using its curved25519_scalarmult_basepoint() function to match. This pushed me towards trying jedisct1/libsodium. Got crypto_scalarmult_base() function results from libsodium to match those from ed25519-donna:-)

However, it is unclear how jedisct1/libsodium can be applied to generate public Ed25519 keys only from secret Ed25519 keys that are natively in an ASCII hexadecimal format:-( It seems that jedisct1/libsodium requires keys to always be generated from it native keypair generation process, opposed to an externally supplied private key.

Used the sodium_hex2bin() to stuff an ASCII hex encoded private key from the reference into the 64 unsigned char ed25519_skpk variable:

sodium_hex2bin( ed25519_skpk, 32, ED25519_SECRET_KEYS[ii], 64, NULL, NULL, NULL );

Results from the following libsodium function were as expected:

crypto_scalarmult_base( curve25519_pk, ed25519_skpk )

Was a bit frustrated when I discovered that crypto_sign_ed25519_sk_to_pk() was coded to extract the public key from ed25519_skpk that was never initialized.

crypto_sign_ed25519_sk_to_pk( ed25519_pk, ed25519_skpk );

Becoming a bit disappointed not locating a libsodium function to compute the ed25519_pk key when ed25519_skpk is loaded with a working private key from an external source. Any assistance will be greatly appreciated.

It's not possible to directly compute the ed25519 public key from the private key.  Instead, use the deterministic private key to create a seed, then use the seed to re-create the private key with its corresponding public key. The following code snippet assumes ed25519_skpk is already initialized:

char           hex_ed_pk[65];
unsigned char  seed[crypto_sign_SEEDBYTES];
unsigned char  ed25519_skpk[crypto_sign_ed25519_SECRETKEYBYTES];
unsigned char  ed25519_pk[crypto_sign_ed25519_PUBLICKEYBYTES];

// COMPUTE ED25519 PUBLIC KEY, REQUIRES ESTABLISHING A SEED
(void)crypto_sign_ed25519_sk_to_seed( seed,ed25519_skpk);
(void)crypto_sign_seed_keypair( ed25519_pk, ed25519_skpk, seed );
(void)sodium_bin2hex( hex_ed_pk, 65, ed25519_pk, 32 );