Your wallet is locked with a passphrase, first you need to unlock it before executing commands related to private keys using walletpassphrase:

# Unlock the wallet for 60 seconds
$ bitcoin-cli walletpassphrase "my pass phrase" 60

# Some transaction commands ...

# Lock the wallet again (before 60 seconds)
$ bitcoin-cli walletlock


ModuleNotFoundError: No module named 'bitcoin'

You are using a version of pip with a different version of Python. You are using Python 3 but your pip is for Python 2. Thus anything that pip installs will not be available to your Python which is why it cannot find the correct library. You will need to do pip3 install python-bitcoinlib in order to install the library for your python version.


There are a lot of protocols that sit on top of bitcoin that do something like what you're asking. They're mostly called "colored coins" (see http://coloredcoins.org/)

Basically, the idea is that you need some way to create the inventory tokens on the bitcoin blockchain, then track them using normal bitcoin transactions. The big thing to note is that there is a 5430 satoshi minimum for transactions, so the various colored coins protocols (at last count, at least 5) try to get around that in some way.

Best of luck in finding a solution.


Trying to create a bitcoin based webapp in python which takes BTC deposits. How would I use pybitcointools to implement this?

You're mostly on the right track.

The ideal way to build a user deposit system is to simply have a one to many user->address mapping.

By default, when a user deposits BTC to an address, you automatically generate a new address for them. However, you don't delete the previous address, or the fact that it is linked to that user.

This way, even if a user sends BTC to an older address, you are able to receive it for them.

Additionally, how you process withdrawals depends on what kind of system you are building. If it is simply a straightforward wallet system, then the process you described of sending the BTC out when the user asks from the user's address will be fine.

If you are building a platform where the user exchanges BTC for goods, services, or other coins, and then makes withdrawals based on their remaining balance, you may want to consider a hot/cold wallet system.

In such a system, when users deposit coins, you provide no guarantee that the same coins will be used to process their withdrawals. You either use all users' coins to process each others withdrawals, or you move them into a handful of addresses, and process all withdrawals from their.


Is this the answer to Bitcoin's massive energy consumption issues?

You can probably make more money selling the energy you farm than you can mining BTC with it.


I got linked this question.

I made a tool which includes a component that allows one to simulate mining:

http://yogh.io/#mine:last

It's not entirely accurate; it doesn't support BIP 34, so the block height is not reflected in the coinbase tx, and it's still got some bugs. Currently in alpha. But it can give you some pointers.

It'll construct a block on top of the tip of the current best chain, with a coinbase transaction and nothing else, then start hashing at 4 hashes/sec, showing every failed attempt (which at this hashrate, is likely to be all of them).


What is the estimated size of complete blockchain when all bitcoins are mined. i.e around 2140?

The blockchain will not reach its maximum capacity by the year 2140, the only thing that is going to change is that all bitcoins (a little less than 21M bitcoins) will have been mined by then and the total number of blocks at that time will be around 6,929,999.

Assuming that a block's maximum size will remain 1 MB then we can estimate that the maximum blockchain size at that time will be ~6,6 terabytes.

Currently the average block size is 0,4 MB so if the usage remains in the same levels the estimated blockchain size will be around 2,64 terabytes.

A minimal block contains a single 1-input/1-output transaction. The tx size in this case is: 1 x 148 + 1 x 34 + 10 + 1 = 193 bytes. Adding 4 bytes for the magic number, 4 bytes for the blocksize indicator, 80 bytes for the block header and 1 byte for the transaction counter we come up with: 193 + 4 + 80 + 1 = 278 bytes or 0,0002651214599609375 MBs so if limits remain unchanged, the minimum blockchain size at that moment will be ~1,794 GB (~0,001752 TB).

For coinbase txs the tx size is ~233 bytes so the total size of the blockchain occupied by coinbase txs would be ~1,503 GB

So to sum up:

Min est. size: ~1,794 GB (~1,503 GB for coinbase-only txs)
Avg est. size: ~2,64 TB
Max est. size: ~6,6 TB

Note: The blockchain is currently ~36,5 GB so the above min value is only the theoretical limit, we already know that the blockchain size will be larger than today's ~36,5 GB.


What is wallet? How is it uniquely identified?

What is a wallet?

Its software that stores your cryptocurrency, manages the keys to your wallet, and watches for transactions.

  How is it uniquely identified?

As jakob said above, it is made unique by the keys and addresses.

With the Bitcoin wallet addresses being 26-35 numerals and characters long, you can see how it is unique.

Hope this helped!


All bitcoin transaction are not linked to user ip address, unless some wallets which links your transactions to your ip address.

I don't know what blockchain.info doing but what i know it's not possible to track any bitcoin transaction through ip address.


Can we think of an address a mini-account, and is re-useable and disposable?

No, you should not reuse addresses/treat them as a "mini-account". You should create a new one for every transaction and not re-use old addresses.
Your wallet software will generally handle this automatically for you -- just remember to request a new receive address each time you receive new bitcoin, and it should give you a new address that you should only use once.


Merged mining: are there any ways to prevent it?

It should be possible for the parent coin protocol to prevent being used for merged mining, by eliminating the ability to populate the coinbase transaction with random data.

Merged mining works because it is possible to inject a hash of an auxiliary block into a block of the parent blockchain.

The coinbase block does need to contain some random data because otherwise miners would hash to the same values and it would restrict the range of the hashing function.

However if the source of this entropy is restricted to a well-formed address (remember all bitcoin addresses are unique), and a consequence of putting the address in the coinbase is that it will be credited with the mining rewards, then it would not be possible to insert the auxiliary chain hash without forgoing the parent chain reward.

To my knowledge the provision of a bitcoin address + nonce within a certain range, would be a sufficient source of entropy for hashing purposes.


Is there a testnet version of data.ripple.com -- the Ripple Data API v2?

At https://medium.com/interledger-blog/sending-out-of-the-interledger-network-9f42c1217c72 there was a link to https://testnet.data.api.ripple.com/v2/ which seems to be what I was looking for.


Where are the Diablominer Config Settings stored in Mac OSX?

Correct locations might be either ~/Library/Application Support/Diablominer or ~/.diablominer

Of course it might be in in an incorrect location. Super Meat Boy, for instance, stores its configuration inside the .app itself (brrr). To check there you have to right click the app and "show package contents".

The best way to find this configuration file, if you already know at least the file name, is casting find ~ -name filename, hoping at least it is somewhere in your home directory.


JSON RPC call from webpage to Bitcoin Core

Make sure your 8332 port is open using ufw. Some VPS providers only have very few open by default for security. Digitalocean, for example doesn't have it open by default anymore.

sudo ufw allow 8332

Easybitcoin library uses cURL, and it's not always enabled or installed by default.

With PHP 5, you can easily install it by running  apt-get install php5-curl command.
With PHP7, sudo apt-get install php-curl

Once installed make sure its enabled. Locate your php.ini file and uncomment ;extension=php_curl.dll this line by removing ;(semi colon).

Run a test page with phpinfo(); and make sure curl is installed and enabled.  Restart Apache, sudo service apache2 restart.

If you still can't get it to work go back to your php.ini file and turn on all error reporting and let us know what the error is. Be sure you turn the error messages off again before you go live.


Lightning - why are commitment transactions supposed to use different keys

An optimization is to use elliptic curve trickery and thus construct something similar to pay2contract scheme. I believe this way you still have to store all old values or am I mistaken?

The elliptic curve trickery you mentioned is elliptic-curve multiplication. And yes, you need to store all old values.

In BOLT-03, under Key Derivation, it gives three reasons why the keys are changed(localpubkey, remotepubkey, local_delayedpubkey and revocationpubkey), and one of them is related to your question,

  Changing the localpubkey every time ensures that commitment transaction ID cannot be guessed except in the trivial case where there is no to_local output, as every commitment transaction uses an ID in its output script.


getrawtransaction seems to only work for certain transactions

getrawtransaction is only guaranteed to work for mempool transactions, unless you're running with the -txindex command line flag, or txindex=1 in your bitcoin.conf file.

In practice it works for all transactions that have at least one unspent output remaining, but it's relatively slow, and functionality that may be removed at some point.


Sent two btc transacton to payeer wallet less than the mnmum deposit,neither where credited

What can do to retrieve my funds ?

Bitcoin transactions cannot be reversed once they have been included in a block that is part of the valid chain.
The only way is to have the funds returned is to contact the person you sent them to, and ask for them back.


How many addresses are there now with segwit?

There are 2160 P2PKH addresses.
There are 2160 P2SH addresses
There are 2160 P2WPKH addresses.
There are 2256 P2WSH addresses.
There are 16 defined but unused witness versions which can be encoded by BIP173 (Bech32) addresses, each with data length 2 to 40 bytes. That's 16*256/255*(25640 - 256) =~ 2324.006.

That's 2144363455669619533814323684450670475181580230986810095535626033037852598144837730344835022389248 in total.

The number of private keys has not changed; that's still slightly less than 2256, namely 115792089237316195423570985008687907852837564279074904382605163141518161494336. Only the number of ways to use them increased.


This is the critical error:

2018-01-07 10:22:45 ERROR: ReadBlockFromDisk: Deserialize or I/O error - CAutoFile::read: fread failed at CBlockDiskPos(nFile=693, nPos=38137925)
2018-01-07 10:22:57 *** Failed to read block

I would 1st check if you have run out of disk space?


As the block id is known, the fee can be found from the coinbase itself without an overhead. Maintain a simple map for reward points saying blocks between 0-149 gives 50 BTC, next 149 25 etc.

Now, the first transaction in any block is always a coinbase tran.
Coinbasetran->vout[0] - reward = Fee (actual fee + unclaimed change)


How to import address with private key using importmulti

$ bitcoin-cli help importmulti
importmulti "requests" ( "options" )

Import addresses/scripts (with private or public keys, redeem script (P2SH)), optionally rescanning the blockchain from the earliest creation time of the imported scripts. Requires a new wallet backup.
If an address/script is imported without all of the private keys required to spend from that address, it will be watchonly. The 'watchonly' option must be set to true in this case or a warning will be returned.
Conversely, if all the private keys are provided and the address/script is spendable, the watchonly option must be set to false, or a warning will be returned.

Note: This call can take over an hour to complete if rescan is true, during that time, other rpc calls
may report that the imported keys, addresses or scripts exist but related transactions are still missing.
Note: Use "getwalletinfo" to query the scanning progress.

[...SNIP..]

Examples:

> bitcoin-cli importmulti '[{ "scriptPubKey": { "address": "<my address>" }, "timestamp":1455191478 }, { "scriptPubKey": { "address": "<my 2nd address>" }, "label": "example 2", "timestamp": 1455191480 }]'
> bitcoin-cli importmulti '[{ "scriptPubKey": { "address": "<my address>" }, "timestamp":1455191478 }]' '{ "rescan": false}'

As for your specific import you are passing the keys array (specified as such in the help, see the command above) as an object so bitcoind could not give you a helpful message :
$ bitcoin-cli importmulti '[{ "scriptPubKey": { "address": "3M5e4QMBUYtpEewwuuoWCArpiM2fT4KEDy" }, "timestamp":"now", "keys": [ "Kwngf5FSYmHM5oPHjSoKxtHWUxXiQ5YN5ZR6shmzkYpMMftBh92c" ], "redeemscript": "00144c88353345f2e03abc8e96b818fd030c3c9f59ab"}]' '{"rescan": false}'

[
  {
    "success": true,
  }
]


If the maximum target was 2256-1, every candidate block would be a valid block.

As even the CPU miner in Bitcoin's first software release was capable of doing 100 kH/s or more, this would have led to a very rough start of the chain, with 1000s of blocks produced per second until the difficulty adjusted.

Because of that reason, the maximum target was probably set to a level that would guarantee not too frequent blocks after genesis.


How to create a P2SH address which will be the hash of a redeemScript

Quick and dirty code for your task. Hope it helps.

1) Let us create address from secret.

