Where does the litecoin wallet store coins?

On Linux, the default data directory is ~/.litecoin/. This is where the wallet, blockchain, configuration, etc. files are stored.

You can backup your wallet from File > Backup Wallet. This is the part that contains your private keys. See the pic:

You should encrypt with a secure passphrase (in Settings > Encrypt Wallet) before exporting your wallet. If you don't, the private keys in your backup will be unencrypted. As long as your wallet has been encrypted, your backup will be encrypted and you can safely* put it on Dropbox, Google Drive, email it to family/friends, etc. for safe-keeping.

*As safe as your passphrase is, so make it very high quality.


Do you need a user interface or to find them via API? We do not have UI at the moment for this (we will very soon) but you can definitely use our REST API to get them.

If the API is what you need then you can just use the following API call to filter ORPHANED blocks only.

  https://api.biteasy.com/blockchain/v1/blocks?type=ORPHANED

If the transactions weren't included in the main chain then they will either be DEAD or PENDING and you can fetch them with the following API call:

  https://api.biteasy.com/blockchain/v1/transactions?confidence=DEAD

and

  https://api.biteasy.com/blockchain/v1/transactions?confidence=PENDING

Check out the link to our documentation and also you can use our testing tool which you can find here https://www.biteasy.com/developers/sandbox


How to find out a p2pool's node fee/donation setting?

Not really, you have to trust that the owner is being truthful. In actuality they could be stealing every bit of work you submit, but I'd like to think that they wouldn't.

If you don't trust the node, it's up to you to run your own.


Do all of the records in the same block share the same hash?

There are transactions, and blocks. Both have their own unique identifiers, which are calculated as a hash of all the data in it.
When a transaction is included in a block, its hash (txid) doesn't change. It just becomes part of a block. That block also has a hash, which depends on the hash of the parent block, as well as on the hash of all transactions included in it.
So no, not all transactions share the same hash. Their hash is simply the hash of their data, and once created and signed, that hash cannot change without invalidating the signatures. Including it in a block doesn't change that.


2-of-3 multisignature account with limitations on withdrawal

You will likely need to add an OP_CHECKSEQUENCEVERIFY guard before the OP_CHECKMULTISIG statement in your output script.

https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki


Possible to buy bitcoin at MtGox at $259 and sell for $635 at BitStamp at 18th February 2014?

In short: At this current time, you can buy BTC but you can not withdraw your BTC from Mt. Gox due to immaturity of their infrastructure and modified Bitcoin code. Time will tell if they survive this. So no, it is not possible to buy from GOX and then sell those at Bitstamp since Gox will not allow this until further notice expected before thursday.

  At the beginning they will do so at a moderated pace and with new
  daily/monthly limits in place to prevent any problems with the new
  system and to take into account current market conditions.


Recommended way to automatically retry sending of bitcoin via JSONRPC upon failure

Try to figure out why you get an http error 500. Check your debug.log, double-check the command you're sending that causes the 500. Try to solve it.
After you sent your Bitcoins or got an error, check if the desired recipient has been payed by fetching your wallet transactions and parsing it after the recipient and eventually the amount. Use listsinceblock or listtransactions. Eventually use the txid for performance from a successful sendrawtransaction (or send* command). Use time-range in case you reuse addresses.
Make sure you flag your transaction as "sent" (in your application / user-flow logic) when you can fetch it over the listcommands (see 2.)
Re-creating the payment transaction in case of a sudden crash or shutdown of your system may be done by forging, signing and sending the transaction again.


What is meant by "relaxed standards" for P2SH redeem scripts in Bitcoin Core 0.10.0?

What are the specific changes which have been made (ie relaxed standards)?

Gavin Andresen made this pull request proposing the change, as well as this rationale document describing why he supported the change.

  Does it only apply to P2SH Txns?

It applies only to P2SH redeem scripts, which is the script that is run to see if you have the data required to spend an output sent to a P2SH address.

  Finally, "n-of-m OR y" and hash-locked oracle addresses are mentioned as examples: what does this refer to exactly?

n-of-m OR y refers to a script that checks for multiple signatures from a set of keys OR a single signature from another key.  For example, if Alice owns a business and Bob and Charlie are her employees, she can allow Bob and Charlie to work together to spend her bitcoins (2-of-2) or Alice ("y") can spend her bitcoins on her own.
hash-locked oracle means, generally, that you can create a transaction that can only be spent when the hash of some data is provided.  For example, this PDF (page 24) describes a hash-locked contract with three parties: Alice, Bob, and Charlie.

Alice wants to pay 1.00 BTC to Charlie through Bob.
Charlie randomly generates a large number r and then hashes (HASH160) that number to produce h.  The value r is the oracle and the value h is the hash lock.
Charlie gives hash h to Alice.
(Transaction 1) Alice gets Bob's pubkey and pays him 1.01 BTC in an output with a script like: <Bob's pubkey> CHECKSIGVERIFY HASH160 <hash h> EQUAL
(Transaction 2) Bob can't spend that output without the number r that generated hash h, but he knows Charlie has the number r so Bob gets Charlie's address and pays him 1.00 BTC with a script like: <Charlie's pubkey> CHECKSIGVERIFY HASH160 <hash h> EQUAL
(Transaction 3) Charlie spends the output from transaction 2 by creating the signature script: <number r> <Charlie's signature>  This means r is revealed on the block chain.
(Transaction 4) Bob sees r on the block chain and uses it at some point to spend the output from transaction 1: <number r> <Bob's signature>

The example above seems overly contrived, but the PDF linked above uses it as part of a micropayment channel that allows settling transactions off the block chain in a distributed and low-trust manner, possibly allowing Bitcoin to scale much better than it does without such a system.


SPV wallets allow a user to verify that the information they have received is legit, thus the node they are connected to is unable to send them fraudulent transactions. This is possible because the block header that an SPV wallet will download contains the block hash (allowing the wallet to verify that the block header is indeed part of the bitcoin blockchain, tracing back to the genesis block), and the transaction merkle root (allowing the wallet to verify that a certain transaction is included in a certain block). Through these cryptographic mechanisms, a user can interact with the network without placing a large amount of trust in the node that is communicating with their wallet.

Using multiple endpoints for an API wallet does not provide a more secure solution than the cryptographic proofs utilized by an SPV wallet. By using an API wallet, you are trusting that the API provider will not provide you false information. Using multiple endpoints is probably better than just one, but the risk still remains because now you just trust that a bunch of nodes aren't lying, instead of just trusting that one node isn't lying.

Luckily, SPV wallets are not super resource intensive as is, block headers are only 80 bytes, so a year's worth of blocks only add up to about 4.2 MB.


Bitcoin 0.18: how to send bitcoin from one address to another using Bitcoind?

Please let me know how can I define the account or address from which I need to send Bitcoins or is there any other method available.

The listunspent and createrawtransaction commands together can be used to achieve what you are asking.

The listunspent command will give you all the UTXOs that your wallet controls. You can pass an address parameter to filter all the unspent outputs by address. The documentation of listunspent is available here. This command will return you the txids, output index, value and others.

Then use the createrawtransaction command and specify those txids and output indexes in the input, and the address and value that you want to send in the output.


Does merkle root contain hashes of transactions from previous blocks?

The blockchain is the mechanism for Bitcoin to converge on one shared state. Participants submit payment orders in the form of unconfirmed transactions to the network from which miners then select a set of transactions into their block candidates. The Merkle root hereby represents a commitment to one specific list of previously unconfirmed, valid transactions. When a new block gets authored, all network participants validate the block and then adopt the new set of balances as the current network state.

Beside the Merkle root as a commitment to this block's transactions, the block header also commits to exactly one preceding block as its parent by including the hash of that predecessor block. As the predecessor in turn committed to it's own predecessor, a new block therefore inductively commits to the full history since the Genesis Block.

Given that each preceding block in turn contains a Merkle root with which it committed to its own set of transactions, any new block also commits indirectly to the full history of all transactions.

Coming back to your example, this means that if Block#1 committed to {A, B, C, D}, the Merkle root in Block#2 would only commit to {E, F, G, H}. However, Block#2 commits to {A, B, C, D} indirectly by declaring Block#1 it's predecessor.


How is hash rate of mining hardware calculated

The sha256(sha256(header)) is commonly called the hash in the Bitcoin world. So the hash rate is the rate of sha256(sha256(header)) operations, not the rate of single sha256 operations. Otherwise it'd probably called a sharate or something similar :)


What will happen when the last bitcoin will be find

The Mining process uses the proof-of-work algorithm to generate new bitcoins and protect the network from attack by attackers, such as the publication of an invalid block or the modification of a transaction within a block. .
Bitcoin performs the validation of transactions on average every 10 minutes and they are considered "valid" only when the block containing them is appended to the official chain; each transaction can include within it a bitcoin value which is equivalent to a fee addressed to the miner for reward of the work done, which can choose to give precedence to transactions with a higher commission than a quantity of bitcoins of their choice.
Bitcoin establishes a process of creating a new decreasing and limited currency, in fact it imposes a maximum upper limit of twenty-one thousand bitcoins; the value created by the miners halves every 210,000 blocks, on average every 4 years.
The creation of bitcoin began with an amount equal to 50 bitcoins per block in January 2009 and halved to 25 bitcoins in November 2012 thus estimating the complete issuance of all the bitcoins available in 2140; at the end of the issue, the gain of each miner will be exclusively the value of the commission.

So, the mining will not stop, only the miner's gain will decrease (it is not said because there could be many transactions)


Can lightning transaction participants link the transaction to on-chain funding transaction UTXOs?

