So, after many days I was able to solve this problem. I was able to send transaction from one customer having (NGN) to another Customer who received it in (USD).

For others who may likely face similar problem in the future, this are the steps I took to solve this problem.

Step 1

I created offers for all the currencies. see example request and response below

{
  "method": "submit",
  "params": [
    {
      "offline": false,
      "secret": "snYothV5CFDMpMYStmL5VwMHzxHFr",
      "fee_mult_max": 1000,
      "tx_json": {
        "TakerGets": {
          "currency": "EUR",
          "value": "0.94",
          "issuer": "rJ5mA3kRwJWahdb3GqH3vmrbRd7eVufsVk"
        },
        "TakerPays": {
          "currency": "USD",
          "value": "1",
          "issuer": "rfJbVE7tTrkbmuqTBvhdYDRExp9oamTzrQ"
        },
        "Account": "rJ5mA3kRwJWahdb3GqH3vmrbRd7eVufsVk",
        "TransactionType": "OfferCreate",
        "Fee": "12",
        "Flags": "65536"
      }
    }
  ]
}

and sample response

{
  "result": {
    "engine_result": "tesSUCCESS",
    "engine_result_code": 0,
    "engine_result_message": "The transaction was applied. Only final in a validated ledger.",
    "status": "success",
    "tx_blob": "1200072200010000240000001764D4838D7EA4C68000000000000000000000000000555344000000000045249D498FF76EF67DACD0958930DB02EE4A9D4465D46165400CE380000000000000000000000000004555520000000000C260B3831882A44608EE81C2F3726AA72D11CA9568400000000000000C732102272E391673B735C9D96435DAFF89F9EA7B4EC285C39643A754848EDE19A6542674473045022100CD7511B302ED7D0C299C0F2C1014EA5AA62F7584B361B940C0E8A98FBA04EDE10220047590E7A678818000B5B221EBBC3D21AB1FCE5C003F8F02AAC41F96D054F90A8114C260B3831882A44608EE81C2F3726AA72D11CA95",
    "tx_json": {
      "Account": "rJ5mA3kRwJWahdb3GqH3vmrbRd7eVufsVk",
      "Fee": "12",
      "Flags": 65536,
      "Sequence": 23,
      "SigningPubKey": "02272E391673B735C9D96435DAFF89F9EA7B4EC285C39643A754848EDE19A65426",
      "TakerGets": {
        "currency": "EUR",
        "issuer": "rJ5mA3kRwJWahdb3GqH3vmrbRd7eVufsVk",
        "value": "0.94"
      },
      "TakerPays": {
        "currency": "USD",
        "issuer": "rfJbVE7tTrkbmuqTBvhdYDRExp9oamTzrQ",
        "value": "1"
      },
      "TransactionType": "OfferCreate",
      "TxnSignature": "3045022100CD7511B302ED7D0C299C0F2C1014EA5AA62F7584B361B940C0E8A98FBA04EDE10220047590E7A678818000B5B221EBBC3D21AB1FCE5C003F8F02AAC41F96D054F90A",
      "hash": "C35F98185CEBD03EEBCBDB6BB4364288DD8A0EDCF6FE137E9E3950524353AC8B"
    }
  }
}

Step 2
I Did a find path to get the path to use in sending the transaction, based on the offers earlier created in step 1

{
  "method": "ripple_path_find",
  "params": [
    {
      "source_account": "rfJbVE7tTrkbmuqTBvhdYDRExp9oamTzrQ",
      "source_currencies": [
        {
          "currency": "XRP"
        },
        {
          "currency": "USD"
        }
      ],
      "destination_amount": {
        "currency": "NGN",
        "value": "305",
        "issuer": "rE3FSvB4Q59WZUXcDyB8tgAFBTZMwCJ1FD"
      },
      "destination_account": "rwRRz7yt7GXe2NjZjB9ruLs7r71fi1WNpQ",
      "SendMax": {
        "currency": "USD",
        "value": "1",
        "issuer": "rfJbVE7tTrkbmuqTBvhdYDRExp9oamTzrQ"
      }
    }
  ]
}

Sample Response

{
  "result": {
    "alternatives": [
      {
        "paths_canonical": [],
        "paths_computed": [
          [
            {
              "account": "rntHFZfVgoCeBNYDxSejkPewViFow1Sz6r",
              "type": 1,
              "type_hex": "0000000000000001"
            },
            {
              "account": "rJHPyhod8HuZhps6Gerf7t3yLfinpVLXNT",
              "type": 1,
              "type_hex": "0000000000000001"
            },
            {
              "currency": "NGN",
              "issuer": "rE3FSvB4Q59WZUXcDyB8tgAFBTZMwCJ1FD",
              "type": 48,
              "type_hex": "0000000000000030"
            }
          ],
          [
            {
              "currency": "EUR",
              "issuer": "rJ5mA3kRwJWahdb3GqH3vmrbRd7eVufsVk",
              "type": 48,
              "type_hex": "0000000000000030"
            },
            {
              "currency": "NGN",
              "issuer": "rE3FSvB4Q59WZUXcDyB8tgAFBTZMwCJ1FD",
              "type": 48,
              "type_hex": "0000000000000030"
            }
          ]
        ],
        "source_amount": {
          "currency": "USD",
          "issuer": "rfJbVE7tTrkbmuqTBvhdYDRExp9oamTzrQ",
          "value": "1"
        }
      }
    ],
    "destination_account": "rwRRz7yt7GXe2NjZjB9ruLs7r71fi1WNpQ",
    "destination_amount": {
      "currency": "NGN",
      "issuer": "rE3FSvB4Q59WZUXcDyB8tgAFBTZMwCJ1FD",
      "value": "305"
    },
    "destination_currencies": [
      "NGN",
      "XRP"
    ],
    "full_reply": true,
    "ledger_current_index": 3,
    "source_account": "rfJbVE7tTrkbmuqTBvhdYDRExp9oamTzrQ",
    "status": "success",
    "validated": false
  }
}

Step 3
I used one of the paths returned in the response from above to send payment request.

Sample Request

{
  "method": "submit",
  "params": [
    {
      "offline": false,
      "secret": "sn1GPS42vNZXg6GYrsSXxYv2VrbkG",
      "fee_mult_max": 100000,
      "tx_json": {
        "Amount": {
          "currency": "NGN",
          "value": "305",
          "issuer": "rE3FSvB4Q59WZUXcDyB8tgAFBTZMwCJ1FD"
        },
        "Account": "rfJbVE7tTrkbmuqTBvhdYDRExp9oamTzrQ",
        "Destination": "rwRRz7yt7GXe2NjZjB9ruLs7r71fi1WNpQ",
        "TransactionType": "Payment",
        "Fee": "10",
        "Flags": "0",
        "Paths": [
          [
            {
              "type_hex": "0000000000000030",
              "issuer": "rJ5mA3kRwJWahdb3GqH3vmrbRd7eVufsVk",
              "type": "48",
              "currency": "EUR"
            },
            {
              "type_hex": "0000000000000030",
              "issuer": "rE3FSvB4Q59WZUXcDyB8tgAFBTZMwCJ1FD",
              "type": "48",
              "currency": "NGN"
            }
          ]
        ],
        "SendMax": {
          "currency": "USD",
          "value": "1",
          "issuer": "rfJbVE7tTrkbmuqTBvhdYDRExp9oamTzrQ"
        }
      }
    }
  ]
}

Sample Response

{
  "result": {
    "engine_result": "tesSUCCESS",
    "engine_result_code": 0,
    "engine_result_message": "The transaction was applied. Only final in a validated ledger.",
    "status": "success",
    "tx_blob": "1200002200000000240000000461D50AD5F57690A0000000000000000000000000004E474E00000000009B0C47828166D6258E8E7F0AA3B464FEA9C17E6668400000000000000A69D4838D7EA4C68000000000000000000000000000555344000000000045249D498FF76EF67DACD0958930DB02EE4A9D4473210336DF52033C6AE8F955A8AE89CE32793C0DB54A3DA2477A0F769EA9A4320D754D74463044022019DBE3D2C7ADF58AD35F1924889B8612EC46E8421492BDC591D50EEABCBC0BA9022046F9D34D8DAF24698B3B5A973AB575E5901A1C14EB80E8ABDC25B0D8010F0983811445249D498FF76EF67DACD0958930DB02EE4A9D4483146757FA04E0212B971F7F76E3E4A85A1B280EAE770112300000000000000000000000004555520000000000C260B3831882A44608EE81C2F3726AA72D11CA95300000000000000000000000004E474E00000000009B0C47828166D6258E8E7F0AA3B464FEA9C17E6600",
    "tx_json": {
      "Account": "rfJbVE7tTrkbmuqTBvhdYDRExp9oamTzrQ",
      "Amount": {
        "currency": "NGN",
        "issuer": "rE3FSvB4Q59WZUXcDyB8tgAFBTZMwCJ1FD",
        "value": "305"
      },
      "Destination": "rwRRz7yt7GXe2NjZjB9ruLs7r71fi1WNpQ",
      "Fee": "10",
      "Flags": 0,
      "Paths": [
        [
          {
            "currency": "EUR",
            "issuer": "rJ5mA3kRwJWahdb3GqH3vmrbRd7eVufsVk",
            "type": 48,
            "type_hex": "0000000000000030"
          },
          {
            "currency": "NGN",
            "issuer": "rE3FSvB4Q59WZUXcDyB8tgAFBTZMwCJ1FD",
            "type": 48,
            "type_hex": "0000000000000030"
          }
        ]
      ],
      "SendMax": {
        "currency": "USD",
        "issuer": "rfJbVE7tTrkbmuqTBvhdYDRExp9oamTzrQ",
        "value": "1"
      },
      "Sequence": 4,
      "SigningPubKey": "0336DF52033C6AE8F955A8AE89CE32793C0DB54A3DA2477A0F769EA9A4320D754D",
      "TransactionType": "Payment",
      "TxnSignature": "3044022019DBE3D2C7ADF58AD35F1924889B8612EC46E8421492BDC591D50EEABCBC0BA9022046F9D34D8DAF24698B3B5A973AB575E5901A1C14EB80E8ABDC25B0D8010F0983",
      "hash": "58906C7DEFCF60ED6AC55A646BE3BF50E32F7B633AC6CD62E1AA6799888AA5EA"
    }
  }
}


Unconfirmed Transactions on Balance and History

You should enable this feature in copay settings:


