text:
What kinds of wallets are there?
Can I get short a explanation about cryptocurrency cold/hot wallets?
Are there more kinds?

Hi karlos.
Hot wallet mostly looks like app or software,
they mostly not 100% open source so its not top secured..
Cold wallet mostly looks like USB driver.
When they not connected ,bitcoins/crypto currency safe.
There have also an exchange wallet .
Exchange wallet functioned like your hot wallet but that's some third party wallet that supply you the API for visual preview of your money and actually store your bitcoins/crypto currency in there private exchange wallet.

Hope that its short enough and helpful  for you.

Thank you in advance, Sadikov.

What kinds of wallets are there?

There are many ways of classifying wallets
Index

Wallet types

Hot vs Cold
Desktop vs Mobile
Non-custodial vs Custodial
Paper vs Hardware vs Brain
Full-node vs Lightweight
Watch-only

Things to remember
Other lists

Can I get short a explanation about cryptocurrency cold/hot wallets?

Hot wallets vs Cold Wallets
Hot Wallets
These are any kind of wallet that has a network connection and so is vulnerable to attack and is relatively unsafe. Many people prefer to keep their savings in a cold-wallet and only transfer money to a hot-wallet when they need to spend the money.
You need a hot-wallet to send a payment
You don't need a hot-wallet to receive payments.
synonyms: online-wallet (confusingly - don't use this term)
Cold wallets
These are wallets that are not connected to the Internet, or any local network, and so are relatively safe from network-based attack by thieves.
A cold-wallet can receive payments.
Synonyms: offline-wallet.
Varieties: paper-wallet, hardware-wallet (at least when not plugged in). Desktop wallet on isolated or turned-off PC, ...

Are there more kinds?

Here's the main other kinds I know of, the main other ways of classifying wallets or dividing them up into types. Note that any wallet can be several kinds, a wallet might be a hot-wallet that is also non-custodial and also a full-node wallet all at the same time:

Desktop wallets vs Mobile wallets
This is about the sort of device that runs the wallet software.
Desktop wallet
A wallet that runs on a normal PC.
Mobile Wallet
A wallet that runs on a mobile phone. Almost always these are lightweight wallets.

Non-custodial wallet vs Custodial wallet or account
This is about who controls your money, you or big business.
Non-custodial
This is the type of wallet that the inventor of Bitcoin created. Just like a leather wallet in your pocket, you use it to look after your cash yourself. No one else manages the cash in the wallet in your pocket.
Bitcoin was invented so one person could pay electronic cash to a second person without involving any trusted intermediary. No banks no exchanges.
Custodial
A wallet where the private-keys are held by an online service, not by the customer.
Typically access to the wallet is by a web-browser but sometimes with an app or using a custom desktop-client.
Advantages: easy and fast to set up, transfers to other customers of the same service can be instant (no wait for confirmations) and cheaper.
This is the least safe way to hold crytocurrency (see large scale thefts from MtGox, Poloniex, Bitstamp, BitFinex, Cryptopia, Quadriga-CX etc etc etc)
Key point to remember: "No private-key = no Bitcoins" or "not your private-key means not your Bitcoins".
Synonyms: web-wallet, hosted-wallet, online-wallet (rarely and confusingly)

Paper wallets vs Hardware wallets vs Brain wallets
This is mainly a choice of where the private keys are stored.
Paper wallet
Wallets don't contain crytocurrency coins, the only important thing they contain are private-keys - anything else in them is disposable.
Therefore printing your seed-phrase or private key onto paper as a QR-code, other barcode or as a hex or base64 string etc, can act as a wallet.
A paper wallet can receive payments but cannot make them.
A properly-managed paper-wallet is one of the most secure types of wallet.
Hardware wallet
A hardware device that safely holds your private key and which can connect to a PC, usually  using a USB port, to sign transactions (without divulging the private key to the PC)
This is arguably the most secure form of wallet.
They typically need software on the PC which knows how to talk to them. Several desktop-wallets can interface with one or other hardware wallets.
Brain wallet
NOTE: Brain-wallets can be very insecure. For more info see this question, or this one.
You don't hear this very often but it is an interesting form of wallet. There are standards for generating private-keys from a seed-phrase. Many wallets support this. If you can remember a seed phrase you can destroy your wallet and later re-create it using only the seed-phrase.
If your wallet is only stored as a memorised phrase in your brain, it can still receive payments - so long as you have your payment address(es) noted down somewhere. Payment addresses need not be kept secret.
Unfortunately people are pretty bad at remembering stuff.

Full-node Wallet vs Lightweight wallet
This is about the amount of data storage available to a wallet.
Full Node
A wallet that keeps a copy of the whole blockchain. E.g. bitcoin-core.
The trade-off is that the wallet takes days or weeks to synchronise when first installed. It will use up more of your network bandwidth (at least initially)
This is the type of wallet that was first invented and is in many ways, one of the best types of wallet.
Lightweight wallet
A wallet that does not keep a copy of the whole blockchain and which trusts some other nodes to give it truthful blocks.
The advantage is they don't need lots of storage space and can start-up much faster.
Synonym: SPV wallet.
SPV stands for Simplified Payment Verification and was outlined by Satoshi Nakamoto in the 2008 Bitcoin Whitepaper. I expect there are other ways of implementing lightweight wallets.

Watch-only wallet
This is not really a type of wallet but a way of using a wallet.
A watch-only wallet is one that has had a public-key / address imported into it but which does not have the corresponding private-key.
It can show the "balance" for an address but cannot be used to spend that balance.
Often used by scammers to trick people but also useful as a safe type of hot-wallet to monitor your balance without any risk of theft.
A wallet can usually have several sets of, erm, subwallets. A wallet could have both a private key for a hot-wallet with a small amount of money in it and an imported watch-only address for a cold-wallet so you can monitor balances for both "hot" and "cold" subwallets in one place.

Things to remember ...
(... about wallets and their use)

Wallets don't contain money.

The only important thing in a wallet is the private-key(s).

Money is not sent to wallets.

Money is sent to bitcoin-addresses. The wallet contains a private-key that
allows you to "spend" money at a corresponding bitcoin-address

Never share a wallet-password - even if you change it afterwards, you've lost control of any money that has been, or might later be sent to addresses in that wallet.
Never share your private-key. Never.
Backup your private key or seed-phrase safely in several places.
Share overlapping parts of your private-key or seed phrase with several family members with instructions on what to do if you are hit by a bus this afternoon. (see several questions here from desperate bereaved relatives of people who made no provision for this)
What do you want to happen if your house burns down to ash with  all your pcs, laptops, notebooks, phones, paper etc destroyed. (see questions here from people who lost their phone or overwrote their PC or mistyped their seed-phrase or forgot a password and don't know what a backup is or why they should have made several, in several places, in fireproof boxes, and tested recovery)

Other lists
Other places that have lists of different types of wallet:

Choose your wallet, Bitcoin.org
Comprehensive Cryptocurrency Wallet Guide, "fastInvest"@Medium.com
Types of Crypto Wllets, CoinSutra
Is there a Wiki comparing different wallets?

Thank you for this great info! helped me to understand more..

Hot and cold in this case refer to if the private key is stored on a system connected to the internet or not. Hot wallets are stored on system connected directly to the internet. This can be on the client machine or on a centralized server. A cold wallet can be a HW wallet, an offline wallet or a paper wallet. You kind of create an air-gap that drastically reduce the attack surface on the wallet.


text:
BTC recovery from registration details without wallet.dat
I started mining march 2009, i remember registering. is there any way to get my BTC back from the registration process? I know you need the wallet.dat and the password or key to access the BTC, but is there any way to get my BTC back. I am desperate, the fact that i know i have money out in the ether, but yet have none is killing me. I vaguely remember when i signed up they just added a registration process that linked my info to the coins i generated in 03/2009. I know there are lists of dormant addresses, can they be used to get my BTC back? Please help

Registration with whom? There is no admin for the bitcoin network, users are responsible for their own coins. In March 2009 there would not have been any mining pools, etc, to sign up with, I think at this point you will either have your old wallet.dat file, or not. Best of luck.

is there any way to get my BTC back from the registration process?

In general there is no registration process for buying or mining bitcoin or for most types of bitcoin wallet. Certainly not in 2009.

I started mining march 2009, i remember registering.

There is no registration process for mining. At least not in the January 2009 Bitcoin software released by Satoshi Nakamoto.
At that time, I believe mining would have placed any mined coins into an address controlled by the private-key in a wallet on your PC.
Registering for a custodial wallet service (trading/exchange service)
There may have been a registration process if you had a "custodial" wallet, a type of wallet where you arranged with a third party for them to manage your wallet on your behalf. There are many such companies, all different. In that case you would have to contact the specific company that you registered with. This would not have been the case in March 2009 but maybe in later years you signed up with a custodial-wallet business to use their trading services? (In any case, this paragraph may be helpful to later searchers who find this question because they have the problem expressed in the title).

there are lists of dormant addresses, can they be used to get my BTC back?

No. To regain control of the BTC you need the private-key that was stored in the wallet. The address is not enough.

In 2009, the (only) Bitcoin software did not support encryption (that was added in 2011, in version 0.4), so there would not be any password.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
Can the Bitcoin network boycott a misbehaving miner?
If a miner misbehaves, can other miners “boycott” him/her by refusing to build on top of his/her blocks in the future? Will such a “boycott” keep the miners from behaving badly?

any hints will do fine!!

I'm not sure what you mean by 'misbehaves', but if a miner creates an invalid block, the rest of the network will ignore it.
And in any case, a specific miner cannot be banned from participating in the network. The network only cares about whether a new block is valid or not, the origin/creator of that block is not even necessarily known. There is no 'ID' or anything like that that links blocks to certain miners. Anyone that submits a valid block hash can create the next block on the network.

By 'misbehaves,' if somehow this miner controls 51% hash power of the network, and then he tries to attack blockchain network, adding invalid blocks or creating a fork in blockchain then trying to add the block on top of his block

A miner with 51% of the hashpower cannot add invalid blocks, but they can fork all other miner's block off the network, except for their own. In any case, the network's nodes will continue to follow the longest chain of valid blocks. There is no way of knowing who has submitted the blocks, so if they are valid, the nodes will accept them.

What will happen to transactions present in the fork in which all other miner's block are present which he(mischievous miner) set off the network. Will those transactions become useless?

for eg. merchant who waited for 6 confirmation to verify payment, then ship the product bought. But if those transactions became useless or in some sense were thrown out of the public ledger, then merchants would have to bear loss!

@PrajitVerma Yes, if there is a fork (reorganization) then the transactions that were confirmed pre-fork, may no longer be confirmed post-fork. This is why it is often recommended to wait 6 confirmations: the chance of a long reorg is low, and it is very expensive to attempt such an attack. See: https://bitcoin.stackexchange.com/questions/658/what-can-an-attacker-with-51-of-hash-power-do also relevant: https://bitcoin.stackexchange.com/questions/3343/what-is-the-longest-blockchain-fork-that-has-been-orphaned-to-date

As other's have noted it is unlikely that boycotting is practical  with bitcoin or any other automated trust-minimized network. There needs to be a defined mathematically provable function that prevents certain types of transactions, otherwise you cannot guarantee that it didn't occur. That being said the question of 51% attacks is something I have thought about a lot. There is a recent innovation in progress being developed on the Ergo blockchain called Succinct Non-Interactive Share Proofs  (reference https://www.youtube.com/watch?v=x-9x_PveRog). As mentioned it is a work in progress however in theory a proof like this can determine the amount of hashpower a particular address is holding.
I can only imagine that in order to extend this into a feasible 51% attack resistant algorithm you would need share proofs to be committed on chain per block creating a chain of proofs for any particular miners address. You can then distribute rewards based on hashpower consistency and make it unprofitable/invalid to mine if you have X percentage of hashpower which theoretically is provable. The problem now is that miners don't disclose their public key until the UTXO is spent essentially, so tying down a miner identity becomes pretty much impossible as a necessary privacy preserving function of the network. So you would need miner address' to be revealed in this theoretical alternative algorithm, the reward structure should outright reject anyone attempting to solve proofs with a threatening amount of hashpower. Even this cannot solve all scenarios of 51% attack though because an individual can still damage decentralization through mining on different address' to spoof being different individual people. Not to mention that the blockchain has no current way to keep track of its own network hashrate (would need to be in consensus across 100% of clients). Essentially the only thing I can think of is prevent artificial forks created by a single address through a complex method of mining share proof credit reward structures.  Such structures have never been developed and as far as I'm aware I am the only person who has ever even come up with such an idea. I personally cannot see the solution to the identity issue who overall removes the possibility to protect from some sort of anonymous mining attack. That being said the general protection against the attacks are the amount of power being used and the device cost and rarity used to mine. Bitcoin has all of this down to such a sweet-spot due to its calm gradual approach to adoption. It is likely not to be replicated by anything other than natural decentralization. I got thinking down this rabbit hole by the fact that miners usually mine to one address but I don't think that general assumption is quite enough to base an entire proof of work algorithm around. It needs a lot more work...

Yes, other miners can boycott a misbehaving Bitcoin miner on an ongoing basis. This can be done by simply not including the blocks that are mined by the misbehaving miner in the blockchain. Miners are free to choose which blocks they include in their own version of the blockchain, and if they do not include the blocks mined by the misbehaving miner, those blocks will not be included in the final, consensus version of the blockchain.
However, it is important to note that this type of boycott may not be effective in all cases, as the misbehaving miner may have a significant amount of mining power and be able to create a longer chain of blocks than the rest of the network. In this case, their chain would be accepted as the valid chain and the boycott would not be effective.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
how to generate bitcoin adddres using seed?
Hi i am new to bitcoin all i want to know is how to generate address using mnemonic seed?
let testnet =Bitcoin.networks.testnet;
let keypair =Bitcoin.ECPair.makeRandom({network:testnet});
let address=keypair.getAddress();
let privateKey=keypair.toWIF();
res.json("Public Address  "+ address+ "  "+privateKey)

Using bitcoinjs-lib and bip39. You can install those with npm install bitcoinjs-lib bip39 --save
const Bitcoin = require('bitcoinjs-lib');
const Bip39 = require('bip39');
const Bip32 = require('bip32');

function getAddress (node, network) {
  return Bitcoin.payments.p2pkh({ pubkey: node.publicKey, network }).address
}

const mnemonic = `entire taste skull already invest view turtle surge razor key next \
buffalo venue canoe sheriff winner wash ten subject hamster scrap unit shield garden`;

const seed = Bip39.mnemonicToSeed(mnemonic);

const root = Bip32.fromSeed(seed, Bitcoin.networks.bitcoin);

const child1 = root.derivePath("m/44'/0'/0'/0/0");
const child2 = root.deriveHardened(44).deriveHardened(0).deriveHardened(0).derive(0).derive(0);

console.log(getAddress(child1)); //1ENQm8nEP7sd6dqXbAMYZ4AuqcP8Y7AtR
console.log(getAddress(child2)); //1Hb6Z1uZ1RuZ6GXTvedQ2ETYKYsMc5qynN

You can check the code is working using this website. You might also want to read up a little about BIP32, BIP39 and BIP44. An executive summary below:

The BIP32 describes how you can generate new child keys programmatically from a single key and a few other properties.
BIP39 defines a set of standard words used to mimic a key and how to transform them back to the original "seed" (the key from BIP32).
BIP44 specifies how you should compute the child keys from the parent one. You can see from my code that I used derivePath("m/44'/0'/0'/0/0"); in conformance of its specification.

Does the GUI have a way?

Here's the complete code to run everything from your browser:
#!/bin/bash
#
# call this {anything}.sh
# when finished, run chmod +x *.sh
# then ./*.sh should execute the script
#
# Create a ECDSA keypair for use with crypto currencies
# The key will be derived from whatever seed phrase is entered by the user
#
# Copyright (c) 2019 B Tasker

read -p "Enter a seed sentence: " seedphrase

# Derive a private key
privkey=$(echo "$seedphrase" | openssl sha256 | cut -d\  -f2)

# Get a proper copy of the private key
privkeyfull=$(openssl ec -inform DER -in <(cat <(echo -n "302e0201010420") <(echo -n "$privkey") <(echo -n "a00706052b8104000a") | xxd -r -p) 2>/dev/null)

# Now start creating the pub key
longpub=$(openssl ec -inform DER -text -noout -in <(cat <(echo -n "302e0201010420") <(echo -n "$privkey") <(echo -n "a00706052b8104000a") | xxd -r -p) 2>/dev/null  | tail -6 | head -5 | sed 's/[ :]//g' | tr -d '\n' && echo)

# Create the compressed version
compub=$(echo -n "$longpub" | cut -c1-66 | sed 's/^04/02/')

# Now RipeMD it:
hash256=$(echo "$compub" | xxd -r -p | openssl sha256 | cut -d\  -f2)
ripemd=$(echo "$hash256" | xxd -r -p | openssl ripemd160 | cut -d\  -f2)

# Now RipeMD the uncompressed :
hash256=$(echo "$longpub" | xxd -r -p | openssl sha256 | cut -d\  -f2)
ripemdunc=$(echo "$hash256" | xxd -r -p | openssl ripemd160 | cut -d\  -f2)

# And a version we can pass into OpenSSL if we need to
pubkeyfull=$(openssl ec -inform DER -in <(cat <(echo -n "302e0201010420") <(echo -n "e359ae12b3c49fa0d59d0947a97acc9d8595017205909a883501ae09d4ea1888") <(echo -n "a00706052b8104000a") | xxd -r -p) -pubout 2>/dev/null)

cat << EOM
Seed Phrase:
$seedphrase

Keys:

Private: $privkey
Long public: $longpub
Compressed Public: $compub
RipeMD (Compressed) Public: $ripemd
RipeMD (Uncompressed) Public: $ripemdunc

PEMs:

$privkeyfull
$pubkeyfull

Keep these safe
EOM

It is simpler than you think using command lines. Look at https://github.com/libbitcoin/libbitcoin-system/wiki/Altcoin-Version-Mappings#7-bitcoin-btc-bip-3944-technology-examples.


text:
What exactly is an address in bitcoin
Here is what I've understood of bitcoin:

Everybody has a public and private key.
If A sends bitcoins to B:

B is generating an address and sends it to A
This addresses are generated for each transaction.
A needs to sign something with his private key and B's address

Am I wrong?
If not, I want to understand how this address is computed.
I have read it is a kind of public key computed from private key. That's it? So we can have many public keys which match to a common private key?
I have also read the address is derived from the public key.

related: https://bitcoin.stackexchange.com/q/13059/5406

Everybody has a public and private key.

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

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

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

This addresses are generated for each transaction.

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

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

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

What is physically an address in bitcoin

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

You're right, but this is slightly more clear:

Everybody can generate an arbitrary amount of private-public keypairs.
For A to send bitcoins to B:

B generates a private key, and the corresponding public key, and its address and sends it to A
For every payment request, address reuse may be avoided for privacy reasons.
A has (at least) one Unspent Output (which is the reference to a previous transaction that sended coins to A).  A's public key matches his address, so with his private key he can sign a transaction saying "I own the coins, I spent them to B's address, which he can spend with his public key matching this address, after signing it with his private key"

An address consists of a checksum (extra few bytes to make sure if one makes a mistake while typing the address, the checksum won't be valid), the network byte (meaning "For use with the main Bitcoin network"), and the hash of a public key. (You can experiment with an example of a hash here. And why a hash is used in addresses)
For one to spend, the public key is revealed and its hash is compared with the address's, and then the signature is verified with the public key.
A private key always maps to only one public key. Usually, there's only one address we can derive from a public key. In reality, a public key is a point something called an elliptic curve. Because there are multiple ways to encode its coordinates, a public key can map to multiple addresses (not because of the hash. Hashing always gives one output)


text:
Generate public/private key for bitcoin with openssl
I want to understand how bitcoin works and I do not trust tools or bitcoin platforms.
I have read this on Internet. Can you confirm me this lines are generating a bitcoin public/private key safely ?
openssl ecparam -genkey -name secp256k1 -rand /dev/urandom -out tmp_private.txt
openssl ec -in tmp_private.txt -outform DER \
    | tail -c +8 | head -c 32 | xxd -p -c 32 > private.txt
openssl ec -in tmp_private.txt -pubout -outform DER \
    | tail -c 65 | xxd -p -c 65 > public.txt
rm tmp_private.txt

I know it is not a good thing to store private key in a basic clear text file, I just want to know if the way generating the key is good.
Is there an openssl command which can generate a bitcoin address from public.txt file?

Linux has shred which can be substituted for rm

Shred is notoriously  unreliable for this stuff - modern filesystems, especially those with copy on write, or even SSDs and some HDDs will often use different blocks to store the shredded data - in many cases, the original keys will still be recoverable if you use shred.

Yes, it's randomness is trustworthy, so it's safe.
The only problem I see is that "rm" does not remove all of its traces from the hard drive. The private key may be recovered. The pedantic way to erase such secrets is to use the Gutmann method which overwrites files 35 times.
To derive the address you need to use something like https://bitcoin.stackexchange.com/a/67093

The rm is not a problem for me i want to know if the previous lines are OK. The keys seems to be very small in fact...

Yes it's correct and safe. The rand /dev/urandom argument specifies the randomness source which is also used by a dozen of crypto(currency) software including Bitcoin Core.

The format written and read by most openssl commandline utilities, although it is textual in nature, is specifically PEM and usually named accordingly, not 'text' or 'txt' which can be (and frequently is) zillions of other formats that aren't PEM and wouldn't be usable here.
Some other things you can do with openssl that might help:
# instead of head/tail/etc you can use asn1parse -strparse to extract the private and public values
# but as raw/binary not hex:
$ openssl asn1parse <privpem -strparse 5 -out privraw >&/dev/null; od -Ax -tx1 privraw
000000 23 34 02 73 64 bb 35 79 f0 f5 25 76 f5 f9 5f df
000010 ff aa 94 d3 24 21 da c9 e3 2d 33 95 8b 8d 4f 1d
000020
$ openssl asn1parse <privpem -strparse 50 -out pubraw >&/dev/null; od -Ax -tx1 pubraw
000000 04 f8 04 f9 ea 79 7e 9b 07 89 e7 37 f2 76 c4 86
000010 16 17 f9 70 4e c4 67 ce 6e 64 ca 3a 5a bf 4d cb
000020 98 e1 11 0b 7a ec 40 f3 ea 32 d4 e9 6c 16 6e 14
000030 e3 77 15 1a 2e c2 81 a6 ed de f5 5c ed cb 10 26
000040 09
000041
# (the >&/dev/null discards error messages because the contents of these fields are not ASN.1)
# (or you can omit it and just ignore the messages)

# openssl ec -text directly displays (all) the fields of the PEM file,
# with the two you want in hex:
$ openssl ec <privpem -noout -text
read EC key
Private-Key: (256 bit)
priv:
    23:34:02:73:64:bb:35:79:f0:f5:25:76:f5:f9:5f:
    df:ff:aa:94:d3:24:21:da:c9:e3:2d:33:95:8b:8d:
    4f:1d
pub:
    04:f8:04:f9:ea:79:7e:9b:07:89:e7:37:f2:76:c4:
    86:16:17:f9:70:4e:c4:67:ce:6e:64:ca:3a:5a:bf:
    4d:cb:98:e1:11:0b:7a:ec:40:f3:ea:32:d4:e9:6c:
    16:6e:14:e3:77:15:1a:2e:c2:81:a6:ed:de:f5:5c:
    ed:cb:10:26:09
ASN1 OID: secp256k1
# you can then postprocess this data as desired,
# excluding the first line which is on stderr and not easily pipable, e.g.:
$ openssl ec <privpem -noout -text 2>/dev/null | sed -n 3,5p | tr -d ' :\n'; echo
2334027364bb3579f0f52576f5f95fdfffaa94d32421dac9e32d33958b8d4f1d
$ openssl ec <privpem -noout -text 2>/dev/null | sed -n 7,11p | tr -d ' :\n'; echo
04f804f9ea797e9b0789e737f276c4861617f9704ec467ce6e64ca3a5abf4dcb98e1110b7aec40f3ea32d4e96c166e14e377151a2ec281a6eddef55cedcb102609

# given the _binary_ publickey, as from asn1parse above,
# openssl can compute the address in _hex_ or binary
# but not base58check (or bech32) as often wanted:
$ openssl sha256 <pubraw -binary | openssl ripemd160
(stdin)= 149a326797fdfd3790fba8f82571fd5f569341cc
# for binary output add -binary to the second subcommand,
# and redirect to a file >outfile because it isn't displayable

# by default openssl creates an EC key in uncompressed form, but you can specify,
# or subsequently convert to, compressed; the asn1parse output depends on its input.
# The ec -text output can be converted in the same operation, e.g:
$ openssl ec <privpem -conv_form compressed -noout -text
read EC key
Private-Key: (256 bit)
priv:
    23:34:02:73:64:bb:35:79:f0:f5:25:76:f5:f9:5f:
    df:ff:aa:94:d3:24:21:da:c9:e3:2d:33:95:8b:8d:
    4f:1d
pub:
    03:f8:04:f9:ea:79:7e:9b:07:89:e7:37:f2:76:c4:
    86:16:17:f9:70:4e:c4:67:ce:6e:64:ca:3a:5a:bf:
    4d:cb:98
ASN1 OID: secp256k1
# shows the compressed pubkey regardless of whether the file was compressed
# and now you would select lines 7-9 instead of 7-11.

Yes, the script generates keys safely as it uses renowned OpenSSL. Note that other factors besides the tool contribute to the safety of keys generation, e.g. air-gapped computer without viruses etc.
The keys are not output in Bitcoin Wallet Import Format (WIF), though. They need to be converted in order to be used in Bitcoin Wallets. There is the script for the converstion: https://gist.github.com/GregTonoski/438992249df6e4bd613f9758421ff38a
There is the Seed Tool to generate Bitcoin address: https://bitcoiner.guide/seed/ (look for the "Single Signature Address" section).


text:
Get/Calculate Address
I'm currently using a program that analyses the block files. It splits all the stuff into multiple .csv files. Is there any method I can do to get the addresses & amount sent/received from tx_in and tx_out?

Can you explain what part is giving you problems? If your tx_out.csv already contains value and address and tx-in.csv already contains hashPrevOut (a txid value) and indexPrevOut (an indexOut value) - why is there a problem retrieving this? (apart from the huge inefficiency of CSV). IS the problem in parsing to CSV or in retrieving from CSV?

It's totally new for me. I want to get the address and value from tx_in.csv

Does this answer your question? Why not use address in raw transaction instead of public key bytes


text:
How to make a block explorer (like blockchain.info)?
I've tried JSON-RPC, but it's very slow. What other things can you recommend?

I think for something like blockchain.info, you'd need to write software to parse the blocks directly. You'd probably want a database of all the things you want to be able to search for, for quick lookups.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Accountability with Bitcoin transactions
In one of the comments to this question Highly Irregular pointed out an interesting legal issue that might arise with Bitcoin. Mainly, if some organisations use Bitcoin (say, Wikileaks) and are deemed illegal by some authority (say, the government of USA), and subsequently sending money to them could be deemed illegal, how would issues with unintentional donations be handled?
Say, someone convinces a person to send "them" Bitcoins, instead of providing them with an address of the illegal organisation. The victim performs the donation, and their support of the organisation is later revealed.
How would such a case be handled in court at the current date? Do you know of any relevant laws in say, USA, that would apply to such a situation?

You are not sending money to them. You are sending them bitcoins, which aren't money.

I am no lawyer, but as far as I know there is no specific precedent for this, or none that I could find anyway. Due to this, if you could reasonably prove that you had no intent in supporting that illegal organisation or group I don't see a strong case for any prosecution. Obviously there is a huge amount of grey area here, so what is "reasonable" would be up to interpretation. Also each country would have its own individual laws, which makes this even harder to give a specific answer.
If you are worried, I would recommend that you do two things. 1) Cover your ass by keeping all emails or any correspondence relating to your BTC transactions in a secure place. 2) You can also use tools like PGP, Hushmail, Cryptocat, Zfone, TrueCrypt and Tor to help protect your online anonymity.

In the United States, most criminal laws explicitly include one or more words which describe a guilty person's mental state at the time the crime was (allegedly) committed. Generally speaking, to commit a crime, the defendant must have intended to perform an/the act that constituted the crime.
So a prosecution for giving funds to Entity A would involve factual questions about whether or not the defendant knew that he was sending funds to A. The prosecution would probably introduce evidence that a wallet under the control of the defendant was used to send funds to A. This might be parts of the blockchain, or contemporaneous records like a "Thanks for your donation!" email, or pages saved in the defendant's browser's cache.
The defense would want to introduce evidence showing explaining what really happened (consistent with your "I was tricked!" hypothetical) - perhaps a copy of the webpage soliciting donations to Bitcoin address X, with pictures of cute puppies and kittens exhorting the viewer to donate to address X to buy food for the cute animals. Or maybe there's a solicitation for donations to a UN relief mission to help the starving children of region Y, but the address is really that of the Evil Turrurists. Or whatever. Since there's likely to be no significant dispute about who sent funds, or where the funds eventually ended up, the fight is going to be over what the defendant thought they were doing at the time the funds were sent.
In the US, the defense is allowed to not present evidence if they choose, and rely on the [in]sufficiency of the prosecution's evidence. So the defense could, if they chose, point out the possibility that the defendant didn't know who he was sending BTC to, or that he believed he was sending it to someone else. (* Also, include the standard dodge about "air guitars" and BTC's are fairy money and whatever.) In the real world, the "computers are mysterious; we don't know what really happened or who did it; the defendant should be free!" defense has been unsuccessful when applied to computer crime and pornography cases, so I don't think it'll be successful in the Bitcoin context, but there are always optimists.
NB - this means that it may be advantageous not to hide/destroy records your BTC transactions, in the event that you want/need to demonstrate that they were innocent.
I am not saying that this is how I think things ought to work - there is not much correlation between the way I wish that things worked and reality.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
How should one try verifying to whom a given Bitcoin address belongs?
Lets say, I'd have a website that shows a large number of Bitcoin public addresses, and wanted to give option for anyone that owns a given address to verify it automatically.
Assuming that one shouldn't trust anyone on the internet based just on their word, how should one go about verifying that a person owns a given address? (methods that can run autonomously, without admin input, are preferred)

The v0.5 client (still experimental as of time of writing) supports a function where you can sign a text message with a private key.
So you could:
a) have a "register" button next to the address.
b) provide the user a message to sign which includes some identifying information (account name, email address, etc) and the address.
c) user will run bitcoind signmessage  ""
d) this will sign the message with user's private key.
Only a user which has access to the private key that corresponds to the address in question will be able to generate the correct signature.  Think of it as similar to a Bitcoin transaction but it isn't published to Bitcoin network and involves any text message.
Eligius uses this method to link NMC payment addresses to BTC payment addresses for his pool.
http://eligius.st/
Obviously this will have more value once Bitcoind v0.05 is publicly released.