Let us start with the direct payment via channel Uab. According to BOLT 02, the payment is conducted by adding an HTLC and settling it. From a protocol perspective, Bob does not know if the payment was originated by Alice. Of course, as there was originally an invoice issued by Bob (and potentially presented out-of-band to Alice), he could deduce that Alice was the payer, but Alice might have forwarded the invoice to someone else who later routed through Alice. Thus, Bob cannot tell with certainty who paid him. All he knows is that he got money from Alice.
In that specific setting, Alice can however be sure that Bob is the one receiving the money as Bob issued the invoice. Invoices are signed by the private key corresponding to the node id, so Alice knows that Bob has requested the payment. Of course, Bob might have been a proxy in the sense that he issued an invoice with the same payment hash as someone else. In that case, Bob might have routed the payment before he was able to present the preimage. Such behavior would be impossible to distinguish for Alice.
Similarly, in the Alice-Isidore-Bob setting: Isidore only knows that Alice sent him money and that he was asked to forward to Bob. Isidore does not know if Alice is the originator nor if Bob is the final destination (this of course assumes the protocol is secure and no attacks exist that reveal such information). Like before, Bob only knows that the payment came through the channel Uib, but cannot tell with certainty who paid him.
In the Alice-Isidore-Bob setting, Alice is aware of all funding transactions as she chose the route and the route is encoded with short_channel_ids which point to funding transactions. Alice will most likely have learnt about them via the gossip protocol.


What open source miner applications are there?

The official list is on The Wiki and is constantly being modified since new software shows up fairly often, but here's the quick breakdown:

Poclbm - Python/OpenCL GPU miner (GUI)
DiabloMiner - Java/OpenCL GPU miner (MAC OS X GUI)
RPC Miner - remote RPC miner (MAC OS X GUI)
Phoenix miner - miner
Cpu Miner - miner
Ufasoft miner - miner
Pyminer - Python miner, reference implementation
Remote miner - mining pool software
Open Source FGPA Bitcoin Miner - a miner that makes use of an FPGA Board

Poclbm and Phoenix are probably the most popular (links go to the sources) though that's based more on my opinion than any facts or studies. In either case, both should shed some light on the mining process.


HD wallets with an exposed child private key

I don't know where you found this formula, here is the code to derivate a childkey, the BIP is here, it does not look like your formula, but I'll try to respond to some of your questions.

I just got a little confused about this. Is s the mnemonic seed that user knows? which generates the private keys.

A mnemonic seed is just a sentence that permit you to get the master key with (optionally) a password. A master key is the real important piece of information, a mnemonic is only a way to generate one that can be write it down in words.

Secondly a service provider only needs to know sG to calculate the user's next address. Am I right?

Your formula does not look like what is in the BIP, so I can't really comment on that.

And lastly more importantly I am just wondering whether it is possible to calculate the master private key (seed) if an attacker or service provider gets one child's private key address?

Yes, if all the children in the path to the leaked private are non-hardened keys AND the root HD PubKey leaked. I explain that P 35 of my book.

A non-hardened key can “climb” the hierarchy.
Non-hardened key should only be used for categorizing accounts that belongs to a single control.


What does it mean to say that Huobi "self-match" trades?

It basically means that the exchange is showing false volume on their site.

Here is how:

Exchange inserts order to buy 1 btc @500USD/BTC
Exchange inserts order to sell 1 btc @500USD/BTC
Orders match and the exchange's trade volume has increased by 1btc.

But actually, no real trade has occurred. They artificially updated their records to attract more traders.

This would be harshly penalized if it was done by a regulated exchange.


What is "trickling" in terms of bitcoin?

Trickle is a reference to how the node manages announcing other peers addresses.


Does the introduction of Schnorr signatures require segwit?

The current proposal for Schnorr Signatures relies on script versioning, a feature which would be introduced by SegWit. If SegWit doesn't activate, many things are still possible in bitcoin via a hard fork or a complicated soft fork, and Schnorr might be one of them. No reasonable proposals towards that end exists today.


Generate Bitcoin Address JS Step-By-Step "Invalid Address" Error

You are hashing everything as hex strings. However that is not the proper way to hash stuff. They should all be hashed as bytes (i.e. the raw data), not strings of hexadecimal.


When you are buying servers you can order multiple IP per one server, typically in the same /8 or /16 subnet. So 1 server can serve as 100 or even 1000 Bitcoin nodes.

Ordering lots of IPs in lots of different /16 subnets is rarely possible for the same server.

Hence this change makes it harder/more expensive to launch 1000's of rogue Bitcoin nodes - you will have to distribute them across large number of servers in different datacenters.


I'll try to give a list of the cases I know of. Whether these are considered bugs or implementation oddnesses is debatable, I guess.

The genesis block's coinbase output cannot be spent.
The OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY operations pop one element too much from the stack (requiring an extra dummy push in the redeem script).
The checksig operations in a coinbase's scriptSig count towards the sigop limit of a block, even though that script can never be executed.
Encoded public keys and signatures are valid if and only if OpenSSL accepts them, including the many non-standard or simply broken encodings it accepts. Since 0.8, such non-canonical encodings are considered non-standard, but still valid inside blocks.


If it is the format and the checksum then that can be easily done. Specifically you can use steps 4 to 9 in the technical description of Addresses to check for typos. Beyond that however it gets difficult

If you want to access blockchain information such as the current balance you cannot unless you have a copy of the blockchain somewhere, and on a phone or tablet disk space is still too precious for that. For that you'll need to rely on some external service or sacrifice disk space to track the blockchain in its entirety.

Notice that Andreas' Bitcoin Wallet only selectively tracks addresses that were known while synchronizing with the network, so if the addresses you'll eventually be interested in are known in advance you could also selectively sync those.

EDIT: as requested here is the reversed example from the documentation, as python code:

import hashlib

# Take the address as input, using the sample address from the
# technical description to follow along
address = "16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM"

# Decode into 25 bytes (0x00 for the network identifier, 20 byte
# RIPE-160 hash and 4 byte checksum
decoded_address = b58decode(address,25)

# Print as hex, should match step 8 in the docs
print decoded_address.encode("hex")

# Slice into its components
network_id = decoded_address[0]
private_key_hash = decoded_address[1:21]
checksum = decoded_address[-4:]

if network_id != chr(0):
    print "ERROR: not a Bitcoin Main Net address"

# Print the private key hash as hex, matches step 4 in the docs
print private_key_hash.encode("hex")

# Print the checksum as hex, matches step 7 from the docs
print checksum.encode("hex")

# Now we can check the checksum to reduce chances of typos
# Print first round of hashing (docs step 5)
hash1 = hashlib.sha256(network_id + private_key_hash).digest()
print hash1.encode("hex")

# Print second round of hashing (docs step 6)
hash2 = hashlib.sha256(hash1).digest()
print hash2.encode("hex")

# And finally verify that the checksum we extracted from the address
# and the one we just calculated match

if checksum == hash2[:4]:
    print "Everything ok, checksums match"
else:
    print "The end is nigh"

Sadly we can't go any further in verifying without further information, like the actual public key.


Which cryptocurrency exchange provides a trailing stop limit orders?


Profitability will all depend on the cards you buy, your electricity cost, and your overclocking configurations. I haven’t mined zcash in a few weeks, but when I was mining I was getting about $12ish dollars a day with 3 Nvidia 1070 Ti’s. My hash power was about 1560 sols/s(zcash’s version of a h/s). Each card was running at 85% power and getting around 520 sols/s.

I would say at 15 cards, and the hashing power you mentioned, you should be more than profitable. If you want to get a good idea of how much you will make, checkout whattomine.com, it’s a great resource for measuring profitability.


When I pay, how is my balance checked, if I use different address every time?

So (as I understand) when I want to buy something I send my address encrypted with private key to recipient, he decrypts it with public key & then checks the blockchain to determine if I can afford the transaction

Not quite the way it works. You just send the address, which is essentially the public key, to the person who is trying to do the paying. Given the address (more technically, references to times that address has been paid to on the blockchain before), anyone (not just the payee/payer) can verify that the transaction has the funds to spend.

And rather than sending the private key to show that you are the owner of the coins, you send a Digital Signature, which you need the private key to generate.

Your wallet reports your balance by looking at the list of times that you have been paid to before, which you have also not spent. This will be across many addresses. The network doesn't know which payments on the blockchain are yours, you have to reference a few of them when you want to spend funds, and prove you own the key to them with a digital signature.


cannotsend error using python bitcoin library to send bitcoin on testnet

The issue was that addr is being provided an invalid address - a Main Net address does not work on Test Net, and vice versa.  (From the edit revisions history, the code sample you provided was using bitcoin.wallet.CBitcoinAddress('1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T') which would provide a Main Net address)

Replace the address being supplied in the addr variable with a legitimate Test Net address, and it should work.


Interpreting results from "bitcoin-cli getmempoolinfo"

After some digging, I believe I have an explanation: the memory pool is clogged with 'junk' transactions.

Bitcoin Core's minrelaytxfee parameter defaults to 0.01 mBTC/KB, which is "too low" in the sense that it permits TONS of 'junk' transactions to enter the memory pool. I've bumped minrelaytxfee to 0.05 mBTC/KB and the results so far are very encouraging. The memory pool profile now makes sense, from the # of transactions to the size of each transaction.

And minrelaytxfee=0.00005 strikes me as "fair" as it is one-tenth the broadly recommended transaction fee of 0.5 mBTC/KB (backup up by the Pareto breakdown of real transactions on various websites).

I encourage everyone running Bitcoin Core can make their own decision on minrelaytxfee for their full node.


To recover your bitcoin cash, you need the access to the private keys of the wallet where your bitcoins were before the fork, which happened at the beginning of August 2017.

If you have withdrawn your bitcoins from your Multibit wallet in October 2017, then you can recover bitcoin cash from your Multibit wallet only. If you have no access to your Multibit wallet anymore, then your bitcoin cash coins are lost. I am sorry.

Update:

In case you still have access to your MB seed, I would recommend you the following simple steps:

Follow this video tutorial to import your MB HD seed into Electrum. Check if there are still any bitcoins on that wallet and withdraw them to another bitcoin wallet. Just to be sure that you won't lose them during the further process. This will not affect your BCH
Follow the official Electrum Recommendation on how to redeem Bitcoin Cash. Short version below:

  2.1 Install Electron Cash.

  2.2 Import your MB seed into Electron Cash.

  2.3 Enjoy your coins and send your promised bitcoin cash reward to :) 3AxGUDoXKtz4w6fba6HPrp8j8XFmSwFCoE

Note1: For a more safer approach, read the recommendation.

Note2: In case you will not be able to import your MB HD seed into Electron Cash, first export another seed or private key from your Electrum wallet, which you created in step 1 and use it instead of the MB HD seed.