That would probably work fine.  Mining doesn't generally require fast disk access, especially if you are mining in a pool.

Of course, you'll have to reboot into your Ubuntu installation each time you want to start mining, and you won't be able to use your "daily" operating system at the same time as mining.


Which is the smallest hash that has ever been hashed?

I don't think there is a site that will show you this information, but it is fairly trivial to find out.

Here's an old Bitcointalk thread that discusses this: https://bitcointalk.org/index.php?topic=29675.0

Here's a python script that will calculate it for you. You will need a bitcoind for it to connect to:

from bitcoinrpc.authproxy import AuthServiceProxy, JSONRPCException
import binascii
import struct

def uint256_to_str(u):
    rs = b""
    for i in range(8):
        rs += struct.pack("<I", u & 0xFFFFFFFF)
        u >>= 32
    return binascii.hexlify(rs)

def uint256_from_str(s):
    s = binascii.unhexlify(s)
    r = 0
    t = struct.unpack("<IIIIIIII", s[:32])
    for i in range(8):
        r += t[i] << (i * 32)
    return r

def byteswap(a):
    return "".join(reversed([a[i:i+2] for i in range(0, len(a), 2)]))

# rpc_user and rpc_password are set in the bitcoin.conf file
rpc_user = "user"
rpc_password = "password"
rpc_connection = AuthServiceProxy("http://%s:%s@127.0.0.1:8332"%(rpc_user, rpc_password))

best_hash = uint256_from_str("ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff")
best_height = 0
counter = 0

while True:
    try:
        commands = [ [ "getblockhash", height] for height in range(counter, counter + 10000) ]
        block_hashes = rpc_connection.batch_(commands)

        for block_hash in block_hashes:
            block_uint256 =  uint256_from_str(byteswap(block_hash))
            if block_uint256 < best_hash:
                best_hash = block_uint256
                best_height = counter
            counter += 1

        print("Processed " + str(counter) + " blocks")
    except Exception as e:
        print(e)
        break;

print("Lowest Block Hash: " + byteswap(uint256_to_str(best_hash).decode()) + " at block height " + str(best_height))

This script gave me the following output:

Lowest Block Hash: 00000000000000000000011246f099d94f91628d71c9d75ad2f9a06e2beb7e92 at block height 458091


What's the most efficient way to create a raw transaction with a specific fee rate?

Yes! The trick is to count each input with its effective value rather than its nominal value.
Transactions are composed of three parts: the overhead, the inputs and the outputs.

Outputs:
The size of the output scripts is determined by the recipient addresses, so their size is given by the transaction instructions. We do not know whether we will need a change output yet, but we know what size it would be if we created one.

Overhead:
The transaction overhead is 10 bytes for non-segwit transactions, or 42 WU for segwit transactions. You can probably guess which one you'll need, but in the worst case you overestimate by 0.5 vB. We can therefore consider the overhead size also to be fixed.

Inputs:
The tricky part is the transaction inputs. You do not know how many you will need, and might not know what input script sizes they'll have if you have inputs of various address formats. Additionally, signatures are not always the same size. However, we do know the maximum size of the signature, and the size of the input script for each UTXO. Together with the target fee rate, we can calculate the effective value:
effectiveValue = utxo.value − feePerByte × bytesPerInput¹

The selection target starts out as the sum of the recipient amounts. We simplify the coin selection problem by adding the fixed costs to the selection target. We then perform the selection via counting effective values rather than nominal values. Since each input has paid for itself already when it is selected, we no longer need to worry about an input's fee impact after selection; instead each effective value goes fully towards the selection target.
In regard to the change output, there are two strategies. One, if you are aiming to build a transaction that avoids creating change, e.g. by using Branch and Bound selection, you keep the target as is: target = recipient amounts + fees for fixed transaction parts. Two, if you are using a strategy that will create change, you add a buffer to the selection target that is large enough to cover the fee of the change output and leave enough for a good-sized change output: target = recipient amounts + fees for fixed tx parts + change output cost + minChange.
For the signatures, you estimate using the maximum signature length. Since the signatures are part of the witness for segwit inputs, this results only in a small size overestimation which will lead to minutely overshooting the target fee rate.² Alternatively, you can use signature grinding to save an expected 0.5 bytes per signature and estimate the fee rate more precisely.
¹ Effective value was proposed in section 5.3 of An Evaluation of Coin Selection Strategies, Erhardt 2016, disclosure: authored by yours truly.
² Overshooting the target fee rate is preferable; it costs only a few satoshis and slightly increases the priority of the transaction. Undershooting the target fee rate is problematic, since some payment processors require a minimum fee rate to accept a payment and falling below the default minRelayTxFeeRate can prevent a transaction from relaying altogether.


Vouching for (or against) the reputation of a bitcoin user

There is already three rating systems in existence from different trading platforms: #bitcoin-otc , Bitmit and Silk Road. Bitcoin users actively using their rated OTC identity to make their words more trustworthy.

I believe integration of rating system into Bitcoin Network won't be beneficial and developers will not ever try to implement that. It is possible that in future obfuscation will be enabled by default, at least it is feasible to do it : Automatic Coin Mixing Idea and P2P coin mixing.


Can you send Bitcoins from Bitcoin-Qt without downloading the whole blockchain?

No, because Bitcoin-Qt still has no way of knowing if you actually have those bitcoins.

Imagine you had the same wallet on two separate computers one with the block chain fully downloaded and one with it only half downloaded. Now Imagine you have 10 bitcoins. On the wallet with the block chain fully downloaded you send all 10 coins to your friend. This computer now reflects that you have 0 bitcoins while the one with the half downloaded block chain still says you have 10. If Bitcoin-Qt allowed you to send those bitcoins, it would be opening the network up to double spending.


If you want to set the transaction fee manually, then you will need to use the *rawtransaction commands. Those commands give you full control over the inputs and outputs so you can set the fee accordingly (since the fee is the difference between the inputs and outputs).

You can create a raw transaction with no inputs and no change output using createrawtransaction. You do so like this:

bitcoin-cli createrawtransaction '[]' '[{"<address>":<amount}]'

where <address> is the address you want to send to and <amount> is the amount you want to send. You can then take the resulting raw transaction and use fundrawtransaction with it to get inputs and a change output if necessary. fundrawtransaction allows you to set the fee rate. So if you wanted a transaction with a fee rate of 0.0001 BTC/kB (10 satoshis per byte):

bitcoin-cli fundrawtransaction <raw tx> '{"feeRate":0.0001}'

The funded transaction is the one in the hex field of the output of that command. You sign this with signrawtransaction and then broadcast it with sendrawtransaction.


Why is my segwit private key generating a 3 address vs a bc1 address like how I originally generated?

There is no standard for specifying whether a private key should correspond to a bech32 address, P2SH nested segwit address, or P2PKH address (1... address). The WIF format has traditionally been used for P2PKH addresses. However some wallets now will decide to instead create a P2SH nested segwit address or even a bech32 address instead. But because there is no standard for private keys that correspond to segwit addresses, it is entirely up to the wallet to determine what kind of address to give you for a private key.

In your case, the wallet gave you a P2SH nested segwit address. But it could have just as easily given you the P2PKH address or the bech32 address since the private key can be used to produce all 3 types of addresses.


Is it possible to design a hardware wallet that can allow operation of a routing Lightning node with the security level of a hardware wallet?

Yes, a hardware wallet could be designed for use on the Lighting Network, but no, there's no such thing as eliminating risk of theft.  There is always risk of theft, no matter what you do.

A hardware wallet could be made to sign the transactions needed to construct the smart contracts for lightning channels, and could even be made to communicate with them.  This would keep the private keys out of the memory of the computer running the lightning node, thus reducing the risk...but not eliminating it.

There is always the chance that the protocol used to communicate to with the wallet is vulnerable to exploitation, or even the hardware wallet itself.  Even if the vulnerability didn't compromise the wallet, but merely rendered it inoperable for a time, an attack could be crafted where you end up forfeiting your money in the channel because you are unable to sign transactions.

Our technology is built on layers on top of layers on top of layers on top of layers.  Hardware wallets and tier 2 smart contract networks are no exception.  Anyone who tells you it is risk-free is selling something.


What does "NODE_WITNESS (12)" mean as it is shown in bitnodes.21.co?

I've looked through several pages on bitnodes to find some more nodes that show NODE_WITNESS (12). I've noticed a pattern: the number corresponds to the services that a node offers. Nodes advertise the services that they offer by sending a bitmap named nServices. The number in the brackets matches the decimal representation of the service bits that a node has set.

Looking around a bit, I've identified the following five bits:

NODE_NETWORK (1)
NODE_GETUTXOS (2)
NODE_BLOOM (4)
NODE_WITNESS (8)
NODE_XTHIN (16)

So, I'd say that with (12), you must be offering the services NODE_BLOOM, NODE_WITNESS (12), lemme guess, you run a pruning node? :) Or would it be "blocksonly"?

Edit: Here are the service bits defined in the source code: protocol.h:249


You can create raw transaction, sign, ...etc programmatically but if you need to fetch address transactions (inputs) or broadcast the signed transaction to bitcoin network you'll need to connect to Bitcoin network.

Bitcoin-core is amazing for this purpose and if you don't want to download the whole blockchain you can alternatively use Electrum servers.

helpful commands for Bitcoin-core:

listunspent: returns an array of unspent transaction outputs belonging to this wallet.

ListTransactions: returns the most recent transactions that affect the wallet.

Electrum commands:

after connecting to some electrum server you should send JSON-RPC commands

listunspent example:

{ "id": 1, "method":"blockchain.address.listunspent", "params"["1NS17iag9jJgTHD1VXjvLCEnZuQ3rJDE9L"] }

UPDATE

if you are already using Bitcoin-core, so you only need to call listunspentto get your wallet UTXO's or provide an address to get that address UTXO's.

bitcoin-cli listunspent MIN_CONF MAX_CONF "["ADDRESS_NUMBER_ONE","ADDRESS_NUMBER_TWO"]"

If those address doesn't belong to your wallet, you should import them first.


Where can I read more about the fields of the transaction returned by listtransactions API

The Bitcoin developer reference has a section on the listtransactions call:

The blocktime is the timestamp of the block that confirmed this transaction on your local best blockchain. It is not returned for unconfirmed transactions.

The time field tracks the time that your wallet started tracking this transaction.

The timereceived field tracks the time that your node learned about the transaction, or alternatively the time of the block that included this transaction.