That is a cool feature. Is there also the "opposite" (encrypting a message with someone else's public key)? The public key cannot be derived from the bitcoin address, but it is included in the block chain once that address has been used, so such a function could be used to send confidential messages to someone that has sent you (or anyone) bitcoins before.

@Thilo I don't know if that functionality is currently included but if not there is no reason it couldn't be included in future version.  Signing a message is simply encrypting a hash of the message with the private key (so it can be decrypted w/ public key and verified).  If that can be done encrypting entire message w/ public key (so it can be decrypted w/ private key) is certainly possible.

For RSA, it is true that signing equals "encrypting with the private key"; this is, however, not the case for DSA-based algorithms like ECDSA. Except for the wallet encryption added in v0.4.0, bitcoin does not employ encryption anywhere.

There are some other suggestions as to how this can be done without the "sign a message" feature coming in v0.5.
 - http://forum.bitcoin.org/index.php?topic=4411.0
One suggestion was to receive a trivial but unique amount and then send that same amount back to the sender.  Awkward, but possible.


text:
Bitcoin client incentives to share peers and blockchain
Question a bit related to Microsoft's research on incentives of sharing transactions.
What is the incentive for a custom-tailored Bitcoin client to share information regarding known clients and the existing blockchain? For example, the client could set its "services" in "version" message to 0 and not be bothered with sharing much data. What encourages the Bitcoin clients, asides common curtsey from the people running the software, to share the data?

Is this question really different than the question you linked to?

When you send out transactions, you want to get to as many peers as possible so they would be included in the block. Sharing peers and blocks takes more bandwidth and computing power, while the return of doing so for you is not too clear.

If data is not shared, Bitcoin won't work. So the people who want Bitcoin to work and be useful share the data. If there aren't enough people who want Bitcoin to work and be useful, then it doesn't matter whether anyone can get the data or not.

Bitcoin users want to get information about their own transactions transmitted quickly and generally want to see Bitcoin succeed, and sharing the load of publishing transactions on the p2p network is courteous and the default; it would take a really selfish person to hack and compile Bitcoin so it took but didn't resend transaction data or Bitcoin blocks.
The paper refers more to a barely-possible attack where a miner or mining pool might get more transactions (and the associated fees) included in blocks they solve if they were to not broadcast those transactions to others.


text:
"State of the Coin 2012" and the mention of Satoshi Dice
Jeff Garzik in his presentation "State of the Coin 2012" put the following slide:

Bitcoin development
Like trying to fix and upgrade a car,
While the car is going 100 m.p.h.,
With users fighting over the driver's seat,
Including one big burly driver named
SatoshiDice,
All of whom do not really listen to the mechanic,
Who will lose all their money if the car crashes.
And this is what we call fun!

What did he mean by that reference to SatoshiDice? I wouldn't want to not get any possible jokes, hints or allegations ;).

There was a very controversial and heated discussion among developers and on forum started by Matt Corallo: Huge increase in satoshidice spam over the past day. Essentially he proposed to police transactions priority for block inclusion to punish websites which doesn't take measures against overburdening Bitcoin Network.
It's worth to note that SatoshiDice by no means was trying to DDOS Bitcoin Network. The amount of transactions is the result of its successful business model and somewhat careless implementation.
Personally I think SatoshiDice is a very good thing, it pushed Bitcoin Network to its limits, but not to the point where it could become dysfunctional. SatoshiDice revealed that network's choke point was disk access time to verify transactions rather then ECDSA verification time. As far as I know LevelDB implementation to store transactions history to reduce disk access time was the direct result of SatoshiDice spam. It is also accelerated development of Ultra Prune method to reduce storage requirements.

If I can comment as the one who is working on "ultraprune": these are developments that would have happened anyway, though potentially only later. The sudden increase of transactions on the network (and lack of corresponding economic activity) means we had to shift priorities, and are potentially losing users or at least losing full nodes on the network due to the unexpected burden. It is not necessarily a problem, but a less sudden growth might have made things a lot smoother for everyone.


text:
How to access any transaction detail in Bitcoin version 0.8 and above?
Since the Standard Client version 0.8 removed the full index of all historical transactions, some Bitcoin applications that relied on that functionality have stopped working. For example, one is no longer able to find out the sender of a given transaction by pure RPC calls. How can one access that transaction detail in the newer versions of the Bitcoin client?

You cannot find the sender of a transaction in any case. You can find the addresses the input coins were previously sent to, but that is not necessarily the sender of the transaction, and not useful in general.

Two new command-line or bitcoin.conf file commands have been added in the 0.8 release that allow for historical transactions to be accessible by recreating the old index:

txindex : maintains an extra index of old, spent transaction ids so they will be found
  by the getrawtransaction JSON-RPC method.
reindex : rebuild block and transaction indices from the downloaded block data.

[...]

you must run once
  with -txindex=1 -reindex=1 to rebuild block-chain indices

How do I make sure the Bitcoin client maintains this transaction index always even when it frequently synchronises and download new blocks?

@Myth17 I think it keeps the index after you set the index flag.

I am facing issues with raw transactions even after with flags set: http://bitcoin.stackexchange.com/questions/17451/getrawtransaction-in-bitcoin-qt-0-8-5


text:
bitcoind: incorrect rpcuser or rpcpassword (authorization failed)
The host system is Linux Debian Stretch (9 / testing).
The Bitcoin Core package for Linux I have just downloaded and verified and installed.
I have created the following file:
/home/myUsername/.bitcoin/bitcoin.conf

With contents:
listen=1
server=1
rpcuser=myUsername
rpcpassword=myPassword
rpcport=8332
rpcconnect=127.0.0.1

Then I have punched the following holes to my firewall:
sudo iptables -A INPUT -p tcp -m tcp --dport 8333 -m comment --comment "Bitcoin Listen" -j ACCEPT

sudo iptables -A INPUT -p tcp -m tcp --dport 8332 -m comment --comment "Bitcoin RPC" -j ACCEPT

And forwarded the 8333 port from my router to the server.
I am unsure whether the second hole is necessary for RPC connections, but that's not the question now.

If I now run the following command as my regular user:
bitcoind -daemon -datadir=/raid1a/bitcoind/

It says:

Bitcoin server starting

I wait for a few minutes for it to initialize and then invoke:
bitcoin-cli getinfo

With the result:

error: incorrect rpcuser or rpcpassword (authorization failed)

I have a very long and complex password, could that be the pickle?
The debug log says only:

ThreadRPCServer incorrect password attempt from 127.0.0.1:someport

Despite I run both bitcoind and bitcoin-cli as the same user, it for some reason fails to find my personal config file located in standard location:
$HOME/.bitcoin/bitcoin.conf

So I have set up an alias:
bitcoind -daemon -datadir=/raid1a/bitcoind/ -conf=/home/user/.bitcoin/bitcoin.conf

Case solved.


text:
Multisig where one of the keys specifically is required?
Is it possible to make a multisig wallet that requires one of the keys specifically and any of the other ones in order to sign a transaction?
For example, let's say I have a 2-of-3 multisig that has signators A, B, and C. Can I make a multisig that requires that every transaction be signed by A specifically and then one of either of the other keys?

why does this have the nbitcoin tag? looks unrelated

No, but instead you can make a 3-of-4 multisig where you hold both keys A and B, then you give key C to a family member, and D to someone else(just as an example). This way you are certain that you are involved in all transactions. I presume this is the end result you are after?

That works and makes sense.

no need the "D" key. just 3-of-4 of (A+A+B+C)

ahh, very clever amaclin

@amaclin Are you saying that sets of private keys in a multisig definition are not required to be unique? Is there is no limitation with regard to repeating a set of private keys in a multisig definition? So with a 3 of 4 wallet, A and B can both be the same set of private keys?

Yes, both of these policies achieve what you are trying to do.
thresh(2,pk(A),or(pk(B),pk(C)))
thresh(2,pk(A),thresh(1,pk(B),pk(C)))
Each of them use thresh() as defined here:

thresh(NUM,POL,POL,...): Require that NUM out of the following subpolicies are met (all combinations are assumed to be equally likely).

This link is broken. I am trying to setup a multisig wallet using Sparrow. I have tried entering these definitions in the Script Policy Description field but it is throwing an "Invalid output descriptor" error.

There is another solution but it removes the ability to identify who signed the second transaction.
Create a 2 of 2 multisig wallet in Electrum. The first signature is yours. The second signature is done via a hardware wallet like Trezor. Clone that Trezor as many times as you want with the recovery seed.


text:
Requesting Blocks
I've been thinking about this for a while and can't seem to understand part of the network.
Lets assume that I'm a node that has been offline for 5 months and I want to retrieve the new blocks. When I broadcast the getblocks message different nodes see it, do all of my peers respond or do some of them respond and the others ignore it because of the other responses? And if they all respond back, would my node then choose which one/ones it wants to get the data from, or would it get the data from all of them? If it gets the data from all of them then wouldn't that slow the system down a lot and create a lot more traffic on the network?

A node does not know about the other nodes that one of their peers are connected to. They will respond with whatever your node requests from them, even if this ends up being duplicate blocks.
Because network connections are direct streams, your node knows exactly what it has sent and received to and from each of its peers. So your node will choose the peers it wants to download blocks from and send them specific requests for those blocks. Since Bitcoin Core uses headers first sync, there is no need to just send a getblocks message; instead it can use getdata messages to request specific blocks and spread out the download over multiple peers.
In previous versions of Bitcoin Core, it would choose one node to sync off of and download all of the blocks from just that node. However this behavior is no longer done, although it is still part of the protocol and can still be done.

So it basically gets the responses from all of the other nodes and then processes them into a chain for itself? Wouldn't that cause a lot of traffic?

No, it does not cause a lot of traffic. There are not duplicate responses from each node because your node ensures that there are no duplicates by not requesting the same data from different nodes.


text:
WSL PATH command help
Following these intr: https://github.com/bitcoin/bitcoin/blob/master/doc/build-windows.md I have retrieved a git for a crypto. But I am hung up on the step where I add the PATH command. Per the instr:
PATH=$(echo "$PATH" | sed -e 's/:\/mnt.*//g') # strip out problematic Windows %PATH% imported var.

I am unsure of what to place in this command. But obviously need to put a correct file location for my git? Any help appreciated.

It is a command that you enter into the command prompt. This isn't a file or something that you have to add to a file, just type it (or copy and paste it) into the command prompt once the bash shell is running.


text:
who actually amasses or builds the blocks ... and how do they get passed to miners?
The question is not about the block being included on the block chain, but
who actually creates a block? Like what is the process here.
Can someone walk me through this? I do know that blocks are summarized in form of a block header and contain a list of transactions.

Who selects the transactions to go into this block? If not a person, where in the Core is this included
How do they then get bundled as a block?
How do they get passed on then to the miners?

Who selects the transactions to go into this block? If not a person, where in the Core is this included

Miner select them. More specifically, node software that miners run select the transactions. Most miners use Bitcoin Core or some variation of it.

How do they then get bundled as a block?
How do they get passed on then to the miners?

When the node software selects transactions, it creates a hexadecimal string for each transaction that represents each of the fields. That hex string follows the same format used for serializing transactions for sending over the network, just as the hex representation of the bytes instead of the bytes themselves. This is then packaged together with some other information into a JSON object in the getblocktemplate format and provided over a JSON-RPC interface to mining software.
The mining software then takes the information provided by getblocktemplate, adds their own additional information (e.g. the nonce) and constructs a serialized block. Serialized blocks are byte arrays containing all of the information in a block and are the same format as sent over the network. If the block is valid, the miner sends the serialized block back to the node which then sends it to the rest of the Bitcoin network.

Here is a step by step example of how a miner Alice mines a block.

Alice runs Bitcoin Core which constantly receives, validates, and relays transactions and other blocks.
Alice runs a mining software (such as cgminer) and connects here hashing machines (e.g. an Antminer S9) to that.
Alice also provides to her instance of cgminer the credentials to the JSON-RPC interface for her Bitcoin Core node.
cgminer will use getblocktemplate and send a request for a block template to Bitcoin Core.
Bitcoin Core receives the getblocktemplate request and chooses transactions from its pool of valid and unconfirmed transactions that it has stored in memory. The transactions are typically selected by their fee rates, highest fee rate being selected first.
Bitcoin Core constructs a block template using the selected transactions and adds any additional information required.
Bitcoin Core responds back to cgminer over the JSON-RPC interface with the completed block template.
cgminer receives the block template and uses it to construct a serialized block header in a form that is acceptable to the hashing hardware
cgminer sends whatever data it has serialized to the hashing hardware and the  hardware computes SHA256 hashes on it while incrementing some data in the data.
The hashing hardware (or cgminer) checks whether a hash has a valid proof of work. If it does, skip to step 14.
Once the hardware exhausts all possible combinations it can try using the data given and responds back to cgminer
cgminer, when the hashing hardware can no longer continue with its data, sends another getblocktemplate request to Bitcoin Core for a new set of transactions and block data to try.
Repeat steps 4 through 12 until the hashing hardware finds a hash with a valid proof of work in setp 10.
Once a hash with a valid proof of work has been found, cgminer takes the data that was hashed for that valid proof of work and combines it with the serialized transactions.
The serialized block is converted into a hexadecimal string and sent to Bitcoin Core using the submitblock RPC command.
Bitcoin Core takes the hexadecimal string representing the block, converts it into a byte array, checks that the block is valid, and if it is, sends the block to the nodes that it is connected to.

+1 for extensive. you seem to know more than you should. But one more thing. How do these bundled blocks get propagated throughout the network to other miners ? how is it made sure that some of the transactions aren't part of other blocks ?

@FrankL The block gets propagated through the network in a peer-to-peer fashion. Eventually they will get to the miners. When a miner receives the block it will place it to the top of his chain. After that he would exclude the transactions already included to the new block when he tries to mine the next block because otherwise it would constitute a double spend and the block would be invalid (other nodes would reject it)


text:
How to size in bytes for a transaction using BitcoinJ
The calculation of a transaction fee uses fee/kb. So how do I get the size in bytes for a transaction using BitcoinJ?
SendRequest req = SendRequest.to(address, value);

req.feePerKb = Coin.parseCoin("0.0000100");

Wallet.SendResult result = kit.wallet().sendCoins(req);

You cannot know the size in bytes of a transaction without knowing the inputs to the transaction. Just knowing the amount you want to transfer and just the output does not tell you anything.
Using the sendCoins() method and setting feePerKb in your SendRequest should create a transaction that pays the specified fee rate. If you want to get the transaction details after you send, the SendResult that you get has a field named tx which is a Transaction object. You can then get the necessary information from there.
If you want to know the size before you send, then you need to craft the transaction yourself as sendCoins() will automatically create and send the transaction for you.

Thank you for the answer, So my next question is how should I know the fee per kb for a transaction.For example if transaction is 2.0 BTC and fatest fee is 240/kb so how much in total fee I should include. @Andrew Chow

As I said in my answer, you need to know the size of the transaction, which can only be known after inputs are selected.

AFAIK, the fee is .001 BTC/kb and more the miner fee, the faster it gets confirmed.

Median transactions are of sizes 226b, which is approx 24000 Satoshi


text:
Displaying price in BTC based on USD exchange rate
This is a pretty classic programming question, but I think it is a very common one for the Bitcoin community, and would be helpful to have the code publicly available.
My preference is for a php script.

Bitpay publishes it's exchange rates here: https://bitpay.com/api/rates
If an item is $10 USD, how would I do the following?
1) extract the BTC/USD exchange rate from the array at this URL
2) Define the price, then divide by the exchange rate
3) Display the BTC price in an HTML page?