Which serialization format the transactions use?

All of the data structures in Bitcoin use a custom Bitcoin specific serialization format. The standard that is followed is the Bitcoin defined standard, not any other standard. A description of the non-segwit format can be found here. For segwit transactions, the format is described in BIP 144.


Does 'Mixing' in bitcoins really add up protection to my bitcoins?

do you mean "anonymize" insteadt of "protect"? if so:

in general: no

everybody can track your bitcoin-transfers on the blockchain. so everybody can theoretically comprehend that you have used a mixer-service. if your mixer-service does really mix your bitcoin, you must still trust your mixer-service that it will never provide some information about that mixing-process in future to anybody. (but maybe this service will be hacked in future or the service must provide some information to a prosecuting authority for example.)

hint: you can improve your anonymity a little bit by changing your bitcoins to a cryotocurrency which has a little bit more anonymity/privacy (for example monero) and then make some transactions and change it back to bitcoin.


Displayed transactions may not be correct!

You are running bitcoind 0.3.24.  This is a very old version that won't work properly on today's Bitcoin network. The latest version is 0.8.6.

It appears that the Ubuntu maintainers have not updated the version of bitcoind in the standard 12.04 repository; so you'll have to get a current version from somewhere else.  The Ubuntu developers maintain a repository of their own for bitcoin, so you can install the latest version by doing:

sudo add-apt-repository ppa:bitcoin/bitcoin
sudo apt-get update
sudo apt-get install bitcoind

You can also get these instructions from an "official" source by going to http://bitcoin.org/en/download and following the "Ubuntu (PPA)" link.

In answer to your other question, when you run bitcoind without arguments, it runs in the foreground and accepts commands on standard input (after a delay of a minute or two while starting).  You can exit it by typing stop.  You can also run it in the background by doing bitcoind -daemon, and then feed it commands by running bitcoind getinfo, etc.


Try and use iptables instead! Just forward the port secondary ports to the primary.

https://serverfault.com/questions/320614/how-to-forward-port-80-to-another-port-on-the-samemachine


Is this "transaction malleability" really an issue?

Here's a good interview by Gregory Maxwell himself who's a Bitcoin developer:

  Oh there is a “problem” in the Bitcoin protocol, known since at least
  2011 (see the link I gave). But for normal applications, not involving
  unconfirmed transactions, it shouldn’t cause any severe problems
  because wallets can handle it locally.

This has to do with systems, such as Mt.Gox, that rely on unconfirmed transactions. Normal Bitcoin apps don't rely on unconfirmed transactions.

The Transaction Malleability issue that Mt.Gox talks about has been around since 2011. It only effects transactions which are not included in a block. Once a block is hashed, you can't change the transactions within it because then the hash of the block would have to change as well.

For all other Bitcoin applications that rely on confirmed transactions, as they should, this is not an issue.


Answered on Twitter

  The hash of the provided prevtx must match the prevtx hash given in the input. The attacker is unable to construct a fake prevtx that hashes to a predefined value. The prevtx hash in the input cannot be changed either, otherwise the network will reject the tx.

Basically, you can't create fake previous transactions because that would require producing a sha256 collision, which we assume can't happen.


Many exchanges have similar policies, either officially (such as Bittrex) or unofficially.

The reason for this usually comes down to time and security. Any exchange worth their salt will have security set up in a manner to prevent human access to private keys, and prevent unauthorized tx signing even through an automated system.

While cross chain recovery is sometimes technically possible, with an exchange's systems in the mix it will often require:

Someone with a very high level of trust manually accessing private keys, or accessing a system that will sign arbitrary transactions. For most exchanges, this will only be one or two people, as anyone with this level of access could move any funds to any address, and effectively clean out the exchange.
That person's time. Due to security set ups, this kind of process will often not be a 5 or 10 minute thing. Considering that the person performing this action is going to be of a fairly high level, any time they spend on the recovery is time taken away from regular business, and is costing the exchange.

Due to this, most exchanges impose minimums and other rules on coin recovery, since it makes no sense for them to sacrifice security and time over small amounts.


I am looking for a list of all the public repositories for as many different cryptocurrencies as possible

https://www.coingecko.com compiles the developer activities of almost all or most public traded cryptocurrencies.

They have the repo data stored on their site. Site may be hard to navigate, click Coin then choose Developer tab and look for Code Repository link. Enjoy.


Network admin blocks P2P, Bitcoin clients can't connect

You can use a proxy with -proxy, a VPN, or Tor.


What technical reasons exist for off-chain transactions?

Speed
An off-chain transaction can complete instantly, without waiting for confirmation.

Naming
With off-chain transactions, you can send Bitcoins to another user by referencing their username, rather than typing in an address.

Possibly lower transaction fees, possibly fewer on-chain transactions
Depending on how many transactions happen off-chain, it can save space on the blockchain. However, if there's only one off-chain transaction, it will end up consuming more space. (The coins will travel from User A -> Off-chain transaction provider -> User B instead of User A -> User B)

(Related to #3) It makes it feasible to have lots of very small transactions. For example, you might use off-chain transactions to pay someone a microfee for every minute that you use their wifi.


BitcoinJ : Balance and Transaction are not showing in wallet after restoring wallet from MnemonicCode

I think this example can help you, to synchronize the wallet

https://github.com/bitcoinj/bitcoinj/blob/master/examples/src/main/java/org/bitcoinj/examples/RefreshWallet.java


Generally when paying an invoice a chain of htlcs from the sender via some path on the network to the recipient is set up. The htlcs lock in by exchanging signatures on every local channel. Now there is a min timelock  which is the amount of time the payment can take. Or the time frame in which the htlcs must settle by releasing a preimage to have a successful payment.

The general workflow is that the recipient is supposed to release the preimage once the htlc on their channel is set up and the amount is equal or bigger the one requested in the invoice.

With the HODL invoice as described in the pullrequest the recipient decides not release the preimage automatically. Therfore the settlement of htlcs is deferred into the future (or the timelock cancles the payment process)


Is it possible to decode the private key from a signed input?

No. Signatures and public keys are meant to be public. In typical use, using a correct implementation of the signing code, it is currently not possible to determine the private key for a signature and pubkey pair.

Signed inputs are not encrypted or obfuscated in any way, so when you broadcast your transaction, everything in the input, including the signature, will be publicly available for anyone to see.

There are some cases where it is possible to determine the private key for a signature and pubkey pair. However these all involve faulty implementations of the signing code. They usually revolve around the use of bad randomness and otherwise failing to produce a random enough number. For the most part though, these failures are rare.


Running multiple BTC nodes on separate VMs on the same host machine?

Having multiple nodes running will help you get connected to more peers. The algorithm behind finding peers takes into consideration a variety of variables, such as the success rate of previous connections, and the IP addresses that get relayed by other nodes. Therefore, the more nodes you have running, the better the chances of connecting to different peers.

This means that it doesn't really matter that they're running on different operating systems. You can run different nodes on the same OS, on different ports. This would effectively be the same as running them on different virtual machines.

What matters here is the high peer connection rate, which can be accomplished by running many nodes on different ports.


Difference between a bitcoin wallet and the blockchain

As stated in comments, the blockchain is a public record of all bitcoin transactions. If a wallet is like a bank account, the blockchain is the currency system.

For a new or casual user, it might be easiest to use a remote web-based wallet, rather then one on your own device. In that case, you don't really need to worry about interacting with the blockchain. For more information on remote wallets you can use, go here https://bitcoin.org/en/choose-your-wallet Click the "web" icon and you will see seven options to consider.


mining Cryptonote currency on scrypt and sha-256 miner

Not possible.  Monero uses the Cryptonight hash algorithm which is distinct from scrypt and sha-256.  However, you should be able to find other CPU mining implementations for this algorithm.  The place to ask would be https://monero.stackexchange.com.


All addresses and their corresponding private and public keys are stored in the wallet.dat file in the data directory. Assuming your Bitcoin Core is running on a machine which has access to many people but you want to prevent unauthorized persons from dumping the wallet on that shared machine, the best way I can think of is that you can encrypt your wallet with a passphrase. When they run the dumpwallet command, the private keys that are dumped will be encrypted.

When you want to get the unencrypted private keys you can run the command walletpassphrase <passphrase> <time to unlock in seconds> and then run the dumpwallet command.

However, using an online connected wallet for storing large number of bitcoins is not recommended as there always will be a weak point which can be exploited. You could run two Bitcoin core, one online and other offline. With the current Bitcoin Core, you create a wallet on your offline machine. Using it, you get one or more addresses (saving them, for example, to a text file). You copy those addresses to your online computer and give them to people to pay you. When you want to spend those payments, you create the transaction on the online computer in an unsigned form, copy it to your offline computer, verify it, sign it, copy the signed transaction back to the online computer, and send it. You can use the watch only functionality in the online Bitcoin Core wallet by importing the addresses using importaddress command.

EDIT for Bitcoin Core v0.18. The latest release of Bitcoin Core v0.18 supports hardware wallet integration to allow command line management of several hardware wallets including Trezor Model T, Trezor One, Ledger Nano, Digital BitBox, KeepKey and ColdCard. This would allow you to get the same security of a hardware cold wallet but with added functionality of relying on your full node rather than the SPV node of the wallet. For more information refer Using Bitcoin Core with Hardware Wallets on GitHub.


Get transaction that spent a transaction id

The raw transaction info includes the Unspent Transaction Out (UTXO) which is the link to each of the components of the spend:

http://blockchain.info/rawtx/$tx_index


How to earn my first bitcoin in baby steps?

HOW TO BUY BITCOINS

1) From exchanges. Exchanges are many based on countries. UNOCOIN is a popular one for India. Alternatively, if your nationality is different from what I presumed, you can have a look at this site for many exchanges and wallets: COINDESK. You can create a bitcoin wallet here: BLOCKCHAIN

2) Have a look at this link for more detailed explanation: How do you obtain bitcoins?

WHERE CAN I SPEND THEM

You can spend them on websites/services which ACCEPT bitcoins as a mode of payment just like Paypal, Credit Card or Debit Card.


Cryptocompare Api - understanding API return values

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

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