The testnet data directory is not ~/.bitcoin but rather ~/.bitcoin/testnet3. ~/.bitcoin holds the data for the main Bitcoin blockchain.


My wallet doesn't show a confirmed transaction

Open your btc wallet using app then go to addresses ! click on the address that you want to recover the and hope des :D


Like all true Bitcoin wallets, the Copay wallet secures your Bitcoin and Bitcoin Cash only on your device. To restore your wallet if your device is lost or stolen, you must save the 12-word backup phrase that you receive when you create a wallet. Without this recovery phrase, you will not be able to recover your funds.


I just buy some bitcoin and this is how I see from Electrum, what should I do now to receive the bitcoin?

You don't have do anything. That transaction will confirm in due course of time. You don't have to keep electrum or even your PC running.

On average it takes 10 minutes for the first confirmation. More confirmations happen all the time as the blockchain gets extended.

Note that you bought 0.001 bitcoins. The unit of account displayed there is mbtc which is 1/1000th of a bitcoin. If you want to change it to btc you can do so via tools > preferences > appearance tab > base unit option.


What does the Sender of a Transaction include in the Input that allows the Recipient to Unlock/Redeem?

The transaction output has a property called the scriptPubkey that is executed with the scriptSig when the output is spent in a transaction. An understanding of Bitcoin script would help.

Bitcoin Script

Bitcoin uses it's own stack-based scripting language with a set of op-codes. This scripting language is used to determine whether an unspent transaction output (utxo) can be spent. When you send Bitcoin, you are really just assigning a Bitcoin value to a script, which can be spent only if the script executes successfully and results in a single true value on the stack. The script that is assigned to the Bitcoin transaction output is called the scriptPubKey. To satisfy the script, you must provide the correct scriptSig, which is also a script, which is prepended to the scriptSig and executed to test if the spending succeeded. Let's look at an example:

scriptPubKey (raw): 76a914306e2ea1eed91bf66dfe5d94f3957d4ba63bde8488ac
scriptPubKey (assembly): OP_DUP OP_HASH160 306e2ea1eed91bf66dfe5d94f3957d4ba63bde84 OP_EQUALVERIFY OP_CHECKSIG

In plain english, this script, when executed will do the following:

OP_DUP: Duplicate the top item on the stack (place a copy of it on the stack)
OP_HASH160: Pop the top item off the stack, calculate it's HASH160, i.e. the  RIPEMD160(SHA256()), and place that on the stack
OP_EQUALVERIFY: Pop the top 2 items off the stack, and if they are not equal, it will exit immediately and fail, otherwise nothing
OP_CHECKSIG: Pop the top 2 items off the stack, and use the top as the public key, the second as the signature, and verify the transaction signature

In order to spend this output, we must provide a valid signature and public key. We'll just provide 00 for the signature for this example, and not worry about the final checksig op.

Example

Let's visualize this example with a scriptSig. Let's use kallewoof's btcdeb Script visualization tool. After the first command, you can type step once, and then just press enter each time after that to step through each operation:

$ btcdeb '[00 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046 OP_DUP OP_HASH160 306e2ea1eed91bf66dfe5d94f3957d4ba63bde84 OP_EQUALVERIFY OP_CHECKSIG]'

btcdeb -- type `btcdeb -h` for start up options
valid script
7 op script loaded. type `help` for usage information
script                                                             |  stack
-------------------------------------------------------------------+--------
0                                                                  |
030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046 |
OP_DUP                                                             |
OP_HASH160                                                         |
306e2ea1eed91bf66dfe5d94f3957d4ba63bde84                           |
OP_EQUALVERIFY                                                     |
OP_CHECKSIG                                                        |
#0000 0
btcdeb> step
        <> PUSH stack
script                                                             |  stack
-------------------------------------------------------------------+--------
030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046 |      0x
OP_DUP                                                             |
OP_HASH160                                                         |
306e2ea1eed91bf66dfe5d94f3957d4ba63bde84                           |
OP_EQUALVERIFY                                                     |
OP_CHECKSIG                                                        |
#0001 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
btcdeb>
        <> PUSH stack 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
script                                                             |                                                             stack
-------------------------------------------------------------------+-------------------------------------------------------------------
OP_DUP                                                             | 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
OP_HASH160                                                         |                                                                 0x
306e2ea1eed91bf66dfe5d94f3957d4ba63bde84                           |
OP_EQUALVERIFY                                                     |
OP_CHECKSIG                                                        |
#0002 OP_DUP
btcdeb>
        <> PUSH stack 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
script                                                             |                                                             stack
-------------------------------------------------------------------+-------------------------------------------------------------------
OP_HASH160                                                         | 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
306e2ea1eed91bf66dfe5d94f3957d4ba63bde84                           | 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
OP_EQUALVERIFY                                                     |                                                                 0x
OP_CHECKSIG                                                        |
#0003 OP_HASH160
btcdeb>
        <> POP  stack
        <> PUSH stack 306e2ea1eed91bf66dfe5d94f3957d4ba63bde84
script                                                             |                                                             stack
-------------------------------------------------------------------+-------------------------------------------------------------------
306e2ea1eed91bf66dfe5d94f3957d4ba63bde84                           |                           306e2ea1eed91bf66dfe5d94f3957d4ba63bde84
OP_EQUALVERIFY                                                     | 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
OP_CHECKSIG                                                        |                                                                 0x
#0004 306e2ea1eed91bf66dfe5d94f3957d4ba63bde84
btcdeb>
        <> PUSH stack 306e2ea1eed91bf66dfe5d94f3957d4ba63bde84
script                                                             |                                                             stack
-------------------------------------------------------------------+-------------------------------------------------------------------
OP_EQUALVERIFY                                                     |                           306e2ea1eed91bf66dfe5d94f3957d4ba63bde84
OP_CHECKSIG                                                        |                           306e2ea1eed91bf66dfe5d94f3957d4ba63bde84
                                                                   | 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
                                                                   |                                                                 0x
#0005 OP_EQUALVERIFY
btcdeb>
        <> POP  stack
        <> POP  stack
        <> PUSH stack 01
        <> POP  stack
script                                                             |                                                             stack
-------------------------------------------------------------------+-------------------------------------------------------------------
OP_CHECKSIG                                                        | 030cfcefa07af9dd6dbe770b87d7dbdd2c31ba7f4fcf8f3a1196d502f13561b046
                                                                   |                                                                 0x
#0006 OP_CHECKSIG

You can play around with this using any of the opcodes listed at Script.


On public keys compression, why an even or odd y coordinate corresponds to the positive / negative sign respectively?

There is no such thing as a negative or a positive value when you're talking in a finite field.

For example, in Z7, the field of integers modulo 7. There holds:

0 = 7 = 14 = -7
1 = 8 = 15 = -6
2 = 9 = 16 = -5
...

So you can't say that the number 2 is positive, because it's equal to -5.

Despite that, the square root still has two solutions. For example, 3^2 = 9 = 2, 4^2 = 16 = 2. Thus both 3 and 4 are square roots of 2.

So we need a way to say which solution we want. Turns out, that when reduced to a range of 0-6, the two solutions of the square, one is odd and the other is even.


I believe you can still use the generate and generatetoaddress commands to mine a certain number of blocks. setgenerate was removed in version 0.13 because mining with bitcoin core on mainnet is useless and has been for a number of years:
https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.13.0.md#removal-of-internal-miner


How do i setup 2x TTbiT Usb Miners on CGminer?

