text:
How do I get the scriptPubKey type from the raw output script?
I use zeroMQ to get the transactions from Bitcoin Core.
The output looks like this:
{ value: 200000,
  script: <Buffer 00 20 e3 30 7e 8e 0b 63 0e 53 c2 f1 f8 17 06 7b ce 01 c4 38 92 83 3e 02 2d ad f5 e9 5f 31 be 89 b1 22>
}

The same output looks like this in Bitcoin Core:
{
      "value": 0.00200000,
      "n": 0,
      "scriptPubKey": {
        "asm": "0 e3307e8e0b630e53c2f1f817067bce01c43892833e022dadf5e95f31be89b122",
        "hex": "0020e3307e8e0b630e53c2f1f817067bce01c43892833e022dadf5e95f31be89b122",
        "reqSigs": 1,
        "type": "witness_v0_scripthash",
        "addresses": [
          "tb1quvc8arstvv898sh3lqtsv77wq8zr3y5r8cpzmt04a90nr05fky3qemqr3j"
        ]
      }
    }

Question: How do I get the scriptPubKey type from the script buffer ?

Internally, Bitcoin does not have the concept of scriptPubKey type. To the system, scriptPubKey is simply a mathematical equation into which some bitcoins have been locked (UTXO) and the spender must satisfy the unlocking conditions, which most of the times are the signature(s) and public key(s), in order to spend those bitcoins. These basic construct can be used to build higher level concepts like the scriptPubKey type that you are referring in your question.
Since Bitcoin is a programmable money, a user can lock their bitcoins in a number of different ways. The Bitcoin community has accepted certain output types as standard locking scripts. Below are some of the standard output scripts (scriptPubKey) that can be used to determine the script address type (main net address types have been used):

Pay to Public Key Hash (P2PKH): In this type of script, the bitcoins are locked in the hash of a public key. The output script will look like the following:
{
  "value": 0.00200000,
  "n": 0,
  "scriptPubKey": {
    "asm": "OP_DUP OP_HASH160 243f1394f44554f4ce3fd68649c19adc483ce924 OP_EQUALVERIFY OP_CHECKSIG"
    "hex": "76a914243f1394f44554f4ce3fd68649c19adc483ce92488ac",
    "reqSigs": 1,
    "type": "pubkeyhash",
    "addresses": [
      "14JetYAhLevTRaePcAAX1vRMwaJt2QGRzp"
    ]
  }
}

Pay to Script Hash (P2SH): In this type of script, the bitcoins are locked in the hash of script. The script can be a multi-sig output, time-locked output, P2SH-P2WPKH (SegWit address in P2SH format) and others. The output script looks like the following:
{
  "value": 0.00200000,
  "n": 0,
  "scriptPubKey": {
    "asm": "OP_HASH160 243f1394f44554f4ce3fd68649c19adc483ce924 OP_EQUAL"
    "hex": "a914243f1394f44554f4ce3fd68649c19adc483ce92487",
    "reqSigs": 1,
    "type": "scripthash",
    "addresses": [
      "34zfp5f8tZEqWkLpjFq7SYnJ66bbdaTmt"
    ]
  }
}

Pay to Witness Public Key Hash (P2WPKH): In this script, the bitcoins are locked in the hash of the public key, but follows SegWit. The leading 00 indicate that it is SegWit version 0. The output script looks like the following:
{
  "value": 0.00200000,
  "n": 0,
  "scriptPubKey": {
    "asm": "0 eb308eb99tb8ff3797d2e5cfb33a9231700d6195"
    "hex": "0014eb308eb99tb8ff3797d2e5cfb33a9231700d6195",
    "reqSigs": 1,
    "type": "witness_v0_keyhash",
    "addresses": [
      "bc1qavcgawvmerln097juh8mxw5jx9cq6cv46xmzxk"
    ]
  }
}

Pay to Witness Script Hash (P2WSH): In this script, the bitcoins are locked in the hash of a script, but follows SegWit. Similar to P2SH, the redeemScript can be a multi-sig output, time-locked output, etc. The leading 00 byte indicate that it is SegWit version 0. Below is how the locking script looks like (your example in the question):
{
  "value": 0.00200000,
  "n": 0,
  "scriptPubKey": {
    "asm": "0 e3307e8e0b630e53c2f1f817067bce01c43892833e022dadf5e95f31be89b122"
    "hex": "0020e3307e8e0b630e53c2f1f817067bce01c43892833e022dadf5e95f31be89b122",
    "reqSigs": 1,
    "type": "witness_v0_scripthash",
    "addresses": [
      "bc1quvc8arstvv898sh3lqtsv77wq8zr3y5r8cpzmt04a90nr05fky3qwnkvta"
    ]
  }
}

Pay to Public Key (P2PK): This type of output script pays the public key directly. Note: Although currently Bitcoin Core shows an address starting with 1 for P2PK, it is an error that will be rectified in the next release of Bitcoin-Core. Below is how the output script looks like:
{
  "value": 0.00200000,
  "n": 0,
  "scriptPubKey": {
    "asm": "02d2a6892c51741f83759088d9eed12c2c52eea9b999ecc36af1cb569b733b6ff1 OP_CHECKSIG"
    "hex": "2102d2a6892c51741f83759088d9eed12c2c52eea9b999ecc36af1cb569b733b6ff1ac",
    "reqSigs": 1,
    "type": "pubkey",
    "addresses": [
      "1FK1FmLuTY19JGdb9SsKHs68HxRD69jtc1"
    ]
  }
}

As I said earlier, bitcoins can be locked in any allowed operator operations. However, if the output script does not belong to the above five types, the output script will be non-standard and you will see the type as "nonstandard" in the scriptPubKey field.

So, If I understand well, in your first example:
76 -> OP_DUP
a9 -> OP_HASH160
14 data to be pushed onto the stack ( 0x14 = 20 bytes = 40 chars)
-> 243f1394f44554f4ce3fd68649c19adc483ce924
88 -> OP_EQUALVERIFY
ac -> OP_CHECKSIG
from this pattern we can conclude the scriptPubKey type is pubkeyhash ?

@jfjobidon Yep, absolutely correct.

Are you sure of #5 P2PK? A compressed pubkey must be 33 bytes, and that one is, so surely the opcode to push it should be 21 not 20.

@dave_thompson_085 you are right my friend. Thanks for pointing it out.

May you provide P2TR script pub key please ?

You need to parse the script and get to the script type by examining the opcodes.
If you examine the rpc/rawtransaction.cpp source file on Bitcoin Core you'll see the RPC call that outputs this is getrawtransaction(). Tracing it further it leads us to ScriptPubKeyToUniv in core_write.cpp which calls so let's take a look at that:
const char* GetTxnOutputType(txnouttype t)
{
    switch (t)
    {
    case TX_NONSTANDARD: return "nonstandard";
    case TX_PUBKEY: return "pubkey";
    case TX_PUBKEYHASH: return "pubkeyhash";
    case TX_SCRIPTHASH: return "scripthash";
    case TX_MULTISIG: return "multisig";
    case TX_NULL_DATA: return "nulldata";
    case TX_WITNESS_V0_KEYHASH: return "witness_v0_keyhash";
    case TX_WITNESS_V0_SCRIPTHASH: return "witness_v0_scripthash";
    case TX_WITNESS_UNKNOWN: return "witness_unknown";
    }
    return nullptr;
}

This subroutine maps script types to the string name which you asked about. In your case you got a TX_WITNESS_V0_SCRIPTHASH whose value is 0x06 per its definition in script/standard.h :
enum txnouttype
{
    TX_NONSTANDARD,
    // 'standard' transaction types:
    TX_PUBKEY,
    TX_PUBKEYHASH,
    TX_SCRIPTHASH,
    TX_MULTISIG,
    TX_NULL_DATA, //!< unspendable OP_RETURN script that carries data
    TX_WITNESS_V0_SCRIPTHASH,
    TX_WITNESS_V0_KEYHASH,
    TX_WITNESS_UNKNOWN, //!< Only for Witness versions not already defined above
};

We now know how to extract the scriptPubKey type name from the value, but we don't know how to extract that value from the raw bytes, so let's take a look at that next.
txnouttype is extracted from scriptPubkey by ExtractDestinations which is defined in script/standard.cpp, the relevant line being typeRet = Solver(scriptPubKey, vSolutions);. So let's step into Solver.
Here's the answer to your question:
txnouttype Solver(const CScript& scriptPubKey, std::vector<std::vector<unsigned char>>& vSolutionsRet)
{
    vSolutionsRet.clear();

    // Shortcut for pay-to-script-hash, which are more constrained than the other types:
    // it is always OP_HASH160 20 [20 byte hash] OP_EQUAL
    if (scriptPubKey.IsPayToScriptHash())
    {
        std::vector<unsigned char> hashBytes(scriptPubKey.begin()+2, scriptPubKey.begin()+22);
        vSolutionsRet.push_back(hashBytes);
        return TX_SCRIPTHASH;
    }

    int witnessversion;
    std::vector<unsigned char> witnessprogram;
    if (scriptPubKey.IsWitnessProgram(witnessversion, witnessprogram)) {
        if (witnessversion == 0 && witnessprogram.size() == WITNESS_V0_KEYHASH_SIZE) {
            vSolutionsRet.push_back(witnessprogram);
            return TX_WITNESS_V0_KEYHASH;
        }
        if (witnessversion == 0 && witnessprogram.size() == WITNESS_V0_SCRIPTHASH_SIZE) {
            vSolutionsRet.push_back(witnessprogram);
            return TX_WITNESS_V0_SCRIPTHASH;
        }
        if (witnessversion != 0) {
            vSolutionsRet.push_back(std::vector<unsigned char>{(unsigned char)witnessversion});
            vSolutionsRet.push_back(std::move(witnessprogram));
            return TX_WITNESS_UNKNOWN;
        }
        return TX_NONSTANDARD;
    }

    // Provably prunable, data-carrying output
    //
    // So long as script passes the IsUnspendable() test and all but the first
    // byte passes the IsPushOnly() test we don't care what exactly is in the
    // script.
    if (scriptPubKey.size() >= 1 && scriptPubKey[0] == OP_RETURN && scriptPubKey.IsPushOnly(scriptPubKey.begin()+1)) {
        return TX_NULL_DATA;
    }

    std::vector<unsigned char> data;
    if (MatchPayToPubkey(scriptPubKey, data)) {
        vSolutionsRet.push_back(std::move(data));
        return TX_PUBKEY;
    }

    if (MatchPayToPubkeyHash(scriptPubKey, data)) {
        vSolutionsRet.push_back(std::move(data));
        return TX_PUBKEYHASH;
    }

    unsigned int required;
    std::vector<std::vector<unsigned char>> keys;
    if (MatchMultisig(scriptPubKey, required, keys)) {
        vSolutionsRet.push_back({static_cast<unsigned char>(required)}); // safe as required is in range 1..16
        vSolutionsRet.insert(vSolutionsRet.end(), keys.begin(), keys.end());
        vSolutionsRet.push_back({static_cast<unsigned char>(keys.size())}); // safe as size is in range 1..16
        return TX_MULTISIG;
    }

    vSolutionsRet.clear();
    return TX_NONSTANDARD;
}