I'm pretty sure that all crypto payment processors that deal with fiat <-> cryptocurrency exchanges are doing AML/KYC routines including chain analysis. That's not only true for BitPay and Coinbase but Circle et al. too. As soon as you're trying to move value between crypto and fiat you're going to have to deal with different levels of privacy invasions if you're using a payment processor.
The exceptions to those KYC/AML routines is either cash <-> crypto transactions (like localbitcoin, mycelium...) or using a crypto currency that can't be traced by (evil) companies like chainalysis.

tl;dr I don't know any non-privacy invading bitcoin payment processor as soon as fiat gets involved.

ps: However I know that there a various people working on new (open-source) cryptocurrency payment processors. I will try to dig out some additional info on those and update my post accordingly.

edit: interesting update on coinbase: https://news.bitcoin.com/coinbase-helps-fbi-shut-kickasstorrents/


Do all outputs have an address associated with them?

Not every UTXO has an associated address.

An address is really just a shorthand notation for a particular Bitcoin Script. There exist many interesting scripts which do not correspond to an address, but are still spendable under some conditions.

Note that every P2SH output does have associated address, and almost all interestong scripts these days use P2SH.


There are two factors that define the profitability of mining, and they tend to change somewhat independently of one another or at least lag one another quite significantly.

The first factor is difficulty. Blocks should be generated every 10 minutes on average, regardless of the amount of processing power available to the network, so difficulty adjusts how hard it is to find the solution to a block. This factor is based solely on the total hashrate of the bitcoin network.

The second factor is price. Assuming we're speaking of profitability in terms of US Dollars or other fiat currencies, we have to account for our earnings in the same currency that was used to pay for our costs. To my knowledge there is not (yet) a power company that will allow you to pay your electric bill in bitcoins.

From personal experience I can say that my dedicated rigs consume about $4 worth of electricity to produce 1 BTC and if I'm lucky enough to be average my hardware will have a long enough MTBF (mean time between failures) that its cost amortized over the life of the machine will perhaps bring that up to $4.50 or $5 per coin. At today's rate of $8.69 per BTC, it is still profitable though just barely.

CPU mining cannot produce at a high enough efficiency to be worth the electricity cost, and the same can likely be said for less efficient GPUs. Of course some folks don't pay per kilowatt-hour for electricity usage and for these folks ANY kind of mining is still profitable.

There are also a few folks on the forums selling FPGA boards which, though quite expensive up front, consume only 10-15% of the electricity of a comparable GPU. A single Xilinx Spartan6 board, for example, produces 100 MH/s at a little under 7 watts, compared to a Radeon HD 5830 which produces around 200 MH/s (without overclocking) at about 108 watts (54 watts per 100 MH/s).


bitcoind getrawmempool without downloading the full blockchain

Bitcoin core does not provide this functionality (as far as I know).

The mempool is where transactions are stored until they get put into a block. It would be hard to determine you had the correct mempool if you didn't keep track of the whole block chain, though. For example, someone could broadcast an older transaction, and you would have no way to determine that you shouldn't just add it to your mempool if you didn't keep track of the whole block chain. Transactions also have to pass some basic validation before they can be added to the mempool, validation which requires having all the blockchain data.

If there were a program to implement this, it would at least have to process all new blocks as they came in, in order to determine which transactions to take out of the mempool as blocks get solved.

With this said, you can set up a light-weight node that just monitors what transactions are being spread around on the network, but without the full blockchain data you won't be able to validate that the transactions are candidates for inclusion in the next block.

As Amaclin pointed, one such program to do this network watching is

https://github.com/sebicas/bitcoin-sniffer.


Does GNOME or KDE desktop enviroment matter, at running a BitcoinCore node?

The particular desktop environment does not have a direct impact as long as you have the necessary libraries for running Qt applications.

On Debian (or Debian-Based distributions, such as Ubuntu) the following command should install the dependencies necessary for the UI:

sudo apt-get install libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler

Those are the packages used by the bitcoin-qt package. Source


Several clients confirmed transactions with the same hash

Today it was discovered that in callback sent by the Blockchain.Info we received the confirmation of two facts of payments to different addresses, the transactions of which have the same hash.

You mean more than one customer paid you in a single transaction. There's nothing particularly unusual about that.

  Can transfers of bitcoins to different generated addresses have the same hash? Why?

Yes, they can. A single payment can produce a number of outputs, sending bitcoins to several different addresses.

  Why does the transaction consist of a set of outputs, the total amount of which is 11 BTC, which is hundreds of times the amount that customers had to pay us?

Because several customers paid you and several other people paid for other things in a single transaction. This is a way to save on fees.


Not sure why this question was down voted, some explanation would have helped...

In general: A p2sh tx sends data to a hash. The hash is a one way function, so we cannot know, what content is behind the hash... also there is no double mining or similar. There is a funding tx, and a spending tx. Like with any other tx, you mine a first tx from someone else to my account, and if I spend the tx, another tx is created and mined. Same applies to p2sh transactions.

The funding tx is created, defining a condition for spending the funds (e.g. multisig, with a “type3” address), and post this tx to the network. Everyone can see the tx, but nobody knows, what’s inside (privacy gain). If then one day these funds get spent, the content of the hash is made visible, and only then one can see, what the original funding tx was about.

Advantage beside privacy: the funding of the tx is fairly cheap on fees, cause you have a short tx with several bytes. The spending tx however, reveals the hash contents, and if multisig, can be very long (increasing tx size and thus fee costs).

I found the best explanation for this in Andreas book “Mastering Bitcoin”, which is also available online.


Would it be any cheaper to transfer US dollars to Canadian using Bitcoin?

If you exchange your US Dollars for Bitcoin and then use Bitcoin to buy Canadian Dollars, you will pay the exchange fees for that plus some more hidden costs such as for the bank transfers to fund these trades and the insurance cost for your Bitcoin exchange companies going bankrupt on you or the exchange rate dropping in between your purchase of Bitcoin and purchase of Canadian Dollars. Due to the volatility of Bitcoin and the surprisingly high rate of defaults of Bitcoin exchanges, these risks are, if priced correctly, much more costly than one might be used to in more established financial business.

Here are some wild estimates:

Low volume purchases of Bitcoin might cost up to about 0.5% in exchange fees.
Same for low volume sales of Bitcoin (i.e. for Canadian Dollars).
If you want to avoid the risk of the exchange rate moving between these transaction, you should budget for a similar loss (0.5%) due to the ask-bid spread.
Let us assume it takes you a week to complete everything including the money transfers, and that the risk of losing all is approximately the rate at which Bitcoin exchanges have historically defaulted (approximately half after one year of operation), and that you stand to lose all money involved if that happens. Then a fair insurance against this risk is another 1%.

The total of all this is an expense, either directly or as risk allowance to insure yourself, of 2.5%. Since you may be able to improve a bit on every point, this could be called competitive with banks' international currency exchanges (which have once been described to me by a banker as carrying a guaranteed flat-rate 2.5% fee plus hidden costs).

But if you only pay $157 for exchanging $9000 in your particular case, which is about 1.7%, it will only be advantageous to use Bitcoin if either you can improve significantly on my example, or manage to talk yourself into ignoring or neglecting the risk of the Bitcoin exchange defaulting on its obligation to you. Of course, there are many entrepreneurs, myself included, who are trying to improve on the poor track record of Bitcoin exchanges!

EDIT: From the comments to the question, my best guess currently is that you effectively paid 2.57% in fees with the solution you now have. This makes it a tough call to answer if using Bitcoin is advantageous---by my example, it only is if you put a very low value on the added hazzle of dealing with at least one company acting as a Bitcoin exchange. In practice, you might find it possible to improve on my estimates, so the answer might be that it may be advantageous, depending on circumstances.


How does the New York subpoena of important people in Bitcoin affect the currency?

It certainly doesn't mean the end of Bitcoin it just means the the authorities are taking it seriously and making an attempt to understand how the currency works.

It might mean the end of money laundering and evasive techniques to disguise where your money is coming from as the feds will be pushing to regulate it

I dont think it's a bad thing and I also dont think it should be a surprise to anyone, if you millions of dollars of unregulated currency floating about, of cause it's going to be regulated at some point


Most mine-able coins are essentially clones of the bitcoin code and therefore have testnet. Many alt-coins do not have very active testnets so finding another peer on this network can take time, but given enough patience, your alt-coin testnet node will find another connection.

If you are impatient you can google for "testnet addnode" and include the coin you are looking for; this will (hopefully) find forum posts of people who have setup/found the IP address of a testnet in your desired coin, adding this to your configuration file will make your client attempt to connect to this IP on startup. If you need help with a particular coin, let me know :)


How to scan QR code with multibit wallet application?

Webcams aren't supported in MultiBit.

You can however paste a QR code using the 'paste' button in the side bar. You can also drag and drop an image onto the existing QR code in the side bar.


What is the scriptCode in a P2WSH transaction?

Yes, the scriptCode would be that multisig script.


Yes for sure, You can send requests to electrum servers or your server (recommended) by sending JSON-RPC requests.

Take a look on Electrum documentation

https://electrumx.readthedocs.io/en/latest/protocol-methods.html

for bitcoin cash use Electroncash  same commands work.

For example, to broadcast a hex transaction you can call

{"id": 1, "method": "blockchain.transaction.broadcast", "params": ["YOUR_HEX_TRANSACTION"]}

There are no wallet commands available, but blockchain commands.


Eventually, the difficulty will drop. This will cause the mining to increase. This will cause an increase in the price because the verification problem holding the price down is gone.

There's another factor too -- once you've bought mining hardware, the cost of the hardware is a sunk cost. So long as it can pay for its electricity, you'll keep it running. A typical mining rig today produces Bitcoins worth about 60 times its cost of electricity (1W/GH/s). So the price would have to drop astronomically for people to stop mining.

It could, of course, significantly reduce the incentive for miners to invest in new equipment. But that will just keep the difficulty from rising. It won't significantly slow confirmations.

Also, people might see that the difficulty is going to drop and the price is going to come back up. So they might see this as a great opportunity to get new mining hardware in place in expectation of the easier mining.


Doubt regarding hashing function in Merkle trees

combined together to get the penultimate hash which together with the nonce