static void p2sh_create ( )
{
  const MyByteArray secret ( QByteArray ( "My secret phrase" ) );
  const MyKey32 sha256 ( secret.sha256 ( ) );
  const MyByteArray redeemScript ( MyByteArray ( ).putInt8 ( OP_SHA256 ).putPush ( sha256 ).putInt8 ( OP_EQUAL ) );
  const MyKey20 hash160 ( redeemScript.hash160 ( ) );
  const QString address ( hash160.toStringP2SH ( ) );

  qDebug ( ) << "secret      =" << QString ( secret.toHex ( ) ) << "(in hex)";
  qDebug ( ) << "sha256      =" << sha256.toStringRev ( );
  qDebug ( ) << "redeemScript=" << QString ( redeemScript.toHex ( ) );
  qDebug ( ) << "hash160     =" << QString ( hash160.toHex ( ) );
  qDebug ( ) << "address     =" << address;
}

The output is:

secret      = "4d792073656372657420706872617365" (in hex)
sha256      = "73d83ecabab6ba96a47f03d0e21ffbdfeaab5d337b7e93a0cc2e85019190fb3f"
redeemScript= "a82073d83ecabab6ba96a47f03d0e21ffbdfeaab5d337b7e93a0cc2e85019190fb3f87"
hash160     = "fa3156d1e95111b0105fb538711bf8e19dadf1bd"
address     = "2NG482PHrj6f41UoqUHYGVkUR39oB3UvWkE"

2) Now let us fund the address 2NG482PHrj6f41UoqUHYGVkUR39oB3UvWkE. Follow the link https://testnet.coinfaucet.eu/en/ and ask for some test coins. Testnet faucet sent me 0.86978283 TBTC in transaction https://testnet.smartbit.com.au/tx/21c181c6052f6266ea6c936cf86111d6a2662a1f1e3251560b718fb8b1e6457d

3) Now create spending tx from this address.

static void p2sh_spend ( )
{
    const MyByteArray secret ( QByteArray ( "My secret phrase" ) );
    const MyKey32 sha256 ( secret.sha256 ( ) );
    const MyByteArray redeemScript ( MyByteArray ( ).putInt8 ( OP_SHA256 ).putPush ( sha256 ).putInt8 ( OP_EQUAL ) );
    const MyByteArray tx ( MyByteArray ( )
      .putInt32 ( TX_VERSION )
      .putInt8 ( 1 )
      .putArray ( MyKey32::fromHex ( "21c181c6052f6266ea6c936cf86111d6a2662a1f1e3251560b718fb8b1e6457d" ) )
      .putInt32 ( 1 )
      .putPrefixed ( MyByteArray ( ).putPush ( secret ).putPush ( redeemScript ) )
      .putInt32 ( TX_SEQUENCE )
      .putInt8 ( 1 )
      .putInt64 ( 86978283 - 200 )
      .putPrefixed ( MyByteArray ( ).putInt8 ( OP_HASH160 ).putPush ( MyKey20::of ( "2N8cj6kf3RkPHzQSCG13bvq6iXXWWPuGurZ" ) ).putInt8 ( OP_EQUAL ) )
      .putInt32 ( TX_LOCK ) );
    const MyKey32 txid ( tx.sha256d ( ) );

    qDebug ( ) << "tx   =" << QString ( tx.toHex ( ) );
    qDebug ( ) << "txid =" << txid.toString ( );
}

The output is:

tx   = "01000000017d45e6b1b88f710b5651321e1f2a66a2d61161f86c936cea66622f05c681c1210100000035104d79207365637265742070687261736523a82073d83ecabab6ba96a47f03d0e21ffbdfeaab5d337b7e93a0cc2e85019190fb3f87ffffffff01232e2f050000000017a914a89aec4cd53e6d74215332459b7fea3ec4aca9758700000000"
txid = "75e0904ca3f8895c6f6af45f1c7f3d1f9dcee32814ca144852bce669a5ee4421"

4) Now push the tx to the network: https://testnet.smartbit.com.au/txs/pushtx

5) Voila! https://testnet.smartbit.com.au/tx/75e0904ca3f8895c6f6af45f1c7f3d1f9dcee32814ca144852bce669a5ee4421


I ran the blockchain during 2009 and 2010

By "ran the blockchain" I guess you mean you ran Bitcoin-core wallet software sometimes known as Bitcoin-qt.

I downloaded the Bitcoin.org wallet

Bitcoin.org lists many wallets, I guess you mean Bitcoin-core wallet.

I found an old file I had renamed to xxxx.dat.

There are many different data formats and software applications that use ".dat" as a filename extension. So your xxxx.dat might not be a wallet.

Any suggestions?

Check the format of your xxxx.dat file. See if it matches the expected format.
There are tools that might assist with this - such as pywallet.
Otherwise maybe you have to download an ancient version of Bitcoin-core


Can the bitcoin network hashrate be used for a 51% attack on other coins?

You could easy manipulate a pool to wreck havoc on other SHA256 coins if you owned it or managed to gain access. You don't even need to be a large pool, some altcoins are really small and vulnerable. It has affected other coins before, where a pool or a large miner created trouble solely by mining a smaller altcoin.

Feathercoin hit by massive attack

Only thing that prevents this regularly happening is that is isn't profitable to attack small crypto-currencies and in fact devalues whatever you make in the end.


Their assumption is correct: if you send a transaction that gets orphaned, and then send another transaction that goes into the block, the other transaction automatically becomes invalid.

Transactions don't have a timestamp embedded, so miners don't have a way of knowing which transaction came first. They just include the one that first reaches them, which in your scenario will be the second one.


Creating empty blocks vs creating full blocks

Yes, you are correct that miners get to decide whether to include transactions in their block that they're mining. The protocol itself doesn't force them to include any transactions. Instead, they have a financial incentive to include transactions because they can collect transaction fees and profit more.

It's an interesting trade-off for them, because their profit has to outweigh their costs of validating those transactions. However, I suspect transaction validation doesn't cost miners anything because they can validate and hash transactions for block i+1 as they are mining for block i with different hardware: validation is done on CPUs, mining is done on ASICs.

But there are interesting cases: For instance, miner A has to recompute their next block i+1 if  another miner B finds block i and it includes transactions from miner A's next i+1 block. In that case miner A would have to remove some TXs from his block i+1 and recompute the Merkle tree. Or miner A can create an empty block i+1 and just mine on that.

Sometimes, when mining on block i+1, miners even skip on validating other miners' block i in the hopes of winning the race by starting earlier [1].

Hope this helps clarify things a little.


I don't see how this can be possible. Obviously you can look at the block chain to see the transactions that occurred, but since addresses are anonymous, there's no way to tell whether a given transaction transferred coins to a new owner (which should count toward velocity) or to an address belonging to the same person (which should not).


How to restore my Copay / BitPay Wallet?

I tried recover: https://bitpay.github.io/copay-recovery/ [...] No success.

I don't know why you put your recovery phase into a website. That seems a very risky thing to have done. The distinction between github.com and github.io is also something I'd find a concern that would make me hesitate.
A message like There are no record of your wallet on our servers. makes it sound like recovery of a custodial wallet but wasn't the Copay wallet non-custodial?
I would worry that having typed my recovery phrase into a website, someone will have already stolen any money.

What I would have done is download the Bitpay wallet app from the Google play store (after checking very carefully that the app authors are listed as Bitpay) and use that software's wallet "recovery" features. I would not use "import".
If the balance showed zero, I would check for recent transactions moving the money away.


How Bitcoin system prevents the previous owner of a Bitcoin to spend it?

If I spend my bitcoin, I still know the private key of it, using which I can spend it later despite not owning it.

Your are not really "the owner of the bitcoin". It's decentralized. You are the owner of a private key and of an adress.

And you can use the private key to send money away from your adress. Let's assume, you have only 1 BTC on your adress and send it all to your friend. After that, you can't send BTC from your adress anymore because there is nothing on the adress anymore. Only if someone sends BTC to your adress again, you can spend them again. You can't spend the 1 BTC again because it's on your friend's adress. You don't have the private key for his adress, but he has. So he can spend the BTC.


Computta stealing bitcoin and behave like its nothing

they steal my bitcoin. What to do in such case?