May be useful psp(python) example:
<%psp
import urllib2;
import simplejson as json;
j = json.loads(urllib2.urlopen("https://data.mtgox.com/api/2/BTCUSD/money/ticker").read());
%>

<%=str(j["data"]["last"]["value"]) %>

Or one command line:
# /usr/bin/python -c 'import urllib2; import simplejson as json; j = json.loads(urllib2.urlopen("https://data.mtgox.com/api/2/BTCUSD/money/ticker").read()); print str(j["data"]["last"]["value"]);'

Since Mt. Gox is down and the market is split, I would suggest using blockchain.info's API. I believe they combine different current market prices to make one average price. This is much more reliable than trusting one market only (see what happened to Mt. Gox). Also blockchain.info is a generally well trusted site.
To load the information in PHP use the file_get_contents() and json_decode() functions. Most of these functions are available in other high-end programming languages.

Here is an example that retrieves the current current values from the json stream at mtgox (current, low, average, last, and now).   It is written in python, but should be very easy to port it over to the language of your choice.
#https://github.com/spudstud/alfred-bitcoin-workflow

     #json is the standard python json parser
     #urllib2 is a webpage fetching library
import json
import urllib2

#The url that provides the raw json stream
url="http://data.mtgox.com/api/2/BTCUSD/money/ticker"