That's not correct. The "penultimate hash" is the merkle root. The nonce is not part of the merkle root at all. That is part of the block header and is hashed along with the merkle root and several other things in order to get the block hash.

  This merkle tree structure is provided so that one can go back retracing to the roots (i.e to the initial transactions) to verify them, right?

No. It is provided to commit all of the transactions to the block and to allow someone to prove that a particular transaction is in that block.

  If that be the case, how does the merkle tree allow one to retrace back and verify transactions?

It doesn't. Given a transaction, you cannot determine whether it is part of the merkle tree without knowing the hashes of other branches in the tree. The goal isn't to determine whether a transaction is in the merkle tree yourself, rather it is to allow for someone else to prove that a transaction is in the merkle tree by having them provide the hashes of all of the other branches in the tree in the path to the root.

In your example of 4 transactions, if you wanted to prove that C is part of the merkle tree, you would provide C, the hash of D, and the hash AB. The verifier would hash C, hash it with the hash of D to get CD, and hash that with AB in order to get the root. Then they would check whether the root that they calculated matches the root in the block header. In this way, a node can prove to a SPV client that a transaction was included in the blockchain.


The method described in the post has nothing to to with OP_RETURN, but is concerned with the SIGOP limits in a block.

Each block has a limit on the number of SIGOPs that can be present in transactions in that block. Signature validation is a CPU intensive operation, and the limit exists to ensure that no block gets too big to validate on regular hardware.

The post describes how a single transaction can be made to consume up to 225 SIGOPS fairly trivially, limiting the number of such transactions in a block to 88. These utxos can be redeemed to any regular output, or an OP_RETURN.

Note that the post is from 2015, and the activation of segwit has increased the total SIGOPs allowed by a factor of 4, so this attack could cost more now.


Actually, the BlochChain API is pretty good and Ben Reeves has done a nice work implementing it. And for the most part, for free. You only have to know how to send HTTP requests from your code, and parse the Json your app receives. If you think his API is not complete or unworking, do it yourself and make him competition ;-)

An API is designed for programmers, not simple users. What do you want to do exactly?


The BlockCypher web services supports 3 different cryptocurrencies right now, more may be added in the future. All coins have the exact same services exposed so it's easy to develop for all of them at once.


Are the mining incentives of bitcoin compatible with the existence of a competing Proof-of-Work chain?

Both chain in your scenarios can coexist because the current value of a coin (and the current mining reward) isn't the only factor miners are taking into consideration when they have the choice to mine two different coins.

They also put their personal conviction into consideration when choosing what to mine. If they prefer the change brought in chain A, why would they mine chain B that doesn't have it ? (Mining chain B in case of a HF would be being against chain A in that case)

So yeah both chain A & B can coexist as long as the differences between them are big enough. If not their would be no incentive to choose to mine the chain with the least value.


cgminer with two R9 290 giving me headaches

I managed to fix this by using the kalroth patched version of cgminer 3.7.2. Sometimes my cards still black screen after rebooting the mining process, but generally it runs quitestable once started from a clean reboot.


Can an old passphrase recover my bitcoins using an old backup wallet.dat file?

The passphrase is stored as part of the wallet.dat file, so yes, that should work, as long as you haven't received any payments to addresses with private keys that don't exist in the old wallet.

Note that these received payments can actually occur when you send a payment, as a hidden "change" amount is sent to an unused hidden private key which is stored in your wallet file. Your old wallet file should have had stored 100 of these generated in advance though, which means you're probably ok as long as you haven't used more than 100 private keys since your backup.

Most payments you make will use one of the pre-generated private keys, as will each receiving addresses you create.


What information is available in the blockchain

This information does not exist on the blockchain. It is gathered from exchanges. The blockchain has no idea what fiat is nor does it care. The only information that exists on the blockchain that sites like coinmarketcap uses is the total number of coins in existence which is then used to calculate the market cap. Everything else is from exchanges.


What does the listaddressgroupings rpc method do?

listaddressgroupings is a RPC call that really could have been left an internal method, but the core devs decided to expose it in order to give users more control and awareness of Bitcoin's privacy issues.

Let me explain:

As you probably know, when you make a purchase, the bitcoind or bitcoin-qt client (which both use bitcoin-core) return your change by default to a new address.  Well, if decide to use that address for another transaction, you have created a chain of "connectable" transactions.  If you're not careful, there are various other ways that you can create connected transactions (like always using the same receiving address).  However, if you already generate a new address to receive Bitcoins, this isn't a problem.

There are already numerous programs available that have the ability to scan the blockchain and list such connected transaction chains, which are definite proof that the addresses in question are or have been in the same wallet.

listaddressgroupings is a method that allow users to have the same ability to discern which groups of their addresses are connected on the public blockchain.  It allows users to use the (relatively) new coin control functionality with greater awareness of potential privacy-revealing issues.


Trial recovery of blockchain.info Wallet to MultiBit HD wallet

MultiBit HD supports BIP39 seed phrases for BIP32/44 wallets. If a different deterministic algorithm is used then the seed phrase is not compatible. Also note that due to the limitations of SPV mode MultiBit HD is not currently able to support accounts other than 0.

You can read more on this here: https://multibit.org/en/help/hd0.3/how-spv-works.html


No the blockchain does not contain IP addresses.

The bitcoin node or bitcoin API server (if used) that you initially send your transaction will know the IP though and they could keep it in their own databases.

For anonymous buying/selling you can use the Tor network. You may also be interested in mixing to anonymize bitcoin address (e.g. if you bought your bitcoins from an online exchange that has your IP plus much more).


How should I get all transaction history in a format that I can analyze?

I wanted to do a similar thing to put all the transactions in the database (it was PostgreSQL for me, but you can use anything). After some research ended up using bitcoin abe and it worked great for me. Be patient though, it does take a long time - was several days in my case.


The transaction hash is determined by the contents of the transaction.  As such the payment sender determines the transaction hash so it is not random.

But the SatoshiDICE bettor does not know the secret that SatoshiDICE will use and the result of the hash after including the secret is for all practical purposes random.

To know that SatoshiDICE didn't cheat, the hash of the secret is known to the bettor in advance and then released the following day.  So the bettor can verify that correct secret was indeed used, and with that verify that the correct payout occurred.

Since SatoshiDICE wagers are bets against the house, all that is needed is a way to determine that the house properly made each payout.  This method of using the transction hash plus secret (revealed at a later time) succeeds at providing  just that.


Read an XPUB list of transactions to Python using my own node

Something like this might be a lead for what you're after.  It gives you a list of addresses which you can then query your node by RPC.

You then use the getbalance RPC method.  People I know use the python slickrpc package from pypi.


Check when transaction was added to the mempool?

The getrawmempool interface provides this information in the time field, though it is potentially very slow to respond with a large number of transactions in the mempool. It does not record this time once the transaction is removed from the mempool for non-wallet transactions, so it either needs to be gathered from this interface or recorded on addition with the zmq socket.

"result": {
    "89ee39117b4b55e54ace29c631eef80a875ae109a4fbd79ddd10b6f21329e88d": {
        "size": 225,
        "fee": 0.00000573,
        "modifiedfee": 0.00000573,
        "time": 1556802637,
        "height": 574268,
        "descendantcount": 2,
        "descendantsize": 451,
        "descendantfees": 3247,
        "ancestorcount": 1,
        "ancestorsize": 225,
        "ancestorfees": 573,
        "wtxid": "89ee39117b4b55e54ace29c631eef80a875ae109a4fbd79ddd10b6f21329e88d",
        "depends": [

        ]
    }
}


What situations will you lose your bitcoins during backup?

When you do certain actions (usually a send), a new key is generated. Your backup pre-generates 100 of these keys. Once you need more than 100 keys generated, your backup no longer knows about the new keys. This means you should perform backups regularly, at least every 100 transactions.


So first of all, 'anti-economical' is not a proper word and doesn't have a clear definition.

But I'll try to answer the question:

1) It is true that in a perfect market for mining, the cost of mining should be equal to the mining revenues generated. But think of it: For most of bitcoin's history they weren't worth very much so even if at the time people spent as much on mining as the bitcoins were worth this would have been a small amount. Most of the current value of bitcoins came through the price increase. Overall, this means that only a fraction of the value of bitcoin's were actually spent on mining.

2) I think it's wrong to say that those resources were 'lost forever' as they served to verify transactions and maintain the bitcoin network. This is an extremely valuable service. It would be more adequate to compare the costs of mining to the costs of maintaining the bank's payment processing infrastructure. So it only makes sense to say "resources spent on mining are lost forever" if you applied the same to a significant portion of bank's expenses.

3) In the medium to long-term miners will make most and then all of their revenues not from mining new coins but from transaction fees. So we would expect that the total cost of mining will end up being equal to the transaction fees. This means that transaction fees or how much people value making bitcoin transactions will drive miner's revenues and thus how much they invest in mining hardware and electricity which in turn will drive the difficulty. That seems like a pretty efficient system to me.


Is proof-of-stake a viable alternative / augmentation to proof-of-work?

This answer might be enough to make proof-of-stake not needed.


explain decoderawtransaction output fields and interpretation

Your post is a bit long, in stack exchange we prefer shotrt, easy to answer questions - see here: https://bitcoin.stackexchange.com/help/how-to-ask

You probably have an example of a JSON interpretation as reference. From where do you have it? As everyone can interpret a raw transaction, I think it is best to reference the original raw transaction from bitcoin.org. This is anambigous. It would look like this (non-segwit, to keep it easy going. Segwit only on demand :-)