When someone steals something from you, the appropriate response is to report it to the police. You'll have to provide evidence that a crime has occurred.
If the evidence is not the sort that would be credible in a court of law, it may not be possible to progress this.
If the criminal is outside the jurisdiction of your police, and the sums involved are low, it may be difficult to progress this.

Due Diligence
Part of the intent of cryptocurrencies is to create currencies that are outside the control of governments. A corollary to this is that you need to be diligent when assessing the trustworthiness of cryptocurrency organisations
See

Computta Review: Hand over the keys to your PC to persons unknown
Computta – Smart Cryptocurrency Mining PC Application Software?

Computta is made by a company named Computta Networks LLC. The corporation started appearing online in July 2017. They claim to be registered in Delaware.
There’s virtually no information about the company available online. In fact, one of the first results that pops up when you search for Computta Networks LLC on Google is this page on RealScam.com, where the website is identified as a likely scam.
There’s also the problem that Computta’s testimonials are accompanied with stock photos that have been taken from other websites. They do not appear to be legitimate testimonials.


$ lnd --version did the trick.

Output should contain the version plus commit hash

lnd version 0.5.0-beta commit=f4305097e1638f6f8958dfa9eec941d8bf80246e


Bitcoin has a complex scripting system which can be used to set the conditions under which the money sent by a transaction can be redeemed. For example, it is possible to send bitcoins in such a way that they can be only redeemed by someone who finds a collision for a specific hash function.

Most of the time, however, bitcoins are sent to a script which requires a signature from a single key to redeem. In this case, the address is the encoded hash of that key. In general, however, not every script corresponds to an address.

Strange transactions are transactions which have either input or output scripts not matching any of the predefined patterns for standard scripts. Such transactions must be created manually, but they can contain any script permitted by Bitcoin. So, there are no specific patterns that they follow, but rather there are patterns that they do not follow.


Ripple JSON API - Can I use more than one destination while transaction?

for now there is none... you can only use single destination address


Is "inherited" replace-by-fee signaling implemented as described in BIP125?

The answer to this question is: no, inherited signaling is not currently implemented in Bitcoin Core as described in BIP 125.
In May 2021, Antoine Riard discovered the missing implementation could be exploited in the context of the Lightning Network "pinning attacks against second-stage HTLCs" as well as other contexts:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html


Why does Bitcoin Core not let met change the label for "requested payments"?

I think what you are looking for may be:
In version 0.21 Open the Windows menu and choose Receiving Addresses

In older versions you had to open the File menu and choose Receiving Addresses

then right-click on any unwanted label and choose Edit.


I cannot send btc before my last transaction get confirmed

This will happen sometimes, and there's not much you can do about it. Much the same thing happens with cash. Say you have a $100 bill, and you want to pay me $10. In our transaction, the $100 will be split -- you'll get $90 back and I'll get $10. But while that's unfinished, you can't spend your $90 change from the transaction with me because it's not fully yours yet.

The exact mechanics will depend on what unspent outputs you have. If you only have a single output, then you will have no funds available until the transaction confirms. If you have multiple outputs and not all of them are needed for the transaction, then some of them will still be available before the transaction confirms.

Cash behaves the same way. If you have a $10 bill, a $50 bill, and a $100 bill, you can send someone $60 and still have the $100 bill available. Or you can send someone $65 out of the $100 bill and still have the $10 and the $50 available while that transaction is finalizing.


Bitcoins recently sent from localbitcoins.com wallet not showing in recipient wallet

I do not use localbitcoins.com but it is possible if you can see the transaction that you made, you might be able to find the transaction ID. Then, you can search for your transaction ID on blockchain.info to find out the status. Even if you cannot, the answer is just to wait.

Every time you request a receiving address a new one is generated.


How a new wallet knows balances locked in P2SH transactions?

In short, it knows because it knows. Whatever information was used to make the original wallet construct the addresses (whether that consists of a seed, a set of keys, a master key, a descriptor, a mnemonic phrase, ...) must be imported into the new wallet too.
The P2SH redeemscript is not created randomly: there is a procedure to generate it from keys the wallet has, and those keys may themselves also be generated from such information. What that information is depends on the standards or schemes involved, so it's hard to be very specific here.
Deterministic wallets have been standard since 2013 or so, and pretty much all wallets have some means of deterministically constructing keys from some fixed immutable piece of data. For single key policies (simple wallets) a wallet also needs information to turn those keys into scripts/addresses. Common ways include P2PKH (address contains a hash of the public key), P2WPKH (similar, but uses segwit for spending), or P2SH-P2WPKH (where the address is a P2SH address containing the hash of a segwit program that contains the hash of the public key). The wallet needs to know which (possibly more than one of these) is used to convert the keys into scripts, and that implies also a way for computing the redeemscripts involved. Sometimes this choice is implicit in the standard being followed; sometimes it needs to be imported/chosen specifically.
For multisignature or other policies it is more complicated, as wallets also need to know how the other participants generate their keys, but this information is always needed - both in the first and the second wallet.


Are you saying it's difficult because the user would have to sign their own transaction manually? P2SH isn't really at a "typical" user level. For multisig to work as it's intended to, it assumes each potential signor knows how to sign a transaction. A website that would require it's users to sign their own P2SH transactions would have a pretty small target audience. Aside from building your own native desktop app that makes multisig signing easy for the average user, I'm not sure what other options you would have.


I want my website to accept bitcoins without dealing with security issues

I would suggest integrating https://bitpay.com/
They charge you like any other service but they do all the payment stuff. Also they have plugins for most open source shopping carts Bitpay plugins
Also keep you wallet offline to avoid problems.


What is my chance to find a block on a TestNet ?

You have almost 5MH/s, so at the current difficulty = 1787.78664453 and given, that base diff for testnet is 0.5 diff for main btc network, you can put this into calculator, and you get

  9 days, 6 hours

. Hope this solves your case.


What is the NTX ID that Mt. Gox refer to in their Feb 17th Statement?

This is closely tied to the transaction-malleability bug, which allowed the re-posting of unconfirmed transactions with an altered transaction id. The issue increased the complexity for bookkeeping for services with a high number of transactions. Especially, some people used it to sneak duplicate withdrawals from Mt.Gox.

The change to the transaction ID was made by pushing additional zeros to the signature's front. I think NTX ID stands for normalized transaction id which will map all duplicate transactions back to the same representation, even when they were altered by exploiting the transaction malleability.

It is an internal blockchain representation used by Mt.Gox and has nothing to do with the service blockchain.info.


There is no minimum. In theory, you could find a valid block on your very first attempt. The best we can do is an average.

Here's the average energy required to find one valid block using CPU mining:

  average energy required = difficulty * 232 / 2*10^6 * joules

Or, at current difficulty, 1.018×10^14 joules.

Explanation:

  difficulty * 232

The average number of hashes to find a block.

  2*10^6 * joules

According to the Bitcoin wiki, the typical mining efficiency for CPUs is 2 Mhash/J.


How can I generate a Dogecoin address from a Litecoin private key?

Let's assume we have this compressed Litecoin WIF private key:  T4DRLwPgnkg9jyivjbbnmqJZjHRxeYTy4idAV5uwEuFdyJBGuxXE.

% echo T4DRLwPgnkg9jyivjbbnmqJZjHRxeYTy4idAV5uwEuFdyJBGuxXE | bx base58check-decode

wrapper
{
    checksum 625264444
    payload 22b207aa76eb058876c667dc64ab8eeaa0a073bc018561c2463d438a0444b70501
    version 176
}

ANSWER for Doge WIF Key:

% bx base58check-encode -v 158 22b207aa76eb058876c667dc64ab8eeaa0a073bc018561c2463d438a0444b70501

QPn542uVdzBgCfV6nEViShboFTpDd1at8mQpQugEQHgpuLbsgcZe

VALIDATION CHECK:

% echo QPn542uVdzBgCfV6nEViShboFTpDd1at8mQpQugEQHgpuLbsgcZe | bx base58check-decode

wrapper
{
    checksum 2298567751
    payload 22b207aa76eb058876c667dc64ab8eeaa0a073bc018561c2463d438a0444b70501
    version 158
}

Examine 158, base58check-decode and base58check-encode for more details.


Yes you can but I recommend Electrum instead because with Electrum you are not relying on one server for your view of the blockchain.

Copay and Electrum are both wallets that give you control of and responsibility for your private keys. Your private keys are all generated from your seed which will be displayed to you during wallet creation as 12 random English words. Only someone with knowledge of your seed will be able to move your bitcoins and since you are the only one with that knowledge only you control them. No government or corporation can freeze your bitcoins or censor your transactions.

You can find a list of other such wallets here.


bitcoind is refusing to connect to my other server

By default bitcoind only binds RPC to the loopback interface, so you can only connect to it from localhost.  This is for security.

You can allow connections from a specific other machine with -rpcallowip, or in general with -rpcbind, but beware that this substantially increases the attack surface.  Moreover, the data sent and received is not encrypted, see Why is JSON-RPC over SSL "strongly discouraged"?.

It's recommended instead to use VPN software to set up a tunnel between the two machines.  In such a setup, bitcoind will see the RPC connection as coming from localhost.


What benefit does bitcoin provide over using a credit card?

I don't consider these to be competitors.

Credit cards are a convenient way of doing payment processing on top of fiat currency. Bitcoin is a digital currency on itself.

Sure, Bitcoin today can function as a very rudimentary way of doing payments (just like cash-via-mail can be), but it's not particularly good at it - all it provides is storing and transferring value. What I hope is that in the future it will become a platform upon which payment processors can build. Since the currency is already inherently digital, building a payment platform on top of it should be significantly easier. Furthermore, since it is decentralized, everyone has the ability to become their own payment processor (or bank...).


How find own address in testnet using bitcoin-cli?

You'll want to use getnewaddress. Here is the output of bitcoin-cli help getnewaddress from Satoshi:0.17.0.1:

bitcoin-cli getnewaddress( "label" "address_type" )

Returns a new Bitcoin address for receiving payments.
If 'label' is specified, it is added to the address book
so payments received with the address will be associated with 'label'.

Arguments:
1. "label"          (string, optional) The label name for the address to be linked to. If not provided, the default label "" is used. It can also be set to the empty string "" to represent the default label. The label does not need to exist, it will be created if there is no label by the given name.
2. "address_type"   (string, optional) The address type to use. Options are "legacy", "p2sh-segwit", and "bech32". Default is set by -addresstype.