Here is a link[https://docs.google.com/viewer?url=https%3A%2F%2Fwww.eyeboot.com%2Fdownload%2FTTBIT%2FTTBIT-SHA256-USB-Miner-Setup-Guide.pdf]
That was what i used to set mine up


This is likely implementation specific. Bitcoind is an intensive application to run on a basic server, especially if the webapp lives on the same machine.

You should never directly connect a page's code with Bitcoin Core, for static information you should run a cronjob to update a cache every n seconds. If all you're showing is the last 10 blocks, maybe you shouldn't have every user at that moment triggering calls for the same data.

Update: It's worth mentioning that RPC responses suffer a delay whenever Bitcoin Core is syncing, whether syncing for the first time, or being switched on after a day. This is because the block verification functions block for a while.


What does score tell me in getnetworkinfo?

It's about the network reliability to other nodes, score keeps increasing the longer your node is reachable.


How can I create a transaction that collects inputs from many addresses and sends them to one address in bitcoind?

When you have a bitcoin balance, that balance is actually unspent outputs from transactions your addresses have already received.

So when you want to send a raw transaction, what you include in that is the transactions and unspent outputs from those transactions... these can be from any address in your wallet.

The basic idea is;

createrawtransaction
signrawtransaction
sendrawtransaction

If you google around, you'll find plenty of examples of their use.


Wrong Electrum private keys when using BIP-84?

Electrum uses a modified WIF that encodes the address type:

Release notes

Source


child keys generated addresses reflect in wallet?

Use incremental indexes instead of random

First of all, you should generate child addressess incrementally instead of randomly, as wallets will re-generate them starting from the index 0, incrementing the indexes until they start finding empty addresses.

From the BIP44 Account Discovery chapter:

  When the master seed is imported from an external source the software should start to discover the accounts in the following manner:

  derive the first account's node (index = 0)
  derive the external chain node of this account
  scan addresses of the external chain; respect the gap limit described below
  if no transactions are found on the external chain, stop discovery
  if there are some transactions, increase the account index and go to step 1

  Address gap limit

  Address gap limit is currently set to 20. If the software hits 20 unused addresses in a row, it expects there are no used addresses beyond this point and stops searching the address chain. We scan just the external chains, because internal chains receive only coins that come from the associated external chains.
  Wallet software should warn when the user is trying to exceed the gap limit on an external chain by generating a new address.

If you generate your child keys at random indexes, most likely the first 20 indexes will be empty, so the wallet will stop the discovery and show you an empty wallet.

Standard derivation paths

The standard derivation path (defined in the aforementioned BIP44 standard) is the following (M denotes the master private key):

  m / purpose' / coin_type' / account' / change / address_index

Most wallet implementations (Electrum being a notable exception) follow this standard. That means for a given receiving address, you should use a derivation path like this:

m / 44' / 0' / 0' / 0 / 0

Which translates to bx commands like this:

cat m | bx hd-private --index 44 --hard \
       | bx hd-private --index 0 --hard \
       | bx hd-private --index 0 --hard \
       | bx hd-private --index 0 \
       | bx hd-private --index 0

Since the first three levels involve hardened derivation, you have to use the master private key. The master public key can only be used for non-hardened derivation paths.

Electrum doesn't implement the full BIP44 standard as it only supports single-account wallets. In Electrum, the derivation path looks like the following:

m / change / address_index

Since there is no hardened derivation on the account level, you can also import the master public key into Electrum. This is similar to the chain you described but there is an extra "change" level still.

Electrum can also import a BIP44 master private key (there's a checkbox in the import dialog), by making you select an account index at import time.

I suggest to stick to the BIP44 standard as it will be can be imported by other wallets (like Mycelium) as a HD-wallet, and will also work in Electrum if you remember to import it as a BIP44 key.

However, if you need to work exclusively with master public keys, you can still use the 2-level derivation and import them to Electrum. I'm not sure if other wallets support importing them.


How can I generate bitcoin cash addresses programmatically?

You can use the following library to generate bitcoin address using Swfit on IOS

https://github.com/onmyway133/AddressGenerator

Please note that the legacy bitcoin cash and bitcoin address is the same the only difference is the network.

if you're looking for cashAddr (qq address) format, take a look on these open source libraries:

https://github.com/bitcoincashjs/cashaddrjs (javascript)
https://cashaddr.bitcoincash.org/
https://github.com/schancel/cashaddr-converter

Original cashAddr algorithm (C++)

https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/src/cashaddr.cpp

it's pretty easy to read and understand, you can translate it to any language.


Raw SegWit TX look solid and verifies, but is rejected. Need help figuring out why

It's valid. In fact, pasting the transaction here actually shows a little checkmark next to the "signed" icon indicating a proper signature.

It is not valid. That website did not validate anything. It just checked whether there was something in the scriptWitness field, and if there was, it was marked as signed. That checkmark does not mean that it is valid.

Your signature is simply incorrect. There's no other way to put it. Running it through my Bitcoin Core node gives

64: non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation)

which is the typical invalid signature error.

Double check that you are creating the sighash correctly. Problems like this usually are the result of incorrectly serializing the transaction for signing.


The only miner that gets to decide which transactions go into a block is the one that is lucky enough to find the next block. So, yes, if your miner is successful in finding a block, then you get to decide which transactions are included.

If you are mining in a pool, your miner probably doesn't get to decide which transactions get included. The above only applies if you're solo mining.


Create genesis block. Some people get stuck there, it's really easy:

find LoadBlockIndex() function, inside, change:

paraphrase (pszTimestamp) to any recent news phase.
get the latest unix time (do a google), and put in block.nTime.
set any nNonce (doesn't really matter),
you can change the time/nonce for testnet too, if you want to use it.

After you are done, save it. Now the genesis block will not match the hash check and merkle root check, it doesn't matter.

The first time you run the compiled code (daemon or qt), it will say "assertion failed". Just exit the program, go to
config dir (under AppData/Roaming), open the debug.log, get the hash after "block.GetHash() = ", copy and paste it to the beginnig of main.cpp, hashGenesisBlock. Also get the merkle root in the same log file, paste it to the ... position in the following code, in LoadBlockIndex()

 assert(block.hashMerkleRoot == uint256("0x..."));

recompile the code, and genesis block created!

BTW, don't forget to change "txNew.vout[0].nValue = " to the coin per block you defined, it doesn't matter to leave as 50, just be consistent with your coin per block (do this before adjust the hash and m-root, otherwise they will be changed again).

check https://bitcointalk.org/index.php?topic=225690.0 for complete info


If you have found a new valid block at the network's chaintip, then you should submit that block to your network peers as soon as possible, so that they will hopefully add it to their local blockchain record. If other miners build upon your block, then it should become a part of the valid chain, and you will eventually be able to spend the coinbase UTXO in it (after it has matured 100 blocks).
As an example, if you are running bitcoin-core then you can use the submitblock command to submit your valid block to the network.


Remotely call getinfo from bitcoin server

I think your best bet is to run your own node, and then call getpeerinfo on it.  This will give you a list of all the connected peers, including information like the reported version.  You can also use the addnode option to ensure that you attempt to connect to all the nodes in your list.


The risk of sending money to a xpub generated address

That depends on the derivation path which was used for the xpub and derived address, to which the funds were sent to.

The xprv "owner" can scan "standard" derivation paths to determine whether these keys where used (funds were sent to these), by parsing the blockchain transaction history. If a standard BIP44 key derivation path schema was used, it can scan the following addresses by incrementing the index.

Let's say, the owner shared the xpub key M/44'/0'/0'/0. It can then search the following derivation paths for example to determine which one received funds.

M/44'/0'/0'/0/0
M/44'/0'/0'/0/1
M/44'/0'/0'/0/2
M/44'/0'/0'/0/3
...
If a significant number of consequent keys are unused, the wallet may decide to stop the scan.

If arbitrary derivation paths were used which are unknown to the "owner" instead of standard ones, the space to scan can be very large.


Where is the data folder for Bitcoin-Qt?

It is the same data folder as the non-QT version of the standard client used to use:

Linux:

~/.bitcoin/

MacOS:

~/Library/Application Support/Bitcoin/

Windows:

%APPDATA%\Bitcoin

(This defaults to C:\Documents and Settings\YourUserName\Application data\Bitcoin on Windows XP and to C:\Users\YourUserName\Appdata\Roaming\Bitcoin on Windows Vista, 7, 8, and 10.)


Simply put, a so-called hard fork is a change of the Bitcoin protocol that is not backwards-compatible; i.e., older client versions would not accept blocks created by the updated client, considering them invalid. Obviously, this can create a blockchain fork when nodes running the new version create a separate blockchain incompatible with the older software.

For potential future changes that would require a hard fork, see the associated wiki page.


How can pool operators reduce the number of orphaned blocks that they mine?

Lots of things really, most are fairly abusive if they're a large pool though, or at least undesirable in network terms.

Not including transactions in blocks. This is the obvious one, it's a lot easier to broadcast a single 25kB block than it is a bigger one. You do of course forfeit all the fees you would otherwise get, but some might see that as a tradeoff for an almost instantly reaching block.
Multiple exits for blocks. Something that many pools already do, having exists in the Tor side of the network, along with multiple high-bandwidth nodes apparently has an effect. Curating a list of high profile nodes like nogleg.com and those based on .edu domains would probably allow for the fastest block propagation. Remember that you need to have enough bandwidth to submit to every peer you are connected to simultaneously, if you fill your pipe then your block is seriously delayed and has a greater chance of being orphaned.
Building on orphan blocks. This is something I know at least one pool does, the concept is to build on your own orphans until they are at least 2 blocks buried. The chance of you getting a second block on top of the orphan is the same but the expectation of profit is double that of a normal block. The idea is essentially to orphan the block that orphaned you, and once the other chain gets higher than you by a sizeable amount this becomes a negative expectation and it's time to revert to the main chain yourself.

There's no secret sauce really, just a combination of many factors. Orphans are fairly rare now anyway.


What is the cheapest Bitcoin -> prepaid VISA/Mastercard service?

That's quite a lot of money to try to load onto a prepaid card and likely not something you'll find easily done.

Some options are:

http://www.okpay.com/en/services/debit-card/index.html
https://www.aurumxchange.com/cards Expect to get their cards program back soon.

With OKPay, you can reload using bitcoins, which OKPay will exchange into USDs for you (the cost of this was just reduced from 5% to 2.5% of transfered amount).
With AurumXChange, you can reload using USDs from Mt. Gox codes.

For that amount though you'll probably be best arranging trades with some buyers willing to exchange Moneypak to you.  For instance, on the #bitcoin-otc there often times are traders looking for BTC and for larger amounts will go out and buy a MoneyPak to do the trade.

You can load a number of different prepaid cards with MoneyPak, up to $1,000 each.  See the Prepaid Cards section for the list: https://www.moneypak.com/WhoAccepts.aspx

Along the same lines, you might find a trader that would deposit cash at Western Union to reload a Western Union prepaid card.


Why does blockchain.info show a different balance from bitcoin-qt?

Either one of the factors may affect either balance:

There is a double spend against one of your accounts
Some transaction might not have yet been included in a block and one program does not see it yet
There can be an error in one of the programs that skipped over some transactions. In case of the client, you should try rescanning the blockchain to make sure all data is properly extracted in case you suspect an error

You should make sure your client is fully synchronised and all your transactions have at least one confirmation.

You should generally trust the place where you issue your transactions from to have an accurate balance of your outgoing transactions, and blockchain.info for the information available everywhere else.


How to find a specific bitcoin address from all the addresses?

As Arturo and Aussie already said, directory.io shows all Bitcoin addresses sorted by private key. Also, the author explains his intent on directory.io/faq.

The first page has 11.302 Byte. Assuming they all are about the same size, 1TiB would just store 97,284,695 pages. Yet, there are 904625697166532776746648320380374280100293470930272690489102837043110636675 pages. That is approximately 9.05 × 1074, i.e. ~1066 TiB.

There is not enough memory to store them, and it is infeasible to search for one address in them in reasonable time.

Concluding, everyone's bitcoins are still safe. :)


Bitcoin peer to peer network source code

The source code for Bitcoin can be found at https://github.com/bitcoin/bitcoin. The P2P part is integrated within the core Bitcoin code, and is not available separately.


I used the wallet out of sync and cannot find my adress

Bitcoin Core doesn't check if it's in sync with the network or not. Try using rescan to make the client go through all the blocks in the blockchain and find the transactions affecting your wallet.


How was the blockchain's "hard fork" automatically resolved?

The highest blockchain containing only valid blocks is always the "correct" blockchain.

The first 225430-block was accepted by 0.8 clients/miners, but due to a flaw in 0.7 clients/miners couldn't accept the block.

The 0.7-fork was accepted by all client and miners, and the 0.8-fork was only accepted by 0.8 clients/miners. The core Bitcoin developers decided they wanted the 0.7-fork to be highest, however 0.8 had the most mining power, so the developers asked mining pools to switch back to the 0.7 client.

After some time, the 0.7 blockchain (which didn't have the "flawed" transaction) was highest, and 0.8 clients/miners would treat this as being the "real" blockchain (and stop mining on the blockchain with the transaction 0.7 clients didn't accept).

The 0.8 fork is simply treat as many orphaned blocks and is not worth anything (it can't be spend, etc).


Why are coin miners (such as GUIMiner) a "threat" in Windows Defender?

It is because of hackers that bundle the CPU miners in their viruses causing unaware AV makers to ban the miners that are being used. (including cgminer due to the fact it was cpuminer)

EDIT: According to nmat, there are also virus GPU miners.


Bitcoin Cash to CoPay Bitcoin Wallet - How to Recover?

how can he recover his payment?

He can't. Bitcoin Cash transactions are not reversible and generally cannot be cancelled.

  how can we recover his payment?

Create a Bitcoin Cash wallet using your Bitcoin private keys. Then refund him (less transactions fees, agreed handling fees etc)

Given that this involves putting your private keys into an unfamiliar piece of software, there are security issues (you need to be sure you trust it and obtained it from the right place and know how to use it properly etc) there may be significant man-time costs that some businesses may be reluctant to commit to help a small one-time customer.


Determining the genesis transaction value or genesis_tx

The genesis block's coinbase transaction hash will be the same as the blocks merkle root because the coinbase transaction should be the only transaction in the genesis block. You should be able to find it in chainparams.cpp if the codebase is still similar to bitcoin, like so:
https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L125

assert(genesis.hashMerkleRoot == uint256S("0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b"));


How does blockchain ensure that a closed loop in network is not formed?

Nodes have more than 8 connection slots, by default they have 125 maximum connections. There are 8 outbound connections, but can still have incoming connections from other nodes when all 8 outbound connection slots are full. So in your example, the new node can open a connection to any of the other nodes in the network because they all have available incoming connection slots.

Furthermore, because connections are classified as incoming or outgoing (but data is still bidirectional), at least 8 of the 9 nodes will have at least one more outgoing connection slot.

Also, your question has nothing to do with blockchains and is solely related to networking.


Bitcoin private keys are 32 bytes, but are often stored in their full OpenSSL-serialized form of 279 bytes. They are serialized as 51 base58 characters, or 64 hex characters.

Bitcoin public keys (traditionally) are 65 bytes (the first of which is 0x04). They are typically encoded as 130 hex characters.

Bitcoin compressed public keys (as of 0.6.0) are 33 bytes (the first of which is 0x02 or 0x03). They are typically encoded as 66 hex characters.

Bitcoin addresses are RIPEMD160(SHA256(pubkey)), 20 bytes. They are typically encoded as 34 base58 characters.


Have network DDoS attacks ever been successful on any coin?

This is more or less impossible, since you don't know where the miners are. Attacking the major mining pools is feasible, though they deploy some anti-DDoS measures. But even when such an attack would succeed, there still are people non-affected (eg. running behind NAT) and running the *coin network like if nothing happened.

The only issue that I can notice there is that the difficulty for getting a new block would be too high, so that the blocks would be mined much slower.


Controlling bitcoind connection bandwidth

If you're running two bitcoind instances on one machine, depending on the use case, you may instead be better off by connecting one to the other only, and not make it talk to the network. This will reduce the total bandwidth used significantly, as every block and transaction will only be fetched once.

Run the first one normally, and use -connect=127.0.0.1:18442 on the second.


How can the compressed UTXO set be stored in just 4GB?

The sizes you give don't match the paper. I can't even find mention of the sizes you give in the paper itself. Those sizes are incredibly wrong and way too large. They seem to be for input sizes, not output sizes. Input sizes are irrelevant to the UTXO set.

P2PKH are 21 bytes, P2SH are 21 bytes, P2PK are 33 bytes, everything else is their actual script size.

P2PKH = 1.147 GB
P2SH = 0.2393 GB

I've decided to omit the other outputs types because there are so few of them that their size is negligible.

The amounts are at most 0.5328 GB. However the amounts are compressed, so that should actually be smaller.

The outpoints (txids and output indexes) are at most 2.398 GB.

So in total the serialized UTXO set is approximately 4.3171 GB which is close to what we actually observe.

There are some more bytes due to the omitted scripts and because of the LevelDB's overhead, but there shouldn't be much (and certainly not several GB). Additionally the amounts and the output indexes are compressed which significantly reduces the serialized size. So in total, it's ~4 GB. My node reports 3.9 GB.


What is the best way to implement micropayments with Ripple?

Pre-signed transactions won't work the way you want due to how Ripple uses a simple sequence number. The only downside to doing small transactions via Ripple is the 0.000010 XRP transaction fee and the 2-20 seconds (or so) delay between signed ledgers.

Normally a merchant generates the payment information. E.g. "send 1 USD to account A, destination tag 123 (any 32 bit number), invoice ID 0x12345678 (256 bits of data)", often this would be with a Ripple URI (note that page doesn't document how or if an invoice id can be specified in a Ripple URI). The customer then selects the URI and is taken to the send page in their configured client (currently now always ripple.com/client) with all that information pre-filled in. The merchant then listens on their connection to a Ripple server (either local or remote) for information on payments to their account and uses the destination tag and/or invoice id to update payment status for individual customers or invoices. Normally merchants should handle the possibilities of one invoice being paid via multiple transactions and overpayments or the like as well.

You could have the customer provide the transaction hash(es) as you suggest, but that's not normally done and is usually more work for the customer for no reason.


What's the purpose of the WalletLocator field in Ripple accounts?

The original idea of the field was to keep a hash of the contents of your wallet that you could update in the Ripple ledger. Your wallet would also contain any prior hashes of earlier versions of the wallet that you couldn't confirm had already been replaced in the ledger.

That way, a malicious (or negligent) wallet provider couldn't serve you an old/obsolete version of your wallet. You just retrieve your WalletLocator from the network and if that isn't either the hash of your wallet or a prior hash stored in your wallet, you know you have a newer wallet out there somewhere. This would also catch the case where you store your wallet in more than one place and retrieve it from the "wrong" place.

Since the field was added, a different wallet model was used. But the field is still in the server and Ripple network in case anyone wants to use it.


Bitcoin library - how to check number of confirmations

"confirmed" in this case means the transaction is included in at least one block that belongs to the current best chain.

If you want to find out exactly how many confirmations each transaction has you can use fetch-history to get a full list of all transactions sent to and from your address. fetch-history will return the block number that the transaction has been included in. You can then use that along with the current height to figure out how many confirmations your transaction has.

bx fetch-history 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
bx fetch-height


What's the advantage of bitpay over coinbase for a merchant solution?

I would encourage you to look at the customer reviews of each service.  BitPay is definitely a stronger and more reliable platform, and is fully "on-blockchain" and compatible with all of the bitcoin wallets.  For a low-volume use case, like a few orders per day, probably either service will work.  For higher volumes, BitPay is more business-grade, with features like Quickbooks import.


Is a multi script possible that requires relative time locks relative to each signature?

Your question is a nice thought experiment.

Your example would not itself work: as CHECKSEQUENCEVERIFY is relative to the mining date or height, so in week 3, all three parties could sign at the same time.  On day 1 things work as you intend. On day 8 'X' can now sign at any point without delay but must wait a week for Y and two for Z. On day 15, 'X' and 'Y' can both sign at any point without delay but must wait a further week for Z. On day 22 all three of them can sign without delay, and it's no different to a regular multisig.

The direction of your thoughts seems to be that CHECKSEQUENCEVERIFY could be made relative to a previous signature. I'm not aware of any method of doing this within a single script: how can a computer tell that a signature has been made more than a week prior, other than by seeing it on the blockchain? The mempool would be wholly inappropriate a venue not least because people would be storing something for potentially long periods of time.

An improvement of sorts would be to have the multisig lock 10% of the funds for ten months, and each month, lock another 10%. At the start of the eleventh month, the three of them redeem to a new multisig, and so relock that original 10% for a new set of ten months. In this manner, all three of them are needed and 90% of the funds are locked for at least one month even if they're all present.


Why is not Bech32 address selected as default in Bitcoin Core 0.16.0?

Bech32 Addresses is still not supported on the other platforms. There are many libraries even considering bech32 address as "invalid."

If I'm using Bech32 address and asking someone who is using another platform to send me some bitcoin they may never be able to make the payment.

We need some time so it becomes supported everywhere.

Right now Blockchain.info, Electrum doesn't support bech32 address and they're highly used.


How to download Bitcoin block headers from Blockchain.info and save to file?

You can download the blockchain headers from here. The data is binary packed, but can be deserialized easily enough. You seem to be trying to solo mine, which is a bad idea at the best of times, let alone with JavaScript. You also seems to be trying to build a SPV client. An easier way would just be to use https://blockchain.info/latestblock to get the lastblock hash and use that.


Will all UTXOs eventually be worth 1 Satoshi?

Can two UTXOs ever be combined into one UTXO?

Yes, absolutely.  Each transaction can have any number of inputs and outputs; it can certainly have fewer outputs than inputs.

Here for example is a transaction with four inputs and one output, leading to a net decrease of three UTXOs.


Bitcoin MultiSig balance not showing under listaccounts

The documentation on addmultisigaddress states:

  This functionality is only intended for use with non-watchonly
  addresses. See importaddress for watchonly p2sh address support.

Since the wallet does not have both private keys, it won't show a balance unless you use importaddress. Note the ismine: false property in validateaddress, that means your wallet doesn't have ability to spend (doesn't have private keys).

addmultisigaddress nrequired ["key",...] ( "account" "address_type" )

Add a nrequired-to-sign multisignature address to the wallet. Requires
a new wallet backup. Each key is a Bitcoin address or hex-encoded
public key. This functionality is only intended for use with
non-watchonly addresses. See `importaddress` for watchonly p2sh
address support. If 'account' is specified (DEPRECATED), assign
address to that account.

To watch a multisig address (get it's balance), you should use importaddress:

importaddress "address" ( "label" rescan p2sh )

Adds a script (in hex) or address that can be watched as if it were in your wallet but cannot be used to spend. Requires a new wallet backup.

Arguments:
1. "script"           (string, required) The hex-encoded script (or address)
2. "label"            (string, optional, default="") An optional label
3. rescan               (boolean, optional, default=true) Rescan the wallet for transactions
4. p2sh                 (boolean, optional, default=false) Add the P2SH version of the script as well

Note: This call can take minutes to complete if rescan is true, during that time, other rpc calls may report that the imported address exists but related transactions are still missing, leading to temporarily incorrect/bogus balances and unspent outputs until rescan completes. If you have the full public key, you should call importpubkey instead of this.

Note: If you import a non-standard raw script in hex form, outputs sending to it will be treated as change, and not show up in many RPCs.

Examples:

Import a script with rescan
> bitcoin-cli importaddress "myscript"

Import using a label without rescan
> bitcoin-cli importaddress "myscript" "testing" false

As a JSON-RPC call
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "importaddress", "params": ["myscript", "testing", false] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/


What exactly is the relation between Bisq and Bitcoin Core?

As Bisq is not a full node wallet, it must connect to a full node in order to be able to receive transactions and learn when a transaction confirms. Without a local instance of Bitcoin Core, it will simply connect to a random node on the internet (there are some built in discovery methods for how it can find a node to connect to). If Bisq detects that you are running a node locally (i.e. you are running Bitcoin Core as well), it will instead connect to your local node and get its information from there.
Since Bisq relies on BIP 37 which Bitcoin Core has turned off by default since 0.19.0, you will need to enable this feature by adding peerbloomfilters=1 to your bitcoin.conf file. Otherwise Bisq will be unable to receive Bitcoin transactions. This is likely the syncing issues you are running into.
For some more information about local node settings in Bisq, you can read https://bisq.wiki/Connecting_to_your_own_Bitcoin_node.


Creating watch wallet from master public key at command line?

electrum -w wallet_path restore <mpk>

Above created watch wallet from master public key.


Transaction fees are calculated according to priority and transaction size.

Priority is a function of age and value of a single input in the wallet. The larger the value and the older the input age the higher the priority will be. Input value and input bytesize are static values. Input age is a variable that increases with time. So, in short, you can decrease your fees by allowing the coins to "age" (aka wait).

priority = (input_value * input_age)/input_bytesize

priority >57600000 is free (not accounting for transaction size)

Transaction size is going to incur fees anytime 5 or more inputs are included in an output. The only way to avoid incurring transaction size fees is to create outputs containing 4 or less inputs. I am not aware of any coin control extensions for the litecoin client so achieving this will likely prove very difficult for very small inputs.

The litecoin client is expected to receive a significant update sometime in May 2013 that may address some of the transaction fee concerns in the current client.


How does the Chinese Bitcoin ecosystem differ from the European/North American ones?

The Chinese are intense savers and frugal. Their interest in Bitcoin will involve relatively small price corrections.

    Do you want to say the will be resistent to price drops (in the bubbles for example)?

Yes. Bubbles will still happen, but the correction would be less severe because Chinese investors tend to buy-and-hold through the ups and downs. They save a little at a time and don't spend anything until the need to (and the price is high). Being frugal would mean that they'd buy bitcoins when the price goes down rather than panic sell on a momentum trade. Last evening was an excellent example. The bitcoin price should have had a major correction last night, but it was only a minor dip. China investment is increasingly moving the prices.

Chinese people have modest incomes but they save everything. They are limited by law to only having two homes, so you sometimes find children owning homes. They are modest homes, but often the land they sit on (like in Beijing) can be worth millions for new building construction. They invest in family, businesses, real estate, metals, and increasingly bitcoin. China is like America used to be when people were more interested in producing and achieving than consuming and taking.

Lawyers and regulations rule the US. There is no liberty because someone might get hurt. China has little of that. People are free there in many ways that the US is no longer. People are happy and enjoy life there. The bad side of China is well hidden, and is diminished through increasing prosperity.


What is the estimated USD fee price in BTC when Bitcoin is worth 1 million dollars in the future?

I think no one can read the future but some things can be said with high confidence and I will try to point them out.
First I think it the conversion to USD does at best make sense for cosmetics thus I will do most computations in the more natural form of satoshis and confirm only at the end if necessary.
if the average feerate in a block is x sat/Byte and with 1 MB blocks we will have a total fee of x Million satoshi per block. This is equivalent to x * 0.01 BTC.
Assuming 2500 tx per block we would end up having
x * 4,000 sats per transaction. (I guess with taproot, schnoor and signature aggregation we could stuff in a few more tx.)
as 1 sat / byte is the absolute minimum fee these 4,000 sats would at a 1 million usd / BTC boil down to $40 per transaction which would have to be multiplied by the feerate x which is any number larger or equal to 1.
I see it from the perspective of Lightning Network rather than from the perspective of making on chain payments. It seems like a reasonable fee to open your channels and be able to transact as often and frequently as you wish. As far as I know it is currently not clear how fees on the Lightning Network would evolve.


Finding wallet address on peer 2 peer network

An address is a human construct, and is meaningless to the p2p protocol - The p2p protocol is only concerned with Bitcoin Scripts.

If you have a raw tx object, you can attempt to find the address for an output by checking if the locking script (scriptPubKey) field matches the format for a known p2sh, p2pkh, p2wpkh, or p2pk address.

If it does, you can follow the respective base58 or bech32 encoding methods to convert it to an address. If it does not, then you have a non-standard output that does not correspond to an address.


Bitcoin Mining as a Newbie (link wallet to another person's miner)

What should I share with him

Nothing, because

  I'm trying to avoid being conned

See for example

I think ive being scammed

  I invested with a man who said he can mine me btc ... he then says I need to deposit another 950usd

How can I get a private key for this address

  I invested my bitcoins in someone's miner ...
   Now for the key he wants me to pay him $500

my money gone from wallet scam

  one trader miner told me that he would double the btc and do minning. i did the i gave access online to my wallet blockchain . later a big scam. my money disapper from wallet and a watch only adress linked created and the my entire btc transferred in to it

BTC Stolen from Blockchain

  A guy ... told me that I can mine for bitcoin ... Within half an hour my wallet was empty.

I've been asked to share wallet credentials to participate in mining. Is that a scam?

    I've been approached ... claiming that they would be able to increase my bitcoin by linking my wallet to their miner.


My question is about the possiblitiy of going overdrawn by mistake if account is hacked

You can never spend more coins than a wallet controls, there is no 'overdrawing an account' in bitcoin. You either control the keys that can spend some coins, or you don't.


You can't solo mine if you're not synched. In order to mine, you need to know what the longest chain is, and you can't do that until you're synched.


Is the target the source of the difficulty?

So basically, am I right in saying that the difficulty is calculated from the target, and not the other way around?

That is correct. Difficulty is just a concept introduced to make the target value easy to represent for humans.  It has no meaning internally.


What are the requirements of a transaction being included in a block?

From the Bitcoin wiki (as-of March 19, 2013):

  Transactions are cryptographically signed records that reassign
  ownership of Bitcoins to new addresses. Transactions have inputs -
  records which reference the funds from other previous transactions -
  and outputs - records which determine the new owner of the transferred
  Bitcoins, and which will be referenced as inputs in future
  transactions as those funds are respent.

  Each input must have a
  cryptographic digital signature that unlocks the funds from the prior
  transaction. Only the person possessing the appropriate private key is
  able to create a satisfactory signature; this in effect ensures that
  funds can only be spent by their owners.

  Each output determines which
  Bitcoin address (or other criteria, see Scripting) is the recipient of
  the funds.

  In a transaction, the sum of all inputs must be equal to or
  greater than the sum of all outputs. If the inputs exceed the outputs,
  the difference is considered a transaction fee, and is redeemable by
  whoever first includes the transaction into the block chain.

  A special
  kind of transaction, called a coinbase transaction, has no inputs. It
  is created by miners, and there is one coinbase transaction per block.
  Because each block comes with a reward of newly created Bitcoins (e.g.
  50 BTC for the first 210,000 blocks), the first transaction of a block
  is, with few exceptions, the transaction that grants those coins to
  their recipient (the miner). In addition to the newly created
  Bitcoins, the coinbase transaction is also used for assigning the
  recipient of any transaction fees that were paid within the other
  transactions being included in the same block. The coinbase
  transaction can assign the entire reward to a single Bitcoin address,
  or split it in portions among multiple addresses, just like any other
  transaction. Coinbase transactions always contain outputs totaling the
  sum of the block reward plus all transaction fees collected from the
  other transactions in the same block.

http://en.bitcoin.it/wiki/Protocol_specification#Transaction_Verification


starting alphad what is the correct rpcconnectport

Because in order to validate sidechain transfers, alphad needs to connect to a testnet bitcoind. The rpcconnect-like flags passed to it are information about how it can do that, so you need to use the running bitcoind's port.


Why blockcypher send transaction is throwing fatal error?

The problem was caused becasue BlockCypher-php-client-1.2.2 does not support uncompressed public keys.

Details: https://github.com/blockcypher/php-client/issues/5


Currently, all mining software have GPU and CPU mining disabled by default. You're going to need to recompile from source and enable CPU/GPU mining to be able to mine with your CPU/GPU. You should be warned that this is not profitable in any way, shape, or form and that even on testnet, your CPU won't likely find a block for many hours.

That said, if you're determined to do it, get the source for bfgminer here: https://github.com/luke-jr/bfgminer

Compile with the --enable-cpumining flag and you should have a binary that lets you use the CPU.


How can I run Bitcoind -server in "light mode"?

I don't think Simplified Payment Verification (SPV or "light mode") is available in the reference client. There are plans to implement it in the development going on in the discussion email list though.

However, you could download the source code for MultiBit and then use that as a starting point for your own daemon. Alternatively, just use the underlying BitcoinJ library which offers some example tools that probably do what you want right out of the box.


Which wallets have support for BIP 70 - 72 for merchant message transactions?

I've been searching for the same and found this article. Below I put the wallets that support Bitcoin URIs (BIP 21) and Payment Protocol (BIPs 70, 71, 72,73). For more info please check the link.

+-------------------------------+--------------+------------------+
|            Wallet             | Bitcoin URIs | Payment Protocol |
+-------------------------------+--------------+------------------+
| Bitcoin Core (Satoshi client) | V            | V                |
| BitPay Wallet                 | V            | V                |
| Breadwallet                   | V            | V                |
| Mycelium                      | V            | V                |
+-------------------------------+--------------+------------------+

And add Copay to the table, which also supports BIPs 70-73 and is not in the link. For your URI question check this answer.

That's all I can do for you. Hope it helps!


What happens to a person's bitcoins if they should happen to die prematurely?

Yes. Those bitcoins will never be used again unless someone creates a private key that hashes to the same public key.


Was the 51% attack a real threat in the early days of bitcoin existence?

Yes it was easier back then, that is why ASICs are a good thing and keep the network much safer. But no you don't need to worry about it, even a 51% attack can only do a limited number of things to the network, blocks and transactions must still be valid. So if a 51% attack had occurred, for example double spending a transaction, that is long in the past and would definitely not affect you now.


You could check by starting a geth console and using the personal.unlockAccount function:

$ geth console
> personal.unlockAccount("address", "password")


Would it be visible that someone moved bitcoins to or from tumblebit?

All confirmed transactions are publicly visible on the blockchain.

What's probably far more interesting for you is whether anyone can find out whether you put your money through Tumblebit.

What you really need to know is in this sentence of the paper you linked to:

  Specifically, while the blockchain reveals which payers and payees
  participated in an epoch, no one (not even the Tumbler τ) can tell
  which payer paid which payee during that specific epoch.

Tumblers are recognizable on the blockchain. If you pay someone via Tumblebit from an address which is publicly known to be yours, people will know that you paid someone via Tumblebit. They won't know who you paid but just know that you paid someone via Tumblebit might be enough to raise suspicion.

If you receive payment through Tumblebit, people can find out you received it through a tumbler. But they won't know who the "you" in the previous sentence is until you somehow reveal your identity. Until then, it's just that money went to someone. Who that someone is, isn't known to the public. But if your next transactions goes to an online shop with a order to ship a parcel to your home, you can be pretty sure the merchant knows that the address he received the payment from belongs to you.

The fact that people know that money went through tumblers simply emerges from the fact that tumblers want to get money from a lot of people involved. Look at transaction f653dc8cf567b6cf0cf98660a66a1b138677388c16c87b8f4d68f5979cd4627f. I just looked for one to show to you in the newest block and came across it. It moves money from 13 addresses to 13 different addresses. And not exactly little: The equivalent of 2.5 k$. Moving money from 13 addresses to 13 different addresses isn't exactly how a transaction of someone who just bought a computer for 2.5 k$ on tigerdirect.com would look like, is it?

If you look at how the input addresses got their funds, it gets even more suspicious. For example, 1HjfSKDVnKDsJBWWDWcgcmGDDhauc7cR8q got its funds from 19 addresses. It doesn't seem like this just happened by random chance, does it?

You might also want to take a look at this question and at this one.


This is highly implementation specific.

For common token platforms, namely Bitcoin and Ethereum, fees for transactions must be paid in Bitcoin and ether respectively.

Your contract or token mechanisms can impose a further fee in your token, or another token, but the platform itself requires the transaction cost to be paid by the native currency.

There are various proposals (1, 2), mainly for ethereum, that would allow tokens to be used to pay base transaction fees as well. However, these will require a hardfork, and are not currently usable.


How does Bitcoin "inventor" makes money?

Idealists might argue that Bitcoin was developed to forever change the financial landscape, and would be affronted at the suggestion that Satoshi was out for profit. Skeptics might call the whole thing the most elaborate Ponzi scheme ever envisioned. Realists might suggest that Satoshi, emotionally traumatized by the recent unceremonious departure of his former love interest, was ruminating after a few too many beers late one Saturday night and decided to write some code on a whim.

If he retained the bitcoins he mined early on, he could certainly make quite a bit by cashing them out for fiat. No one would disagree that Bitcoin has made at least a small dent in the current dominant financial system, though whether it will really change the landscape has yet to be seen. And a girlfriend is a small price to pay for what he created.

The truth is, we don't know who Satoshi is, why he created Bitcoin, why he left, or what he sought to gain from it. For all we know, he could be among us today in a different guise. But whatever goals he had, I would suspect we're well on the way to accomplishing them if we haven't done so already.


How in laymans terms do I restore a .dat BTC backed up wallet file on my mac please?

Close Bitcoin core so that the program is not running.
Go to /Users/{yourusername}/Library/Application Support/Bitcoin/ and there you will see much of the blockchain data, and a wallet.dat file.
If there is a wallet.dat file here that you also need, save it elsewhere by copying and pasting.
Put your backup.dat in this directory, and rename it to wallet.dat.
Start Bitcoin-QT with the -rescan option so that it will go and look for any coins that your received in the blockchain.

That's it!


How can I track transactions in a way that is not affected by their malleability?

Since none of the answers that were given were fully fleshed enough to properly answer my question, I'm posting my own answer which synthesizes everything that has been said:

The best way to track a transaction in a way that will be resistant to transaction malleability, is to actually track only the data that has been signed. To do so, I suggest using a double SHA256 of the signed data. The documentation of the OP_CHECKSIG script operation (and it's very useful diagram form hints at which procedure should be followed.

A transaction malleability invariant "Tracking Hash" can be obtained from a pay-to-pubkey-hash transaction by:

Verify the technical validity of the transaction, as is done the reference bitcoin client. This includes verifying the signatures of the transaction. This is a crucial step, if you don't do that, the tracking hash is useless.
double SHA-256 hashing all of the following things:

the version number
the number of inputs
for each input :

the transaction ID of the output to spend
the index of the output to spend
the sequence number
(Note: We intentionally do not hash the input script or the length of the input script)

the number of outputs
for each output:

the amount
the length of the output script
the whole output script

the lockTime

Doing this should give you a nice tracking hash, that will be the same for all equivalent transactions, no matter how it may have been modified by taking advantage of transaction malleability.

Note that this tracking hash is not part of the bitcoin protocol, so you will not find it in the blockchain, and you won't be able to look it up using blockchain.info.


Transaction Relay and trickling in Bitcoin

If a node has 100 connections to other nodes and receives a new transaction using a getData request, it sends an inv message to it's 100 connecting peers correct?

No. It depends on what nodes have sent an inv stating that they have that transaction. When an inv is received, the node will remember what has been inv'd to them by that node so that it does not attempt to send it something it already has. At most, there will be 99 inv messages sent. Since we already know that the peer that sent us the transaction already has it, we don't send them an inv. At minimum, there will be no inv messages sent because all nodes could have already sent us an inv for the same transaction.

  Does it also send the inv message to the peer that it just received the transaction from as it is still one of it's connecting peers?

As stated above, it does not. While there is no rule the explicitly prevents this, it is sensible to not send an inv to someone who has already sent an inv to you for the same thing. This saves bandwidth costs.

  I'm having a bit of difficulty understanding how trickling works in terms of transactions.

For each peer, the node keeps a list of transactions that it is going to inv to it. It sends inv's for transactions periodically with a random delay between each inv. Transactions are selected to go into the inv message somewhat randomly and according to some metrics involving fee rate. It selects a limited number of transactions to inv.

  I believed that the process was when a transaction occurs, the node responsible for the transaction would send INV messages to its peers and send the tx if the peers respond with getData.

The node the creates a transaction treats that transaction like any other it received over the network. For every peer that node is connected to, it adds that transaction to the list of transactions that it will send to that node eventually. Then everything else is as usual. At the next time it is to send an inv message for a particular peer, it chooses transactions to inv, and the transaction it created may or may not be one of those. Once the inv is sent, the other node will respond with a getdata for the things it wants, which may or may not include the transaction it created. Then your node responds to the getdata with the transactions themselves.


how to find the block height from merkle root?

The block hash is the output obtained when hashing the header of a bitcoin block. The header of a bitcoin block is comprised of several pieces of data, one of which is the merkle root.
So having the merkle root alone is not sufficient to calculate the block hash, you would need additional information (the rest of the block header).
You could write some code to query the block database for a specific merkle root, but otherwise I am not aware of any software that currently includes this functionality.
(this seems odd to me though: if you have calculated the merkle root, you assumedly have all the transaction data from the block in question. I'm not sure in what situation you would have all of this data, but not the rest of the block header data)


How to calculate variable length fields?

it's a lot easier, just omit the "fd". Here is the explanation from the bitcoin developers webpages.

Assuming you have the value in an array (tx_array) and a pointer into the array (tx_array_ptr), here is an (unixoide shell script) code example:

# var_int is defined as:
# value         size Format
# < 0xfd        1    uint8_t
# <= 0xffff     3    0xfd + uint16_t
# <= 0xffffffff 5    0xfe + uint32_t
# -             9    0xff + uint64_t
# if value <= 0xfd, Bytes  = 1
# if value =  0xfd, Bytes  = 2
# if value =  0xfe, Bytes  = 4
# if value =  0xff, Bytes  = 8
  var_int=${tx_array[$tx_array_ptr]}
  if [ "$var_int" == "FD" ] ; then
    tx_array_ptr=$(( $tx_array_ptr + 1 ))
    tx_array_bytes=2
    var_int=$( get_TX_section )
  elif [ "$var_int" == "FE" ] ; then
    tx_array_ptr=$(( $tx_array_ptr + 1 ))
    tx_array_bytes=4
    var_int=$( get_TX_section )
  elif [ "$var_int" == "FF" ] ; then
    tx_array_ptr=$(( $tx_array_ptr + 1 ))
    tx_array_bytes=8
  else
    var_int=${tx_array[$tx_array_ptr]}
  fi

When you have your var_int, don't forget reversing the hex values (big endian conversion)! Then you can send the value e.g. to your decimal converter, so for your value (fd5d01) you get:

omit the "fd"
take the next two bytes "5d01"
big endian conversion "015d"
convert to decimal:

use of "bc" to convert value to decimal:

$ echo "ibase=16;015D" | bc
349


I have a casascius coin -- how can I sell it?

You have two routes here:
Sell the physical Bitcoin
Don't remove the sticker on the back. Use a website like localbitcoins to sell it to someone near you.
Some people might want a physical Bitcoin, especially since they're not being made anymore.
Sell the Bitcoin 'contained' within the physical coin.
Peel off the sticker on the back. Inside will be a code that lets you spend the Bitcoin. (I recommend using Blockchain.info as your e-wallet.) You can sell the Bitcoin online or locally.
The remaining brass part is mostly worthless.


Could speculation some day rise bitcoin to the moon?

Because there is no guarantee that bitcoin will be in demand in the future.  Here's an example, in a recent Gawker article they put "(RIP)" when naming Bitcoin .. as if it had died. http://www.gizmodo.com.au/2011/09/is-digital-money-the-new-way-to-buy-drugs

Of course, the existing $35 million or so valuation of the currency come from those speculating that the value of the currency will at some point in the future buy more than it will today.

Whether or not this will be a stratospheric rise nobody knows but it isn't unprecedented, just not typical nor expected by most.  But there are those, such as Rick Falvinge, who believe it.  Rick describes his thoughts here:

http://falkvinge.net/2011/06/16/bitcoins-four-drivers-part-one-unlawful-trade
http://falkvinge.net/2011/06/18/bitcoins-four-drivers-part-two-international-trade
http://falkvinge.net/2011/07/03/bitcoins-four-drivers-part-3-merchant-trade
http://falkvinge.net/2011/07/05/bitcoins-four-drivers-part-4-investment


What will happen when all bitcoins are issued?

As far as the stopping of mining, no. Even when all 21 million bitcoins have been created there will still be transaction fees which will be given as rewards to miners. It has yet to be seen if this will lead to a reduction in miners or an increase in transaction fees, or both.


Ripple paper wallaet from Rippley (https://ripply.eu/) code check / safe?

Try http://www.ripplepaperwallet.com that should be safe.  If you can disconnect it from the internet and still generate an address in your browser while offline, then yes it is safe.


How to change Nxt/Ardor wallet settings to keep the account ledger table untrimmed?

To generate a full ledger for a specific account set the following nxt.properties:

# Do not trim the ledger
nxt.ledgerTrimKeep=0

# Only log these specific accounts
nxt.ledgerAccounts=NXT-V4D7-D3XW-JX9Z-EAC8K;NXT-XK4R-7VJU-6EQG-7R335

To rebuild the ledger, invoke the scan API with parameter height set to 0.
This operation can run for several hours depending on your configuration.


I can help to answer about how wallet submits transactions to the network. Bitcoin wallet clients solve this problem with several methods. Several reliable peers are registered in DNS under the name bitseed.xf2.org. By doing a nslookup, a client gets the IP addresses of these peers, and hopefully one of them will work. If that doesn't work, a seed list of peers is hardcoded into the client.

The hardcoded peer list in the Bitcoin client is in chainparams.cpp in the array vSeeds.


Can I Recover Bitcoins Transferred to a “Sending” Address?

Bitcoin payments are irreversible

  Any transaction issued with Bitcoin cannot be reversed, they can only
  be refunded by the person receiving the funds. That means you should
  take care to do business with people and organizations you know and
  trust, or who have an established reputation. For their part,
  businesses need to keep control of the payment requests they are
  displaying to their customers. Bitcoin can detect typos and usually
  won't let you send money to an invalid address by mistake. Additional
  services might exist in the future to provide more choice and
  protection for the consumer.

No, they might not be lost. Addresses can both be used both for sending and receiving transactions. You have sent them to one of your own addresses. In your case you transferred to another address you own. So your wallet will have a new total minus the transaction cost. So technically, you could refund yourself again but you will loose another transaction cost.

Crucial note:
All of this depends on your wallet. Some online wallet services share addresses between different users, so you want to be careful if you are using one of those.

If you are using the standard client, all your addresses are fully under your control and are safe to receive transactions.

Source


Which cryptocurrencies are considered base coins?

In the context of defining basecoins as those that change directly with USD, there are actually quite a few. The 4 you've listed are available through Coinbase, which is currently the most popular fiat to cryptocurrency gateway.

However, there are many exchanges that still accept USD/EUR/JPY/KRW deposits with some level of verification. For example Bitfinex allows for fiat deposits after verifying your account, and they have 20 or so crypto assets (including EOS, XRP, NEO that you mentioned). I'm sure there are many more exchanges that allow fiat deposits, even if crypto deposits are growing increasingly popular for legal reasons.


Something similar to blocknotify but for new transaction

Have a look at the Bitcoin Core ZMQ possibilities. Using blocknotify (or walletnotify) seems very inefficient (the fork a new process each time).

ZMQ does allow to have a IPC push channel from Bitcoin-Core to your client application (from there you could emulate a websocket or something that talks to your web-clients).

https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md

ZMQ is fast and relatively reliable, although has currently no wallet features (you can't get notification on wallet events, only on "global" events [new tx, new block]).


You could use https://localbitcoins.com/ it's a bitcoin escrow service, YMMV, read up up how it works here.
They list Harare as a place where you can trade with locals.
May be good for small amounts.

That or if you can open an bank account in Europe, USA, Australia etc (You can often do that from a large bank in your home country), wire the money to that account, then use one of the larger exchanges; like most other people do. However, that could be rather expensive with international wire & exchange fees etc. Better for larger amounts.


Where can I buy bitcoins from Ireland without photo ID?

I've been using Intersango's service lately, and am happy with it. You can deposit by SEPA bank transfer, no ID required.


I am new to bitcoin, and GUI miner won't work on slush's server

Your hashpower is magnitudes too low. It is so low, that the pool doesn't accept your work, because it will never amount to any use. You are competing with a teaspoon in a world of Bucket-wheel excavators. You will be expending energy and never gain any revenue. Please check out In the ASIC-age, is it worth starting mining Bitcoin at home? for a more comprehensive overview of the mining situation.

Shares are simpler portions of work at a lower difficulty than blocks. They are used by mining pools to gauge the contribution of miners. You apparently found a single share, but it was found after the pool had started working on a new block. When your guiminer told the pool about it, it was already outdated.


I lost my uncle few Weeks ago due to the covid 19 and I have his wallet

I have my uncle wallet

The only important thing in a wallet is the private key(s). Usually the wallet's contents are protected by a password. Without the password, no one can get the private key out from the wallet.

The actual money is better thought of as being in the public blockchain. Money is not really inside the wallet.

  and I don’t have his private key

Then you don't have any control over his money.

You must find the private-key or a seed-phrase (recovery phrase) - usually consisting of 12 or 24 words from a special list. The private-key can be recreated from the recovery phrase. Prudent people put this information somewhere safe. Some people stamp the recovery phrase onto a fire-resistant  metal sheet and lock that away somewhere.

  can anyone help

You will get lots of offers from dishonest people trying to steal the money or, to trick you out of money in "unlocking fees" or other fictions. Don't trust new people who communicate in private. Never give anyone else anything that looks like a private-key or recovery-phrase.

But no, you really need to find the key or recovery phrase. Nothing else.


Withdraw from a BTC wallet Ucoincash 24hours is still pending?

Do you have a copy of transaction (tx) ID or the address of the wallet that you sent it to? If so, go to https://blockchain.info/ and copy/paste one of those pieces of information into the search box in the top right-hand corner of the blockchain.info webpage and hit 'ENTER'. If the transaction went through okay it will show up on the blockchain.

Over the past few weeks there has been in increase in bitcoin transactions and the transfer times have slowed down. I also had a transfer that took over 24 hours. It isn't common, but does occur during peak times.

The bottom line is that as long as you got the right wallet address for the transfer the bitcoin will be on the blockchain (i.e. you won't have lost it).


Trying to mine bitcoin on home PCs will generate you absolutely no income, to mine bitcoin you need a lot of hashpower which home PCs just don't have. So that isn't a viable way to generate revenue. But also, secretly mining bitcoin on peoples computers while they run your software is probably quite dishonest, if you tried such a thing you would need to ensure you let them know it was going to happen. And antivirus software would probably quarantine your file as a bitcoin mining trojan.


Does Bitcoin limit the number of parallel connections from the same IP?

The measure is that the node running bitcoin removes the cap to the number connection slots.  The cap for connection slots I have found is set to no limit when running a bitcoin service.

Sorry I stand corrected, back in 2011 looks like a cap of 125 connections was introduced Is there a connections limit on bitcoind?

in the net.cpp file  https://bitcointalk.org/index.php?topic=52772.msg629593#msg629593

but this has since been changed and I dont think there is a cap anymore... Looking at the file looks like this is the area you are interested in: https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L1081
and the values set here https://github.com/bitcoin/bitcoin/blob/master/src/net.h


Exactly how does one calculate how many BTC they will get a certain hashrate?

The answer of D.H. assumes the hashrate of the network never changes between difficulty jumps. But it can in fact evolve quite a bit, so it can be inaccurate sometimes. Your proportion in the network may change but, until the difficulty adjusts, this will not change your rewards.

Your average reward will be :

So, in your case, with 600 MH/s and a time period of 1 day, the result is, in average, 0.3394412542813765 BTC a day (with current difficulty).

Explanations: the first term is the average reward per difficulty-1 share, and a difficulty-1 share is found in average every 2^32 hashes.

Now, if you're going to be pooled mining, adjust the 50 in the formula to take fees into account (use 48.5 for example for a 3% fee). Same goes when blocks start generating 25 BTC only.


Is it possible to combine multi-sig and locktime?

only one of the keys is time-locked

Keys aren't time-locked. Transactions are. However, Bitcoin now has an opcode for this purpose: OP_CHECKLOCKTIMEVERIFY.

Essentially, it forces the transaction to have a lock time further in the future than its argument, otherwise the transaction is invalid.

In your case, the script would look like this:

OP_IF <this pubkey can spend at any time> OP_CHECKSIG OP_ELSE <block number> OP_CHECKLOCKTIMEVERIFY OP_DROP <this pubkey must wait until block number> OP_CHECKSIG OP_ENDIF

The spend-anytime key can redeem the transaction with

<Sig> 1 <above script>

The other key can redeem with

<Sig> 0 <above script>

but only after the given block number.


Undo a transaction to a wrong adress

Bitcoin transactions cannot be undone.

I made a transaction to a wrong adress.

That is usually hard to do because standard addresses have checksums.
If you sent it to a genuine address given to you by someone other than the intended recipient, you'll need to contact the person who gave you that address and see if they are willing to create a new transaction sending money to you.
If you somehow entered an address that no-one gave you, then there will almost certainly be no-one who owns that address. There are an incredibly vast number of valid addresses and almost none of them will ever be owned.

How can I find where the transaction reciever has an exchange adress?

Not all addresses in use are related to exchanges. Many addresses that are in use will have been generated by standalone wallets on phones or personal computers. As I wrote above, almost all valid addresses are not owned by anyone and never will be.
There are businesses that analyse the blockchain to try to associate used addresses with exchanges but they may be very expensive to employ. Even if you did identify an exchange, the exchange has no reason to violate their customer's privacy. At best they might pass on a request to their customer for that customer to consider your request that the customer send money back to you. But even that might take an enormous amount of persuasion.


This could happen for two reasons:

1 - You did not included tx fee in your transactions so the priority of your tx is lower than the ones which paid for transactions network fees. You can check this simply using your TX ID on a block explorer like www.blockchain.info. You will see which is the priority for your transaction and the status of it in real time.

2 - The other reason could be that, as Murch suggested, the network has been over stressed for some reasons and this takes some txs to take more time to get confirmed. However this happens rarely and you should always check the first option before.