VERSION
TX_IN COUNT         (how many input this tx has)
 TX_IN[0...n]
  OutPoint hash     (the previous tx where funds come from)
  OutPoint index    (the n'th TX_IN)
  Script Length     (the length of the following Script Sig)
  Script Sig        (signature)
  Sequence          (a sequence field, originally intended to disable lock-time)
TX_OUT COUNT        (how many outputs this tx has)
 TX_OUT[0...n]
  Value             (the value in Satoshis)
  PK_Script Length  (length of the following script)
  pk_script         (the script, which defines the condition, under which the funds can be spent)
LOCKTIME            (earliest time or earliest block when that transaction may be added to the block chain)

The assembly of a tx before to be sent was pretty well explained by the answer of @amaclin here.

  How can the amount of each input within the vin subset be determined?

The wallet software would need to lookup the values when wanting to spend a new tx. Therefor a reference to a previous tx is required, where v_in is found. If unsufficient for the current spent, then another v_in or even another tx with its v_in will be used (TX_IN count would be increased).

  How can the scriptSig be validated, like: is the input CLTV or CSV
  locked?

I do not understand what you mean by this. Scriptsig and CLTV/CSV are not directly linked to scriptsig. CLTV and CSV both came into the game by BIP-68 and BIP-112. CLTV (as also locktime) are both absolute timelocks, with CSV we talk about relative timelocks. So they define, when a transaction's output can be spent. Maybe worthwhile to lookup in the BIPs. There is also lots in the forum here and in bitcointalk.

Scriptsig (in general) is validated with the hash and the pubkey. Ken Shirrif's blog (link at the bottom) explains very well. Scriptsig proofs, that you had the private key ("you are the rightful owner") to spend this transaction. The privkey signs a hash of the tx, which is followed by the pubkey. There can be more to it, but I want to stay general. Here is an example how you can verify a signature at the unixoide systems shell with openssl (bitcoin always uses hex encoded data to do hashes, and openssl needs a PEM formatted key):

sig=30450221009a29101094b283ae62a6fed68603c554ca3a624b9a78d83e8065edcf97ae231b02202cbed6e796ee6f4caf30edef8f5597a08a6be265d6601ad92283990b55c038fa
pk=03F5D0FB955F95DD6BE6115CE85661DB412EC6A08ABCBFCE7DA0BA8297C6CC0EC4
hash=4eb4dccd727e81315a9ff801c205efc62635471cf8668e42c1c8aebfb51500a3
printf $( echo $hash | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > tmp_utx_dsha256.hex
echo "MDYwEAYHKoZIzj0CAQYFK4EEAAoDIgAD9dD7lV+V3WvmEVzoVmHbQS7GoIq8v859oLqCl8bMDsQ=" > cat pubkey.pem
printf $( echo $sig | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > tmp_sig.hex
openssl pkeyutl <tmp_utx_dsha256.hex -verify -pubin -inkey pubkey.pem -sigfile tmp_sig.hex

  Does the redeemScript (if p2sh) validate to true (e.g. required number
  of sigs available, other IF/ELSE rules fulfilled)?

The redeemscript is basically a hash of "something". It has the advantage to "hide", what is intended, when the funding transaction is mined into the blockchain. When you create your spending transaction, then the data of your p2sh script is revealed. The common usage is a multisig script. But you can put all type of code into it, which would define the condition, under which funds can be spent (next to multisig, any type of smart contracts, ...). There are limitations to it. The OPCODES, that can be used are explained here. In bitcoin.org are also explanations on p2sh.

I learned all this from 2 additional references: the unbelievably well written book "Mastering Bitcoin" from Andreas, and a very good explanation on transactions by Ken Shirrif.


How can Auroracoin be the 4th crypto-coin by market cap if it's unreleased yet?

Turns out I was wrong. It is mineable right away and it is actively being traded in different exchanges, as cryptorush.in and cryptsy. What hasn't happened yet is the release of the pre-mined coins (50% of final amount), which will be given to Icelandic citizens.

Too bad the official page isn't clear about this (info on pools and exchanges is a bit hidden in the forums), nor does it list anywhere a list of exchanges dealing with it or pools for mining it - the cryptocointalk page linked first states all that.


Relationship of Bitcoin address and Public Key

Addresses are textually encoded public key hashes, which means that somebody in possession of only the address cannot read the public key - but eventually the public key must be revealed in order to spend the funds which are locked by an address - so it may become a privacy concern if addresses are reused, which is discouraged anyway.

With a HD wallet, we have what are known as extended public keys, which, as well as a regular secp256k1 public key, also contain a chaining code and an index, and a fingerprint of the parent key. They usually begin with xpub. These should never be publicly shared as it is not necessary for anybody to know more than the secp256k1 public key in order to verify information from the blockchain. The purpose of the extended key is to allow you to create more child keys from a given key pair.

In the case of non-hardeded extended public keys, it is possible for anybody with the xpub to create the extended child public keys, which could reveal a lot more information linking your transaction activity. These kind of keys are useful for auditing purposes as you do not need to reveal private keys, but should not be shared otherwise.

Also note that, even if you never share extended public keys and you never reuse addresses, this does not give any guarantee of privacy. It may still be possible to link your transactions if multiple inputs are used, or if you transact with KYC services which relate them to other identity documents. You should never assume that any KYC service is not sharing that information with other parties, or that they won't at some point be hacked and have all of the data dumped on the web.

In regards to the way addresses are created from public keys, this is nicely illustrated by the diagram below, taken from the bitcoin wiki


How to change RPC port for bitcoind? (rpcport=xxx in bitcoin.conf doesn't work)

Found the solution: rpcport needs to be in the [test] section

Please update your original config file to read:

testnet=1
server=1
daemon=1
txindex=1
rpcuser=XXXXXXXXXXXXXXXXXXXXXXX
rpcpassword=XXXXXXXXXXXXXXXXXXX
rpcallowip=127.0.0.1
onlynet=ipv4
zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333
[test]
rpcport=19832

And restart the daemon. Also take a look at Can't specify rpcport for testnet for related changes to other options. We were being warned what to do in the log file. ~/.bitcoin/testnet3/debug.log includes the line Warning: Config setting for -rpcport only applied on test network when in [test] section.

We could have picked this up faster had (we read the log file! And if) the example bitcoin.conf made a mention of now requiring sections.

Would be great if you could make this the ticked solution instead!


Can importing a bitcoin address retrieve the lost coins with it?

If you have the private key for the address that holds the Bitcoin, you still have control over those coins and they wouldn’t be considered lost. If you sent bitcoin to an address for which you don’t have the private key, then you cannot retrieve them unless the owner of the private key to whom you sent them sends the Bitcoin back to your address or gives you the private key to their address.


Why was the RIPEMD-160 hash algorithms chosen before SHA-1?

There are a multitude of reasons.

As @ThePiachu mentioned, there is a theoretical 2^60 bit attack that is possible on SHA-1, meaning that the algorithm is weaker than designed.

RIPEMD-160 was designed in the open academic community, in contrast to the NSA designed SHA-1 and SHA-2 algorithms.
It is worth noting that Satoshi could've used SHA2-256 twice and truncated the second digest to 160 bits as this is equally secure. The fact that he didn't is some evidence to show that his decision was a conscious decision to use RIPEMD-160 over the NSA suit of algorithms.

Lastly, I believe RIPEMD is based on a different design to the SHA1/SHA2 algorithms, and thus attacks that apply to one may not be transferable to the other (which is good).


channel count differs on my site and 1ML

Since 1ml is not open source I can not give the exact reason. But some things are known that add to the discussion. The information about your node that you get from getinfo or listfunds are accurate and up to date.

New channels have to be announced over the gossip protocol so it will take some time until 1ml is aware of your most recent channels. This is one certain reason for the difference.

Another reason is that 1ml does not see your private channels since they are not announced over the gossip protocol. This could be the reason if the difference exists for a longer time.

Also it seems to me from my user experience from using 1ml that 1ml does not update its info in real time but does some batch processing (this part is speculation as their software is closed source) anyway this could also slow down the process of updating your node info.


Bitcoin-qt -how does it choose the address to take money from when sending btcs

There's a patch awaiting merging into the Satoshi client which allows you to see the balance on each address and pick which address(es) you want to pay from.

See here for more description and a video of it in action.

Lots of people have been showing their support for this feature by posting "+1" comments on the pull request despite requests that they stop doing so.


PoolserverJ seems the best so far and easiest to set up.

Pushpool was the original but has some issues. The documentation is also a little hazy if you're a newbie to linux.

P2Pool is a decentralised pool, meaning that if you want to set up your own private pool, you can't use P2Pool.


Why hasn't bitcoin mining been scaled / wouldn't that ruin the concept?

The Bitcoin network automatically adjusts "difficulty" to produce a block every 10 minutes on average. As the difficulty rises it takes many more hashing attempts to find a block, so no matter how many exaflops in the network (we are already over 1) the number of coins will still be around 3600 daily (until the reward halves again.)

The only advantage to scaling is if you can scale faster and cheaper than the other miners, and even they you will only see an earning advantage until the difficulty changes and/or the competition steps up and matches their increase.

Technical Explaination of the mechanism:
https://en.bitcoin.it/wiki/Difficulty

More detailed and descriptive link for newcomers:
http://coin.furuknap.net/understanding-bitcoin-mining-difficulty/


Stable bitcoind build with watch-only wallets

Depends on your OS, but building it yourself is crazy easy on OSX / Linux. It's an old enough pull request that it doesn't contain autotools.

$ wget https://github.com/sipa/bitcoin/archive/watchonly.zip
$ unzip watchonly
$ cd watchonly
$ qmake
$ make -j8

I'd supply builds for you myself, but there's absolutely no reason to trust that my binaries aren't backdoored or malicious in some other fashion.


I think my bitcoin wallet was hacked. What to do?

Probably not. You can try to look at the addresses the coins were transferred to (or, if those were since sent elsewhere, at those addresses too) and see if you can figure out who they belong to. If the thief is somewhat competent, however, it's a good bet that he's made it very hard to track. If you can determine the identity, you might be able to take them to a court (small claims, civil, criminal...I don't know, and might depend on how many bitcoins were stolen, and where in the world you and your thief live) to demand the bitcoins (or equivalent value) back. But as far as the Bitcoin protocol itself goes: no, you cannot reverse the transaction.

To prevent this in the future, make sure that your computer is free of malware, always encrypt your wallet with a secure password, and consider using an offline wallet. See bitcoin.org's Securing your wallet page for other tips.

Are you sure that the addresses don't belong to you, maybe in some online service you used and forgot about?


Litecoin-qt getblocktemplate ￼Support for 'segwit' rule requires explicit client support (code -8)

You need to explictly declare the segwit rule:

litecoin-cli getblocktemplate '{"rules":["segwit"]}'


Is it possible to brute force the Secure Element of Ledger Nano S?

No. Secure elements are designed to be resistant to physical attacks. So you shouldn't be able to do anything physical to the chip that allows you to get data off of it. They are designed to prevent unauthorized access to their data so they also are more than just storage devices.

While you can desolder the chip and attach wires to its pins in order to interact with it physically, the chip specifications are not public and require signing an NDA. The manufacturers make it difficult for the general public to be able to know the functionality and ways to interact with the secure element. They are doing security through obscurity.

Furthermore, secure elements are generally complete systems with their own CPU, RAM, storage, etc. So it isn't just a storage device where you can get the contents. Rather they are tiny computers where you can only interact with them in a very specific way.


If a wallet has multiple addresses, is the money in the wallet or in the address?

The bitcoins you received with an address are always associated with that address. The wallet is merely summing up the balances of individual addresses contained in the wallet. You can move addresses between wallets by exporting the private key from one wallet and importing them in another and the bitcoins will show up in the second wallet as well.


Why are there more than two transaction outputs in a coinbase transaction?

A coinbase transaction can have as many outputs as the miner who created it wants. You may see that there are not just one output for the reward, sometimes there are multiple outputs so that the coinbase transaction pays to multiple miners. Additionally, there may be other 0 value OP_RETURN outputs if the miner so chooses. Typically this is because the miner wants to include some additional data for another protocol that they are using.
Additional outputs are not required by Bitcoin's consensus protocol. In fact, Bitcoin does not require any particular outputs. A miner could forfeit all of the generated coins by creating an output with less than the correct amount. A miner can include other OP_RETURN outputs just because they feel like it. Even the BIP 141 OP_RETURN is only required if the block contains any segwit transactions, so if it does not, it doesn't need to be included.
The most common reason for other outputs that go to addresses and have positive value is for mining pools which directly pay their miners from the coinbase reward. Most mining pools do not do this, but some do. There are also peer-to-peer mining pools such as p2pool which directly pay the participating miners from the coinbase transaction.
For additional OP_RETURN outputs, the miner is typically participating in another consensus protocol that require commitments in the block. These are not required for Bitcoin, but rather for something else. There are two common protocols that miners participate in: p2pool, and merged mining. P2pool uses an additional OP_RETURN output to commit to some p2pool data that is stored elsewhere. Merged mining uses the Bitcoin blockchain to help protect an altcoin's blockchain by including a commitment from the altcoin in a Bitcoin block. This is typically done by including a hash in an OP_RETURN output.


Don't worry, you've not been hacked. This is just one of your wallet's change addresses:

https://en.bitcoin.it/wiki/Change
How does change work in a bitcoin transaction?
Why does Bitcoin send the "change" to a different address?


For most transactions, the input scriptSig will be a push of the signature followed by a push of the public key. The "push" part is done with script opcodes which say how long it is, and the signature is encoded as DER.

47/48 are the push opcodes, to say 0x47 or 0x48 bytes will follow. Then the signature is encoded as:
0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S] [sighash-type]
So the total length in your examples is either 0x44 or 0x45, and the R-length is 0x20 or 0x21.


What exactly would need to be added to Bitcoin to support Zerocoin?

I found out that it's explained quite exactly here

https://github.com/Zerocoin/libzerocoin/wiki/Integrating-with-bitcoin-clients


My bitcoin-qt client connection status and uptime at http://blockchain.info/connected-nodes does not show reliably - why?

The list on http://blockchain.info/connected-nodes is just a list of nodes currently connected to that specific business' bitcoind server. It has no connection to the list of all Bitcoin nodes connected to other nodes. This hypothetical list doesn't exist anywhere, for obvious reasons, and would be 10 to 20 times longer than blockchain.info's list.

Blockchain.info's server is not authoratative in any way and has no formal connection to the "official" Bitcoin client (bitcoin-qt), the Bitcoin project, or Bitcoin.org.

As for the 360 minutes thing, Blockchain.info's bitcoind server probably prunes clients connected for 6 hours for whatever reasons that business has decided to do that. Or perhaps their bitcoind server lost its internet connection momentarily around 6 hours before you checked their connected nodes list.


Jelurida Public License (jpl) and IGNIS ico

If you held NXT during the ignis snapshop on 2017 Dec, 28 you'd receive .5 ignis once the Ardor platform releases in 2018. As for the JPL license, supposedly you'd receive 10% of the coins being created with a new fork of NXT. Also child chains on Ardor are giving out airdrops if you hold ignis like bitswift. (https://www.jelurida.com/bitswift)

  Paul Busch also announced that he will be giving away 10% of all
  Bitswift tokens to all holders of Ignis coins, relative to the amount
  of Ignis coins they are allocated at the time of the Ardor Genesis
  Snapshot. However, all funds for this 10% giveaway will come from
  Paul’s own personal funds. Bitswift does not intend to compete with
  Ignis as a child chain, but rather to complement the entire platform.
  Additionally, further customized development will be explored that
  will not only differentiate the two chains, but also provide the
  needed customizations that Bitswift requires. Some features will also
  be disabled due to business reasons as requested by Bitswift.


send btc from specific input without running bitcoind

You can implement your own very light bitcoin client. It should support version and tx messages: https://en.bitcoin.it/wiki/Protocol_documentation

So, you make TCP connection to any bitcoin node with white IP. You can choose blockchain.info, for example. Your light client sends version message, remote node sends you getdata message, and you send back your transaction in tx message. After that remote node verifies it and spreads to other nodes, and to entire network.

You don't have to care about safety. Noone can steal your bitcoins if you correctly generated raw transaction.


I had money on MtGox, can I get it back?

MtGox has millions of USD missing according to the latest news reports. The final draft of what, where, how and why has yet to be published by the administrator however.

Some customers who lost money with MtGox are under the false impression that since their funds were in fiat currency instead of Bitcoin they would be safe and receive all of their money back, this simply isn't the case.

The administrator has already hinted the remaining coins would be sold and all assets pooled for even redistribution. There has been strong support for receiving Bitcoin instead of fiat amongst some creditors but it has yet to be seen how the administrator distributes the remaining funds.

If however MtGox is sold to another entity then this would obviously change the dynamics of the situation. For now there is not much to do but wait for the administrator to finalize his report and wait on an outcome for redistribution or sale.


What exactly is the "point at infinity"?

It's a point that is added to the points on the curve. Together they form a group. It has the following properties:

(x,y) + (x,-y) = infinity
(x,y) + infinity = (x,y)
infinity + (x,y) = (x y)

In other words, the point at infinity is the identity element of the addition in the group. Therefore some people write the point at infinity as "0".

  Is there more than one "point at infinity"

Just one.

  How can I identify if my EC generated x and y are the "point of infinity"?

The point at infinity is not on the curve, so it does not have x or y coordinates. It appears whenever a point is added to its own negation (for which the normal addition rule has no answer).

  Is there a way to calculate the "point of infinity"?

It simply is "the point at infinity", there is nothing to be calculated about it.


Bitcoin 51% majority miner attack - question on the role of user activated soft forks as defense tactic

A soft fork describes a situation in which the consensus rules of the network are tightened: in simple terms, something that was allowed before is no longer allowed.

After a soft fork, old nodes will still be a part of the network, even if they are unaware of this rule-tightening. However, miners will need to craft blocks according to the new rules, or else the nodes running the new code will ignore their blocks.

The term ‘user activated soft fork’ more specifically refers to a soft fork that is initiated by nodes, instead of miners.

With that in mind, a user activated soft fork cannot protect against a 51% attack, because there is no way to tighten the rules which would exclude a single miner from being able to create blocks. A valid block requires no identifying information from the miner, it is simply seen by the network to either be valid, or invalid.

Proof of work is the method by which the network’s history is secured. If this method fails, it is unclear how the network’s nodes could coordinate to continue onwards honestly. Some people have suggest changing to a different proof of work algorithm, but if an attacker can gain enough resources to outrun the entire honest network of SHA256 miners, I’m not sure I see any reason why they couldn’t just do the same for the next algorithm as well.

Forking to a different consensus algorithm (ie, not proof of work) is another option, but I am yet to see an algorithm that provides the same security and economic guarantees that proof of work does, so this option has an unclear future at best. Such a change would likely require a hard fork to execute cleanly anyways, so it seems to be outside the scope of this question.


Given a set of consecutive HD private keys, can you generate the next private key without knowing the master private key?

No, this cannot be found out if we assume

(which is a desired property of BIP32 and which I'm going to refer to as Φ describing the problem φ) to be true and assume that n+m <= 2^32 - 2

Assume you have an efficient solver ξ : P^m → P for the problem you described with

P := { a ∈ ℕ | 1 <= a <= 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140}

being the set of valid secp256k1 ECDSA standard private keys.

Let Ψ = (r_1, r_2, ..., r_{m+1}) be an instance of a problem impossible to solve efficiently if Φ is true.

Solve φ as follows: If and only if ξ(r_1, r_2, ..., r_m) = r_{m+1}, return true, otherwise return false. This contradicts Φ.


If you want to run your private pool with a minimal amount of extra configuration, run bitcoind with -server and some additional configuration for RPC commands. This would allow you to create a simple pool for your personal use.

However, are you sure your mining endeavours would be profitable? You'd better check my calculator website that I linked right there. You might find it not worth your time to even set this thing up unless you have some really good GPUs in those machines.


Yes, the information is public and in the ledger history.

you can find how inflation works in Stellar.org's mandate
https://www.stellar.org/about/mandate/#Stellar_creation
and
https://www.stellar.org/developers/learn/concepts/inflation.html

in a nutshell: you can look at the inflation transaction that runs every week and look at its metadata. The metadata will tell you who was the recipient of the inflation.

As far as re-computing the input, you need to:

Download the historical ledger this inflation transaction ran
against (so the one right before it)
(can be skipped to get a fairly close approximation) apply the transactions that precede inflation during that ledger round (can be done with the metadata or running a node)
Look at the balance and InfladionDest of all accounts in the ledger to compute the vote tally. Voting power is the STR balance in the account.

Nicolas


How does block propagation delay not cause accidental forks?

How does bitcoin prevent accidental forks like this?

It doesn't. Bitcoin make little effort to prevent forks at a technical level, instead relying on the fact that when a fork does happen, it can be resolved by waiting for additional blocks and picking the chain with the most work.
As Pieter mentioned, the mining mechanism itself prevents long term forks. The act of mining extends one chain beyond the other, reducing the shorter chain to a temporary and now discarded fork.
For miners specifically, they put in a lot of effort to avoid this - mining on even a minor fork is inherently risky, as they could lose their blocks if the other side of the fork wins, thus losing the block rewards.
To reduce this risk, all serious miners join high speed links as Bitcoin Fibre. These are specially designed to minimize propagation delay.
No serious mining operation will be looking at propagation delays of 122 seconds - those would only be happening at nodes run by people with absolutely abysmal peering and internet access. For the vast majority of nodes, blocks are received in a few seconds, and for miners, usually in <1s.


I don't know if this issue still a problem? But Sending the amount property as a string worked for me.


Is there a difference between bytes and virtual bytes (vbytes)?

Yes, they are referring to two different metrics: size and virtual size (vsize).

The size in [bytes] of a transaction refers to the raw byte length of its serialized format. It is used to measure the data footprint of transactions when relayed on the network or stored on disk.

The vsize in [vbytes] refers to a transaction's weighted size under segwit's rules. It is used to compare how much blockweight needs to be allocated to confirm a transaction.

Block weight limit
Bitcoin blocks are limited in their transaction capacity. Before Segregated Witness (segwit) was activated, blocks were limited to a blocksize of 1,000,000 bytes. Under that paradigm, the size of a transaction corresponded to the byte count of its serialized format.
The activation of the segwit softfork replaced the blocksize limit with a blockweight limit of 4,000,000 [weight units (wu)]. The new protocol rule defines the weight of a transaction as the sum of the witness bytes counted at a factor of one and non-witness bytes counted at a factor of four.
weight [wu] = 4 [wu/B] × non-witness length [B] + 1 [wu/B] × witness length [B]

Since non-segwit transactions don't have any witness data, this results in equivalent rules for non-segwit blocks before and after the rule change:
1 B / 1,000,000 B = 4 wu / 4,000,000 wu

One byte is the same portion of the previous blocksize limit as four weight units of the new blockweight limit. Transactions without witnesses, non-segwit transactions, take exactly the same portion of the blockweight as they took of the blocksize prior to segwit activation. This allowed segwit to be introduced as a forward compatible soft fork.
Segwit Discount
For segwit transactions, which do include witness data, the resulting transaction weight is strictly smaller than 4 × size due to the witness bytes contributing at a lower factor. This results in a lower relative portion of the blockweight to include a segwit transactions than an equivalent non-segwit transaction. The adoption of the segwit output format results in an effective capacity increase. Segwit blocks may exceed raw byte sizes of 1,000,000 bytes, with e.g. the biggest block to date achieving a raw byte size 2,377,364 bytes.
Feerates and their units
Before segwit activated, users measured transaction sizes in [bytes] and feerates in [satoshis per byte]. Since segwit activated, the protocol measures transactions by weight in [weight units]. At the protocol level, this shifts the range of feerate values by a factor of four.
Segwit introduces the measure virtual size (vsize) in [virtual bytes (vbytes)] to ease comparison of feerates before and after segwit activation. The vsize is calculated by dividing the transaction weight by four: vsize [vB] = weight [wu] / 4.
The range of values of fee per vsize thus matches the range of the pre-segwit fee per size. To this day (Oct 2020), it remains popular to track feerates in [satoshis per vbyte].
If you are looking for an approachable example, check out this detailed comparison with concrete values:
How do virtual size, stripped size and raw size compare between legacy address formats and native segwit?


Javascript library or code that can convert an "uncompressed" bitcoin private key to a compressed one

Update:

Oops sorry I read "public key". A private key can be converted to a public key that is either compressed on uncompressed, but raw EC private keys are always 32 bytes. That website appears to be generating what is called Wallet Input Format (WIF) which is used to transfer private keys between software applications. To convert to hex:

decode using Base58Check
drop 1st byte
If the WIF started with K or L, then also drop the last byte (0x01) which denotes the private key corresponds to a compressed public key

Example:

WIF: 5J2zgrqrMFcnWALe5foVPzaA8VLNJV8zoZn37WfQCu8DYDCVmXE

Base58Check decoded: 801cdb52e9a9fa3e089c7b8713218df4a7924b2109b159df480960ddfe73e221c3
Drop 1st byte:
1cdb52e9a9fa3e089c7b8713218df4a7924b2109b159df480960ddfe73e221c3
N/A

old:

Given a public key, e.g.

04a097026e876544a0e40f9ca836435560af4470e161bf60c23465dcb3151c947d1cbe052875211972107e25fca8dd939f1c6e749a43862673ec5cf7a8567f2d95

The 0x04 designates this as an uncompressed public key, where the next 32 bytes are the x value and the final 32 bytes are the y value of the point on the elliptic curve, respectfully.

To convert from an uncompressed public key to a compressed public key, you can omit the y value because the y value can be solved for using the equation of the elliptic curve: y² = x³ + 7, given x. Since the equation solves for y², y could be either positive or negative. So, 0x02 is prepended for positive y values, and 0x03 is prepended for negative ones. If the y coordinate is even, then it corresponds to a positive number. If odd, then it is negative. Since the y value ends in 0xee, which is even, and therefore positive, the compressed version of the public key becomes:

03a097026e876544a0e40f9ca836435560af4470e161bf60c23465dcb3151c947d

Javascript

You can use bitcoinjs-lib to convert:

const bitcoin = require('bitcoinjs-lib')

const pubkeyBuf = Buffer.from('04a097026e876544a0e40f9ca836435560af4470e161bf60c23465dcb3151c947d1cbe052875211972107e25fca8dd939f1c6e749a43862673ec5cf7a8567f2d95', 'hex')
const pubkey = bitcoin.ECPair.fromPublicKey(pubkeyBuf)
pubkey.publicKey.toString('hex')

'03a097026e876544a0e40f9ca836435560af4470e161bf60c23465dcb3151c947d'


Clarification on execution of complex script with OP_CHECKLOCKTIMEVERIFY

Bitcoin uses a stack based language due to which the logical condition that will execute the IF or ELSE statements comes prior to the operator IF or ELSE. Let's take both your cases one by one and see how it gets executed on the stack.

Case 1: ScriptSig: 0 <Alice's signature> <Bob's signature> 0

The stack starts at 0 <Alice's signature> <Bob's signature> 0
Since 0 is on top of the stack, the ELSE condition will execute and drop the 0
number 2 is pushed on the stack
Stack is now 0 <Alice's signature> <Bob's signature> 2
script outside the IF/ELSE statement is pushed to the stack
Stack is now 0 <Alice's signature> <Bob's signature> 2 <Alice's pubkey> <Bob's pubkey> 2 CHECKMULTISIG
This is a normal 2-of-2 Multi-sig operation that will execute by verifying both Alice's and Bob's signature to the public keys

Case 2: ScriptSig: 0 <Alice/Bob's signature> <Lenny's signature> 1

The stack starts at 0 <Alice/Bob's signature> <Lenny's signature> 1
Since 1 is on top of the stack, the IF statement will execute and drop the 1
<now + 3 months> CHECKLOCKTIMEVERIFY is pushed to the stack and verified whether 3 months have passed. If yes, the execution will continue.
DROP operator drops the TRUE on top of the stack if verification is successful
<Lenny's pubkey> CHECKSIGVERIFY is pushed to the stack
Stack is now 0 <Alice/Bob's signature> <Lenny's signature> <Lenny's pubkey> CHECKSIGVERIFY
CHECKSIGVERIFY will consume the top 2 items of the stack. It will check whether Lenny's signature matches Lenny's pubkey. If yes, the execution will continue.
Stack is now 0 <Alice/Bob's signature>
1 is pushed to the stack
Stack is now 0 <Alice/Bob's signature> 1
Script outside the IF/ELSE statement is pushed to the stack
Stack is now 0 <Alice/Bob's signature> 1 <Alice's pubkey> <Bob's pubkey> 2 CHECKMULTISIG
This is now a normal 1-of-2 multisig operation and will execute if Alice or Bob provides a valid signatures to their pub key.


How do I buy Bitcoins safely face-to-face?

Shamelessly summarized from this extensive guide on local transactions:

You want to meet in a sufficiently public location, such as a pub or mall, preferably one that has an open wifi.
If you have agreed on terms in beforehand, print out what you agreed upon and take it with you.
If you have not agreed on terms yet, be sure to check the current price of bitcoin during the meeting.
Wait for the transaction to complete and check if the right amount was paid. If the other person is willing to wait around for one additional block together that is a good sign.
Specify your expectations in advance: When and where to meet, what each person will have on hand to make the deal, how the price for the bitcoins will be calculated.
Consider taking a second person along for additional safety.


What is meant by "we are approaching a step change in bitcoin mining"

That was my answer, and "minder" was a typo and meant to be "miner".  Apologies for any confusion this might have caused.

There are ASIC-based bitcoin miners that generate north of 60GH/s.  A high-end PC might get up to 1GH/s, with a similar cost for power.  So there is going to be a massive influx of GH/s additional power in to the bitcoin mining pools.

The difficulty rating for mining self-adjusts over time to ensure that the number of blocks found remains relatively constant at around 1 block every ten minutes.  Let's assume that the influx of ASIC-based miners pushes the overall difficulty up 10x in the short term.  This means that for the same amount of work your PC is doing next week as opposed to last week you will only receive 10% of the reward.

The end result is that the idea of mining on a PC to obtain bitcoins is going to go away over the next year or less (depending on how quickly the ASIC companies can churn out production-ready mining platforms).


How can someone patch Bitcoin?

git clone
do changes
make && run

  Why are those people trusted?

You have a right not to trust them

  And how would they publish the new code so every node gets the updated
  version?

Node owners have a right not to upgrade to "referal" version

  Do every node download it from some central server?

No. Everyone have a right to change everything in his own copy of sources.

  Or do someone push it?

No.

  In both cases, it doesn't seem decentralized.

The development of "referal" software is not decentralized.


Register at github, go to https://github.com/bitcoin/bitcoin and press "fork"