Result:
"address"    (string) The new bitcoin address

Examples:
   > bitcoin-cli getnewaddress
   > curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getnewaddress", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/


Just an account on http://phoneco.in/  because thats exactly what the service does.  [Update: Phoneco.in is defunct.]

Update: A new service as well to check out. http://dialcoin.com/ [DialCoin's site is up yet but has suspending service.]


How does public address "know" private key?

How does public address “know” private key?

It doesn't. There's no need.
When receiving money, nobody needs to know anything from you other than your receiving address (in reality a Bitcoin script, the most common types of which can be displayed as an address). At this point no-one cares about your private key.

If later wanting to sell the Bitcoin,

When spending money, you have to provide proof that you know the private key corresponding to that receiving address, without revealing the private key. This is what your wallet does when constructing the transaction details that are sent out for miners to pick up.
Other Bitcoin nodes (wallets, miners etc) can mathematically check that the proof matches the public key and will then know that you have the secret number known as a private-key.

See

https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm


How does `bitcoind` generate the private key?

Bitcoind does not support BIP39, which encodes a seed (128, 160, 192, 224, 256 bits) in a mnemonic phrase, from which the 512b HD root seed is later generated via PBKDF2 (Password-Based Key Derivation Function 2). This 512b root seed is used to derive the (extended) master keys.

For wallets without BIP39, the 512b HD root seed is directly supplied as entropy, without the intermediary step involving an encoded mnemonic phrase and PBKDF2.

Backing up the wallet.dat file.
https://bitcoin.stackexchange.com/a/22722/90088

Amended:
Bitcoin Core wallets will deterministically derive new extended key pairs and addresses as wallet usage progresses, which is reflected and updated in the wallet.dat file. However, when restoring a wallet from an older wallet file, the wallet will (re)derive all standard child key derivation paths, whilst (re)scanning the blockchain to determine past usage of these keys in transactions, thereby recreating the last used hd wallet state. The wallet can be fully restored, even if the wallet file backup is not the most recent one because of this rescan.


New params of chainparams.cpp. What put on them and how generate?

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

The first line describes a minimum difficulty.

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

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

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

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

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

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

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

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

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

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

nPruneAfterHeight = 100000;  //what this do ?

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


(2) Based on the previous block hash, I calculate the possible block
  header combinations of the nonce, the version number, the timestamp*
  and the Merkle root. The goal is to simply find a valid block header
  which has a lower hash value than the current target.

The block header is 80 bytes size:

version: 4 bytes.
previous hash: 32 bytes.
merkle root: 32 bytes.
time: 4 bytes.
bits: 4 bytes.
nonce: 4 bytes.

Miners iterate the nonce (4 bytes), and the fast ones the extranonce (4 bytes more). The other items are already known, they get them from the pool.

You propose to iterate nonce (4 byte) + version (4 byte) + merkle root (32 byte) to find a target hash faster than them. I belive it will not work.


How to allow/setup crypto transfers/payments on my website?

To check payment:
you can use blockchain api to do so:
https://blockchain.info/q

which is

https://blockchain.info/q/getreceivedbyaddress/[BITCOIN ADDRESS]?confirmations=6

confirmations can be any but minimum 6 is recommended

to accept bitcoin, I suggest u host a bitcoin core and use something like  Easy Bitcoin PHP Library to do so


Should I run the tests every time I review an open Bitcoin Core PR?

The Bitcoin Core contributing guidelines recommend that post Concept ACK, Approach ACK:

A review begins with ACK BRANCH_COMMIT, where BRANCH_COMMIT is the top
of the PR branch, followed by a description of how the reviewer did
the review.