It returns the txnouttype and here's how it determines each one:
TX_SCRIPTHASH
this->size() == 23 &&
            (*this)[0] == OP_HASH160 &&
            (*this)[1] == 0x14 &&
            (*this)[22] == OP_EQUAL

If the script size is 23 bytes, the first script byte is OP_HASH160, second byte is 0x14 and byte 22 is OP_EQUAL then it's a TX_SCRIPTHASH.
Witness Program
The following tests if the script is a witness program:
this->size() == 34 &&
            (*this)[0] == OP_0 &&
            (*this)[1] == 0x20

So, if the script is 34 bytes long, the first OP is 0 and the second byte is 0x20 then it's a witness program (This is the case in your question.).
If it's a witness program, then there are 4 possible script types:
First Witness Script type: TX_WITNESS_V0_KEYHASH
if (witnessversion == 0 && witnessprogram.size() == WITNESS_V0_KEYHASH_SIZE) {
            vSolutionsRet.push_back(witnessprogram);
            return TX_WITNESS_V0_KEYHASH;
        }

If witness version is zero and the witness program is WITNESS_V0_KEYHASH_SIZE (20 bytes) long then it's a TX_WITNESS_V0_KEYHASH.
Second Witness Script type: TX_WITNESS_V0_SCRIPTHASH
If witness version is zer and the witness program is WITNESS_V0_SCRIPTHASH_SIZE (32 bytes) long then it's a TX_WITNESS_V0_SCRIPTHASH. This is the case in your question.
Note: We now know the specific answer to your question : you know if it's a witness_v0_scripthash if the script is 34 bytes long, begins with 00 20 and then there are 32 bytes following it.
Let's proceed for completeness.
Third Witness Script type: TX_WITNESS_UNKNOWN
If the witness version is different from zero, it's unknown.
Fourth and last Witness script type is TX_NONSTANDARD, which means it's not recognized by Bitcon Core.
Now onto the other script types.
TX_NULL_DATA
If the scriptPubKey size is more than one byte long and the first OP is a RETURN, then everything that follows is NULL data.
TX_PUBKEY
If the script is CPubKey::PUBLIC_KEY_SIZE (65) bytes long and the first byte on the script is 65 (CPubKey::PUBLIC_KEY_SIZE) and if the last OP on the script is OP_CHECKSIG then it's a legacy TX_PUBKEY script.
TX_PUBKEYHASH
If the script is 25 bytes long (this length is harcoded in script/standard.cpp), the first operation is OP_DUP, the second operation is OP_HASH160 and script[23] is OP_EQUALVERIFY and script[24] is OP_CHECKSIG then it's the most common type of script of all: TX_PUBKEYHASH.
TX_MULTISIG
Multisig is solved by MatchMultisig in script/standard.cpp. What it does is parse the script looping through it and calling GetOp (script/script.h) to parse the sig out and CPubKey::ValidSize(data) which checks if each signature is the right size. If at the end of this check we are at the end of the script, verified by (it + 1 == script.end()), then it's a valid multisig script.
TX_NONSTANDARD
Lastly if none of the above rules match, then it's a nonstandard script containing undefined contents. Most nodes would probably reject this script but miners and pools are able to insert stuff here if they want to.
These are all the script types in Bitcoin. The rules  presented for each one is how you get the type out of scriptPubKey. To turn it into a string you use the enum map in GetTxnOutputType.


text:
How to reduce Bitcoin loaded wallet memory?
The server has 2GB of RAM memory. It takes up a lot of memory when I create or load a wallet. When I create about 50 wallets, the server is very slow because the memory is full. Is there a way to reduce the memory of a loaded wallet?

There is no way to reduce the amount of memory used by a loaded wallet other than modifying the code itself. There are no configuration options for this. You really should not be trying to run so many wallets on a low powered machine.

There is different way to optimize, configure or reduce the memory usage of bitcoind, I invite you to see this page from the bitcoind github who talk about it: https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-memory.md

source: Stack Exchange

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

sort: votes


text:
Implement HTLC manually by writing scripts
Is there any way to implement HTLC manually for locking funds in the channels in lightning network for a period of time (by setting intervals) and releasing the funds after the time lock expired using bitcoin regtest mode?

Yes...
... But it is going to be a lot of work.
First you should look at BIP 199 which defines htlc scripts. However that alone will only tell you how to create a htlc output.
But with the transaction itself it is not done. You need to use the right channel state and keys so you could read BOLT 02, 03 and 05 to learn about the peer protocol and messages you need to exchange with your channel partner (for such you will actually also need  BOLT 08 and 01 covering setting up a transport session and the message format), the key derivation and the exact onchain specs for htlc output and witeness  scripts. You will find all the BOLTs at https://github.com/lightningnetwork/lightning-rfc?files=1
All of this can be done in regtest. If you want to use a regular lightning implementation you can also run them in regtest mode by changing the corresponding entry in the config file.

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


text:
How to track bitcoin transaction on PC
I am still quite new to Bitcoin, and my question may be a little bit stupid. So I am wondering how can I track the transaction or the newest block on my computer. I know there are tons of websites showing the real-time information, so I guess my question is like is there any way I can type something on my terminal of the PC and shows the data on it? Something like constructed the dataset on my own.

how can I track the transaction or the newest block on my computer.

You can run a full-node Bitcoin client such as Bitcoin core. It will collect the full blockchain - it can take a long time (weeks) to download the full blockchain, but you should be able to examine early blocks and transactions without waiting.
In the case of Bitcoin Core, you can use the API to examine blocks (GetBlock etc) and transactions (GetTransaction etc).

is there any way I can type something on my terminal of the PC and shows the data on it?

For example
./bitcoin-cli getblockcount

./bitcoin-cli -testnet getblockhash 240886

./bitcoin-cli getblock 00000000000000000d2347b601158f40c741dbd9353918903f057cedd82f49de 2


text:
How to combine separately signed inputs from different users?
With two separate signed raw transactions from two users, how would one go about 'batching' these manually (combining the inputs and outputs into a single transaction)?
Is this a viable solution for groups of users attempting to save on fees, or would the extended length of the resulting transaction negate any real savings?

With two separate signed raw transactions from two users, how would one go about 'batching' these manually (combining the inputs and outputs into a single transaction)?

If you are trying to combine two independently signed transactions together it would include a number of constraints on how the amount can be spent and how the transaction is structured. This is because when we sign transaction, we include the serialized transaction as the message (until we have SIGHASH_NOINPUT). The constraints are the following:

The version and nLocktime of both transactions would have to be same.
The individual transaction inputs would need to be signed with ANYONECANPAY|SINGLE SIGHASH flag. The ANYONECANPAY allows adding additional inputs to the transaction. However, if you sign with ANYONECANPAY|NONE, the signer is at a risk of his output being excluded from the transaction as he has not committed to any outputs. Signing with ANYONECANPAY|ALL binds all the outputs and hence no other outputs can be added. All of this means, the signer can only send money to a single address/script and hence cannot include a change output to send remaining money.

The #2 point is true if the signer does not trust any centralized entity in batching the transaction. A signer can however, sign with ANYONECANPAY|NONE flag and assume that when the centralized entity broadcasts the transaction they will sign the transaction with ALL flag in order to bind all the outputs to the transaction.

Is this a viable solution for groups of users attempting to save on fees, or would the extended length of the resulting transaction negate any real savings?

Transaction fees are based on the weight of the transaction. Signatures, outpoints of tx referenced, and locking script occupy the vast majority of that which cannot be done away with batching transactions signed independently. You will only be saving transaction costs on things that are common like 4 byte transaction version, 4 byte nLocktime, 2 bytes for number of tx inputs/outputs.
Batching is generally done to mask who pays to whom (eg. coinjoin) not to save fees. But even in that case the batching server gives the senders a final serialized transaction containing all the inputs and the outputs that all of them sign with sighash_all flag. Each input is not signed independently.


text:
Do HTLCs get "carried over" in the subsequent commitment transactions?
With regular commitment transactions, current transaction invalidates the previous one. This is fine, since TXs between A and B in their channel happen one after another. However, HTLCs are sort of delayed transactions. How then further transactions can happen without waiting for the secret R? Does it mean that the HTLC contracts get simply "carried over" in the subsequent transactions between A and B?

How then further transactions can happen without waiting for the secret R? Does it mean that the HTLC contracts get simply "carried over" in the subsequent transactions between A and B?

Yes, that is correct. You go on adding HLTC outputs in the commitment transactions as more and more HTLCs are added, and delete those HTLCs that are either fullfiled with a successful pre-image or those that are failed. Every time, you add/delete an HTLC, a new commitment transaction has to be signed and the previous commitment transactions have to be revoked.
For that reason, lightning network specification puts a limit of 483 HTLCs for a commitment transaction, so that even if both sides send the maximum number of HTLCs, the commitment_signed message will still be under the maximum message size.

Well said! Just for completeness. The htlcs themselves are "carried over" via update_add_htlc messages defined in BOLT 02 and revoked via revoke_and_ack message.

Where is the "maximum message size" defined and what happens if it is increased? Would it simply result in a heavier P2P protocol? -- Let me answer my own question: 65535 bytes, rationale.


text:
Transaction fee of 8.44 mBTC for 1.22 mBTC?
I made a transaction of 1.22242 mBTC with the electrum client and, I don't know why, it looks like it transferred all the remaining BTC from my account to myself which made a 13063 bytes transaction and costs me 8.43769 mBTC...
Do you know what happened?
https://www.blockchain.com/btc/tx/24c9a54cd4686ef4e0f51298d3fb3862c03ba126fc78cbe382c9094397913314

Your account has received a large number of very small payments. That's going to make for some very high transaction costs as you have to gather all those tiny payments together. If all those tiny payments are coming from the same place, see if you can get them to make a smaller number of larger payments to save you money.

Thanks for the tip, most of the transactions came a long time ago from "faucets", websites that give away a tiny amount of bitcoin for free.

@dki yeah those are mostly scams because you can't really spend that money without paying disproportionately large amounts in fees.

This is a process known as consolidation - If your wallet has several small inputs, many wallets will often try to combine them into a single change input during regular transactions, especially ones made with a low sat/byte feerate. This allows you to spend the coins in a smaller transaction during possibly high traffic times, when the feerate may be much higher.
These days, many wallets only perform such consolidation if there are many outputs to a single address, as combining outputs from multiple addresses unnecessarily can lead to a loss of privacy. Unfortunately for you, it seems like in your case all the outputs do belong to a single address.
In the case of electrum, this doesn't appear to be a configurable option, although you could notice it is happening prior to submitting the transaction by using the "Preview" option - if you notice that the total fee or size or number of inputs consumed it too large, you can force electrum to build a transaction using only specific inputs by selecting them in your transaction history, then right clicking and selecting the spend from option.