#Open the url and turn it into an string containing the json
jsonURL=urllib2.urlopen(url)

#Convert the json text into a json object
jsonObject=json.load(jsonURL)

#Parse the desired values out of the json object
currentValue    = jsonObject['data']['high']['display']
lowValue        = jsonObject['data']['low']['display']
avgValue        = jsonObject['data']['avg']['display']
lastValue       = jsonObject['data']['last']['display']
nowValue        = jsonObject['data']['now']

#Sometimes your json is not a string,you will need to use json.load, not json.loads:

print jsonObject
print currentValue
print lowValue
print avgValue
print lastValue
print nowValue

An older, maybe somewhat wiser me, answering my own question:
Here's some PHP to get the exchange rate.
<?php

$page = file_get_contents('https://bitpay.com/api/rates');
$my_array = json_decode($page, true);
$exchange_rate = $my_array[0]["rate"];

?>

I eventually found it easiest to do in javascript, since you're going to want to display the price as well.
Anywhere you have an element with `class="price", this will add the mBTC equivalent next to it. Tweak to your liking.
$(document).ready(function(){
  $.getJSON('https://bitpay.com/api/rates', function(data){
    var rate = data[0].rate;

    $(".price").each(function(i){
      var tex = $(this).text();
      var usdPrice = Number(tex.replace(/[^0-9.-]+/g,""));
      var mbtcPrice = 1000*usdPrice/rate;
      $(this).append("( ~" + String(mbtcPrice.toFixed(0))+ " mBTC)");
    });
  });
});

Here's a bash command that gets the spot price from the Coinbase API (TM). It pipes the response to jq, which parses it and outputs the value(s) specified in the filter passed to it. -r strips the quotes from its output, which is passed to sed. sed processes the first 4 digits of this output, inserting a thousands comma and dollar sign. Note that it only works for 4-digit numbers (so will need to be modified shortly, replacing the '1' with a '2' ;-) The output redirection 2>/dev/null hides the curl curses interface:
curl --insecure https://coinbase.com/api/v1/prices/spot_rate 2>/dev/null | jq -r '.["amount"]' | sed 's/\([[:digit:]]\{1\}\)\([[:digit:]]\{3\}\)/\$\1,\2/g'

As bitpay make some update, this code allows you to be already setup
<?php $url = "https://bitpay.com/api/rates";
$json = file_get_contents($url);
  $data = json_decode($json, TRUE);
for ($i=1; $i <20 ; $i++) {
    if($data[$i]["code"]=="USD")
        $rate = $data[$i]["rate"];
}
    $usd_price = 10;     # Let cost of elephant be 10$
  $bitcoin_price = round( $usd_price / $rate , 8 );?>

Price: <?=$usd_price ?> $ / <?=$bitcoin_price ?> BTC

Hey I know this thread is 3 years old but anyway I used some of the code on this page to do my script because i couldn't make the code here to work...
import json
import urllib2

url="http://api.coindesk.com/v1/bpi/currentprice/EUR.json"

jsonURL=urllib2.urlopen(url)

jsonObject=json.load(jsonURL)

print jsonObject['bpi']['USD']['code']
print jsonObject['bpi']['USD']['rate']

Hope this will help future visitors.

<?php
$url = "https://bitpay.com/api/rates";
$json = file_get_contents($url);
$data = json_decode($json, TRUE);
$rate = $data[0]["rate"];
$rate1 = $data[1]["rate"];
$rate2 = $data[2]["rate"];
$rate145 = $data[145]["rate"];
?>
BTC/USD: <?=$rate?>

BTC/EURO: <?=$rate1?>

BTC/GBP: <?=$rate2?>

BTC/VND : <?=$rate145?>

I edited the code from first answer and this one is work well


text:
Exception CompactSize when I parsing the blk file >= 976
I wrote a bitcoin core parser, for my personal project and because it helped me to start understanding the bitcoin protocol as a data structure.
This project mainly parsers every blk file and creates the corresponding json with the deserialized information.
I launched the alpha version of the project and actually parserizes the information and converts it into a json file, my application worked fine until the blk file number 976, where I get an exception from the blockchain library and precisely in the ReadCompactSize operation, the exception is of the type
unknown file: Failure
C++ exception with description "ReadCompactSize(): size too large: iostream error" thrown in the test body

I used the bitcoin core libraries for example serialize.h
I don't understand why this error only comes up to me after blk00976 blochi and for all the subsequent ones I tried also with the file blk00977 blk01124
I have some posts I have consulted and others where I asked about this problem, now I was opening an issue on github for bitcoins but there it is written that for general questions you have to refer here.
The questions I have read but do not solve the problem
How to handle incomplete blocks when reading blk*.dat files?
My question
https://bitcointalk.org/index.php?topic=5134784.msg50723554#msg50723554
My source code
https://github.com/vincenzopalazzo/SpyCblock
Two words about the source code
I am a java programmer dealing with the bitcoin protocol and I decided to carry out the C ++ project to study the language too, so to those who linked the code I apologize if it looks like an offense because it is badly written but I am studying to refact and improve the performance of the parser but also the quality of the source code.

Does your code support segwit? (BIP144)?

The BIP144 is this right? Click me     I don't think my code supports it, I didn't know it existed, so is this the reason for the error?
Can you give me more information about this? why was a new type of serialization introduced?
This type of serialization is valid only for transactions (input and output) or even raw transactions and blocks ??

It was part of the segregated witness upgrade, which was a major upgrade to Bitcoin's technology. It affects a lot (P2P protocol, signatures, transactions, ...). You can read more about the reasons for it and design here: https://bitcoincore.org/en/2016/01/26/segwit-benefits/ and https://bitcoincore.org/en/segwit_wallet_dev/ More about the history here: https://bitcoinmagazine.com/articles/long-road-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality/ Currently around half of the transactions on the network use segwit features.

So the serialization types are mixed? or are they all fulfilled in the way you said?

Segwit is designed so it uses an otherwise invalid encoding, so it can be detected. It isn't so much a mix of formats; the new format is an extension of the old format; but the blk files indeed contain blocks with witnesses and without.

excuse the constant questions, what can a block with a witness be re-scanned?  from the transaction version?  as soon as I'm at the pc, I'll read your references thanks again

Read the references, and BIP144 specifically.


text:
BIP 32 Private keys to be imported into HSM
Could someone explain to me how the import of private key in HSM works? Below is the information from the manual:

Private Key Import/Export
Private keys can be imported and exported
with existing PKCS#11 functions. They can be imported and exported
only if the HSM uses the key wrap model instead of cloning. Import a
key by calling C_Encrypt*() on the serialized key followed by
C_UnwrapKey(). Exporting keys by calling C_WrapKey() followed by C_ Decrypt*(). Use C_WrapKey() and C_UnwrapKey() to store keys off the
HSM, or to move them between HSMs.

What key is used for the wrap?

I assume this is to do with Thales SafeNet Luna Hardware Security Module?

yes , it is the SafeNet Luna HSM


text:
How do I get a full transaction index with Bitcoin Core?
How can I sync bitcoin full node so that I can access all details of transactions occurring on other nodes and other wallets also, like blockchain.info.
I have synced a full node using below commands, but that's giving details of node wallet account details.
sudo apt-add-repository ppa:bitcoin/bitcoin
sudo apt-get update
sudo apt-get install bitcoin-qt
sudo apt-get install bitcoins

The commands you have used are not for syncing to the bitcoin blockchain but to install a bitcoin, now with this client you can sync if you want, you will need days or weeks depending on your computer bandwidth and performance and 250+ giga of hard drive, you can start syncing by locating your bitcoin directoryand simply running:

./bitcoind

You can find more information about using and running properly a bitcoin full node here: https://bitcoin.org/en/full-node

after all this command i set up my bitcoin.conf file and started bitcoin demon.but still not getting details of transaction outside of node.

error code: -5
error message:
Invalid or non-wallet transaction id```