As you suggest "I ran the tests on typical hardware" generally isn't particularly useful as Bitcoin Core has solidly improving CI tools but there are exceptions e.g. a GUI change is not covered by tests and there would be value to running tests for certain IBD, validation changes, nontrivial changes too.
Depending on the nature of the PR you may want to perform a less trivial workflow such as sending and receiving transactions.
To get additional assurance that you are comfortable with the code change you could add debug prints, asserts, custom logging and sanity checks. You could change the patch or use debugging tools like gdb and lldb.
You can break many things without the CI or test suite picking it up. Manual testing can catch things that might be missed in code review. You might see warnings or errors when debug building PRs that you might not see otherwise, either because it's buried in one of the CI job logs or because your compiler or configuration or system is different.
If the PR is implementing a particular BIP you could find a particular rule from the BIP in the code, mutate (break) the code and check that test(s) fail as a result.
Another thing to consider is whether the additional tests added in the PR are sufficient.
[edit: An example of something you can test that the CI won't test is to change a line of code in the PR, rebuild (i.e. run make again) and run the test (or multiple tests) that you expect to fail as a result. Jon Atack suggested this is a good way of reviewing PR #19951 which at the time of writing (September 2020) is open and seeking review.]
This answer was collected together from comments from sipa, jonatack, hebasto, jnewbery, robot-dreams, instagibbs on IRC.


BitCoin provides anonymity but not unlinkability. This mean that BitCoin transactions are public and can be traced.

Link a BitCoin address to a real identity is not easy and there isn't a standard procedure to do that. But there are many approaches of how someone could try to know to what person one address belongs.

For example, when you send money to an exchange or make a payment, you're linking your address with your identity. So, the exchange or the person that you're paying, now they know that you're the owner of that address. The goverment may have a legal way to demand for that information to an exchange, for example. Note that the addresses used by exchanges are often of public knowledge and there are studies about that, but your identity is not compromised, except that the exchange is hacked.

There are also other ways to try to identify someone's addresss. And there are ways to try to mix BitCoin payments so they can't be traced. If you want full anonymity and unlinkability, you should use other coins as Monero.

If you want to know more about this complex topic, I recommend this lecture.


I used multibit years ago - now what? (BTC, BTG, BCC etc...)

So I found a solution that worked for me:

BTC
Blockchain.info have online wallets but you can also just create your own transactions without using their wallet.  Add an address using import and then spend them directly using your private key.  You can manually set the fee and i managed to transfer with ~75sat/byte even though recommended was 225.

BCC/BTG
Transaction costs are still small for these so sweeping works fine using practically any wallet.


How can some exchanges/services afford to pay for customers transaction fees?

They can avoid the fees in two ways.

First, they can choose to batch multiple small transactions together into a single transaction with multiple outputs.

Second, since they have a large pool of bitcoins, they can more easily form transactions that qualify to be free transactions, for payouts over 0.01 BTC.

The most efficient way to form these free transactions would be to make a transaction that's nearly 1000 bytes, and is sent from inputs that destroy 4 Bitcoin days (e.g. a 4-day old 1 BTC input, or 2-day old 2 BTC input). This will ensure that it meets the priority requirements.


Can difficulty target by exploited by miner with proprietary computer?

No, for two reasons:

His advantage is always the same. If he has 50% of the mining power, he makes 50% of the revenue when he's mining and 0% when he's not. The difficulty does not change this.
In the on/off scheme, when he's mining, blocks are being found twice as quickly. So the difficulty adjustment comes twice as fast. When he stops mining, he has to wait twice as long for the difficulty to drop, so he's mining less than half the time. By forcing the difficulty up and then not mining, he has to wait an awfully long time before it comes back down -- during all that time, his mining hardware is depreciating.

I am assuming that the only thing he does is mine or not mine. I'm ignoring the possibility that he attempts to force reorganizations or does other "bad" things.


Well if you use volume you discard nothing. Next restart will reuse your volume.


XRP are internally represented as an integer number of millionths of a ripple. No term has yet been accepted for naming these units, but some people have (I think jokingly) referred to them as "Jeds".

Update: It looks like they will be officially referred to as drops as you suggested. A transaction costs 10 drops. There are a million drops in a ripple.


Because it was designed to be that way. Ethereum targets 15 seconds, so the difficulty adjusts to make the block interval 15 seconds. Bitcoin targets 10 minutes, so the difficulty adjusts to make the block interval 10 minutes. It is unrelated to how difficult it is to produce a hash; it is only related to what hashes are considered valid.

The set of hashes considered valid is set by the difficulty adjustment. Making it smaller means that it will be take longer or require more hash rate to find a valid block hash. Making it larger has the reverse effect. So Ethereum has a larger set of valid hashes than Bitcoin, so valid block hashes can be found more quickly as fewer hashes need to be tried, on average.


It looks like you are confusing the BIP 32 serialization with output descriptor serialization.
Output descriptors contain an extended public key serialized using the method described in BIP 32. This serialization applies only to that particular public key. The derivation appended to the end is independent and separate from that xpub's serialization. That is part of descriptors.

My question is for example for the second key: is the depth connected with the appended tail /0/0/*? If it is, shouldn't it be 2 instead of 1? Can depth be restored from the appended tail?

No. The tail is independent from the xpub. The depth applies only to the pubkey serialized by the xpub, which the derivation path is not a part of.

Why is the child index zero for the second key? Should it not be equal to the number that corresponds to the star. Can a child index be restored from the appended tail /0/0/*?

Because the serialization is only for that particular xpub. The appended derivation information is not part of this serialization.


You are correct that the Sprout commitment tree root / anchor is not stored in the block header. It is calculated by each node when a block arrives, and is stored in the block index.

The Sapling commitment tree root is stored in the block header (in what was the hashReserved field); nodes check this against the block contents and reject blocks with an invalid root in the header. This will make shielded address support significantly easier to implement for light clients.

The mappings from Sprout and Sapling tree roots to the IncrementalMerkleTrees themselves are stored in the coins database, and can be accessed wherever you have a CCoinsView.


How to calculate signature generation, signature verification, transaction verification speed?

All of these things you want to calculate are highly dependent not just on the hardware you use, but the software you use. For example you can generate signatures many different ways and every bitcoin wallet generates them a little differently. The signature generation performance of Java in bitcoinJ is going to different than that of Go in btcwallet is going to be different than that of C++ in bitcoin core and so on. In addition, deterministic signatures are going to have a different performance profile than non-deterministic signatures and so on.

That said, if you really wanted to, you can run some performance testing on any one of these, though not all of them exist. For verifying signatures in btcd, there is a benchmark test that you can use.

Note that block verification (or creation) necessarily means verification of all transactions in the block as well as checking the proof-of-work. Checking the proof-of-work, by the way, is really as simple as a calculation of a double-sha256, or a single "hash" that mining gear can do billions or trillions of per second.


Why do mining pools refuse "spammy" transactions when there are transaction fees already?

So, I don't personally think that the reason your transaction wasn't relayed/mined was because of miners refusing to mine the transaction because it was a Satoshi  Dice transaction. (Although I can't say that I know the real reason, or I would have posted an answer there.) The major mining pools right now deny this "transaction discrimination" (see this bitcointalk thread). And looking through the blockchain seems to verify this: there are lots of transactions getting confirmed for the well known Satoshi Dice addresses.

I think the reasoning for accepting them is the same reason you state: that if the transactions are paying the mining fee, they are essentially paying their own way. Some may (and do) disagree, but I this is certainly one of the reasons that transactions fees are part of the protocol. As long as there is a cost to send a transaction (even if it is a small one) then that does protect the network from spam and DDoS attacks.

As far as the second part of your question  "Is it really okay in the Bitcoin network to refuse transactions based on personal preference of the operators (aka Miners), in kind of like the censorship style that many proponents of BTC aim to avoid?", that is somewhat different.

Yes, it is entirely within the protocol (and I would assert the spirit) of the protocol. Bitcoin to a large extent a democracy (except that it is isn't one vote one person). And if there was an attempt to subvert the system, then it is the miners who collectively protect against that.

For example, the BTC market is now large enough that it is conceivable that someone with a vested interest in the BTC exchange rate might find it worthwhile to flood the network in an attempt to devalue BTC, even if it required paying transaction fees on that flood. Another example, if someone found an exploit (or even simple bug in the Satoshi client) that allowed some sort of malformed transaction to crash clients. In most cases, it is entirely reasonable that the miners (from their own interest in protecting the network) would refuse to mine those transactions.

So, yes, I would say that it is entirely reasonable for miners to refuse to mine transactions based on "personal preference". Because that will only affect the network if the majority (actually it likely would take a significant supermajority) were acting on the same personal preference. Which means that they weren't personal preferences so much as a group consensus about the benefit of the network. And since they would be passing up the opportunity to make money on those transactions it is extremely likely that the supermajority could only be reached in the case of a significant network issue. (A great example of this is the March 2013 fork in the network.) The miners collectively chose to ignore the longest blockchain (the 0.8.1 branch) in favor of keeping compatability with 0.7.


Does a new block necessarily include all transactions that occurred before its generation? What about network latency?

Miners have total freedom to choose which transactions they will include in their blocks. Most miners will include any transaction that reaches them (assuming it includes an appropriate fee) but nothing forces them to do so.

But if a miner decides, for whatever reason, to omit a particular transaction, or if it's omitted by an accident of timing, no permanent harm is done. Another miner can include that transaction in a later block with no problem. Transactions don't even have a timestamp, per se, so it's not a problem if it takes a long time (other than the inconvenience to the parties involved). (Blockchain.info and its ilk may record the time at which they first saw the transaction on the network, but that time stamp isn't part of the transaction itself, as far as I know.)


As transactions are getting increasingly slow and expensive, how can Bitcoin compete against newer better currencies?

When transactions are created they are essentially a payment promise. They are submitted as a message to the network, where every node checks that the promised money exists and then forwards the transaction. Some of these nodes collect transactions in order to create a new block. These miners are essentially participating in a giant lottery where the winner gets to author a new block.

To that end, miners chose which transactions they are trying to confirm and add their own Coinbase transaction. The Coinbase transactions is the first in a block and gets to collect the transaction fees, creates the block subsidy, and contains the segwit commitment (in a segwit block). All the other transactions can be chosen at the leisure of the miner, although they pick the transactions with the highest fee rate, i.e. the transactions that generate the most revenue to them, by default.

The mining process is self-adjusting, in that the difficulty of blocks gets reset every 2016 blocks. Hereby, the difficulty can increase or decreaseee by up to a factor 4. Hence, the difficulty does not always have to get larger, in fact we've seen it decrease a few times this year. There is an argument to be made for it becoming slower, in that lately the demand for transaction confirmation has been much larger than the available blocksize which caused a lot of transactions to remain unconfirmed for weeks at times.

  On the other hand, any new better currency would offer exactly the same service, except faster and cheaper.

The thing is: A new network actually cannot offer the same service. There is a huge demand for Bitcoin transactions. However, a new network can only transmit its own tokens. If you want USD, would you settle for Venezuelan Bolivars instead? Although there have been numerous clones, copies and forks, in the past eight years, just cheaper transactions don't seem to be a sufficient incentive for adoption.


Which bitcoin script forms should be detected when tracking wallet balance?

These are the scriptPubKey's that are standard, arranged in order of popularity:

P2PKH (Pay to public key hash)

OP_DUP OP_HASH160 <20 bytes of public key hash> OP_EQUALVERIFY OP_CHECKSIG

P2SH (Pay to script hash)

OP_HASH160 <20 bytes of script hash> OP_EQUAL

P2PK (Pay to public key)

This is now mostly unused, except by miners, but there are still unspent outputs in the form:

<33 or 65 bytes of public key> OP_CHECKSIG

Segregated witness outputs

There are two ways of signaling that a scriptPubKey should be interpreted as a segregated witness program:

Native witness program

<version byte> <2 to 40 bytes of witness data>

The version byte must be equal to or less than 16.
P2SH wrapped witness program

OP_HASH160 <20 bytes of script hash> OP_EQUAL

The scriptSig must have exactly one item. That item is interpreted as a witness program, as above.

Once you extract the witness program, you must match it to one of the witness program types:

P2WPKH

0 <20 bytes of public key hash>

This is hashed identically to P2PKH.
P2WSH

0 <32 bytes of witness script hash>

This is pretty similar to P2SH, except that the script hash is SHA256, not HASH160.
Other version 0 scripts, not 20 or 32 bytes in length, are nobody-can-spend, so ignore them.

Note that any witness program format can be combined with any witness program. For example, you can have P2SH wrapping P2WSH, like this:

scriptPubKey:

OP_HASH160 <20 byte hash of scriptSig element> OP_EQUAL

scriptSig:

<34 byte serialized witness program>

unserialized witness program:

0 <32 byte hash of first witness item>

Then, the first witness item is unpacked and interpreted as the actual program.

More information here.
m-of-n bare multisig

Also pretty rare.

<m> [n <public key>s] <n> OP_CHECKMULTISIG

Data-carrying output

Only one of these is allowed per transaction. These outputs can never be spent, so you probably don't need to detect them.

OP_RETURN <less than 80 bytes of data>

  Should I implement more sophisticated script parser which can detect "non-standard" scripts as well?

No. It's a waste of development time, when nobody uses transactions like that. (If they did, those transaction types would be added to the list of standard transactions. :))

It's also going to be very difficult to implement correctly. If you don't do it correctly, then you'll think you have coins when you really don't. For example, imagine someone sends you a transaction with a scriptPubKey like this:

OP_DUP OP_HASH160 <20 bytes of public key hash> OP_2DROP OP_CHECKSIG

Note that this is like a P2PKH output, except that OP_EQUALVERIFY has been replaced by OP_2DROP. That means that the script checks that the signature is correct, but doesn't check that it's signed by the right key.

That means that anybody can spend it, not just you. Correctly detecting edge cases like these make writing a program that can understand nonstandard outputs more trouble than it's worth.


Secure way to store BTC over a long time - and its risks?

Bitcoin Armoury is the best thing out there for this.

What you want to do is create a new wallet with armoury, create a receiving address and send your BTC there.
The best thing is you do not need to even be connected to the network, synchronized or anything. Armoury can run offline in the dungeons far underneath the earth (like your cellar :) )
You then create a paper backup and print it out 2 or three times. Go and store it in your bank, in your important documents and at your mums house.
Delete armoury. (Yes, but make sure you have your paper backups stored safely!)

Your coins will hang in limbo (on the network) without any transaction history or block chain tracking. COmpletely anonymous and unclaimed.

Now- You might feel like you just threw your coins into thin air and have this uneasy feeling of you will never get your coins back! I know I did. So this is what I did.

I followed the whole process I mentioned above. Created a test wallet. Went to another computer somewhere else and did the same, except I imported the wallet from the paper backup. SYnchronised to the bitcoin network. Viola - The coins appeared in the transaction blocks and in my wallet ready to spend

It is also good for managing many online wallets at the same time. One for savings, possibly donations from your websites or blogs, and a personal one, and even offline unsynchronized for the long term anonymous storing of coins.

As long as the bitcoin network will be running you will never lose offline transactions. Just make sure to keep your paper backup in atleast 3 secure seperate place- and no. Do not store it on picasa albums or gdrive.. keep it offline in a bank, locker and at your nans house under the bed, laminate it, put it in a box and bury it in your back yard next to the tree house.


About performing SHA-256 hashing on the public key

The result you are getting (3251...)
is the result of sha256 on the string 0450....

The expected output on bitcoin.it is the result of sha256 on the bytes that are currently hex-encoded. To resolve this, hex-decode before hashing your input. In Python 2:

import hashlib
in_data = "0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6".decode('hex')
my_sha = hashlib.sha256()
my_sha.update(in_data)
output = my_sha.digest().encode('hex')

That should retain output with the expected value.


Cant spend input with non-standart redeemscript (OP_CSV)

You must provide a scriptSig that, when executed with scriptPubKey results in a true (or any nonzero item) on the stack (and passes all verification ops).
The scriptPubKey you need to satisfy (with a scriptSig) is:
2 OP_CHECKSEQUENCEVERIFY f45d94733d430261962932e0c847075195916a04 OP_CHECKSIG

(note this is not the redeemScript)
There main problem is:
OP_CHECKSIG is looking for a public key, but you have provided a script hash: f45d94733d430261962932e0c847075195916a04. This will never be satisfied so this transaction output is not spendable.
If you want to use the same redeemScript as before, you probably want the following scriptPubKey:
2 OP_CHECKSEQUENCEVERIFY OP_DROP HASH160 f45d94733d430261962932e0c847075195916a04 OP_EQUAL
Note the OP_DROP because the OP_CHECKSEQUENCEVERIFY leaves the 2 on the stack.
In order to spend this, you must provide any signatures and the redeemScript whose hash equals f45d94733d430261962932e0c847075195916a04.
Update:
The redeemScript is still wrong. Instead of 03e8546cfe53ca9014f6a352bc2e5c1f7cec1f5b344c73d4db3ed3b8f075d5c9ef, try 0014e17bbad678e82f8188099a351170c3e0efd4011b. This is the P2WPKH script you used previously in https://tchain.btc.com/46894d9dd5e20147826523b1a3ac8e8c5c64603338430d04bd6f5846af2bb9b4. Also note this is a segwit script so it will look for the signature and pubkey in the witness data: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#p2wpkh


How to send BTC amount from one specific address in Bitcoin Core

If you run Core with the command line flag -zapwallettxes it will forget transactions in its mempool.


Geting back transferred Bitcoins when the opposite party denied to accept the transfer

I think your best bet would be to contact their support and see if they can help.

Bitcoin transactions can't be "cancelled" or "refunded" after they get confirmed. Only the person that owns the address that you sent your BTC to will be able to send you your coins back.


Transaction ID usually refers to the 2xSHA256 hash of the transaction serialized as it would have been transferred in the network. This is also the ID as peers refer to them when broadcasting through the network.

Notice that due to transaction malleability a transaction may have multiple IDs.


Is there information about the buyer and seller in the Blockchain?

Yes & No

You can track a person's transaction only if you know that person's wallet address/es

By the wallet address/es, you can see the transaction.

The incoming transaction can be a buy, or a sale completed, etc.

The outgoing transaction can be a sell, or a purchase, etc.

You can also track a person using all his xpub key to know all the address/es at once.

Buy you cannot track a person just with a name or a single wallet address (if he owns multiple, which at this time, people do).

Hope this answers your question.


Is there any way to make an UTXO that cannot be spent until a certain block #?

No, there isn't currently any way to do what you describe without using a third-party oracle.

Yes, you may be able to do this relatively soon.  A soft fork has been proposed to introduce a OP_CHECKLOCKTIMEVERIFY op code` (CLTV), and what what I can tell it has strong support from the core dev team (but note that soft forks require miner support for implementation).

As Nick says, previous attempts were rejected because they proposed pushing the current block's height or time on to the stack like this:

<pubkey>       checksigverify  block           <data>    equalverify
<your pubkey>  compare to sig  current height  1000000   Only spend in block 1,000,000

Again, elaborating on what Nick said, the example transaction above would be valid in block 1,000,000---but if there was a chain reorganization, it might not be included in the new block 1,000,000 and so any transactions depending on it would be invalid.

The CLTV op code avoids this two ways.  First, it use the nLockTime value from the spending transaction rather than the block height or block header time value.  Since a transaction can only be included in a block if its nLockTime is equal to or greater than the current block height/time, this achieves the primary goal of allowing UTXOs that can't be spent until a particular time.

The other thing CLTV does is check values directly rather than pushing data to the stack.  This allows it to only implement a greater-than-or-equal-to check, so the transaction is always spendable after the specified height/time.

My guess is that the soft fork process to introduce CLTV will begin with Bitcoin Core 0.11, possibly sometime around July 2015.  (But, really, the core devs are unlikely to spend much time on CLTV until 0.10 gets released around January, so don't count on it.)


Made Consecutive Transactions But Unconfirmed at Blockchain.info wallet

According to blockchain.info, the receipt of bitcoins to 17wWzcAXjKjG3LQcGCYJbu7cdi6LgaXB4t has been confirmed (43 times so far).

However, the proceeding transaction that removes the bitcoins from 17wWzcAXjKjG3LQcGCYJbu7cdi6LgaXB4t has not yet been confirmed.

This is likely being caused by the current transaction backlog of about 62,000 unconfirmed transactions. Blockchain.info does regard your transaction as a "High Priority" transaction, so hopefully it will confirm soon, but keep in mind that the backlog is considerably large right now.

Your bitcoins are safe, but they may be in limbo for several hours. The transaction will eventually either be confirmed or be dropped from the network. If confirmed, the coins will go to the intended recipient addresses. If dropped, the coins will remain in 17wWzcAXjKjG3LQcGCYJbu7cdi6LgaXB4t.


Litecoin was not the first altcoin. It actually uses ideas for altcoins that precede it but had died before it was created. This is mentioned in its announcement thread on bitcointalk.. The very first altcoin was actually Namecoin, announced in April 2011. Namecoin was actively used and mined, and can still be used today.


Can you have same Bitcoin Address in 2 different wallets?

Anyone with access to the private key can spend any bitcoins belonging to the public key address.

Once you get the key from him, you should have blockchain "sweep" the balance at that address into a new address that only you have the key for.


Are transactions in the mined block validated by other nodes on the network?

This has been covered before (I can't give links at this juncture as I'm on mobile device), but:

each block references the previous block, preserving manipulation of blocks through POW
each Tx references it's corresponding UTXO hash
each UTXO requires a cryptographic puzzle (script) solution to spend the UTXOs

I'm sure someone will refer you to further information if I haven't edited this myself later on.


What is the differenct between 13.5TH and 14TH

I don't have any specific knowledge about this product, but I would guess this is an example of binning.  They're not really different, it's just a matter of how fast those particular units are able to go.

Most likely, both kinds of units are produced with identical parts and processes on the same assembly line.  Due to normal variation, some units will be more robust than others, so they test each unit at various clock speeds to see how fast it can successfully operate.  The 14 TH/s units passed their tests at a higher clock rate, so they set them to operate at that rate and sell them for a higher price.  The 13.5 TH/s probably failed at the higher rate but passed at a lower rate, so they set them to run at a lower rate, advertise them as meeting a lower performance standard, and sell them for cheaper.

So in that sense the 14 TH/s units are probably "better" and perhaps more reliable overall, but then again they cost more.  You'll have to look for product reviews to try to estimate how reliably these units perform as advertised; that's beyond the scope of this site.


What is relation between scriptSig and scriptPubKey?

First of all two matching scripts are used in two different transactions, one that transfers funds to an address (Transaction A) and one that spends those funds (Transaction B). The scriptPubKey is created by the user that creates Transaction A. It basically adds a claiming condition to the output that is being created. A user may only claim and thus spend the bitcoins associated with the output if he can prove that he owns the output.

This is where Transaction B and the scriptSig comes into play. Assuming a user wants to send some funds somewhere. He creates a new transaction, and adds outputs to it until he has enough to cover the desired amount. Now he has to prove that he owns those outputs, which he does by providing the output that is needed to claim them, i.e., the public key matching the address and the signatures with the matching private key.

The sender of Transaction A does not yet know the public key, but does know a hash of the public key, because he knows the address he wants to send to. The address is nothing more than the hash of the public key. So the sender now knows all he needs to be able to send the funds to the receiver.

When the receiver wants to spend the funds again he provides the input to the scriptPubKey. As you can see the scriptPubKey consists of taking the public key that was pushed on the stack, duplicating it, hashing it and comparing it to the hash of the public key the output was destined for. If they match we still have both the signature and the public key on the stack, which are used by OP_CHECKSIG to see whether the input had a valid signature attached.

Take this transaction for example. It claims one output, by providing the public key and the matching signature. It then creates two new outputs and specifies the conditions for the next user to claim them.


Configure esplora to point to the bitcoind servers ip address - Part 3

Have you checked the following:

do you use bitcoin rpc standard port for the network you are using? If not or not sure specify it explicitly with --daemon-rpc-addr 127.0.0.1:8332
Are you sure the .cookie file is in the default position? Try the explicit option --cookie username:password
Is bitcoind on the same machine? By default only rpc connection from localhost are allowed

If none of the above work, please post log from eletrs


How to increment the number of confirmation of a transaction?

A tx will only be included in a single block in any given blockchain.

Confirmations is simply a count of how many new blocks extend the chain.

If your tx is in block n, it has 1 confirmation. When block n+1 is mined, you need to check that the prevblockhash is the hash of block n. If it is, you now have 2 confirmations, since the chain has been mined. When block n+2 is mined, you check the prevblockhash against the hash of block n+1. If this is valid, you now have 3 confirmations, since block n+1 builds upon the block with your tx, and block n+2 builds upon block n+1. You can keep checking this for as many blocks as you feel necessary to guarantee that your tx will not be dropped. Most wallets/exchanges check until a tx has 6 confirmations.


How is my real identity linked to my bitcoins?

your identity can be linked to bitcoins in more ways: exchange site can gather info about you (your IP address, ID, bank account, etc), your transactions are public through blockchain, your IP can get registered when you send BTC, your IP address can be registered when you visit BTC forums or any website/honeypot related to darknet markets (illegal activities connected to BTC)... so, there are many techiques to get your identity, thetefore, you should pritect yourself by buying BTC face to face or pay someone to do it for you, and use tor to receive/send bitcoins.


Crypto was declared legal in India, earlier this year by the Supreme Court. That being said there are no legal frameworks/regulations right now by the government.
WazirX is one popular exchange in India. Haven't used it though.


What is the dust limit on Bitcoin Cash transactions?

Bitcoin-ABC (the reference implementation of Bitcoin Cash) is a fork of bitcoin core, there are no big changes to the settings.

so bitcoin cash dust limit is exactly the same as Bitcoin which is 546 Satoshi.

To make sure you can review Bitcoin-cash-ABC/transactions_test/ file code on GitHub line 546

And on transactions file here

/**
 * "Dust" is defined in terms of CTransaction::minRelayTxFee, which has
 * units satoshis-per-kilobyte. If you'd pay more than 1/3 in fees to
 * spend something, then we consider it dust. A typical spendable
 * non-segwit txout is 34 bytes big, and will need a CTxIn of at least
 * 148 bytes to spend: so dust is a spendable txout less than
 * 546*minRelayTxFee/1000 (in satoshis). A typical spendable segwit
 * txout is 31 bytes big, and will need a CTxIn of at least 67 bytes to
 * spend: so dust is a spendable txout less than 294*minRelayTxFee/1000
 * (in satoshis).
 */


Generate multiple public bitcoin receiving addresses (HD wallet) from seed phrase in nodejs

If you want to do Bitcoin stuff in nodejs, I recommend using bcoin:

repo: https://github.com/bcoin-org/bcoin

docs, guides: https://bcoin.io

It has a fully-validating full node implementation, SPV implementation, and BIP44 wallet that is used by Purse.io and several other Bitcoin-accepting merchants for this exact use case: Each customer gets a dedicated account and the wallet can track balances per-user, generating new addresses each time the current receive is used (a la BIP44)

You can set up your server with a watch-only wallet to report incoming deposits, and keep the private keys either offline or on more secure, local machine.

Example:

On secure or offline machine:

$ bcoin --daemon
$ bwallet-cli mkwallet --witness=true --id=HOT
$ bwallet-cli --if=HOT account get default
{
  "name": "default",
  "initialized": true,
  "witness": false,
  "watchOnly": false,
  ..
  "accountKey": "tpubDD3BFBuLYg2cspeDSWZgo9qv4qYi7KQF5oov8theqbFRUFqXPmsowPqAY1PQqnEdUe5JrFqf8ZGWLwEQEKB5WjJjxgMwcXmFuu1XDrG4RSr",
  ..
}

On "hot" production server:

$ bcoin --daemon
$ bwallet-cli mkwallet --id=WATCH --watch-only=true --account-key=tpubDD3BFBuLYg2cspeDSWZgo9qv4qYi7KQF5oov8theqbFRUFqXPmsowPqAY1PQqnEdUe5JrFqf8ZGWLwEQEKB5WjJjxgMwcXmFuu1XDrG4RSr
$ bwallet-cli --id=WATCH address default
{
  "name": "default",
  "account": 0,
  "branch": 0,
  "index": 1,
  "witness": false,
  "nested": false,
  "publicKey": "026f1afcab2942fd932760557943b287957bb8aa6ebe0f8dc64fa25862e23d52a2",
  "script": null,
  "program": null,
  "type": "pubkeyhash",
  "address": "mjdcszSLXHd6awrnM4bgJiFEbTFZdyw7de"
}

...etc

From here you can use API calls to create transaction templates and sign them on the offline machine.

If you are queasy about running an alternative implantation of Bitcoin, you can still run bitcoind on the hot server and run bcoin behind it (even in SPV mode) with bitcoind as it's --only= peer, like a Bitcoin Core Firewall

(edit)

Generate static addresses

'use strict';

const bcoin = require('bcoin');
const m = bcoin.Mnemonic.fromPhrase(
  'abandon abandon abandon abandon abandon abandon'
  + ' abandon abandon abandon abandon abandon about');
const master = bcoin.HDPrivateKey.fromMnemonic(m);
const key0 = master.derivePath("m'/44'/0'/0'/0/0");
const ring0 = new bcoin.KeyRing({privateKey: key0});
console.log(ring0)

Will output:

{
  witness: false,
  nested: false,
  publicKey: '03aaeb52dd7494c361049de67cc680e83ebcbbbdbeb13637d92cd845f70308af5e',
  script: null,
  program: null,
  type: 'pubkeyhash',
  address: '1LqBGSKuX5yYUonjxT5qGfpUsXKYYWeabA'
}

You can verify this is address 0 from that mnemonic phrase using https://iancoleman.io/bip39/ and of course because this phrase is so abysmally insecure and used by developers testing on mainnet (sigh) there are several transactions to this address: https://blockstream.info/address/1LqBGSKuX5yYUonjxT5qGfpUsXKYYWeabA


Sign a tx with "low s" value using OpenSSL

Alternatively, you could use libsecp256k1. This is the code used by Bitcoin Core for signing, and will automatically create low-S signatures (disclaimer: I'm the main author of that library).
Perhaps a Go wrapper exists.

If you stick to OpenSSL, it is possible to manually adjust the S value after signing. This is what Bitcoin Core used to do before v0.10. Here is what it used to do: https://github.com/bitcoin/bitcoin/blob/v0.9.0/src/key.cpp#L204L224


Segfault when attempting to run cgminer on ubuntu 10.04

I realize this question is 8 months old but this information may be of value to others seeking a resolution to a segfault as there seems to be no information available at all on the problem. The APP SDK seems to be incompatible with ATI legacy drivers.

The APP SDK is probably causing the segfault. I have a HD4770 and it was working with a pre-compiled copy of cgminer.

When I installed the APP SDK to compile sgminer everything seemed ok, sgminer compiled ok

However is gave me a segfault and when I tried to run cgminer that was working it too gave me a segfault.

After 3 days, I have been unable to restore things the way they were and undo the changes the APP SDK install made.

I fear that a complete OS reinstall will be my only solution.

Also. the flags '-march=native' enables special cryptographic instructions that are incompatible with AMD CPU's before Bulldozer.


How to set up multiple client under the same address?

You can dump the private key from one and import it into the others


What malleability means is that you can create a transaction that is identical in its meaning (same inputs, same outputs) but with a different TXID. That is problematic for 2nd layer protocols where transactions build onto each other but aren't necessarily published to chain.

But a "malleated" transaction is still a double spend. And it appears newer versions  of bitcoin-core that support RBF won't accept double spends into their mempool.

See code snippet here: Validation Error: Error #-26: 258: txn-mempool-conflict


No, this would not be worth it. CPU mining is extremely slow and there is probably no OpenCL driver for your integrated graphics. You could however hook up FPGAs to that computer, or in the future, bitcoin ASICs.

Currently recommended hardware would be FPGAs and/or fast AMD graphics cards.

In the near future there are several ASIC-based mining devices scheduled for launch. These will drive up the difficulty, making today's FPGAs and AMD GPUs seem slow.


What is a mechanism of method how to get the data in the blockchain(e.g. bitcoin, ethereum)?

Blockchain explorers run multiple nodes which receive all blocks and transactions. They store these blocks and transactions in various databases which allows them to write software which query those databases whenever a user requests information about a block or transaction. They will also do additional processing of the blocks and transactions to produce information such as addresses and be able to provide all of the transactions for a particular address.

When you lookup anything on a block explorer's website, you are not actually sending a query to their node, that would be far too inefficient. By using external databases to store information, they can quickly lookup data in order to return it to the user.


Creating a unconfirmed bitcoin transaction

You can achieve this with timelocks.

The bitcoin wiki says "A Timelock is a type of smart contract primitive that restricts the spending of some bitcoins until a specified future time or block height."

EDIT

Further, it reads:

CheckLockTimeVerify

In late 2015, the BIP65 soft fork[6] redefined the NOP2 opcode as the CheckLockTimeVerify (CLTV) opcode, allowing transaction outputs (rather than whole transactions) to be encumbered by a timelock. When the CLTV opcode is called, it will cause the script to fail unless the nLockTime on the transaction is equal to or greater than the time parameter provided to the CLTV opcode. Since a transaction may only be included in a valid block if its nLockTime is in the past, this ensures the CLTV-based timelock has expired before the transaction may be included in a valid block.

CLTV is currently used in CLTV-style payment channels.

Relative locktime

In mid-2016, the BIP68/112/113 soft fork gave consensus-enforced meaning to some values in the nSequence field[7] that is a part of every transaction input, creating a "relative locktime"[citation needed]. This allowed an input to specify the earliest time it can be added to a block based on how long ago the output being spent by that input was included in a block on the block chain.

CheckSequenceVerify
Also part of the BIP68/112/113 soft fork was the CheckSequenceVerify opcode[8], which provides for relative locktime the same feature CLTV provides for absolute locktime. When the CSV opcode is called, it will cause the script to fail unless the nSequence on the transaction indicates an equal or greater amount of relative locktime has passed than the parameter provided to the CSV opcode. Since an input may only be included in a valid block if its relative locktime is expired, this ensures the CSV-based timelock has expired before the transaction may be included in a valid block.

Hope this helps.


Here is Blockchain.info's chart showing the current estimated distribution of the bitcoin network's hashrate.

Keep in mind: some pools are composed of many individual miners, so in the event of an attack, those individuals may simply redirect their hashpower to a different pool that is not involved in the attack.

In general, controlling the hashrate is not equivalent with 'controlling bitcoin'. If a single entity got control of 51% or more of the hashpower, then they could launch a 51% attack, meaning they could censor transactions. This is an existential threat to the network, but many developers have proposed countermeasures such as a POW change in the event such a thing ever happens.


How can I find the coinbase transactions where the bitcoins involved in a transaction were created?

If you have running bitcoin core, you can use JSON RPC and any programming language you want.

getrawtransaction <txid>
decoderawtransaction <hex>

Second call will return all inputs of transaction. If transaction has previous tx equal to 32 zeroes, it is coinbase transaction. You should recursively cycle through all parent transactions.

API calls list


Can't restore Multibit HD 0.4.1 wallet into Electrum, Electron-Cash wallet for BCC

MultiBit HD uses a different derivation path from all other wallets; it does not use the BIP 44 standard for derivation paths. Thus you cannot use your MultiBit HD mnemonic or extended private key with other wallet software because they use different derivation paths and no wallet currently allows you to set an arbitrary derivation path.

The only way that I know of for you to get the MultiBit HD private keys is to use https://iancoleman.github.io/bip39/. Enter your seed words, choose the BIP 32 tab, and choose the option for MultiBit HD. If you don't see your addresses, try toggling the Hardened Keys option and see if that makes a difference.


Bitcoin adresses seem not to be collision resistant. Please tell me I am wrong

The public key is derived from the private key. Generating a private key is pretty collision resistant as the space is huge. The fact that an address is in turn a hash of the public key doesn't change that.

  So how do you prove, that you are the owner of a bitcoin adress?

By having the private key: only then can you sign transactions.

Consent of the receiver is not required to send a transaction. If the receiver really doesn't want free money, he can chose to not spend it.


How does the thunder network work? And how does it keep things decentralized?

The Thunder Network is just an implementation of the Lightning Network, so it follows the same methods as LN. The summary paper provides a good overview of how it keeps things decentralised.


If you download the bitcoin blockchain via a torrent, can you then prune it?

You can, but it seems you'd get the worst of all worlds:

It's slower than letting Bitcoin Core download and validate simultaneously (as you need to wait until you have the full torrent before validation can start).
It takes (temporarily) more space than just running a non-pruned node (as you're storing the torrent download + the Bitcoin Core data directory with a copy of the pruned blockchain).
You end up with a pruned chain rather than a full chain.

If all you want is a pruned chain, run Bitcoin Core in pruned mode, and it will download, verify, and prune all simultaneously - never using more than a few GB of storage, and still faster than first using a torrent download.


Having issues broadcasting BitcoinJS transaction.

The miner fee will, by default, equal the inputs - outputs of your transaction.
I notice some problems with your code. You do not specify a change address to send the left-over amount. If I have an unspent output of 100 BTC and I want to send 10 BTC to someone else, I should have 1 input (the unspent output from the previous transaction) and 2 outputs (the receiver address and the change address). The inputs and outputs will look like this:

Inputs

Unspent output of 100 BTC

Outputs

Receiver address with 10 BTC
Change address (your BTC address) with 89.999 BTC

The fee will be 0.001 BTC since (in)(100) - (out)(10 + 89.999) = 0.001.
Hope I was able to help.


How can I find the sender's address from the transaction hash?

You can for example check the Block Explorer's info about a given transaction. For example, given transaction 1c480aad976c61b51ae47401a554b09f65efe6f95f644041f838d9129e09167c, you can see that the only input was associated with address 1HnjAo2nbHGFDto86smcFiF3uUwfvNJ4cS.

However, generally you should avoid using transaction inputs for basically any purpose - they do not uniquely identify a user, sending Bitcoins back to the user might be problematic with just this information and so forth.


What are the arguments for and against deprecating transaction priority?

Since transaction priority has never really been a consensus based "protocol", it was never really that valuable to have it in the core code. Miners can and DO change the priority how they see fit. I see it as less code to maintain in the end and since Bitcoin is meant to be a free market network, the fees paid will prevail


Why doesn't Bitcoin return lost coins back into the block reward?

As Stephen points out it would force people to spend coins. Age is not a proper measure of lostness. A common recommendation for savings accounts is to put them on physical backups such as printed QR codes that you add to while the account itself remains offline. People may even will their Bitcoin savings to their children. To force people to shuffle these coins around from time to time to keep them from being taken undoes one of the major safety features of Bitcoin. Namely that transactions can not be reversed, and your accounts can not be frozen or taken from you by any mechanism.

Also there is no reason. The entire Bitcoin economy could be run on a single bitcoin because of its divisibility. There simply is no reason to break other important Bitcoin features to regain those coins. It wouldn't even actually increase the miners' rewards because for every extra coin brought back the wealth is distributed over more coins reducing the value of each coin with inflation. A million dollars of value spread over 1000 bitcoins if there are 1000 bitcoins in circulation, is the same one million dollars of value spread over 1 bitcoin if there is only 1 bitcoin in circulation.


Got it working.

Ken's blog assumes a Windows environment, in 64-bit Linux the byte counts are different for certain datatypes so I had to change some of the "pack" formats.

Finally, I'd been doing everything in hex and converting to binary only for the socket send. When calculating the sha256 (twice) checksum however this must be on the BINARY payload.

Working code (for 64-bit Linux at least):

import struct
import socket
import time
import hashlib
import binascii

magic = "f9beb4d9"

def makeMessage(magic,command,payload):
    checksum = hashlib.sha256(hashlib.sha256(payload).digest()).digest()[0:4]
    return magic.decode("hex")+struct.pack('12sI4s',command,len(payload),checksum)+payload
def makeVersionPayload():
    version = 70002
    services = 0
    timestamp = int(time.time())

    addr_you = "127.0.0.1"
    services_you = 0
    port_you = 8333

    addr_me = "127.0.0.1"
    services_me = 0
    port_me = 8333

    nonce = 0

    user_agent_bytes = 0
    start_height = 0
    relay = 1

    #https://bitcoin.org/en/developer-reference#version
    payload = "";
    payload += struct.pack("i",version)
    payload += struct.pack("Q",services)
    payload += struct.pack("q",timestamp)
    payload += struct.pack("Q",services_you)
    payload += struct.pack(">16s",addr_you)
    payload += struct.pack(">H",port_you)
    payload += struct.pack("Q",services_me)
    payload += struct.pack(">16s",addr_me)
    payload += struct.pack(">H",port_me)
    payload += struct.pack("Q",nonce)
    payload += struct.pack("B",user_agent_bytes)
    payload += struct.pack("i",start_height)
    payload += struct.pack("B",relay)
    return payload

ip = socket.gethostbyname("124.248.237.178")
port = 8333
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print "connected to node..."
sock.connect((ip,port))

msg = makeMessage(magic,"version",makeVersionPayload())
print "sending version packet"
sock.send(msg)

while 1:
    msg = sock.recv(2**10)
    if not msg:
        print "done"
        exit()
    else:
        print msg.encode("hex")


Do i have to delete/clear anything in Firefox after creating offline keys using Bitaddress?

The whole idea of bitaddress is that your addresses are dynamically generated. As such, the only place it would be is in the browser cache or RAM. Rebooting the computer will clear the RAM and deleting the browser history (preferences->privacy->clear your recent history) should clear the cache.


Security implications of regular saving into cold storage

Q1: Depens on how you use it.
Transactions to an address does not decrease it's security.
Using a cold-storage wallet and taking it online exposes your wallet and it's security.

Q2: It's correct. Most exchanges require KYC(know your customer), they store information about you and your withdrawal addresses. It's possible to create a new address for each withdrawal. It's hard to prove that you are in possession of the withdrawal address.

  (the reason why I want to do 2 is that I do not feel I really own bitcoins until they are in a wallet under my control)

Can't stress this part enough, you only own bitcoin if only you own the private keys.


I don't see how this would work. If they charge less fees than the current fee they are essentially throwing away money. If they charge more there is no incentive for you to use them. Also you cant expect a mining pool to always include your tx in the next block. If the pool has 30% of the network hashpower you would expect them to mine 1 out of every 3 blocks.


What features of scrypt() make Tenebrix GPU-resistant?

The scrypt() algorithm has at its core a routine called ROMmix.  Basically, it defines

  V(1) = hash(message)
  V(2) = hash(hash(message))
  V(3) = hash(hash(hash(message)))
  ...

and it calculates

  V(V(V(V(...(message))))

Since computing V(n+1) requires computing V(n) first, the most efficient way to do this is to cache all of the previously-computed values.  Once you've generated a large enough table, the V(V(V(...))) is just a bunch of lookups.

Caching all the previously computed values requires lots of memory, and since each lookup depends on the previous one it's sensitive to memory latency (although if you're mining you can work on several blocks in parallel and pipeline the requests to get around this).

GPUs can perform far more integer operations per second than a normal CPU, but have roughly the same memory bandwidth/latency as a CPU.  So an algorithm that is memory-dominated should "level the playing field" between CPUs and GPUs.

I still don't understand why the Tenebrix folks consider this to be an important goal.  It just "equalizes" GPUs and CPUs, but you can still build custom hardware that does scrypt() much faster and cheaper than a CPU.  So it's just going from "GPUs are best" to "custom printed circuit boards covered in memory buses are best".  Nobody's been able to explain why this change is worth all the trouble.


Looking for a comprehensive ICO dataset (prices & dates)

I'm developing an open source software to unify all these disjoint sources in one database. I've found an interesting free API service (IcoBench) that have a lot of information for ICOs, like prices, team, even ratings and a lot of more. The post ICO prices are not stored, but you can use coinmarketcap.com for search historical prices after the ICO was ended and be launched to the markets. I've developed an API wrapper and web scraper for that page that works in Python, check out.

I will advise when the project will be more advanced. Currently, this kind of open source unification is a huge neccesary work in cryptoworld. Cheers!


I don't think the issue is that they don't have the data. I think they're just showing the data at a lower sampling rate.

This chart draws data from three locations:

https://api.bitcoinaverage.com/history/USD/per_minute_24h_sliding_window.csv
Updates once per minute, but only has 24 hours of data.
https://api.bitcoinaverage.com/history/USD/per_hour_monthly_sliding_window.csv
Updates once per hour, but only has a month of data.
https://api.bitcoinaverage.com/history/USD/per_day_all_time_history.csv
Updates once per day, but has all data.

Note how the data that goes back further is less precise.


Sender, nodes or miners? Who validates transactions?

Other nodes check if the transaction is valid, and if it is, they relay the transaction to other nodes. Mining pools have also (at least one) nodes, they verify it too, and if it's valid and the fee is enough, they put it in the block they're working on.
Do miners check it before including it in a block?

Yep. If they include an invalid transaction, the other nodes will not accept that block, and that miner won't earn the block reward for that block. (currently 125k dollars!)

Do other nodes check it and where there is a certain consensuous miners include it into a block

Yes.

Who composes the blocks then?

Miners.

Are all miners trying to solve the same block at the same time or different blocks?

They are trying to find a block with the same height, but with different transactions, different nonces (a random number - related to block hash and difficulty) and different block reward addresses.


Does OP_EQUALVERIFY have a return value?

If the execution of OP_EQUAL gives true, then it does not leave true/false on the stack. If it is false then it leaves false on top of the stack and stops executing.

Bstack.push_back(fEqual ? vchTrue : vchFalse);
if (opcode == OP_EQUALVERIFY)
{
if (fEqual)
    popstack(stack);
else
    return set_error(serror, SCRIPT_ERR_EQUALVERIFY);
}

Source


There is no substantial technical difference between Litecoin and Bitcoin transactions.

Litecoin does not offer any additional "privacy techniques". The only differences are:

address scheme: Litecoin addresses start with an L, Bitcoin standard addresses start wtih a 1.
Volume: Bitcoin volume is much higher, so it might be easier to obscure a payment among the other transactions.
Attention: Bitcoin might have more attention of law enforcement.

Note: The last two points are based on speculation.