The problem is the transaction fee doesn't depend on the values of inputs, but the number of inputs.


text:
How does Bitcoin protect against inflation?
In an economy where the prices of goods keep inflating, like a car going from $10,000 to $20,000 in 1 year, what would be the incentive for people to put their money in Bitcoin? Wouldn't the price of a bitcoin stay the same or decrease because people need their fiat money even more?

Inflation is increase in price without increase in utility. A car with similar features helps you get from point A to point B just like it did one year ago (same utility). However, the cost of the car increased by 2x one year later (higher price) indicating that the currency in which the price has been quoted has been reduced to 0.5x versus its value last year.
In an economy, we have economic output and wealth generation that happens over the course of years. This is represented by increased technological progress that brings in new jobs and as a result improves consumption of goods in the economy. In traditional economics, government tends to stimulate this growth by printing money and spending it on projects like infrastructure, research etc. However, most of the times the increase in economic output trails the value of currency that has been printed. This means slightly higher economic output is now being represented by much higher money in circulation, which results in devaluation of the currency.
In Bitcoin, the supply is capped at 21M. As Bitcoin gets used in almost all of our day-to-activities, it will indirectly represent the global economic output. As technological progress increases outputs, the same number of bitcoins will represent a higher economic output every year. Thus value of a bitcoin tomorrow is worth more than what it is worth today. On a relative basis this means Bitcoin appreciates in value with respect to other fiat currencies.

Interesting - Bitcoin's limited availability actually bakes in a deflationary price trend. It seems the jury is still out on whether that will cause problems or not.

@NuclearWang Inflationary currencies under government control suffer from the moral hazard of easy debt issuance that can later be erased through debasement at the expense of savers. Deflation is not bad, as it would prevent the high and low swings that we view in the economy today and allow a secular increase in economic output. I would highly recommend reading Austrian economics.

@NuclearWang I think Bitcoin's deflationary nature will cause the biggest problems for Wall Street. Their entire pretense is "protecting your wealth" which will not be needed when Bitcoin goes mainstream. Many of the Wall Street funds take their capital from pension funds who invest in market to preserve the worth of the portfolio. I wrote about this several months back on Medium, which you can access here (https://medium.com/@ugamkamat/bitcoin-the-ultimate-wall-street-annihilator-469e5ec4ca19)


text:
Merkle Root for Block 100000: calculation in Excel
I am stuck doing the calculations for the  infamous block 100000. I am doing those in excel. I am trying to add as much detail here of the operation I am doing and intermediate results.
TX1: 8c14f0db3df150123e6f3dbbf30f8b955a8249b62ac1d1ff16284aefa3d06d87
TX2: fff2525b8931402dd09222c50775608f75787bd2b87e56995a7bdd30f79702c4
TX3: 6359f0868171b1d194cbee1af2f16ea598ae8fad666d9b012c8ed2b79a236ec4
TX4: e9a66845e05d5abc0ad04ec80f774a7e585c6e8db975962d069a522137b80c1d

I byte swap those txids to little endian (text functions):
TX1: 876dd0a3ef4a2816ffd1c12ab649825a958b0ff3bb3d6f3e1250f13ddbf0148c
TX2: c40297f730dd7b5a99567eb8d27b78758f607507c52292d02d4031895b52f2ff
TX3: c46e239ab7d28e2c019b6d66ad8fae98a56ef1f21aeecb94d1b1718186f05963
TX4: 1d0cb83721529a062d9675b98d6e5c587e4a770fc84ed00abc5a5de04568a6e9

I concatenate the little endian of the first two transactions: (text functions)
tx1 + tx2 = 876dd0a3ef4a2816ffd1c12ab649825a958b0ff3bb3d6f3e1250f13ddbf0148cc40297f730dd7b5a99567eb8d27b78758f607507c52292d02d4031895b52f2ff

I convert this 128 character hex string into a 512 binary string: (I concatenate a series of HEX2BIN(MID(concatenated,starting chars,2),8).
10000111011011011101000010100011111011110100101000101000000101101111111111010001110000010010101010110110010010011000001001011010100101011000101100001111111100111011101100111101011011110011111000010010010100001111000100111101110110111111000000010100100011001100010000000010100101111111011100110000110111010111101101011010100110010101011001111110101110001101001001111011011110000111010110001111011000000111010100000111110001010010001010010010110100000010110101000000001100011000100101011011010100101111001011111111

I do a sha256 of the above binary using fresle sha function (referenced here on SE). The result is:
c9aee68969373b4aecc87382fb2aa28276c6b9a9bfb6956615b4b29eb14d51d2

I convert this 64 hex string into a 256 binary string: (I concatenate a series of HEX2BIN(MID(concatenated,starting chars,2),8)
1100100110101110111001101000100101101001001101110011101101001010111011001100100001110011100000101111101100101010101000101000001001110110110001101011100110101001101111111011011010010101011001100001010110110100101100101001111010110001010011010101000111010010

I do a sha256 of the above binary using fresle sha function (referenced here on SE)
branch1= f2d117d431bf81ee1a18c12d8c6b2bb05fe0d63b86ca5f2d43b30781fdbd6583

I bet that you already spotted the error by now.
To complete I do all the above steps for the second two transactions (tx3 & tx4).
The result of the second sha round is:
branch2= 910dc8ac1c1373c0a22c74f4ba04fb0e0f45232e292227015400ca549ceec4ef

Now I redo all the above steps for branch1 + branch2, giving me:
eb834a22120b5195270085f999afed5c7f79351e0a8ac9f2d5b355495700cddb

I convert back to big endian:
dbcd00574955b3d5f2c98a0a1e35797f5cedaf99f985002795510b12224a83eb

This should be the merkle root, but it's not. What am I doing wrong?
Here the excel I used:
https://drive.google.com/file/d/1Qdy_PpUj4ZWLGBXCsSSBmQgTMhQITLVz
If I check my sha(hex) with anyahsh.com i get different result, while if i check sha(binary) i get the exact same result. The strange thing I double checked the hex=>bin conversion and it is correct, so I don't understand what's going wrong.

The SHA256 function that you are using in the excel sheet is hashing the binary as a text rather than using the bits from it. This results in the output of your excel function being different from the desired one. Below is a simple python script that will illustrate it to you.
import hashlib
string1 = '876dd0a3ef4a2816ffd1c12ab649825a958b0ff3bb3d6f3e1250f13ddbf0148cc40297f730dd7b5a99567eb8d27b78758f607507c52292d02d4031895b52f2ff'
string2 = '10000111011011011101000010100011111011110100101000101000000101101111111111010001110000010010101010110110010010011000001001011010100101011000101100001111111100111011101100111101011011110011111000010010010100001111000100111101110110111111000000010100100011001100010000000010100101111111011100110000110111010111101101011010100110010101011001111110101110001101001001111011011110000111010110001111011000000111010100000111110001010010001010010010110100000010110101000000001100011000100101011011010100101111001011111111'

hashlib.sha256(bytes.fromhex(string1)).hexdigest()
>>> 'cd93fc352d3b9f27392b3052c61190609fdc80194ade62771ce9588808980be9'

hashlib.sha256(string2.encode('utf-8')).hexdigest()
>>> 'c9aee68969373b4aecc87382fb2aa28276c6b9a9bfb6956615b4b29eb14d51d2'

The first output is the actual one you should get from the first round of hashing. The second output is the one that you are getting from the excel function. That is because you are hashing that binary in the same way as hashing a string like 'hello world'.

Are you familiar enough with Excel to suggest how shall I fix that?

That question is better asked on Stackoverflow.

I would ask this question on the thread where i found this function (this one) , but i lack the reputation needed to comment (rather than posting a "fake answer". Can you point me in the right direction to do that without pissing off mods or other useers?

No luck so far.

@Zippo76 can you link the post where you found this function? Also you can accept this post if you found it helpful so others know that it effectively answered the question

I used this link as a primary source of code/informations: https://stackoverflow.com/questions/22672564/porting-sha-256-library-to-excel


text:
Bitcoin was sent out and still hasn't been received
I sent bitcoin out to a segwit address (P2SH) and it split the transactions in 2 but I still haven't seen them delivered in into the wallet

How long ago did you send the Bitcoin? What exactly is the "it" in " it split the transactions in 2"?

Possible duplicate of https://bitcoin.stackexchange.com/q/736/5406


text:
How does Internal Keychain exactly work?
I understand that an internal keychain is used to receive a change of payment when I pay someone.
For example, I pay $20, but it costs $17, so I get $3.
But what I don't understand is how can there be a change? When I send 1 BTC to someone, how does the receiving end determine that I overpaid by 0.9 BTC and send that back to me?

Bitcoin does not have the concept of account balance. It works on consuming the bitcoins that you have earnt in prior transactions. However, you cannot consume partial amounts. So according to your example, when you are creating a new transaction, in the inputs you will reference the transaction where you earnt the 1 BTC (it may be a single transaction where you got your 1 BTC, or you might reference multiple transactions whose values all add up to 1 BTC) and consume it entirely. Now in the outputs, you will send 0.1 BTC to address A and say 0.895 BTC to your change address. The difference of 0.005 BTC will go as mining fees.

so every time I'm sending a bitcoin, I'm sending my entire balance and receiving balance - payment - mining fee back to my change address? What if I don't have a whole bitcoin? What if I only have 0.001 BTC?

@CarolWard you have to reference multiple transactions in the inputs where you earned your BTCs and the values from those transaction should that add up to an amount that is more that want to intend to pay to a person. the difference (after removing mining fees) is what would go to your change address.

ok. I think I'm starting to understand. So when I send 0.001 BTC, the wallet references enough transactions together that equals 0.001 BTC or greater. If it's exactly 0.001 BTC, then no change needed. If it's 0.0017 BTC, then it pays 0.001 BTC to the recipient, pays mining fee (let's say 0.0003 BTC), and send the change of 0.0004 back to my change address. Is that right?

@CarolWard that is correct


text:
What is the Big-O for LN bandwidth? Can anyone answer this or provide a link to a spec that is sufficient enough for us to calculate it?
When I worked at Google, if someone wanted to deploy a network application they would need to provide a document to the SREs detailing the behaviour of the application at scale in terms of Big-O. Does something like this exist for LN?
I understand that we would have to make some assumptions about the network topology, that's fine. What I really need to know is simply what are all the network functions and when do they fire.

This is an excellent question but still probably a little bit under specified. Let me try to give an answer and elaborate.
When looking at network bandwidth there are several componants playing into it.
The most obvious (and probably most dominant) one is specified in BOLT 07 routing-gossip. There are 4 messages which are used to provide the information about the gossip protocol to every node.

The announcement_signatures Message
The channel_announcement Message
The node_announcement Message
The channel_update Message

While the first one is only sent between two peers to decide if a channel stays private or not the second and third needs to be delivered to every node. The way how gossip achieves this is by forwarding the message to each peer if it was received and novel to the node. The amortized / expected network bandwidth for those messages should thus be O(E/V*(E+V)) where E/V ist the average node degree. And E the number of edges and V the number of nodes. In the worst case (unrealistic) of a fully connected graph we have E=V*V and thus O(V^3 + V^2) = O(V^3)
The situation is even worse for the 4th message. Everytime the routing fees are adjusted by a node this message needs to be delivered to every other node and creates O(E/V*(E)) messages. While the 3rd and 4th message will only be propagated when received first. The update message can be send every second and will be propagated Everytime. This the network bandwidth req can be arbitrary (? Still bound by the second) large even for small networks. This is obviously also a ddos attack vector. There is the million channel challenge by rusty to stimulate this behavior.
Other less dominant components are messages that are only exchanged between peers to maintain the channel state. While connecting, handshakes etc seem neglictable there is the case of routing. Let us in a first step assume that every routing process is successful the bandwidth will then grow as O(b*t) with t being the number of transactions or payments being done by the network and b being the betweeness centrality of the node on the fee graph which according to this video is likelihood of that node being on a cheapest path. This would have to be corrected by the likelihoid of routing failures. For the overall network it could be the product of number of transactions times average Pathlenght times average number of routing attempts.
There is also the network bandwidth coming from the Bitcoin node but that should not change with the growth of lightning.
I hope I didn't miss anything. Stuff changes drastically with AMP routing since every payment is split into several small payments.

Wow, that's actually a great answer. This is the best O() analysis of LN that I've seen. Thanks! One thing I'm confused about though is that channel balances also change the network topology. Shouldn't balances also be updated at some point? If not, the number of failed tx might even create more extra traffic than the updates... Am I misunderstanding something?

Only the capacity of channels is announced and publuc. The channel balance is a private datapoint between the channel partners. This is the reason why path finding (trying routes) is difficult. The exact topology is unknown. I am happy you liked my answer. I think great questions deserve extensive answers (which is why I was happy to do it on a mobile device!) I hope my calculations / assumptions are correct though. Btw goggle tried 3 times to recruite me as a PM and everytime they suggested software engineering after the recruiting process ;)


text:
Will cryptocurrencies that have a finite supply (like 21m btc) cause deflation?
I figured out that cryptocurrencies can cause a deflationary spiral, since the cap is the same (eg. 21m BTC) but the economy is growing. That would only happen if all coins are mined.
But deflation would usually lead to a recession. Is there a way to prevent that?
I've done some research, like on the Bitcoin Wiki page deflationary spiral, but I don't seem to understand why deflation won't happen.

The ‘deflationary spiral’ is a real condition that affects the popular fractional reserve backing system. Bitcoin is not affected by this because it is fundamentally different from popular currency.

Yes, cryptocurrencies that have finite supply are bound to create deflation. This is because the same finite supply of coins will represent an increased economic output that results from technological innovations. Thus the value of a coin is worth more tomorrow than today thereby increasing its purchasing power. However, if this deflation is bad is highly debated in the economic circles and there seems to be no concrete consensus on it.
The critic about deflation being linked to deflationary spiral stems from the great depression of 1929. The deflation in the economy post the great depression increased the real value of debt thereby compounding the problems of economic recovery. Moreover, because of deflation people hoarded money rather than spending it exacerbating the effects of recession. If you look at deflation from this lens then it could be deemed as hurtful as it prevents actions that could potentially stimulate the economy.
However, this can also be viewed from a different angle. We have seen the effects of deflation only in times when our economy was in trouble and there was a complete collapse of demand. Deflationary characteristics of Bitcoin is not based on collapse of demand, but a very predictable supply.
You will also see that a lot depends on the type of money used in the economy. Fiat money is based on debt: government issues bonds and the central banks buy these bonds by printing money. However, Bitcoin has properties that makes it resilient to credit expansionary forces thereby delinking it from public debt. Thus comparing the deflationary aspects of fiat money to the deflationary aspects of Bitcoin is like comparing apples to oranges.
Some people point out that deflationary nature of Bitcoin will lead to hoarding practices and hence lead to fall off in demand. I think it's a fallacy, since purchases related to houses, food, cars etc. will continue to happen. They help you make investments that could produce a higher return than the appreciation in the value of Bitcoin over the same period. For example, using a car helps you get to your office faster and be more productive, there by increasing your year-end bonus. I believe, only investments in assets that people currently invest to protect them from inflation (second home, gold, arts etc.) will reduce. Demand related to consumable/depreciable goods will continue to remain steady.
I'll sign off with a food for thought. The price of electronics gets cheaper every year, still you do not postpone the purchase of your electronic gadget in anticipation of price reduction as it helps you achieve other important goals whose return is higher than the price decrease over the same period. This can be extrapolated to the spending characteristics in hyperbitcoinized world.

Deflation is an ongoing increase in the price of currency relative to some representative basket of goods and services.  An ongoing increase in price can be caused only by an ongoing fall in supply or an ongoing rise in demand.  An ongoing increase in output could plausibly, but would not necessarily, cause an ongoing increase in demand for currency.

@WillO the question primarily focuses on the potential economic implications if everything were priced in Bitcoin. Considering Bitcoin's limited supply, any growth in economic productivity would result in an increased value of Bitcoin relative to a basket of goods and services. In this case, the deflation observed isn't due to a reduced demand for goods as typically seen, but rather because everything is denominated in Bitcoin, which has a finite supply

If the supply of currency is fixed, then deflation can be caused only by an ongoing increase in demand for that currency.  2)  If we were talking about dollars or euros, the usual argument is that increasing economic activity leads to more transactions, which leads to increased demand for currency with which to carry out those transactions.  3)  However in the case of Bitcoin, the market for transactions in equilibrated by the transaction fee, which has no analogue in the markets for dollars and euros.  (CONTINUED)