@indrajit Command gettransaction is for the transaction of your wallet, you can access to all transaction on bitcoin with command getrawtransaction, I suggest you look the documentation official of Bitcoin corer RPC

Notice that gettransaction is for in wallet transaction, maybe you want to use getrawtransaction also you have to have txindex=1 in your conf file and need to sync the full blockchain

yes getrawtransaction is working,but how to find to address, from address and amount transacted from that .

        var transaction = client.request("getrawtransaction", [txHash,true])
        transaction.then((details) => {
            console.log("detailsrtry", details.result);
            var decode = client.request("decoderawtransaction", [details.result.hex])
            decode.then((rrrrr)=>{
                console.log("details", rrrrr.result.vin)
                console.log("details1", rrrrr.result.vout);
            })
        }).catch((err) => {
            console.log("err",err);

        })
    }```

You cannot do that with a bitcoin client, you should use https://btc.com/ see this question and the answers https://bitcoin.stackexchange.com/questions/5555/is-it-possible-to-view-others-transactions-in-bitcoin-client

so how blockchain.info gives all details to address from address and amount of transactiom

I suppose they record every transaction from every blocks and trace every one of them, it is quite fastidious, you can build your own system for doing the same if you want https://bitcoin.stackexchange.com/questions/5518/how-do-i-access-information-on-blockexplorer-com-or-blockchain-info-without-issu/5519#5519


text:
Why is Bisq suddenly acting up and refusing to let me withdraw my coins?
Bisq: v1.2.7 (latest).
I've used it (with this same account) numerous times in the past without problems, in the exact same way.
Now, after I have completed a trade, and try to withdraw the coins to my "external" wallet (local Bitcoin Core on the same computer), it just goes:

Warning
The fees for that transaction exceed the available funds or the
  resulting output value is below the min. dust value:
Missing 0.115 BTC
[CLOSE]

I can't choose to ignore it, in spite of it being a "warning" and not an "error". It just lets me close the GUI box and nothing else. I have no idea what it's even talking about. That "missing" amount is the entire, exact amount I have in Bisq...
What is going on?!

Have you tried recovering the wallet from seed phrase into another program like Electrum and sending the coins from there?

I have no idea what it's even talking about.

When you make a transaction on the Bitcoin blockchain you normally need to include a mining fee to reward the miners for including your transaction into a block they mine which gets added to the blockchain.
When you construct your transaction, the software you are using (whatever Bisq provides) may select a fee automatically or may allow you to specify a fee. If your transaction is for the whole balance of your Bisq account, the mining fee must be deducted first.
For example, if you have 100 balance available and the appropriate mining fee is 1, you can only transfer 99 to your "external" wallet.
The message is a little imprecise, it might mean you tried to transfer 0.001 with a fee of 200 (clearly a terrible mistake). It might mean you tried to transfer 0.000000000001 with a fee of 99.999999999 where the first amount is smaller than the smallest amount economically possible in Bitcoin. See dust. It might mean you tried to transfer 100 with a fee of 1. It might mean your balance is a lot lower than you think it is.
(note: the amounts above are random illustrative placeholder amounts and are not realistic)
It is also possible, on some exchanges, for some or all of your balance to be tied up in trading orders that are not yet fulfilled.
If this happened to me, I would contact Bisq's customer support.


text:
Failing to send a testnet transaction manually
I use Ken Shirriff's post on how to manually create and send a transaction, and I tried to adjust it to work with testnet.
AFAIK after adjusting to the testnet addresses, no further adjustments should be made in the tx creation and signature process.
However, my transaction does not work...
I successfully connect to peer 185.28.76.179:18333, send the transaction but nothing happens.
What should I do to figure this out?
Here is the raw tx:
010000000142ad1ac9d0214d326a9f5f4e0051bb6f0e197bb7bf0661266623f865a1a38d10000000008b4830450221008e434d7e6e0dc3741d99142b1fdb3a6eeba7a6d1d1e95e1aa90dcb638fc17c7b0220179a9004bac06ac64914af1e9f29db3a7cb50942bf3e865a23727151f3bbd6330141047bc52c13eacc1adcb1eea06317760537947d67a9208351e4c213bed82f0ce843249c9675e5f28ca4b0848036118a43defa8b6c5d5d77250ac8709eca8f88e30bffffffff017b000000000000001976a9149437a39c0ddd64205002c3f9adda6bb77df1be8288ac00000000

I forgot to mention that I use version 60002 of the protocol.

What do you mean by "nothing happens"? Do you not see the transaction on a block explorer? What are you expecting to happen?

I don't see the transaction on block explorers, do I guess it was dropped by the peer.


text:
How do I get back into my bitcoin core wallet JSON format no data file
I had 2 wallets long time ago mined on bitcoin core can’t remember JSON that well or what my wallet descriptors was. I did use bip 39 but not giving me my addresses back on electrum wallet please help I have a p2pkh

There’s other ways in I just don’t remember right off hand yet. But I do know I might of backed it up on blockchain but it’s been along time ago and don’t remember the steps

Bitcoin Core wallet JSON Format

Are you sure it was Bitcoin Core? Bitcoin Core doesn't store the wallet in JSON format, it typically stores wallet data in a file named wallet.dat which has a non-text data format (Berkeley DB, but some other data files are LevelDB). See What do the different .dat files contain?
You can produce JSON output from Bitcoin Core's command Line Interpreter (CLI) but that wouldn't be an actual wallet.
There are other wallet programs that store wallet data in JSON. For example version 2 of Electrum.

I did use bip 39

Bitcoin Core does not support BIP 39 - See Is there a reason to why Bitcoin Core does not implement BIP39?
Early versions of Electrum had a different seed-phrase system but you can use BIP 39 with current versions of Electrum so long as you first tell Electrum that the seed-phrase uses the BIP 39 system.
You can check your phrase against various word lists to help identify it. See Identify Wallet based upon word phrase

not giving me my addresses back on electrum wallet

You also need to make sure you are using the same "derivation path" that the original wallet used. See Default derivation paths
You might also need to increase the "gap limit". See Bitcoin address gap limit

I might of backed it up on blockchain

If you mean the blockchain.com business, You'd have to talk to them about recovery. See 16 word recovery phrase for blockchain wallet not working as well as I have forgotten my Blockchain account password and 12 word recovery. I have the wallet id and password to the wallet. Can i get my funds back?

If you only have the P2PKH (the public address) you won't be able to access it anymore.
Bitcoin Core stores wallet information in a .dat file. If you retrieve this file you could restore it in a fresh Bitcoin Core installation. The .dat file is located in "Bitcoin Core installation folder/YourWalletLabel/wallet.dat".
If you uninstalled Bitcoin core a while ago and didn't save that anywhere, I'm afraid the account is forever lost.


text:
Bitcoin Core keeps "quitting unexpectedly" or hangs up with the rainbow swirls on my Macbook Air + External SSD
I'm running V.20.1 Bitcoin Core on a Mac Book Air. Using an external SSD that's connected via USB C.
In the middle of syncing - at random points in time the Bitcoin Core app "quits unexpectedly". No idea what the cause is. Also random instances of the program hanging with the rainbow swirls. Seeing the error message below. I've already tried deleting the chainstate folder to reindex from the beginning, that hasn't worked.
Seeing this from the debug log:
2020-11-26T02:34:13Z LevelDB read failure: Corruption: block checksum mismatch: /Volumes/My Passport/Core/chainstate/031900.ldb
2020-11-26T02:34:13Z Fatal LevelDB error: Corruption: block checksum mismatch: /Volumes/My Passport/Core/chainstate/031900.ldb
2020-11-26T02:34:13Z You can use -debug=leveldb to get more complete diagnostic messages
2020-11-26T02:34:13Z Error: Error reading from database, shutting down.
2020-11-26T02:34:30Z Error reading from database: Fatal LevelDB error: Corruption: block checksum mismatch: /Volumes/My Passport/Core/chainstate/031900.ldb

Seeing the below from my system:
Process:               Bitcoin-Qt [15232]
Path:                  /Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt
Identifier:            org.bitcoinfoundation.Bitcoin-Qt
Version:               0.20.1 (0.20.1)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Bitcoin-Qt [15232]
User ID:               501

Date/Time:             2020-11-25 18:42:07.295 -0800
OS Version:            macOS 11.0.1 (20B29)
Report Version:        12
Bridge OS Version:     5.0.1 (18P2561)
Anonymous UUID:        B8752D10-676E-40B9-77CA-DB75279771FD

Sleep/Wake UUID:       02EFAD81-0B12-45C3-8DB0-128B48C3FA3A

Time Awake Since Boot: 14000 seconds

System Integrity Protection: enabled

Crashed Thread:        9  b-loadblk

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
abort() called

Thread 0:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib          0x00007fff202e48e2 __psynch_cvwait + 10
1   libsystem_pthread.dylib         0x00007fff20316e6f _pthread_cond_wait + 1254
2   org.bitcoinfoundation.Bitcoin-Qt    0x00000001106dfb1b 0x10ff80000 + 7731995
3   org.bitcoinfoundation.Bitcoin-Qt    0x00000001106dfaac 0x10ff80000 + 7731884
4   org.bitcoinfoundation.Bitcoin-Qt    0x00000001106df56e 0x10ff80000 + 7730542
5   org.bitcoinfoundation.Bitcoin-Qt    0x000000010ffafb19 0x10ff80000 + 195353
6   org.bitcoinfoundation.Bitcoin-Qt    0x000000010ffafcfc 0x10ff80000 + 195836
7   org.bitcoinfoundation.Bitcoin-Qt    0x000000010ff957e3 0x10ff80000 + 88035
8   org.bitcoinfoundation.Bitcoin-Qt    0x000000010ff96f50 0x10ff80000 + 94032
9   libdyld.dylib                   0x00007fff20331631 start + 1

Thread 1:: com.apple.CFSocket.private
0   libsystem_kernel.dylib          0x00007fff202ea1fe __select + 10
1   com.apple.CoreFoundation        0x00007fff204356b3 __CFSocketManager + 644
2   libsystem_pthread.dylib         0x00007fff20316950 _pthread_start + 224
3   libsystem_pthread.dylib         0x00007fff2031247b thread_start + 15

Thread 2:: b-qt-init
0   libsystem_kernel.dylib          0x00007fff202e84fe poll + 10
1   org.bitcoinfoundation.Bitcoin-Qt    0x0000000110834d40 0x10ff80000 + 9129280
2   org.bitcoinfoundation.Bitcoin-Qt    0x0000000110836167 0x10ff80000 + 9134439
3   org.bitcoinfoundation.Bitcoin-Qt    0x00000001107fb65f 0x10ff80000 + 8894047
4   org.bitcoinfoundation.Bitcoin-Qt    0x00000001106db77c 0x10ff80000 + 7714684
5   org.bitcoinfoundation.Bitcoin-Qt    0x00000001106de900 0x10ff80000 + 7727360
6   libsystem_pthread.dylib         0x00007fff20316950 _pthread_start + 224
7   libsystem_pthread.dylib         0x00007fff2031247b thread_start + 15

Thread 3:: com.apple.NSEventThread
0   libsystem_kernel.dylib          0x00007fff202e1e7e mach_msg_trap + 10
1   libsystem_kernel.dylib          0x00007fff202e21f0 mach_msg + 60
2   com.apple.CoreFoundation        0x00007fff2040ebe7 __CFRunLoopServiceMachPort + 316
3   com.apple.CoreFoundation        0x00007fff2040d2ba __CFRunLoopRun + 1315
4   com.apple.CoreFoundation        0x00007fff2040c6be CFRunLoopRunSpecific + 563
5   com.apple.AppKit                0x00007fff22dac36d _NSEventThread + 124
6   libsystem_pthread.dylib         0x00007fff20316950 _pthread_start + 224
7   libsystem_pthread.dylib         0x00007fff2031247b thread_start + 15

Thread 4:: b-scriptch.0
0   libsystem_kernel.dylib          0x00007fff202e48e2 __psynch_cvwait + 10
1   libsystem_pthread.dylib         0x00007fff20316e6f _pthread_cond_wait + 1254
2   org.bitcoinfoundation.Bitcoin-Qt    0x00000001100e182f 0x10ff80000 + 1447983
3   org.bitcoinfoundation.Bitcoin-Qt    0x00000001102e6114 0x10ff80000 + 3563796
4   org.bitcoinfoundation.Bitcoin-Qt    0x00000001102afcf6 0x10ff80000 + 3341558
5   org.bitcoinfoundation.Bitcoin-Qt    0x0000000110661338 0x10ff80000 + 7213880
6   libsystem_pthread.dylib         0x00007fff20316950 _pthread_start + 224
7   libsystem_pthread.dylib         0x00007fff2031247b thread_start + 15

Thread 5:: b-scriptch.1
0   libsystem_kernel.dylib          0x00007fff202e48e2 __psynch_cvwait + 10
1   libsystem_pthread.dylib         0x00007fff20316e6f _pthread_cond_wait + 1254
2   org.bitcoinfoundation.Bitcoin-Qt    0x00000001100e182f 0x10ff80000 + 1447983
3   org.bitcoinfoundation.Bitcoin-Qt    0x00000001102e6114 0x10ff80000 + 3563796
4   org.bitcoinfoundation.Bitcoin-Qt    0x00000001102afcf6 0x10ff80000 + 3341558
5   org.bitcoinfoundation.Bitcoin-Qt    0x0000000110661338 0x10ff80000 + 7213880
6   libsystem_pthread.dylib         0x00007fff20316950 _pthread_start + 224
7   libsystem_pthread.dylib         0x00007fff2031247b thread_start + 15

Thread 6:: b-scriptch.2
0   libsystem_kernel.dylib          0x00007fff202e48e2 __psynch_cvwait + 10
1   libsystem_pthread.dylib         0x00007fff20316e6f _pthread_cond_wait + 1254
2   org.bitcoinfoundation.Bitcoin-Qt    0x00000001100e182f 0x10ff80000 + 1447983
3   org.bitcoinfoundation.Bitcoin-Qt    0x00000001102e6114 0x10ff80000 + 3563796
4   org.bitcoinfoundation.Bitcoin-Qt    0x00000001102afcf6 0x10ff80000 + 3341558
5   org.bitcoinfoundation.Bitcoin-Qt    0x0000000110661338 0x10ff80000 + 7213880
6   libsystem_pthread.dylib         0x00007fff20316950 _pthread_start + 224
7   libsystem_pthread.dylib         0x00007fff2031247b thread_start + 15

Thread 7:: b-scheduler
0   libsystem_kernel.dylib          0x00007fff202e40c6 __psynch_mutexwait + 10
1   libsystem_pthread.dylib         0x00007fff203142c5 _pthread_mutex_firstfit_lock_wait + 81
2   libsystem_pthread.dylib         0x00007fff203121bc _pthread_mutex_firstfit_lock_slow + 211
3   libc++.1.dylib                  0x00007fff202ab8f7 std::__1::recursive_mutex::lock() + 9
4   org.bitcoinfoundation.Bitcoin-Qt    0x00000001100ba6c4 0x10ff80000 + 1287876
5   org.bitcoinfoundation.Bitcoin-Qt    0x000000011042b7c6 0x10ff80000 + 4896710
6   org.bitcoinfoundation.Bitcoin-Qt    0x00000001102f98db 0x10ff80000 + 3643611
7   org.bitcoinfoundation.Bitcoin-Qt    0x00000001105bcce7 0x10ff80000 + 6540519
8   org.bitcoinfoundation.Bitcoin-Qt    0x00000001105bc2f5 0x10ff80000 + 6537973
9   org.bitcoinfoundation.Bitcoin-Qt    0x00000001100ddfc3 0x10ff80000 + 1433539
10  org.bitcoinfoundation.Bitcoin-Qt    0x00000001100e7fa4 0x10ff80000 + 1474468
11  org.bitcoinfoundation.Bitcoin-Qt    0x0000000110661338 0x10ff80000 + 7213880
12  libsystem_pthread.dylib         0x00007fff20316950 _pthread_start + 224
13  libsystem_pthread.dylib         0x00007fff2031247b thread_start + 15

Thread 8:
0   libsystem_kernel.dylib          0x00007fff202e48e2 __psynch_cvwait + 10
1   libsystem_pthread.dylib         0x00007fff20316e6f _pthread_cond_wait + 1254
2   libc++.1.dylib                  0x00007fff2027dcf2 std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 18
3   org.bitcoinfoundation.Bitcoin-Qt    0x0000000110653727 0x10ff80000 + 7157543
4   org.bitcoinfoundation.Bitcoin-Qt    0x00000001106536b9 0x10ff80000 + 7157433
5   org.bitcoinfoundation.Bitcoin-Qt    0x00000001106537ea 0x10ff80000 + 7157738
6   libsystem_pthread.dylib         0x00007fff20316950 _pthread_start + 224
7   libsystem_pthread.dylib         0x00007fff2031247b thread_start + 15

Thread 9 Crashed:: b-loadblk
0   libsystem_kernel.dylib          0x00007fff202e8462 __pthread_kill + 10
1   libsystem_pthread.dylib         0x00007fff20316610 pthread_kill + 263
2   libsystem_c.dylib               0x00007fff20269720 abort + 120
3   org.bitcoinfoundation.Bitcoin-Qt    0x000000011057c509 0x10ff80000 + 6276361
4   org.bitcoinfoundation.Bitcoin-Qt    0x000000011057a9cc 0x10ff80000 + 6269388
5   org.bitcoinfoundation.Bitcoin-Qt    0x000000011057abd7 0x10ff80000 + 6269911
6   org.bitcoinfoundation.Bitcoin-Qt    0x000000011057a9cc 0x10ff80000 + 6269388
7   org.bitcoinfoundation.Bitcoin-Qt    0x000000011057b6bb 0x10ff80000 + 6272699
8   org.bitcoinfoundation.Bitcoin-Qt    0x000000011057c1e0 0x10ff80000 + 6275552
9   org.bitcoinfoundation.Bitcoin-Qt    0x000000011009ad53 0x10ff80000 + 1158483
10  org.bitcoinfoundation.Bitcoin-Qt    0x00000001102b0bb5 0x10ff80000 + 3345333
11  org.bitcoinfoundation.Bitcoin-Qt    0x00000001102bafa2 0x10ff80000 + 3387298
12  org.bitcoinfoundation.Bitcoin-Qt    0x00000001102bc8d5 0x10ff80000 + 3393749
13  org.bitcoinfoundation.Bitcoin-Qt    0x00000001102be61e 0x10ff80000 + 3401246
14  org.bitcoinfoundation.Bitcoin-Qt    0x00000001102bfc66 0x10ff80000 + 3406950
15  org.bitcoinfoundation.Bitcoin-Qt    0x00000001100df977 0x10ff80000 + 1440119
16  org.bitcoinfoundation.Bitcoin-Qt    0x00000001100e988a 0x10ff80000 + 1480842
17  org.bitcoinfoundation.Bitcoin-Qt    0x0000000110661338 0x10ff80000 + 7213880
18  libsystem_pthread.dylib         0x00007fff20316950 _pthread_start + 224
19  libsystem_pthread.dylib         0x00007fff2031247b thread_start + 15

Thread 10:: b-torcontrol
0   libsystem_kernel.dylib          0x00007fff202e84fe poll + 10
1   org.bitcoinfoundation.Bitcoin-Qt    0x0000000110ed9347 0x10ff80000 + 16094023
2   org.bitcoinfoundation.Bitcoin-Qt    0x0000000110ed2c18 0x10ff80000 + 16067608
3   org.bitcoinfoundation.Bitcoin-Qt    0x000000011025ed15 0x10ff80000 + 3009813
4   org.bitcoinfoundation.Bitcoin-Qt    0x00000001100fe6b7 0x10ff80000 + 1566391
5   org.bitcoinfoundation.Bitcoin-Qt    0x0000000110265d1e 0x10ff80000 + 3038494
6   libsystem_pthread.dylib         0x00007fff20316950 _pthread_start + 224
7   libsystem_pthread.dylib         0x00007fff2031247b thread_start + 15

Thread 11:: b-net
0   libsystem_kernel.dylib          0x00007fff202ea1fe __select + 10
1   org.bitcoinfoundation.Bitcoin-Qt    0x00000001100fd014 0x10ff80000 + 1560596
2   org.bitcoinfoundation.Bitcoin-Qt    0x00000001100fd6cb 0x10ff80000 + 1562315
3   org.bitcoinfoundation.Bitcoin-Qt    0x00000001100fe49d 0x10ff80000 + 1565853
4   org.bitcoinfoundation.Bitcoin-Qt    0x00000001100ddfc3 0x10ff80000 + 1433539
5   org.bitcoinfoundation.Bitcoin-Qt    0x00000001101142ca 0x10ff80000 + 1655498
6   libsystem_pthread.dylib         0x00007fff20316950 _pthread_start + 224
7   libsystem_pthread.dylib         0x00007fff2031247b thread_start + 15

Thread 12:: b-addcon
0   libsystem_kernel.dylib          0x00007fff202e48e2 __psynch_cvwait + 10
1   libsystem_pthread.dylib         0x00007fff20316e6f _pthread_cond_wait + 1254
2   libc++.1.dylib                  0x00007fff2027dd83 std::__1::condition_variable::__do_timed_wait(std::__1::unique_lock<std::__1::mutex>&, std::__1::chrono::time_point<std::__1::chrono::system_clock, std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000000000l> > >) + 93
3   org.bitcoinfoundation.Bitcoin-Qt    0x0000000110113993 0x10ff80000 + 1653139
4   org.bitcoinfoundation.Bitcoin-Qt    0x000000011030db5e 0x10ff80000 + 3726174
5   org.bitcoinfoundation.Bitcoin-Qt    0x0000000110103592 0x10ff80000 + 1586578
6   org.bitcoinfoundation.Bitcoin-Qt    0x00000001100ddfc3 0x10ff80000 + 1433539
7   org.bitcoinfoundation.Bitcoin-Qt    0x00000001101142ca 0x10ff80000 + 1655498
8   libsystem_pthread.dylib         0x00007fff20316950 _pthread_start + 224
9   libsystem_pthread.dylib         0x00007fff2031247b thread_start + 15

Thread 13:: b-opencon
0   libsystem_kernel.dylib          0x00007fff202e48e2 __psynch_cvwait + 10
1   libsystem_pthread.dylib         0x00007fff20316e6f _pthread_cond_wait + 1254
2   libc++.1.dylib                  0x00007fff2027dd83 std::__1::condition_variable::__do_timed_wait(std::__1::unique_lock<std::__1::mutex>&, std::__1::chrono::time_point<std::__1::chrono::system_clock, std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000000000l> > >) + 93
3   org.bitcoinfoundation.Bitcoin-Qt    0x0000000110113993 0x10ff80000 + 1653139
4   org.bitcoinfoundation.Bitcoin-Qt    0x000000011030db5e 0x10ff80000 + 3726174
5   org.bitcoinfoundation.Bitcoin-Qt    0x0000000110101bb1 0x10ff80000 + 1579953
6   org.bitcoinfoundation.Bitcoin-Qt    0x0000000110114bed 0x10ff80000 + 1657837
7   org.bitcoinfoundation.Bitcoin-Qt    0x00000001100ddfc3 0x10ff80000 + 1433539
8   org.bitcoinfoundation.Bitcoin-Qt    0x00000001101142ca 0x10ff80000 + 1655498
9   libsystem_pthread.dylib         0x00007fff20316950 _pthread_start + 224
10  libsystem_pthread.dylib         0x00007fff2031247b thread_start + 15

Thread 14:: b-msghand
0   libsystem_kernel.dylib          0x00007fff202e40c6 __psynch_mutexwait + 10
1   libsystem_pthread.dylib         0x00007fff203142c5 _pthread_mutex_firstfit_lock_wait + 81
2   libsystem_pthread.dylib         0x00007fff203121bc _pthread_mutex_firstfit_lock_slow + 211
3   libc++.1.dylib                  0x00007fff202ab8f7 std::__1::recursive_mutex::lock() + 9
4   org.bitcoinfoundation.Bitcoin-Qt    0x000000011012128c 0x10ff80000 + 1708684
5   org.bitcoinfoundation.Bitcoin-Qt    0x000000011013555e 0x10ff80000 + 1791326
6   org.bitcoinfoundation.Bitcoin-Qt    0x00000001101038b9 0x10ff80000 + 1587385
7   org.bitcoinfoundation.Bitcoin-Qt    0x00000001100ddfc3 0x10ff80000 + 1433539
8   org.bitcoinfoundation.Bitcoin-Qt    0x00000001101142ca 0x10ff80000 + 1655498
9   libsystem_pthread.dylib         0x00007fff20316950 _pthread_start + 224
10  libsystem_pthread.dylib         0x00007fff2031247b thread_start + 15

Thread 15:: QThread
0   libsystem_kernel.dylib          0x00007fff202e40c6 __psynch_mutexwait + 10
1   libsystem_pthread.dylib         0x00007fff203142c5 _pthread_mutex_firstfit_lock_wait + 81
2   libsystem_pthread.dylib         0x00007fff203121bc _pthread_mutex_firstfit_lock_slow + 211
3   libc++.1.dylib                  0x00007fff202ab8f7 std::__1::recursive_mutex::lock() + 9
4   org.bitcoinfoundation.Bitcoin-Qt    0x00000001100be46d 0x10ff80000 + 1303661
5   org.bitcoinfoundation.Bitcoin-Qt    0x000000010ffb1425 0x10ff80000 + 201765
6   org.bitcoinfoundation.Bitcoin-Qt    0x000000011081e23f 0x10ff80000 + 9036351
7   org.bitcoinfoundation.Bitcoin-Qt    0x0000000110822612 0x10ff80000 + 9053714
8   org.bitcoinfoundation.Bitcoin-Qt    0x0000000110818396 0x10ff80000 + 9012118
9   org.bitcoinfoundation.Bitcoin-Qt    0x0000000110880a8d 0x10ff80000 + 9439885
10  org.bitcoinfoundation.Bitcoin-Qt    0x0000000110881d18 0x10ff80000 + 9444632
11  org.bitcoinfoundation.Bitcoin-Qt    0x00000001107ff724 0x10ff80000 + 8910628
12  org.bitcoinfoundation.Bitcoin-Qt    0x0000000110837e14 0x10ff80000 + 9141780
13  org.bitcoinfoundation.Bitcoin-Qt    0x00000001108362b0 0x10ff80000 + 9134768
14  org.bitcoinfoundation.Bitcoin-Qt    0x00000001107fb65f 0x10ff80000 + 8894047
15  org.bitcoinfoundation.Bitcoin-Qt    0x00000001106db77c 0x10ff80000 + 7714684
16  org.bitcoinfoundation.Bitcoin-Qt    0x00000001106de900 0x10ff80000 + 7727360
17  libsystem_pthread.dylib         0x00007fff20316950 _pthread_start + 224
18  libsystem_pthread.dylib         0x00007fff2031247b thread_start + 15

Thread 16:: QThread
0   libsystem_kernel.dylib          0x00007fff202e84fe poll + 10
1   org.bitcoinfoundation.Bitcoin-Qt    0x0000000110834d40 0x10ff80000 + 9129280
2   org.bitcoinfoundation.Bitcoin-Qt    0x0000000110836167 0x10ff80000 + 9134439
3   org.bitcoinfoundation.Bitcoin-Qt    0x00000001107fb65f 0x10ff80000 + 8894047
4   org.bitcoinfoundation.Bitcoin-Qt    0x00000001106db77c 0x10ff80000 + 7714684
5   org.bitcoinfoundation.Bitcoin-Qt    0x00000001106de900 0x10ff80000 + 7727360
6   libsystem_pthread.dylib         0x00007fff20316950 _pthread_start + 224
7   libsystem_pthread.dylib         0x00007fff2031247b thread_start + 15

Thread 17:
0   libsystem_pthread.dylib         0x00007fff20312458 start_wqthread + 0

Thread 9 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x000070000f5b0000  rcx: 0x000070000f5af338  rdx: 0x0000000000000000
  rdi: 0x0000000000009d0b  rsi: 0x0000000000000006  rbp: 0x000070000f5af360  rsp: 0x000070000f5af338
   r8: 0x0000000000000070   r9: 0x00000000000007fb  r10: 0x000070000f5b0000  r11: 0x0000000000000246
  r12: 0x0000000000009d0b  r13: 0x0000000000000000  r14: 0x0000000000000006  r15: 0x0000000000000016
  rip: 0x00007fff202e8462  rfl: 0x0000000000000246  cr2: 0xffffffb096d1a024

Logical CPU:     0
Error Code:      0x02000148
Trap Number:     133

Thread 9 instruction stream not available.

Thread 9 last branch register state not available.

Bitcoin Core is known to have issues with external drives as usually the USB interface is a bit flaky and the drive can disconnect which causes data corruption. If you use an internal drive, do you run into this problem? The particular issue here is that the database on the external drive has become corrupted.

@AndrewChow Unfortunately I don't have enough space on my internal HD for a full node. Is there anything I could to improve the connection with my external drive?
I tried -reindex yesterday and it still crashed again.


text:
How do I make Bitcoin Core listen on IPV6?
I know my ISP provides IPV6. It was previously broken, but restarting my router fixed it. I confirmed my IPV6 connectivity on several websites. Then I restarted Bitcoin Core so it would see the new IPV6 address on startup, but bitnodes.21.co says my IPV6 address can't be reached. Any advice?

Normally it should autodetect. Check for lines like these in debug.log:

AddLocal([2a02:91a:f3:21aa::1]:8333,1)

If that's the case, Bitcoin Core is listening to it, and if another service can't reach it, it may be a network configuration problem or a problem with that service.
If it isn't, you can manually bind to an IP address (IPv4 or IPv6) using the -bind option.

I checked debug.log and the lines are there. I copy-pasted the addresses into bitnodes.21.co and it still says unreachable. I've got Comodo firewall. I tried disabling it temporarily but still got nothing.

I think Bitcoin Core is hearing requests on my IPv6 address and not responding. Before it synced, it would intermittently respond on IPv4 to bitnodes.21.co, but most of the time the website waited a while and timed out. During this initial sync period IPv6 immediately failed, however. Now IPv4 succeeds quickly and IPv6 takes a while to time out. I know something must be different, since my node would rarely respond at all before the sync. The fact that IPv6 now takes a while to fail as opposed to immediately reporting "unreachable" makes me think the request is getting to me but being rejected

Could it have anything to do with my being on AT&T Uverse, which uses a 6rd tunnel? I have gone to websites that test IPv6 support and they all say I have a perfect IPv6 connection.

is it possible to add multiple -bind directives (e.g. to bind to IPv4 and IPv6) ?

Yes, you can specify -bind multiple times.


text:
Is it possible to design a recursive covenant opcode that results in a full node stuck in an infinite verification loop?
Is it possible to design a new opcode enabling recursive covenants that could result in a full node stuck in an infinite loop of verifying transactions? (Obviously this would never be considered for a Bitcoin soft fork, I'm just wondering about the limits of the design space for covenant opcodes)
e.g. A -> B -> C
A, B, C are transactions. B spends A, C spends B. A imposes constraint on spending conditions of B. B imposes constraint on spending conditions of C. But the spending conditions of C have to check something in A (something that wasn't hashed, perhaps the first few bits of a signature in the witness). As a result of that verification B has to check something in A and the infinite verification loop is set in motion.
I'm leaning towards no but not 100 percent sure. It isn't enough for C to check something in A, it needs to change A in some way such that B needs to verified again. This might even be prevented by the UTXO model (versus account model). In an account model you could refer to the balance of any previous block and get into an infinite verification loop that way.

Thanks to Russell O'Connor and Sanket Kanjalkar for answering this on IRC (I've only lightly paraphrased their answers, any errors are my own though.)

Is it possible to design a new opcode enabling recursive covenants that could result in a full node stuck in an infinite loop of verifying transactions?

No. Recursive in the Bitcoin covenant context only means something like spending an output back to the identical script template.
At the time of writing the only previously formally proposed Bitcoin opcode that when used could result in a script not terminating is OP_EVAL. With scripts that don't use OP_EVAL you can just count the opcodes and each opcode is evaluated at most once.
Consider you have access to OP_EVAL and two other new opcodes: OP_RED (check if the current block has a valid transaction that has OP_BLUE in it) and OP_BLUE (check if the current block has a valid transaction that has OP_RED in it). The block could have two transaction outputs with OP_EVAL, OP_BLUE and OP_EVAL, OP_RED in them respectively. This would require an infinite loop of checks.
The design space for new opcodes is vast. There are lots of principles of various levels of importance that could be violated by newly designed opcodes. For example you would generally want the script result to only be a function of the transaction itself and nothing external to the transaction. You would also want the static analysis of resources to be computable in linear time.
Hence rather than starting from clearly unsafe (but perhaps maximally flexible opcodes) and restricting functionality to make them safe it is probably a better approach to work on proving that certain opcodes are terminating and non-harmful.
The aim of ongoing work on Simplicity is to offer maximal flexibility while still being subject to the desired constraints and principles discussed above. Without something like Simplicity it is difficult to know for sure that any opcodes(s) are provably safe whilst at the same time offering maximal flexibility.