(CONTINUED) 4)  So it is not clear to me that an increase in economic activity has to increase the demand for Bitcoin.  Maybe there is a good argument to that effect, but it can't be the same argument that applies to currencies without transaction fees.

The question isn't whether demand will fall generally with bitcoin. The question is, what will happen in a recession with bitcoin as the only currency? I believe if bitcoin is the only currency, most recessions will result in depressions, because there is no mechanism to get people to spend. People will hoard because of fear, and that will exacerbate the recession, causing a depression.

Can recessions be "with bitcoin as the only currency"?


text:
How to determine the geographic distribution of the hashrate?
I would like to map the hashrate distribution geographically, which would require knowing the IP address of the winning miner for each block.
According to the paper by Miller et al
several aggregator websites, including blockchain.info, maintain low-latency connections to thousands of nodes and record the IP address of the first connected node to relay each block. Is this information provided somewhere? While blockchain.info provides a hashrate distribution, it is aggregated at the pool level while I would like to know more about how the hashrate is distributed among the pools' servers.

While blockchain.info provides a hashrate distribution, it is aggregated at the pool level while I would like to know more about how the hashrate is distributed among the pools' servers.

That is not possible to ascertain with certainty. When a Bitcoin block is mined, there is no way to determine which node/pool mined it. Block explorer sites like blockchain.info look at the coinbase data in coinbase transaction to possibly link the block to a particular pool. For example, if you look at the last mined block 594,041 the coinbase transaction has the coinbase data as:
037910091a4d696e656420627920416e74506f6f6c39331400332020d34beafabe6d6d38d664d05278d5312fc43b4a47d259012d94db2c113f41e0ee36a6711161138004000000000000006cbf008036030000

The first byte 0x03 indicates to push the next three bytes on to the stack. Then bytes 0x791009 indicate the block height (594041 in this case) in little-endian. Then if you look at the bytes 0x4d696e656420627920416e74506f6f6c it represents "'Mined by AntPool" in ASCII. This is what the explorers use to say that the block was actually mined by Ant Pool. Nothing prevents me from mining a block tomorrow with the coinbase data that points to a particular pool when in reality it has nothing to do with them. The block explorer sites will use this false data to show on their websites that the block was actually mined by that pool name that I sneaked in.

Several aggregator websites, including blockchain.info, maintain low-latency connections to a thousands of nodes and record the IP address of the first connected node to relay each block

This data is also unreliable. I can run VPN, mine a block and relay it to the network with an IP address located thousand of kilometers away from my actual location. Moreover, you can run Bitcoin full node on tor which would completely obfuscate your identity.

Thank you @Ugam Kamat. That was very helpful.


text:
Lightning Network conf listen & externalip values
I downloaded LN repo. I have this settings in my lnd.conf file:
listen=192.168.100.134
externalip=186.4.235.84

I am following some tutorials online that do not include this settings (like this one) . Can someone explain the role of this variables please? I am not a network expert and I like to understand the code I write.

Listen: This specifies the interfaces to listen to for incoming connections to your node. This will allow other nodes to establish inbound connections to your lnd node. If you want to listen to all ipv4 connections on port 9735, you can use listen = 0.0.0.0:9735
External IP: Adding an external IP advertises your node to the network. If you'd like to signal to other nodes on the network that you'll accept incoming channels (as peers need to connect inbound to initiate a channel funding workflow), then the externalip flag should be set to your publicly reachable IP address.


text:
Why do two different fully synced Bitcoin Core nodes differ in the blockchain size?
The size_on_disk printed when executing getblockchaininfo is 1.2 GB smaller than other nodes are reporting at the same time/block.
txindex=1
What could it be??
I've asked to other peers on twitter to check if anyone else experiencing the same and everyone has more data in their ledger than me. (https://twitter.com/bitdov/status/1231915231368163328)
Here's all the info printed with getblockchaininfo on my node:
{
  "chain": "main",
  "blocks": 618824,
  "headers": 618824,
  "bestblockhash": "0000000000000000000a1fb0ec42e380215bb58698a1321d2953ee5d1b7b                                                                                685d",
  "difficulty": 15546745765529.37,
  "mediantime": 1582569829,
  "verificationprogress": 0.9999950821417113,
  "initialblockdownload": false,
  "chainwork": "00000000000000000000000000000000000000000cfea65b1b3c9262e87778b8                                                                                ",
  "size_on_disk": 299006763199,
  "pruned": false,
  "softforks": {
    "bip34": {
      "type": "buried",
      "active": true,
      "height": 227931
    },
    "bip66": {
      "type": "buried",
      "active": true,
      "height": 363725
    },
    "bip65": {
      "type": "buried",
      "active": true,
      "height": 388381
    },
    "csv": {
      "type": "buried",
      "active": true,
      "height": 419328
    },
    "segwit": {
      "type": "buried",
      "active": true,
      "height": 481824
    }
  },
  "warnings": ""
}

Running Satoshi 0.19.0.1
protocolversion 70015

The difference in size is due to the number of stale blocks that your node stores. Stale blocks are blocks that once formed the part of the main chain but is not belong to the main chain now.
For example, if say two blocks are mined at height 102 at the same time. When the miner relays the block through the gossip network, the network that is closer to miner 1 will receive its block (102a) first as compared to block mined by miner 2 (102b). Bitcoin core adds the first received valid block to the tip of the chain. The blocks received at the same height after that are not deleted but kept in the database just in case a reorganization happens. So, if the next block 103 is mined on top of block 102b then the node that received 102a first will reorganize its chain to one that contains 102b as shown below.
101 -->102a
    \
     \
       102b --> 103 -->104

Bitcoin Core does not delete any valid block that it receives from its peers. It is stored in your database forever in the file blocks/blk****.dat (which is also same for blocks in the main chain). However, the software does not relay stale blocks. In order to receive stale blocks, you need to be online at the time when your peer broadcasted a block to you from different chain view. Peers will only broadcast those blocks that they view form the current active chain from their perspective. So you will only have the stale blocks that you received when you were online. This also mean you will need to be connected to peers that view one the tip of the chain that is different from other peers. Due to this variability, many nodes will have different view of the sizes of the Bitcoin blockchain

Thanks for the detailed explanation. To sum up, it would be correct to assume that the longer I'm online, the closest I'm to miners, and the better my connectivity with other peers - the more stale blocks I will be storing and the higher my size_on_disk will be?

@bitdov yes, that would be a correct way to think of it. More your connectivity the higher the stale blocks you will receive.

The size of the blockchain on disk can vary depending on how many stale blocks your node has seen. Stale blocks are not part of the main chain, but they are still stored on disk by your node. A new node will have fewer stale blocks than an old, long running, node. Well connected nodes are more likely to see stale blocks than less well connected nodes. So it is possible that your node simply has not seen as many stale blocks as other people's nodes.

Thanks, that makes sense, since my node is probably a very peripheral one and also this specific instance has only been running for around 3 months


text:
Pass Multiple addresses in redeem p2sh script
I have the following code
const script = this.app.env.bitcoin.script.compile([
hashOpcode,
Buffer.from(secretHash, "hex"),
this.app.env.bitcoin.opcodes.OP_EQUALVERIFY,

 Buffer.from(recipientPublicKey, "hex"),
 this.app.env.bitcoin.opcodes.OP_EQUAL,
 this.app.env.bitcoin.opcodes.OP_IF,

 Buffer.from(recipientPublicKey, "hex"),
 this.app.env.bitcoin.opcodes.OP_CHECKSIG
])

But i want to pass one more address. Like this:
Buffer.from(recipientPublicKey, "hex"),
this.app.env.bitcoin.opcodes.OP_EQUAL,
this.app.env.bitcoin.opcodes.OP_AND,
Buffer.from(exchangePublicKey, "hex"),
this.app.env.bitcoin.opcodes.OP_EQUAL,
this.app.env.bitcoin.opcodes.OP_IF,

Buffer.from(recipientPublicKey, "hex"),
this.app.env.bitcoin.opcodes.OP_CHECKMULTISIG,
this.app.env.bitcoin.opcodes.OP_AND,
Buffer.from(exchangePublicKey, "hex"),
this.app.env.bitcoin.opcodes.OP_CHECKMULTISIG,
this.app.env.bitcoin.opcodes.OP_ELSE,

But its not working and i am getting only on 1 in txout. whats the correct way to add another multisig address ?
Just want to follow this pattern:
redeem script: 2 <pubKey1> <pubKey2> <pubKey3> 3 OP_CHECKMULTISIG

in which project/library is this command defined? this.app.env.bitcoin.script.compile

Sorry for late reply
https://github.com/swaponline/swap.core/blob/9295ead434117c995c33976782aa2fac8361becf/src/swap.swaps/BtcSwap.js#L183


text:
Bitcoin Core frozen trying to sync and/or connecting to peers
I downloaded Bitcoin Core directly to my laptop and sent BTC to what i believe is my wallet. The BTC is no longer in my senders wallet and I do not see it in my bitcoin core wallet. It was working slowly but now it is frozen at 12 percent.

so i checked my adress on a block explorer and the BTC is there..so that is a good thing...i finlly got it to 60 % synced but it keeps running out of storge so I have to delete 5-15 gb and then it once again runs out of space ive been doing this for 3 days now. Is there a way to have it save to an external SSD? i cloned my os but it doesnt seem to want to boot and I dont want to delete or format the disk in fear that it will lose my BTC

ok so now it says replaying blocks...press q to shutdown and it stays at 0%

Your wallet will need to sync to the network before your funds will be shown as available. This is because the ‘sync’ process involves your node verifying the history of transactions, so the transaction you received cannot be verified until all other preceding transactions have been verified first.
If you think it has frozen during the sync, I’d suggest turning the debugger on, and then looking at the debug.log file for clues on what the issue is.

Check your address on a block explorer, your funds are like there. As the other answer mentioned, these won't be visible until your wallet syncs.
If you're in a hurry, you can download the blockchain via torrent, then move it to your data folder.
Alternatively, you can import your private keys into a light wallet, which will show your balance immediately

could i get a link to the download of the blockchain via torrent...and...or....instructions on how to find and import my private keys...tia

Sure, see private key export/import instructions


text:
Is transaction verification called mining in blockchain?
A transaction in which A sends $10 to B; then this transaction is published in the network. Now, how the other nodes C and D will know, whether A is having $10 or not. and why A should reveal his account details to every node to verify?


text:
Why is it important that the hash algorithm is puzzle friendly?
I don't understand "PUZZLE FRIENDLY". Here the definition I read:

A hash function h is puzzle friendly if for every possible N-bit
  output value y, if K is chosen from a distribution with high minentropy,
  then it is infeasible to find X such that H(K // X) = Y, in
  time significantly less then 2^N.

And here is what is tried when mining:
H(nonce||prev_hash||tx||tx||..||tx)

"If the hash function satisfies the puzzlefriendliness
property, then the only way to
succeed in solving this hash puzzle is to just try
enough nonces one by one until you get lucky"
Ok, but what would be the problem if the hash function wasn't puzzlefriendly?
I assume that nonce is K in the definition.

In the most straightforward terms: Given a hash function H, that takes some input X from the user, and produces output Y, a good 'puzzle friendly' algorithm will not show any pre-determinable correlation between input X and output Y. That is to say, you cannot select a certain X, with hopes of returning a certain Y.
In practice, the bitcoin network accepts a block hash that is lower than some value (determined by the current network difficulty). The user should not be able to select inputs based on any sort of expected output value, the entire rang of input values* should have an equal chance of returning the desired output.
Otherwise, the user could discriminate against input values within certain ranges, thus narrowing their search field, and increasing their chance of finding a valid output. This would break the function as it is required for a POW cryptocurrency, by allowing users to make 'educated guesses'. In such a broken system, the more 'educated' a guess is, the higher chance the output will be the desired value. So the more you understand the (broken) algorithm, the less resources you would have to spend in order to compute a valid block hash.
Contrast this to the 'ideal' case where every user guess is equally likely to create a valid output. This is what is desired, and what is being referred to as a 'puzzle friendly' here.
*Note: user input includes more than just the nonce value. All input values that the user can alter would be included, there is no functional difference between changing the nonce, or changing the transaction structure


text:
How do i find my private keys in my blockchain.info wallet?
I've tried numerous times to find private key in settings/addresses, but can't find any.
My question is not like the other problems here, because i cannot even see my private key. I can find xPub extended private key on my default wallet. But is that the same thing?

Possible duplicate of I don't know how to export a private key from blockchain.info

Please follow the below steps:

Go to settings, then click addresses as shown below:

Click on more options aside your address whose private key you require as shown below:

In 'More Options' you will find "Private Key", please click it:

They will show you a warning as below, please click continue:

You can see your private key for the corresponding wallet address:

Hope this helps you!

On my addresses page there is none of your screen shots there.

Are you using a desktop/laptop to access or a mobile? The above are screenshots from the former one.

desktop application

Please go to blockchain.info there is no desktop application of blockchain.info.

sorry i meant the web browser on my desktop pc, not desktop application.  How do i add images to these comments?

https://i.imgur.com/GFHZfUu.png

The image in the link above has been edited to remove any identifying information

You have no addresses, then how can you get the private key mate. Click "+ ADD" to create a new wallet, then you can access it. Screenshot: http://prntscr.com/h5u079

But i've been purchasing bitcoin through the wallet, and I have a bitcoin total, and association value. Why do i need to create a new address?

I've done just as you ask and now that address has no bitcoins in it?

So what do i do now? https://i.imgur.com/nFGYTcn.png

If you were buying BTC, were you sending those BTC to this wallet in Blockchain.info?

I was buying BTC through the wallet. Have BTC in the wallet. your images have no corresponding view on my wallet. I can see on other answers, that yoiu've used the same images, I wonder if these are taken from an earlier version of the site. I can find 'xPub' but no where does it give you the link for private keys. I have used addresses, that show a new address for each purchase, but no links to private keys for these either.

i could not find the way to get private keys on bc.i by this manual. May be it depends on security settings (2fa, email confirmation, etc)

This tutorial was made just few days back for another question. It is working for me with security settings of 2FA and Email Confirmation. I don't know why this is not working for the OP. Hope some other answer will surely help you mate.

Here’s how to export your private keys on blockchain.info:
https://medium.com/@bL4nkcode/how-to-export-blockchain-infos-private-key-2ac84057d2d1

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


text:
blockchain.info multi address lookup
https://blockchain.info/api/blockchain_api
multi address
I know I must be an idiot but I cannot for the life of me find out how to pass in the &limit param.
I am looking to pass in a limit of 0 because I am not interested in tx, just in balance on multiple addresses.
For example in their single address lookup:
https://blockchain.info/rawaddr/1NiNja1bUmhSoTXozBRBEtR8LeF9TGbZBN?limit=0
works exactly as expected.

If you are only interested in the balance of multiple addresses I would suggest you use the following call in stead:
https://blockchain.info/balance?active=1NiNja1bUmhSoTXozBRBEtR8LeF9TGbZBN|1MrkWMnWLW53SQVQ5Pd2BsugY1F8H1oKio
But if you need to use multi address the limit flag seems to be wrong in the documentation, it should be 'n' and the minimum limit allowed seems to be 1. 0 will just return all transactions anyway.
https://blockchain.info/multiaddr?active=1NiNja1bUmhSoTXozBRBEtR8LeF9TGbZBN|1MrkWMnWLW53SQVQ5Pd2BsugY1F8H1oKio&n=1

Wow thanks, yea I had the multi address lookup working was trying to not have 50 transactions returned. How did you figure out the param was n?! It does work so thanks so much!
Oh I see you read the json response and since n seems to be used for the tx # it is likely the param used as well?

Oh wow yes :
https://blockchain.info/balance?active=1NiNja1bUmhSoTXozBRBEtR8LeF9TGbZBN|1MrkWMnWLW53SQVQ5Pd2BsugY1F8H1oKio
Is exactly what I wanted where did you find this api call however?! EDIT: wow I feel like an idiot it is simply like 2 more down from the call I was using in their api... Any idea how many addresses can be looked up at a time? (just curious)

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


text:
On a low level, how are long chains kept secret and later broadcast during 51% attacks?
I've been reading about the vulnerabilities of PoW crypto, and there's a part of it that I don't understand.
Suppose I wanted to stage a 51% attack on Bitcoin (not really feasible, but bear with me). This would involve waiting for height n to be achieved, and then immediately working with my superior hashpower to produce blocks at heights n+1, n+2, ..., f without broadcasting said blocks to the network. For simplicity's sake, let's say I'm adding empty blocks to my private chain. When I feel like it, I can then broadcast my chain (which is longer than the trusted chain), which will nullify all transactions starting from block n+1 inclusive (is this correct?).
Firstly, on a semi-low level (i.e. in terms of actual data/file operations), how does one keep and cultivate the secret chain? Would I be saving a sequence of valid hashes for each block, while remaining disconnected from the network?
Secondly, how does one broadcast the bigger chain? My understanding  is that when you connect to the network and submit a block at height k, it will be rejected if the main network is already on block k+1 or greater. So even if I sequentially broadcast my solutions, wouldn't they be rejected before it could be revealed that the number of solutions I have exceeds that of the main network's chain? For example, after starting my 51% attack after block n is found, the main network eventually gets to block n+3 while I am secretly at block n+5. In terms of actual operations, what would I need to do in order to supersede the main chain?

When I feel like it, I can then broadcast my chain (which is longer than the trusted chain), which will nullify all transactions starting from block n+1 inclusive (is this correct?).

Yes, it's correct.

Firstly, on a semi-low level (i.e. in terms of actual data/file operations), how does one keep and cultivate the secret chain?

The same way your node stores regular blocks.  To build your separate chain you can, as you suggest, just disconnect your node from the regular network.

Secondly, how does one broadcast the bigger chain?

Just reconnect to the network.

My understanding is that when you connect to the network and submit a block at height k, it will be rejected if the main network is already on block k+1 or greater. So even if I sequentially broadcast my solutions, wouldn't they be rejected before it could be revealed that the number of solutions I have exceeds that of the main network's chain?

When you reconnect your node to the network, it will establish new connections with new peers and they will exchange messages that say, basically, "what's the best block you know of?".  The other nodes will tell you about the weaker public chain and you'll tell them about the stronger formerly-private chain.  The other nodes will then request all the blocks for the stronger chain and your node will relay them.
As a practical example, during the consensus failure fork documented in BIP50, this is exactly what Bitcoin Core 0.8.0 nodes saw happen.  They followed the strongest chain, which became longer by more than a dozen blocks, but then miners shifted to working on the weaker chain and made it the strongest chain.  The 0.8.0 nodes followed suit just fine.
Something similar happened with the 4 July 2015 fork with most pre-Bitcoin 0.10.0 nodes.  They saw what looked like a valid chain with +6 blocks, but then another chain was extended to become strongest and they switched without problems.

And when we say network of nodes, is that the pool of miners that the attackers initially hides his chain from?

I mean the public network of full verification nodes that miners and all other users connect to by default.  The network isn't working correctly if you can deliberately hide from one pool connected to it with without hiding from everyone else too.

Thanks for your responses. If an attacker wanted to exclude his double spend (well, at that point it'd be the initial spend, but you get what I mean) on his malicious chain, but otherwise use the trusted chain's transactions (this is as opposed to just mining empty blocks), how would this be done? If he disconnected from the network, then he'd be unable to see the pending transactions and therefore be unable to "mimic" the trusted chain with the exception of the double spend transaction.

He can keep one non-mining node on the honest chain and use that to relay transactions to the dishonest mining node.  Do you need specifics?  (If so, please say why---I don't mind discussing theory, but I refuse to help someone actually execute an attack.)

Thanks! That's about as specific as I need; I just wanted to understand 51% attacks deeper than the abstract theory. I intend to create a PoW-based crypto from scratch in the near future as a hands-on project to learn more about how blockchain platforms work, so if there's a need, I'll probably ask the nitty-gritty questions once I get to that advanced level. On that note, how did you get proficient in all things Bitcoin-related?

@TiwaAina a significant part of the answer for how I got proficient is that I investigated the source code in order to find answers to a lot of questions on this StackExchange.  :-)


text:
Is there a gui to manage the bitcoind server via a browser?
I installed bitcoind on my centos server and was wondering if there was a gui that can control everything the bitcoind does. Would be nice check balance, send funds, create wallets via the browser.

Note: I approved (at least, improved) the edit on this question, but in hindsight it should have been rejected (I mistakenly thought the author edited it)

Looks, like it is 50 strings php file:
https://en.bitcoin.it/wiki/PHP_developer_intro
See, https://bitcoin.stackexchange.com/questions/13849/how-do-we-talk-to-bitcoind-in-a-php-plugin
Also, read this http://www.reddit.com/r/Bitcoin/comments/1tvn12/best_way_to_programatically_receive_and_send/
For the rest, https://en.bitcoin.it/wiki/Bitcoin-python


text:
How to install Hard Fork of Bitcoin, such as Bitcoin Cash and Bitcoin Gold?
Just like the title, how do I install hard fork of Bitcoin, such as Bitcoin Cash or Bitcoin Gold?
I would like to install Bitcoin Cash core in Ubuntu 16.04. It seems like there is not a single authoritative implementation according to this answer from "Install Bitcoin and Bitcoin cash".
But, I feel really confused by the name of "BitcoinABC" and "BitcoinUnlimited".
Are they just two different command line interfaces for Bitcoin Cash like Geth and Parity when installing Ethereum?
OR
Are they just two different ways to install Bitcoin Cash? Are they synchronizing the same blocks from bitcoin network?
I have been searching and trying to clarify things that I don't understand.
More I search, more I feel confused.
Does any know about this? I will be appreciated if you clarify things that you feel what I don't know about.

I agree with you, that from a marketing standpoint, the different names used by the various implementations of the Bitcoin Cash fork are confusing.
First, let's understand what a fork is. The rules about what constitutes a valid block, to be added to a blockchain, are set in the program code which miners follow. They compete to be the next to validate a transaction block and add it to the blockchain.     A fork occurs when these rules are changed by some, in a way which is incompatible with the old rules. A subset of miners starts following the new rules, and the rest of the miners keep following the old rules.  The result is that each group of miners starts building distinct chains which fork from a common ancestor chain.     So, if someone holds coins the original common ancestor chain, those coins are now valid on both forks, and can be spent once in each fork. This is because as far as one chain is concerned, spends on the other chain are not visible - they don't exist.
The main difference between original Bitcoin and Bitcoin Cash is that the Bitcoin Cash chain allows transaction blocks to be up to 8 MiB in size, instead of being limited to 1 MiB.
To install the Bitcoin Cash fork, one way is with Bitcoin ABC, "a full node implementation of the Bitcoin Cash protocol". In other words, Bitcoin ABC follows the rules of the Bitcoin Cash fork. In the Ubuntu 16 "Xenial Xerus" command line:
# git clone https://github.com/Bitcoin-ABC/bitcoin-abc.git

This clones the official Bitcoin-ABC repository into your machine. Instructions for installing all the pre-requisite pacakges needed to compile the programs will be in ~/bitcoin-abc/doc/build-unix.md; read this file and make sure your machine is ready for compilation:
# ./autogen.sh
# ./configure
# make

Note: on a mult-core CPU machine, you may use 1.5x the number of cores to speed up compilation. For example, on a 4-core machine:
# make -j 6

Now, in the ~/bitcoin-abc/src directory, after compilation, you will have the server binary: bitcoind, the client: bitcoin-cli and another binary to create, parse, or modify transactions: bitcoin-xt. For convenience, you can copy these to a folder visible to all users, such as /usr/local/bin
sudo cp ~/bitcoin-abc/src/bitcoind /usr/local/bin
sudo cp ~/bitcoin-abc/src/bitcoin-cli /usr/local/bin
sudo cp ~/bitcoin-abc/src/bitcoin-tx /usr/local/bin

Then, as a regular user, create the .bitcoin folder
mkdir ~/.bitcoin

and create a bitcoin.conf file
vim ~/.bitcoin/bitcoin.conf

#------------------------------
server=1
daemon=1
listen=1
maxconnections=16

rpcuser=bitcoin.rpc
rpcpassword=<some-secret-password>
rpcport=12345
keypool=256
#-------------------------------

Then you can run the bitcoind binary.
#bitcoind

and start using it via the command line client
#bitcoin-cli getinfo

{
  "version": 160200,
  "protocolversion": 70015,
  "walletversion": 60000,
  "balance": 1.61803398,
  "blocks": 504043,
  "timeoffset": 0,
  "connections": 8,
  "proxy": "",
  "difficulty": 136961411965.4142,
  "testnet": false,
  "keypoololdest": 1376702008,
  "keypoolsize": 4096,
  "unlocked_until": 0,
  "paytxfee": 0.00000000,
  "relayfee": 0.00001000,
  "errors": ""
}

Thank you so much for your great explanation. Especially, when you explain about general concept of what a fork is and how it works.
Do you know if there are any differences between installing from Bitcoin ABC and Bitcoin Unlimited? According to Bitcoin Unlimited website, they guide users how to download Official Bitcoin Cash (BCH). So, I installed it in my Ubuntu server.
bitcoin-cli getinforeturns the output like below.

{
"version": 1010200,
"protocolversion": 80003,
"walletversion": 60000,
"balance": 0.00000000,
"blocks": 85013,
"timeoffset": 0,
"connections": 12,
"proxy": "",
"difficulty": 1378.028165037326,
"testnet": false,
"keypoololdest": 1512105032,
"keypoolsize": 101,
"paytxfee": 0.00000000,
"relayfee": 0.00001000,
"errors": "",
"fork": "Bitcoin"
}

I really want to give  you a vote, but I don't have qualification yet to vote.

If you think I answered your question, you can select my answer as the accepted answer by clicking on the check mark beside the answer to toggle it from hollow to green.

In regards to differences between them, there must be some, but both must be generally compatible with the Bitcoin Cash fork specifications. I have not looked at them in detail to point out what these differences might be.

Bitcoin ABC and Bitcoin unlimited are nodes of the main fork of bitcoin cash.

Bitcoin Cash XBC is a "Adjustable Block Size" implementation of the
  original Bitcoin client, allowing up to 8mb block size. Forked from
  Bitcoin-ABC and compatible with the Bitcoin Cash blockchain only. All
  credit for previous engineering work goes to Satoshi Nakamoto, The
  Bitcoin Core and Bitcoin-ABC development teams.
Bitcoin XBC is the name of this open source software which enables the
  use of Bitcoin via the ‘Bitcoin Cash’ blockchain.

You can install Bitcoin cash from: https://download.bitcoinabc.org/0.16.1/

Thank you for your great explanation. So basically the Bitcoin ABC and Bitcoin Unlimited are the same nodes of the main fork of bitcoin cash?
If they are different, what would that be?
I find out I could install Bitcoin Cash core from these links Bitcoin ABC and Bitcoin Unlimited.
I installed from Bitcoin Unlimited download link a minute ago, and I am trying to get my foot in the door to discover the differences by looking at the commands from bitcoin-cli help

Yes, Bitcoin ABC and Bitcoin Unlimited are two implementations of nodes that connect to the Bitcoin Cash fork.


text:
Can you specify a date in the future for the Bitcoin transaction
I just came across this Transaction: https://blockchain.info/tx/cf77c2b888916c0debfb801d3d129ba5b7f6445e0dd6db9238b313b51369024c
Received Time:  2063-08-04 05:00:33

Raw Transaction: https://blockchain.info/rawtx/cf77c2b888916c0debfb801d3d129ba5b7f6445e0dd6db9238b313b51369024c
Is it just one case, maybe some kind of bug, which has already been solved, or is this a normal behavior?
Is there any official information regarding this topic?

That looks like a glitch with blockchain.info, there is no "time" encoded in a bitcoin transaction itself so that number is likely just when blockchain.info received the transaction.
In general though, it is possible to create a transaction which is only valid after a certain point in time or a certain block height in the blockchain, by using the "locktime" component of a transaction. If a locktime on the transaction is set, the transaction can only be included in a block after that point, not before, which may be of interest to you.

If you check the very last lines of the raw transaction, you can find the 'time' field with the value of 2953429233. And the 'lock_time' is set to 0. Here is another transaction like the one from my original post: https://blockchain.info/rawtx/da71fda48795fbdf05ca522ceaa7ac34bef68ca6973f33ff5ec764bdfcff045c And again, "lock_time": 0, "time": 1574921809

@GSazheniuk yes, but then"time" field is something blockchain.info has made, it is not part of the raw transaction, that's what I said in my answer

Blockchain.info is a private website, it's not the block chain, most of the information they show is fairly nonsensical. They've a history of displaying misleading, incorrect, or just plain ridiculous things about transactions.

@MeshCollider Just our of curiosity - did you check raw transaction in any other source(s) when you said that 'there is no "time" encoded in a bitcoin transaction itself '?

@GSazheniuk I'm very familiar with the raw transaction format :) you can see the two transaction serialisation formats here: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#transaction-id


text:
Bitcoin is becoming CENTRALIZED and is INSECURE
I'd like someone to tell me if I'm wrong:

More than 50% of the mining is done by Chinese pools.  That means that they control the network - who's transactions get in, who's transactions are left out. Since the block reward was reduced to 12.5BTC, they are completing it with transaction fees - the bigger the transaction you're sending - the bigger the fee you need to pay them.  Last time I've checked I've seen some transactions with fees of more than $1000 worth of BTC in them.  So in a sense, Bitcoin is starting to act like a traditional banking system - owned by Chinese people.
Blockchain size is increasing rapidly and soon to reach 200GB of storage - when the size will get ever larger, especially assuming that people that host the entire chain on their computer do not get rewarded for it and maintaining a full node requires electricity + storage + network uptime, it will soon be costly to run a full node.   200GB and even 1TB of storage is no problem for a central authority to run, and it seems to be going in that direction. How can the network continue to be P2P like that?  And especially what happends if that main storage will be taken over by the authorities and be shutdown?
Same issue as in #2 - Because downloading and installing a node is costly and difficult, most of the wallets being opened by people today are online wallets, most likely under the mainsite blockchain.com, and this site seems to be run by ghosts - there's no actual person there that you can contact in case of problems with your wallet, and the only way to contact them is through a Luxembourg court order (see "Legal" section on their site).  Same goes for the bitcoin.org domain - there's no person that can take responsibility for these operations.  What happends if tommorow blockchain.com gets shutdown for legal actions?   What will happend with people's wallets and their funds then?
There is no governance, and the only thing that governs the entire network is mathematics.  What happends if tommorow all Chinese pools collaborate together, make a Bitcoin transaction of 1M Bitcoins, and after 5 or 6 blocks (confirmation) they start to re-mine all the blocks again in order to erase that transaction from the chain?   Assuming that they outmine all the other competitors, I can't think of scenario where they won't catch up and even win over the honest chain, assuming the difficulty changes only every 2016 blocks.  If I was the owner of these pools, what can prevent me from deliberately ceasing all my mining power.. wait for the net difficulty to lower, and then do this attack?

Any expert thoughts on this?

This question should be broken done into many different questions so that future audiences will find this question more helpful.

It is unclear what you are actually asking in this question. Either you are asking too many questions in the same question (in which case you should create multiple questions for each one that you have) or there is no actual question. Please edit your question to clarify.

I see that dictatorship has arrived to stackexchange.com as well.  I Think my questions here are very clear and the fact 4 people upvoted it speaks for itself.  and the fact people try to escape answering them and trying to shut them down instead isn't going add more trust to Bitcoin as a currency.   Hope you're all enjoying what you're doing and will keep enjoying it as long as you can.

More than 50% of the mining is done by Chinese pools. That means that they control the network - who's transactions get in, who's transactions are left out.

Sure. But electing to censor transactions is pretty much equal to you refusing to pick up some unwanted dollar bill on the ground. Last I checked, eventually someone would pick up free money.

Since the block reward was reduced to 12.5BTC, they are completing it with transaction fees - the bigger the transaction you're sending - the bigger the fee you need to pay them. Last time I've checked I've seen some transactions with fees of more than $1000 worth of BTC in them. So in a sense, Bitcoin is starting to act like a traditional banking system - owned by Chinese people.

False. As a user, you are in complete control of how much fees you want to pay. You can pay the minimum fee rate so as long as you have the patience to wait for the transaction to be confirmed. Alternatively, if enough users elect to pay a fee rate that is homogeneous, miners are still incentivised to mine transactions that pay lower fee rates.

How can the network continue to be P2P like that? And especially what happends if that main storage will be taken over by the authorities and be shutdown?

If storage is an issue, you can elect to run your bitcoin node in prune mode, which effectively removes the need to maintain the whole blockchain. AFAIK, there are enough full nodes with the blockchain out there to prevent a state attacker from shutting down all of them.

What happends if tommorow blockchain.com gets shutdown for legal actions? What will happend with people's wallets and their funds then?

Users should never trust web-wallets nor hold coins in web services to begin with. It was an unintended usage scenario.
Instead, users with storage and computational constraints may elect to store their bitcoins in an SPV wallet, offline paper wallet or hardware wallet with varying privacy/usability tradeoffs.

If I was the owner of these pools, what can prevent me from deliberately ceasing all my mining power.. wait for the net difficulty to lower, and then do this attack?

The net difficulty will not lower itself until a full epoch (2016 blocks) has been reached. So there is no incentive to cease mining operations for the above reason. In fact, there is a huge opportunity cost to be paid by a major pool that ceases mining operation, consider the lost revenue opportunity. That alone could potentially drive a major pool bankrupt.

Thanks for answering.  The first point you said about someone would eventually pick up the transaction - true.  But it could take anywhere from several hours to days if most miners choose to only accept transactions with large fees, aka dictatorship over transactions.  Second - how do you know all full nodes are not reverse proxies that all connect to a central server?    Third - if block reward is 12.5BTC, ceasing mining for 2016 blocks would be a "loss" of only 25000BTC.   If the attacker could then resemble mining to gain 1M BTC by a double spend, I can't see why not do it.

its important to understand that a full block is better than a block that is barely filled with transactions that pay large fees as the revenue derived from filling a block with transactions that pay fees anyways will most likely be greater than a block that decides not to maximise on transactions. So miners don't really have a choice to opt to not fill a block. However, when users are racing each other to pay the highest fee rate, thats when its a good time to be a miner.

Thanks again, but that still doesn't answer any of the concerns I raised above regarding security and safety of information.   When someone challenges a product that lots of people are invested in with legitimate concerns and questions, and gets the subject changed or distracted from the main question towards the product's "advantages", that's an indication of a large scale pyramid scheme.

Miki, you better sell your funds, it's not for you. It is a high risk system, very new on the market, not supported by the main stream, only similiar to banks with it's fees, a dictatorship system, supported by the  stackexchange dictatorship system here, and controlled by a communism country (China!) and their miners. And "they" can always do, what "they" want, without any rules in the protocol, logic in crypto ccy or built-in security of the channels. This is not a playground for you, you are way to suspicious, and want others to explain you, why you are suspicious. No ...? ridicoulous...


text:
Can someone explain how this person hacked bitcoin?
I'm trying to fill a few gaps in my understanding how this transaction happened!
It all started with this article
In short, some vigilante/miner was able to scoop up all of the BCH sitting in segwit addresses (namely, the ones for which the public keys were revealed by the owners spending BTC from the same addresses.
See this Transaction that was created, miner
Bitcoin Cash Block Explorer
Step by Step Breakdown

Miner scoops public key of this address 3P9dyU9ga3aJorHAUqKBFCX2NdyuHEVgx1
(this is a P2SH P2WPKH address see this bitcoin block explorer )
Question: what is that public key? Do you see any keys?
("3" is a multisig address & requires 3 addresses, so there must be 3 public keys, right?)
The article didn't explain how and what raw transaction he created using only public keys.
This is the most frustrating part. The article claims that miner created a segwit node and mined on top of that.
How is that even possible? (Bcash doesnt have segwit activated. However even if he mined using his segwit node, his node will not allow him to create a valid transaction because segwit requires a witness or sign with private key of public key of address 3P9dyU9ga3aJorHAUqKBFCX2NdyuHEVgx1.)

However, this article claims

The miner just created a scriptsig (the article didn't explain what "apply a particular hash" means).
Now it's easy, the miner just has to assign a BCH output (address starting with 1)
it gets even more stupid. The article says after making that raw transaction he mined it ..... without broadcasting it. How does that work?
3.1 If you are not broadcasting it then whats the point? How will that transaction go through to the new address/wallet created by miner (in this case 1C4TafndKYFoGkeoHfQAWkZzEYLum31txf)?
3.2 If the miner is mining his own block and then not broadcasting it, wouldn't it get orphaned? So what is going on here?

It's a good question (though it would be easier to read with capitalized sentences, correct spelling, and fewer ? marks).  However the last paragraph is off topic - this site isn't the place to recruit people for your projects.

i agree however i want to learn ... segwit is so confusing trying to search for 25 days .. already had 46 tabs and 4 windows open in my browser

Question: what is that public key? do you see any keys? ("3" is a multisig address & requires 3 address? so there must be 3 public keys right?)

No. An address beginning with a 3 is a P2SH address. This does not mean it is a multisig address or requires any number of keys to sign the transaction. Rather it just means that there is some script (it can be any script, not necessarily a multisig script) that needs to be included in the input that spends the P2SH output. That script will dictate the other items in the input.
For a P2SH nested Segwit output (P2SH-P2WPKH and P2SH-P2WSH), the script that the address refers to (known as the redeem script) is of the form OP_0 <20 byte hash> or OP_0 <32 byte hash>. When a segwit node sees this script in an output or as a redeem script, it knows that it should look in the newly defined witness are of a transaction to get the rest of the data it needs to verify the transaction.
However for a non-segwit node, they will mark the transaction as valid (but not standard) because for a non-segwit node, those redeem scripts don't specify that a signature is needed. This makes these outputs anyone-can-spend to non-segwit nodes.
Since Bitcoin Cash does not implement segwit, all of their nodes are non-segwit nodes. Thus in order to spend from the P2SH nested segwit outputs, you only need to provide the redeem script. However the redeem scripts are protected by a hash; given only a P2SH output, you cannot figure out the redeem script unless you already know it. Redeem scripts are revealed when the output is spent from.
What the miner did here was that they found as many redeem scripts as they could. The redeem scripts of the P2SH outputs used were all redeem scripts that had been revealed on the Bitcoin network because they had been used as an input in a transaction. So the miner took all of those revealed redeem scripts and checked to see which ones had corresponding outputs on the Bitcoin Cash network. Those that did could then be spent by the miner as the miner then knew the redeem script.

it gets even more stupid ????????????????????? Article says after making that raw transaction he mined it ..... without broadcasting it ?????? what

A transaction does not need to be broadcast before it is mined. A miner can include whatever transactions he wants, and that includes transactions not broadcast to the public. Once the block is mined, the transaction will then be broadcast with the block.

"Once the block is mined, the transaction will then be broadcast with the block." 1.  a miner can include tx that haven't being broadcasted before! isn't that against consensus rules? 2. what will happen if a miner didn't broadcast that tx after the block has been mined? is that block going to get rejected by other peers?

No, it is not against the consensus rules to include a transaction that was not broadcast. It is impossible for a node to know whether a transaction was actually broadcast to the network because they may have not received it if it were broadcast. The transaction itself does not need to be broadcast; it will be included in a block and that block will be broadcast. If the block that is transmitted does not include the transaction but when it was mined it did, then the transmitted block will be invalid.

it will be lot easier if bitcoin.org would have explained how mining works with segwit...  If the block includes that tx and removes it after being mined it will then change the nonce + hash making is automatically invalid ... thats what you're trying to say right?

Yes. It has nothing to do with segwit though. That is a consensus rule that has always existed.

so why didn't he just broadcasted it like a regular person ...instead of mining it ? maybe cuz he was afraid other miners will take that transaction & replace with there address in the output section, i guess .... lol :) just like the game of thrones

thanks for the explanation ... however, what does redeem script has to do with public key and scriptsig "particular hash" thing these articles are talking about?

The transaction was not broadcast because it is non-standard. This means that it is consensus valid, but nodes won't relay it. The "particular hash" and scriptsig things are because the redeem script is placed in the scriptsig and it must hash to a hash that is specified by the P2SH output that is being spent from.

wait.... what you mean by non-standard? also the first article says that miner was using a segwit node in bcash chain to mine this Tx ....does this makes any sense to you?

Bitcoin and related coins (including bcash) have a set of rules call standardness rules. These rules are on top of the consensus rules. A transaction can meet the consensus rules but not the standardness rules. That just means that it is valid but nodes won't relay it. Such transactions are called non-standard. It doesn't make any sense to use a segwit node on bcash because bcash does not have segwit.

jesus christ! (correct me if I wrong)

miner used normal bitcoin-abc node to mine his tx,

The block containing the tx will be broadcasted to other miner & get accepted as a valid block

3., however, the vigilance cannot broadcast this specific tx since it is non-standard .. miner collects coins in his wallet (those prev_out are not broadcasted but mined) ready to spend anywhere? (yes, he will broadcast when he pays to "bob" later)
so whats the purpose of broadcasting a tx like a regular person from wallet?

No, there is no "collect coins in his wallet" or "prev_out are not broadcasted but mined". That is not how Bitcoin or bcash works. There are no coins to collect, only outputs and the inputs that spend the outputs. The miner simply creates a transaction that spends the outputs and includes it in a block he mines, then broadcasts the block. The purpose of broadcasting a tx is so that miners can include them in a block. Miners do not need to broadcast their transactions for someone to include them in a block, but doing so will increase the chances that it will be included sooner.

thanks you're really genius person Mr.chow... i had marked your reply as.. answered

sorry i was asking about the purpose of not broadcasting a tx to save an output ...
if a miner didn't broadcast a tx.. other miners will pick it up & include in their version of the block.. so how did they save this 100 bch tx?
https://twitter.com/khannib/status/931448049125249024

No, if a transaction is not broadcast other miners will not know about it and will not pick it up. In that 100 BCH case, btc.com created a transaction and did not broadcast it.

i agree, however in that special case the sender already broadcasted TX and requested pool's to not to broadcast it... cuz bch came up with solution -  if you send bch to btc than contact miner's not to broadcast it....my Question- it will propagate through every node - then mempool - than miner... even if one miner ignore it ....other will pick it up? so how bch solution works here?

No, that is not how it works. No transaction is being broadcast; if a transaction is broadcast, even if one node (i.e. a miner's) ignores it, the rest of the network (including the other miners) will hear it and may include it in their blocks. What is happening with btc.com is that users talk directly to btc.com. They are not creating a transaction and broadcasting it.

okay, btc.com is just one pool there are many others.... what about them? or maybe i assume its all monopoly

Other mining pools or miners might offer a similar service if they are knowledgeable enough. Regardless, whether miners offer such a service or not, any miner can spend from such segwit outputs as I described earlier provided that they know the redeem script (either discovered it themselves or were told it by the person who actually owns the address on the Bitcoin network).

SegWit outputs look like AnyoneCanSpend outputs to legacy nodes (to keep it as a softfork). Since Bitcoin Cash doesn't have (and strictly opposes) SegWit, all the miners see them as AnyoneCanSpend outputs, and they can redeem it.
This cannot happen on the Bitcoin network, because the other miners would reject that block.
Maybe he's this guy: https://www.reddit.com/r/btc/comments/7g6s9l/an_update_on_bch_segwit_recoveries/ ?
[Removed nonsense part]

yeah that's the miner.. however these outputs where ignored by other miners (miners didnt took it- look the date on bch block explorer) and it is actually after than it was kindof hacked by that bcnsegwit-miner

No, it is not a hack. Other miners could redeem these outputs too, but they didn't for some reason. (Ethics?)

i know its not a hack ... other miners didnt do it cuz its complicated as hell... even the miner admits himself- "Because of the significant effort that was required to both claim these BCH and to verify that each person is the person who should be receiving the BCH, I will be taking 30% "

That article on SegWit is nonsensical FUD, as it completely ignores full nodes. Since nearly every node on the network now enforces SegWit consensus rules, reverting it to steal its outputs would require full nodes to stop enforcing first. That's a hardfork.

@PieterWuille Thanks for reviewing this page ... 1. Which article are you referencing to? 2. quote "Since nearly every node on the network now enforces SegWit" which network ? bcash or bitcoin

I'm referring to the coingeek link.

@PieterWuille
what do you think about the bitcoin cash address conventional? they are changing The version byte to 28 for p2pkh addresses and 40 for p2sh addresses... is it going to this solve this situation for all users on board?

https://support.bitpay.com/hc/en-us/articles/115004671663-BitPay-s-Adopted-Conventions-for-Bitcoin-Cash-Addresses-URIs-and-Payment-Requests

BitPay is acting on their own there. Cash people also have a proposal for new addresses. Yes, they should have done that from the start.


text:
Can someone explain how to read blockchain.info?
1.What is the public key of address 3P9dyU9ga3aJorHAUqKBFCX2NdyuHEVgx1
(usually placed under input.. not in this case)
2.What type of Script (P2PK, P2PKH, P2SH, P2WPKH, P2WSH) is used to make this Tx, also how you discovered?
https://blockchain.info/tx/9d710be07bed7699055ed4c27868ee50fcb91f8d738bebfdbf4145cdbaeb15a2

A Bitcoin address starting with 3 is always P2SH (pay to script hash).
It's not P2PK (in that case you would see a public key instead of an address) nor P2PKH (you would see an address starting with 1).  It could be P2WPKH or P2WSH since these are simply implemented as special types of scripts via P2SH.  The address is only the hash of the script, not the script itself, and hash functions are one-way.  So we won't know what the script actually is, nor whether it happens to be a WPKH or WSH script, until after that transaction output is spent.
See https://bitcoincore.org/en/segwit_wallet_dev/ for more info about segwit.  In particular note the following:

Until a P2SH-P2WPKH UTXO is spent and the redeemScript is exposed, a P2SH-P2WPKH address is indistinguishable from a non-segwit P2SH address (such as a non-segwit multi-signature address)
Like any other P2SH and P2SH-P2WPKH address, P2SH-P2WSH address has prefix 3. They are indistinguishable until the UTXO is spent

Nit: P2WPKH and P2WSH can also be used natively, without P2SH.

@PieterWuille, in that case, it shall not be the segwit address (starting with 1) anymore

@PieterWuille I think this block explorer is useful.. it returns a P2SH P2WPKH script ..however, suppose i'm a 3rd party and i want to verify that public key belongs to that (3P9...) address  .... how to do that?VISIT-
https://btc.com/9d710be07bed7699055ed4c27868ee50fcb91f8d738bebfdbf4145cdbaeb15a2

https://bitcoinvalued.com/tools.php ..... my hash160 generator returns an invalid address from public key's 03144cf9e97d15e70820556aeb4d0f99ca8b9a5876e0fe26a67c0272c21a53009d - and - 03144cf9e97d15e70820556aeb4d0f99ca8b9a5876e0fe26a67c0272c21a53009d

@Nate Eldredge There is an output assigned to this transaction.. so there must be public keys and witness data since this is a segwit transaction or P2SH P2WPKH script ... i see some random string .. how to construct this back to scriptsig????? any ideas