text:
How to tell which part of the previous tx I need to make the hash to sign for an old given tx?
I have recently been taught (here) how to create the hash to sign for a given "input script" for an existing transaction.  I then sought to test my abilities and sought out a difficult transaction to make sense of.  Well, I sure found it, and it proves my understanding is woefully inadequate to handle anything with more than a single input script transaction and or with a previous transaction that has more than 1 script.
I found d1cdb8c3828ee74c22677e705539937d039e6acef19e5f2ac0a2779846e4b6c1
which can be found "raw" here.
These are the first three "input scripts" of literally dozens:
1

3044022062025a634a2144462cca4b8b0e7b09188b214abb44c8738401bbe03b5df74a59022040fc2c48dc4b940b917c55de3d33861f3d0f21f0807039d5cb683caf6d7472a101
02f32fbdcc91934c8ea17cbe3b1ce8bb34cba9f33b959eb5d2d676181466c849ca

2

3044022079b93499324572f031e873c62d12d0207248d2e3d042781db2e6c009325ff6b6022059f81d40a65933bc8ad5f5125432cb5c156d3f64b12ee13f849c76650c36064501
02f32fbdcc91934c8ea17cbe3b1ce8bb34cba9f33b959eb5d2d676181466c849ca

3

3045022100a9c5705ee0427f976fe6f62bb5ab9e1f08a5550149021ef3f275e3f015326786022052e23f2931b7c6697918149cdb34d39884a321305f087e0a092e2c2c7789dfbc01
02f32fbdcc91934c8ea17cbe3b1ce8bb34cba9f33b959eb5d2d676181466c849ca

Many "input scripts" and each one seems to be sourced in a multi input transaction (I think that's what you call it).  The best thing I can do is click the "output" link for each amount shown on the given website to confirm which transaction it came from, but to discern which part of that previous transaction's raw data I'm supposed to take to make the hash to sign for the particular input script from this transaction?  I'd be more efficient at banging my head against the wall.  Banging my head against the wall would be more pleasant to do as well, by comparison.  And that's not even considering what other things I'd have to change to accommodate that piece of data (like do I have to change which input it is in the overall thing before I hash it twice?).
Can someone please walk me through the steps (in relatively layman's terms) on how to create the hash to sign for the first 2-3 input scripts for this transaction?  Please show me the work and show me the full thing I'm supposed to get before hashing it twice and what I'm supposed to get after I hash it twice (for the first 2-3 input scripts).  Even worst case scenario, if you give me just the full thing (that would just have to be copied and pasted to do the double hash) for the first 2-3 scripts and the resulting hash to sign for the first 2-3 scripts, I will upvote your answer identify it as the correct answer (assuming your numbers are correct).
I frequently find answers I get here are...well...beyond what I can understand and follow.  Though I might try, in a jumble of a raw transaction data (especially one such as this transaction, and its previous transactions) I have a difficult time discerning between an "input", a "sighash", a "script sig", an "output", a "dingleberry" or even a "petit point", its all one big skein of numbers to me that I can notice patterns to, but can't untangle.
To show I at least tried, I got 6fa4c7db52edfd1b20f11185283b600e4015d0ef0da7a6f7ffeae53f53a54d42 as the hash to sign for the first input script and I got 4d76fae4618eb086688f50faa2dcfeb5ed7071030cb87be6905c5910a9901ed3 for the second input script and I doubt I'm anywhere close to the right answer as the previous tx's raw transaction data was so convoluted and long and had so many sections, I have no idea what I was supposed to get.
At the very least, please tell me what hashes to sign I'm supposed to get for the first 2-3 inputs please.  At least that way I can check my work and try to figure it out on my own even if I don't understand the given explanation if I have those hashes.
This question may be believed to be similar to other questions, however, to contrast, I am asking for a step by step example with this transaction's first few inputs on how to even know which parts I'm supposed to look at of the previous transaction to really show it so I can confirm my understanding of your steps by comparing the results of me taking those steps, to the results you get from taking the same steps.
If you just say, regarding a particular input script or other thing, "well that comes from input 4 from the previous transaction just look at that" well, I don't know where that input is located in that previous tx's raw data!  Nor do I know how to figure it out.  If you show me, then that will help me identify it so that I can discern some of the nuances thereof and begin to understand how to make sense of it.  If you don't tell me what it is, then I can't confirm I understood your instruction.
If you say "remember to notate that in this part".  Notate what, I don't know what I'm supposed to notate or how I would notate it even if I did know it if you don't show me (or, please assume I don't know, you probably can't be "too basic" in your description of the steps for me as I am, at best, an amateur programmer and far from any degree a computer engineer).
I know my request for specificity exceeds the norm for the description to the steps, but I think that may help others who aren't as familiar who seek such answers and that's also why I'm also asking just for the copy-and-pastable result I'm supposed to get for the first 2-3 scripts that I need to hash twice, but also their resulting hashes; so that I can take your information and try to figure it out on my own such that I won't bug you guys with 16 comments trying to figure it out, waiting hours for responses (some of which never come) in a futile attempt to understand what it is you're trying to tell me in terms I don't fully understand.  Instead, you would be helping me with the tools to figure it out on my own.
Thank you for your help.

Related: https://bitcoin.stackexchange.com/q/41209/51948, https://bitcoin.stackexchange.com/questions/57656/how-would-one-go-about-acquiring-the-hashofthingtosign-from-this-old-transaction

You are correct, it is related, however, it fails to explain the step by step process and how to discern which value in the old tx's raw data is what is needed.  It definitely does not do so in a "relatively layman's" context either.

I know you understand this stuff MeshCollider, if you an give me an answer that has the final iteration of it for the first 3 input scripts AND the resulting hash to sign for each of the first 3 input scripts (as stated in the question) I would totally upvote that and consider it the answer.  At least then I could try to figure it out on my own.

If you cannot or refuse to understand the technical details of the raw transaction format, what the terminology means, and the parts of the transaction that they refer to, then no one can help you. What you are asking is inherently technical and is very in-the-weeds of how Bitcoin works. There is no way to explain this in layman's terms and still have you be able to understand it all correctly and then later be able to produce the hash yourself.

Disclaimer: I am going to assume that you are not completely clueless and that you know what an array is, how to count from 0, and how to match brackets, quotes, and colons so that you can read JSON formatted data. If you don't know how to do those things, then please google them first before reading this post.
Also, this post will be very long, and extremely technical. There is simply no layman's terms way of explaining this, but it can be explained to be very easy to follow assuming you know the things I said above. Things that are bolded are things that you should remember as I will use those terms later in the post.
Lastly, these instructions are for transactions which "spend from" Bitcoin addresses that begin with a 1. "Spending from" the other Bitcoin address type makes this process more complicated.

The transaction
I will be using a different transaction than the one in your question because that transaction is much too large to easily explain. Instead, I will be using ff8766ec873ff55cc0ac17dee7b379a4efa2a5c83dabdd9a30287c7761ad55d5 which is much smaller.
Blockchain.info does not provide enough information to easily construct the hashes. Instead I will be using the output of the getrawtransaction command from Bitcoin Core which breaks down the transaction in JSON format:
{
  "hex": "0100000003b0c03779c38ddabc044947b164adbcffde8e0ddb3678494f4e8b83f13b37629d010000006b483045022100f3c0f555cd39198caf77f6756256801fc57bcabe4892601b9def52259698f40a0220230262841bff151eb617f7d4cdda6bf06d6fa791230c152e47f68bcdd0e6f64a01210204b3506d8903ca601c97a4abab6548e91004c535a5a45e21299a494b146859caffffffff060eeae54b70d12caddcc15f8897ebc2b6c3011c9a600aba74d49b969991cab3000000006b4830450221009dbeb64ddd4646e1118503c87feaa95c531b5178c6e543be782f6ecb05e8fbe602203945570f8dc56c145617f0283fa4032e0b7895a9cf2a81c7b65665b8ac608cb00121026602a5dc59c30f485b2c457ac8e2f617e27b10a1d2ae76f3231f9b01dff08964ffffffff7f715ba408db0289118f9b8578e54e721f1aee10d09844510793b8b20c87903e010000006b48304502210095e300886ec4df78e39d6d0cf5e5e531ded8f42f00e5730c371d8951867dad5b02203c55f9403f6c2aac444213161a93a86661e7367d4007be74ffb3981387cc1c790121023f0aadfeb71a4964c5087fec8b052c8236051dae838d4747543330c6b266ce6effffffff02d5781100000000001976a914342ab422c9e3ef285efe9882ae54269ed9713dd688ac20a10700000000001976a91488d924f51033b74a895863a5fb57fd545529df7d88ac00000000",
  "txid": "ff8766ec873ff55cc0ac17dee7b379a4efa2a5c83dabdd9a30287c7761ad55d5",
  "hash": "ff8766ec873ff55cc0ac17dee7b379a4efa2a5c83dabdd9a30287c7761ad55d5",
  "version": 1,
  "size": 522,
  "vsize": 522,
  "locktime": 0,
  "vin": [
    {
      "txid": "9d62373bf1838b4e4f497836db0d8edeffbcad64b1474904bcda8dc37937c0b0",
      "vout": 1,
      "scriptSig": {
        "asm": "3045022100f3c0f555cd39198caf77f6756256801fc57bcabe4892601b9def52259698f40a0220230262841bff151eb617f7d4cdda6bf06d6fa791230c152e47f68bcdd0e6f64a[ALL] 0204b3506d8903ca601c97a4abab6548e91004c535a5a45e21299a494b146859ca",
        "hex": "483045022100f3c0f555cd39198caf77f6756256801fc57bcabe4892601b9def52259698f40a0220230262841bff151eb617f7d4cdda6bf06d6fa791230c152e47f68bcdd0e6f64a01210204b3506d8903ca601c97a4abab6548e91004c535a5a45e21299a494b146859ca"
      },
      "sequence": 4294967295
    },
    {
      "txid": "b3ca9199969bd474ba0a609a1c01c3b6c2eb97885fc1dcad2cd1704be5ea0e06",
      "vout": 0,
      "scriptSig": {
        "asm": "30450221009dbeb64ddd4646e1118503c87feaa95c531b5178c6e543be782f6ecb05e8fbe602203945570f8dc56c145617f0283fa4032e0b7895a9cf2a81c7b65665b8ac608cb0[ALL] 026602a5dc59c30f485b2c457ac8e2f617e27b10a1d2ae76f3231f9b01dff08964",
        "hex": "4830450221009dbeb64ddd4646e1118503c87feaa95c531b5178c6e543be782f6ecb05e8fbe602203945570f8dc56c145617f0283fa4032e0b7895a9cf2a81c7b65665b8ac608cb00121026602a5dc59c30f485b2c457ac8e2f617e27b10a1d2ae76f3231f9b01dff08964"
      },
      "sequence": 4294967295
    },
    {
      "txid": "3e90870cb2b89307514498d010ee1a1f724ee578859b8f118902db08a45b717f",
      "vout": 1,
      "scriptSig": {
        "asm": "304502210095e300886ec4df78e39d6d0cf5e5e531ded8f42f00e5730c371d8951867dad5b02203c55f9403f6c2aac444213161a93a86661e7367d4007be74ffb3981387cc1c79[ALL] 023f0aadfeb71a4964c5087fec8b052c8236051dae838d4747543330c6b266ce6e",
        "hex": "48304502210095e300886ec4df78e39d6d0cf5e5e531ded8f42f00e5730c371d8951867dad5b02203c55f9403f6c2aac444213161a93a86661e7367d4007be74ffb3981387cc1c790121023f0aadfeb71a4964c5087fec8b052c8236051dae838d4747543330c6b266ce6e"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.01145045,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 342ab422c9e3ef285efe9882ae54269ed9713dd6 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914342ab422c9e3ef285efe9882ae54269ed9713dd688ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "15kqJ5UinhstuG1KVCSJDagaUcFJLvhyNx"
        ]
      }
    },
    {
      "value": 0.005,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 88d924f51033b74a895863a5fb57fd545529df7d OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91488d924f51033b74a895863a5fb57fd545529df7d88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1DUb2YYbQA1jjaNYzVXLZ7ZioEhLXtbUru"
        ]
      }
    }
  ],
  "blockhash": "000000000000000000c93a1c73452d4221f8c88a1721072966c38d590b1b34af",
  "confirmations": 1,
  "time": 1502353841,
  "blocktime": 1502353841
}

The full raw transaction itself is the field hex. The inputs that we want to sign for are in an array in the vin field (the array is enclosed by square brackets [ ]). Each input is enclosed by curly braces ({ }).
The general hash preimage
The hash preimage is the data that is actually hashed. The algorithm to produce this preimage is known as the sighashing algorithm.  The sighashing algorithm for each input goes like this: take the transaction and make all scriptSigs empty. Then for the input we are signing, place the scriptPubKey of the output being spent, append the sighash type, and hash the whole thing with sha256d.
Signing the inputs
Here I will go into the specifics.
The first thing we want to do is to make all of the scriptSigs of the transaction empty. The easiest way to do this is to take raw transaction and do a find for the hex of the scriptSigs for each of the inputs in the transaction and replace that with 00. Then remove the two characters before the thing you just replaced
For the first input, the scriptSig is
483045022100f3c0f555cd39198caf77f6756256801fc57bcabe4892601b9def52259698f40a0220230262841bff151eb617f7d4cdda6bf06d6fa791230c152e47f68bcdd0e6f64a01210204b3506d8903ca601c97a4abab6548e91004c535a5a45e21299a494b146859ca

For the second input, the scriptSig is
4830450221009dbeb64ddd4646e1118503c87feaa95c531b5178c6e543be782f6ecb05e8fbe602203945570f8dc56c145617f0283fa4032e0b7895a9cf2a81c7b65665b8ac608cb00121026602a5dc59c30f485b2c457ac8e2f617e27b10a1d2ae76f3231f9b01dff08964

For the third input, the scriptSig is
48304502210095e300886ec4df78e39d6d0cf5e5e531ded8f42f00e5730c371d8951867dad5b02203c55f9403f6c2aac444213161a93a86661e7367d4007be74ffb3981387cc1c790121023f0aadfeb71a4964c5087fec8b052c8236051dae838d4747543330c6b266ce6e

After performing the find and replace, the unsigned transaction is
0100000003b0c03779c38ddabc044947b164adbcffde8e0ddb3678494f4e8b83f13b37629d0100000000ffffffff060eeae54b70d12caddcc15f8897ebc2b6c3011c9a600aba74d49b969991cab30000000000ffffffff7f715ba408db0289118f9b8578e54e721f1aee10d09844510793b8b20c87903e0100000000ffffffff02d5781100000000001976a914342ab422c9e3ef285efe9882ae54269ed9713dd688ac20a10700000000001976a91488d924f51033b74a895863a5fb57fd545529df7d88ac00000000

You should also mentally note the position of each of these replacements; you will need those positions later.
Now append 01000000 to the unsigned transaction so that we now have:
0100000003b0c03779c38ddabc044947b164adbcffde8e0ddb3678494f4e8b83f13b37629d0100000000ffffffff060eeae54b70d12caddcc15f8897ebc2b6c3011c9a600aba74d49b969991cab30000000000ffffffff7f715ba408db0289118f9b8578e54e721f1aee10d09844510793b8b20c87903e0100000000ffffffff02d5781100000000001976a914342ab422c9e3ef285efe9882ae54269ed9713dd688ac20a10700000000001976a91488d924f51033b74a895863a5fb57fd545529df7d88ac0000000001000000

Keep this original, unmodified unsigned transaction somewhere, we will need it later.
The first input
The first input is the first element in the vin array of the transaction JSON output:
    {
      "txid": "9d62373bf1838b4e4f497836db0d8edeffbcad64b1474904bcda8dc37937c0b0",
      "vout": 1,
      "scriptSig": {
        "asm": "3045022100f3c0f555cd39198caf77f6756256801fc57bcabe4892601b9def52259698f40a0220230262841bff151eb617f7d4cdda6bf06d6fa791230c152e47f68bcdd0e6f64a[ALL] 0204b3506d8903ca601c97a4abab6548e91004c535a5a45e21299a494b146859ca",
        "hex": "483045022100f3c0f555cd39198caf77f6756256801fc57bcabe4892601b9def52259698f40a0220230262841bff151eb617f7d4cdda6bf06d6fa791230c152e47f68bcdd0e6f64a01210204b3506d8903ca601c97a4abab6548e91004c535a5a45e21299a494b146859ca"
      },
      "sequence": 4294967295
    },

Now we need to get some data from the previous transaction output. So we look up the txid that this input spent from, 9d62373bf1838b4e4f497836db0d8edeffbcad64b1474904bcda8dc37937c0b0, and get its JSON format break down:
{
  "hex": "[removed for space]",
  "txid": "9d62373bf1838b4e4f497836db0d8edeffbcad64b1474904bcda8dc37937c0b0",
  "hash": "9d62373bf1838b4e4f497836db0d8edeffbcad64b1474904bcda8dc37937c0b0",
  "version": 1,
  "size": 373,
  "vsize": 373,
  "locktime": 0,
  "vin": [
    {
      "txid": "86efe44adc45a486c51a641cc83612159dc18f31a14da140a24fb4c5623e511a",
      "vout": 1,
      "scriptSig": {
        "asm": "3045022100cf76ad139adc38ae90fd14e6d29ff9bde62e7b3c3ef9880bc41098775100a1d502205a7dfb6aeacd9c58481f317334d5a6edaf2e734053555409550f6d463d9bf5f0[ALL] 030888863fcb4cdf5b7d33b40e613af35df8f39d576e7972238b0d396cd3fcc3f2",
        "hex": "483045022100cf76ad139adc38ae90fd14e6d29ff9bde62e7b3c3ef9880bc41098775100a1d502205a7dfb6aeacd9c58481f317334d5a6edaf2e734053555409550f6d463d9bf5f00121030888863fcb4cdf5b7d33b40e613af35df8f39d576e7972238b0d396cd3fcc3f2"
      },
      "sequence": 4294967295
    },
    {
      "txid": "897817de401d7245912e7add2da98e6d885a50104e147b785116b3a2a295f386",
      "vout": 0,
      "scriptSig": {
        "asm": "30440220633666024ceb08c4e6d076bc158a0dd013be14238afd8157f2b73b5a00aece6d02202a1da4a6def17cba4ae835c07af2b1ebff87bce0c56d21d6d2458cd234d766f6[ALL] 0395aa52bfe17fa8a06cc6b3216210c7ff3254a2095db322250bd2d9148e5b44cd",
        "hex": "4730440220633666024ceb08c4e6d076bc158a0dd013be14238afd8157f2b73b5a00aece6d02202a1da4a6def17cba4ae835c07af2b1ebff87bce0c56d21d6d2458cd234d766f601210395aa52bfe17fa8a06cc6b3216210c7ff3254a2095db322250bd2d9148e5b44cd"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.005,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 52fbbe93faca2c57c6d7ccad877e0da4876ce0c8 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91452fbbe93faca2c57c6d7ccad877e0da4876ce0c888ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "18ZmzEy6fzx9afy2LjWhNjttoh2VBpRq84"
        ]
      }
    },
    {
      "value": 0.01001452,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 2c418ec354a1ab688a656d86b16c02abe8f592e9 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9142c418ec354a1ab688a656d86b16c02abe8f592e988ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1531GU6Ypf66HJ8c9ZyF2rwHyRWUxKSXhb"
        ]
      }
    }
  ],
  "blockhash": "00000000000000000083cb57936842737b6b9da889fed3d9beb9661fe9ad458e",
  "confirmations": 8,
  "time": 1502353082,
  "blocktime": 1502353082
}

The vout field of this input specifies that we need the output at index 1 in the output array of the previous transaction. It is important to remember that arrays element indexing begins at 0. The first element has an index of (numbered) 0, the second element is index 1, etc. So, with an output index of 1, we need the second output of this previous transaction, which is:
{
  "value": 0.01001452,
  "n": 1,
  "scriptPubKey": {
    "asm": "OP_DUP OP_HASH160 2c418ec354a1ab688a656d86b16c02abe8f592e9 OP_EQUALVERIFY OP_CHECKSIG",
    "hex": "76a9142c418ec354a1ab688a656d86b16c02abe8f592e988ac",
    "reqSigs": 1,
    "type": "pubkeyhash",
    "addresses": [
      "1531GU6Ypf66HJ8c9ZyF2rwHyRWUxKSXhb"
    ]
  }
}

The only thing we need from this output is the hex of the scriptPubKey, which is
76a9142c418ec354a1ab688a656d86b16c02abe8f592e988ac

We need to prepend the number for the length of this hex in bytes (half of the number of characters in the string). The number must be in hex, and it is 19. So the scriptPubKey that we will be using is
1976a9142c418ec354a1ab688a656d86b16c02abe8f592e988ac

Now make a copy of the unsigned transaction that we made earlier, we will not be modifying the original which we will need for later inputs. Now take the copied unsigned transaction, and move your cursor to the 00 that we replaced this first input's scriptSig with. Replace that 00 with the scriptPubKey that we just modified. So now our copied unsigned transaction looks like
0100000003b0c03779c38ddabc044947b164adbcffde8e0ddb3678494f4e8b83f13b37629d010000001976a9142c418ec354a1ab688a656d86b16c02abe8f592e988acffffffff060eeae54b70d12caddcc15f8897ebc2b6c3011c9a600aba74d49b969991cab30000000000ffffffff7f715ba408db0289118f9b8578e54e721f1aee10d09844510793b8b20c87903e0100000000ffffffff02d5781100000000001976a914342ab422c9e3ef285efe9882ae54269ed9713dd688ac20a10700000000001976a91488d924f51033b74a895863a5fb57fd545529df7d88ac0000000001000000

This is our hash preimage. Now we need to hash it as bytes. The tool I use for hashing these online is http://www.fileformat.info/tool/hash.htm. Copy and paste the hash preimage into the text box for Binary Hash, labeled Hex bytes. Click Hash and scroll down. Copy the string next to the SHA-256 label and paste that into the same textbox and click Hash again. Scroll down again and the string next to SHA-256 is the hash that was signed for the first input of our transaction. This hash is:
0ca51b9a67de27aa35aba665cedea31025f8d40c85669953952b8dcde4242960

The second input
The second input is the second element of the vin array. The JSON for this is:
    {
      "txid": "b3ca9199969bd474ba0a609a1c01c3b6c2eb97885fc1dcad2cd1704be5ea0e06",
      "vout": 0,
      "scriptSig": {
        "asm": "30450221009dbeb64ddd4646e1118503c87feaa95c531b5178c6e543be782f6ecb05e8fbe602203945570f8dc56c145617f0283fa4032e0b7895a9cf2a81c7b65665b8ac608cb0[ALL] 026602a5dc59c30f485b2c457ac8e2f617e27b10a1d2ae76f3231f9b01dff08964",
        "hex": "4830450221009dbeb64ddd4646e1118503c87feaa95c531b5178c6e543be782f6ecb05e8fbe602203945570f8dc56c145617f0283fa4032e0b7895a9cf2a81c7b65665b8ac608cb00121026602a5dc59c30f485b2c457ac8e2f617e27b10a1d2ae76f3231f9b01dff08964"
      },
      "sequence": 4294967295
    },

We will need the information from the previous transaction output, which is the output at index 0 of the transaction b3ca9199969bd474ba0a609a1c01c3b6c2eb97885fc1dcad2cd1704be5ea0e06. This transaction's JSON output is:
{
  "hex": "[removed for space]",
  "txid": "b3ca9199969bd474ba0a609a1c01c3b6c2eb97885fc1dcad2cd1704be5ea0e06",
  "hash": "b3ca9199969bd474ba0a609a1c01c3b6c2eb97885fc1dcad2cd1704be5ea0e06",
  "version": 1,
  "size": 404,
  "vsize": 404,
  "locktime": 0,
  "vin": [
    {
      "txid": "7195945cfe7d0d5b7e49b35dba8a844ee0ce1fd3b2afdc3e5bf0e3be409080ce",
      "vout": 1,
      "scriptSig": {
        "asm": "30440220234ec20a17fced74c34b94b2c34e77bb1cc824a34916661fa164f4dd47ce4992022078176fe355ccee3675684af148d340c6bc5c039d9e60630b71f789f72edce327[ALL] 026602a5dc59c30f485b2c457ac8e2f617e27b10a1d2ae76f3231f9b01dff08964",
        "hex": "4730440220234ec20a17fced74c34b94b2c34e77bb1cc824a34916661fa164f4dd47ce4992022078176fe355ccee3675684af148d340c6bc5c039d9e60630b71f789f72edce3270121026602a5dc59c30f485b2c457ac8e2f617e27b10a1d2ae76f3231f9b01dff08964"
      },
      "sequence": 4294967295
    },
    {
      "txid": "9dfbb913f9e80d99ec162adce1f61662e99c7a864eb38943135f41b56693a17a",
      "vout": 1,
      "scriptSig": {
        "asm": "3045022100d966ddb0d0ef2f5e09fe88f7a9629409e576f929b10cd33b11d5c2da0fd2bcae022014517f6b43b3c12da786bca5d96de39ab804cd134940815b40bfbf5df336880e[ALL] 026602a5dc59c30f485b2c457ac8e2f617e27b10a1d2ae76f3231f9b01dff08964",
        "hex": "483045022100d966ddb0d0ef2f5e09fe88f7a9629409e576f929b10cd33b11d5c2da0fd2bcae022014517f6b43b3c12da786bca5d96de39ab804cd134940815b40bfbf5df336880e0121026602a5dc59c30f485b2c457ac8e2f617e27b10a1d2ae76f3231f9b01dff08964"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.00439481,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 58be4e12275e895c797c9bf7533452c5a41e4551 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91458be4e12275e895c797c9bf7533452c5a41e455188ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "196ESW77sq7iHzLfJub7KDgTGwvJMZwLs6"
        ]
      }
    },
    {
      "value": 0.00,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_RETURN 6f6d6e6900000000000000010000000011848ee0",
        "hex": "6a146f6d6e6900000000000000010000000011848ee0",
        "type": "nulldata"
      }
    },
    {
      "value": 0.0000273,
      "n": 2,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 88d924f51033b74a895863a5fb57fd545529df7d OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91488d924f51033b74a895863a5fb57fd545529df7d88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1DUb2YYbQA1jjaNYzVXLZ7ZioEhLXtbUru"
        ]
      }
    }
  ],
  "blockhash": "000000000000000000c0fd6a8fee9df17e59c7243c9fce359324ee0fffc70be3",
  "confirmations": 8,
  "time": 1502353358,
  "blocktime": 1502353358
}

We want the first output in the vout array here, so our output is:
    {
      "value": 0.00439481,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 58be4e12275e895c797c9bf7533452c5a41e4551 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91458be4e12275e895c797c9bf7533452c5a41e455188ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "196ESW77sq7iHzLfJub7KDgTGwvJMZwLs6"
        ]
      }
    },

Like the first input, we only need the hex of the scriptPubKey of this output with its length prepended to it, so we will the below as our scriptPubKey:
1976a91458be4e12275e895c797c9bf7533452c5a41e455188ac

Now we take our original, unmodified unsigned transaction, and copy it. Now go to the position where we removed the scriptSig for the second input. Replace the 00 that we had put there with the scriptPubKey. Our copied unsigned transaction should look like:
0100000003b0c03779c38ddabc044947b164adbcffde8e0ddb3678494f4e8b83f13b37629d0100000000ffffffff060eeae54b70d12caddcc15f8897ebc2b6c3011c9a600aba74d49b969991cab3000000001976a91458be4e12275e895c797c9bf7533452c5a41e455188acffffffff7f715ba408db0289118f9b8578e54e721f1aee10d09844510793b8b20c87903e0100000000ffffffff02d5781100000000001976a914342ab422c9e3ef285efe9882ae54269ed9713dd688ac20a10700000000001976a91488d924f51033b74a895863a5fb57fd545529df7d88ac0000000001000000

This is our hash preimage. Take the hash preimage and hash it like we did for the first input. Your resulting hash should be
46016caa2997dc453420a9af5090cd90c5109a93d525bbc3e9e12f8ec0112d58

The third input
The third input of our transaction is the third element of the vin array. This is its JSON formatted break down:
    {
      "txid": "3e90870cb2b89307514498d010ee1a1f724ee578859b8f118902db08a45b717f",
      "vout": 1,
      "scriptSig": {
        "asm": "304502210095e300886ec4df78e39d6d0cf5e5e531ded8f42f00e5730c371d8951867dad5b02203c55f9403f6c2aac444213161a93a86661e7367d4007be74ffb3981387cc1c79[ALL] 023f0aadfeb71a4964c5087fec8b052c8236051dae838d4747543330c6b266ce6e",
        "hex": "48304502210095e300886ec4df78e39d6d0cf5e5e531ded8f42f00e5730c371d8951867dad5b02203c55f9403f6c2aac444213161a93a86661e7367d4007be74ffb3981387cc1c790121023f0aadfeb71a4964c5087fec8b052c8236051dae838d4747543330c6b266ce6e"
      },
      "sequence": 4294967295
    }

Now we need the output at index 1 of 3e90870cb2b89307514498d010ee1a1f724ee578859b8f118902db08a45b717f. That is the second output of 3e90870cb2b89307514498d010ee1a1f724ee578859b8f118902db08a45b717f. The JSON formatted break down of that transaction is:
{
  "hex": "[removed for space]",
  "txid": "3e90870cb2b89307514498d010ee1a1f724ee578859b8f118902db08a45b717f",
  "hash": "3e90870cb2b89307514498d010ee1a1f724ee578859b8f118902db08a45b717f",
  "version": 1,
  "size": 257,
  "vsize": 257,
  "locktime": 0,
  "vin": [
    {
      "txid": "1037821442fe684bd87ad790b4f9fd6a07c3f56ac85478e98e6b06c665eda281",
      "vout": 1,
      "scriptSig": {
        "asm": "3045022100ec9ab3692830627c4f76687d9f2e0fde9fba6f11b6a6025cc7f3c3708be8d8e1022076769507eeb04e867e98e543d54ec8a3c91e17eb4560ff7ab1dd2f40ca7b3d3d[ALL] 023f0aadfeb71a4964c5087fec8b052c8236051dae838d4747543330c6b266ce6e",
        "hex": "483045022100ec9ab3692830627c4f76687d9f2e0fde9fba6f11b6a6025cc7f3c3708be8d8e1022076769507eeb04e867e98e543d54ec8a3c91e17eb4560ff7ab1dd2f40ca7b3d3d0121023f0aadfeb71a4964c5087fec8b052c8236051dae838d4747543330c6b266ce6e"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.00,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_RETURN 6f6d6e6900000000000000030000000000004066",
        "hex": "6a146f6d6e6900000000000000030000000000004066",
        "type": "nulldata"
      }
    },
    {
      "value": 0.00458772,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 a4c3d2d77c214b4e212cdcc0331d21b2fbd6f328 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914a4c3d2d77c214b4e212cdcc0331d21b2fbd6f32888ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1G2CQXJdzzyyUaStUGcsaKLnN5GjD8TeQe"
        ]
      }
    },
    {
      "value": 0.0000273,
      "n": 2,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 88d924f51033b74a895863a5fb57fd545529df7d OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91488d924f51033b74a895863a5fb57fd545529df7d88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1DUb2YYbQA1jjaNYzVXLZ7ZioEhLXtbUru"
        ]
      }
    }
  ],
  "blockhash": "000000000000000000c0fd6a8fee9df17e59c7243c9fce359324ee0fffc70be3",
  "confirmations": 9,
  "time": 1502353358,
  "blocktime": 1502353358
}

The second output of that transaction is:
    {
      "value": 0.00458772,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 a4c3d2d77c214b4e212cdcc0331d21b2fbd6f328 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914a4c3d2d77c214b4e212cdcc0331d21b2fbd6f32888ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1G2CQXJdzzyyUaStUGcsaKLnN5GjD8TeQe"
        ]
      }
    },

Like the previous inputs, we need the hex of the scriptPubKey with its length prepended to it, so our scriptPubKey is
1976a914a4c3d2d77c214b4e212cdcc0331d21b2fbd6f32888ac

Now copy the original, unmodified unsigned transaction. Go to the position where you replaced the scriptSig for this input with 00. Replace that 00 with the scriptPubKey. So now we have a copied unsigned transaction that looks like:
0100000003b0c03779c38ddabc044947b164adbcffde8e0ddb3678494f4e8b83f13b37629d0100000000ffffffff060eeae54b70d12caddcc15f8897ebc2b6c3011c9a600aba74d49b969991cab30000000000ffffffff7f715ba408db0289118f9b8578e54e721f1aee10d09844510793b8b20c87903e010000001976a914a4c3d2d77c214b4e212cdcc0331d21b2fbd6f32888acffffffff02d5781100000000001976a914342ab422c9e3ef285efe9882ae54269ed9713dd688ac20a10700000000001976a91488d924f51033b74a895863a5fb57fd545529df7d88ac0000000001000000

Hash the preimage as you did for inputs 1 and 2. The hash you should get is
b85c3c3b91362e3c8047120152d5d9640a850e1db6d867393ada2e13a6ec079a

Conclusion
The hashes that are signed for each input are as follows:

First input: 0ca51b9a67de27aa35aba665cedea31025f8d40c85669953952b8dcde4242960
Second input: 46016caa2997dc453420a9af5090cd90c5109a93d525bbc3e9e12f8ec0112d58
Third input: b85c3c3b91362e3c8047120152d5d9640a850e1db6d867393ada2e13a6ec079a

I have ran both of these transactions through a modified version of Bitcoin Core that gives me the sighashes.
For d1cdb8c3828ee74c22677e705539937d039e6acef19e5f2ac0a2779846e4b6c1, the sighashes for each input in order are:
36537e9335b00b9627dd067515b85b2dddb3334e946677f5ca01cf07a8de4945
3b10e1e264162eb8fe3011196a756bfea8798775ee5e6c70a107282f74bfd599
fe269a8d6cc3cd801d5c0e0e41c44a32f6fecc0bb7e4909a905e85da43104cf0
166223356d627392d52cd7def6c45a9b7a18bb6cbc628cc1db0db7a1a6c51b19
b42809cd2075ad304fae2205648384b6ac8558dfb17bafc5e2de838af3f5e3bb
d311ba5115ffdce2c73a0e5007b28baa08885cad1a02e719938469fa0e497ccb
43d0509b98408323f6b7ea4ca07d66ad109c647cb9eee413f88464c400371733
6e22e0963dd860525602ad69ab0c9002054588d05c057f51349414ba11f185ab
07f08a0b60a5ebbbe4220e21d912af8c9cbe20f85cfae1cb21171fed8a4b9870
901832f68d7e10e72b57cc029ef161a4044c6fa2633cccf792eccfe34886f075
c5feb7830c2b2f7bd4a604ea3e7497fc8e3e122955c0bf8bd90b7683dc05eee6
f2e29915224de6eec85d7c5fb21e6333dd289b0bb7d07094f0846ca15cab62a1
6ae401edb4c25f7083e59cb0d6145c65d92e749ef93784214aef5e0eba4b38de
2aefa9852164cf75f7a89fd8b0466bb0f49ef2a3bb49243e951611deeafe556d
90698f761a0c6af1de93990e853cf05d760f2c4afce7bf8dc3fa52e8e5ccfa55
f2637c7489c901ce23e133ed252c8084131b8fbeeb604001fda3b2219ed30adc
8430eb0e3576e3a5e376083e7be45725c8a8f6ca3a5d39d97ab13298f82309cf
8da03f6b4f06fb5da308adbad2678f7c6b6ca1bd15bff9accf5dcb404084b214
a2c96c50371204843d9e97848a4afee884f26f3965940db1092bf860736edc11
7f341abb178bac950acd389ce9aa22c8b7bc9982402002f31a5fdbe10db2acff
a6c81aba4d4e08d19f12d02b2651622e5a288f9fac76cb57b930d990a5c18014
d2363eb97fa94ade230a725576a6af91df6c7da516c568195b54d6e3ab7ac97e
570ab2dbb4b4054162617c8c7f95f747a944f39959dc461ce5efce715cac782e
38f638c00eb4f044568ee4d116ebfa9f355cf81ee77237d909d9b0b519edf736
4861a778ad55393bc670e2b73461eedd52d7370b5f86dca2ff319be44bfcb9ea
ea75ff70f64e2a9b2f184c2408c7e28921ddd3c6952f99d193c56134d714839e
ddf948089894409dab74badfcd64055c79b4ba6511b1863eb42bad35bf22d82c
68d4fc82898fae0b41e26affff0fbf37d8c01ecdd416dad299d4fd6837bdddc5
6d5239c61aec375fcf3a13f6ff36660460ebbe49e1372b99cf0ca001381170c8
75bed4705d44d763b9ba59c4a843ba88cc2c58eca1f1c80a683cb02a45052b98
86a6c9a2f5da74825d930d1bf818a9d8bd3f871bc2cb0d71da27940d1d2130cc
9d9537ebb060d5c1bc6c36fd0695833085d753b2860ee3ba9ff65f977b5ab226
f397fea726ddc5a938544283e1dd265aac5ebb8b6856543df48e285f009b4375
120447a585f30f7bb9411f7888b6fcd96862d1cae34ddaadda6291bc46fa36ed
3760ddfd61b0e5f8902195e2b7285da42400446dfd4fcec1ea979ea78c4b32de
271a878980c9087f7004ed21330cd101dd19706513a629eea4cebae9e5e80a56
33c17e7530d3c184acb222165b49155c2a8283032a7ee96ede30546ee571966a
81de851b46bc42b419cdc9905609cc9a4fda206424cbba12626555bf788ba31a
ee864623021df5a2369174f3b8c90f20b6f3021d33f8c9a1ea75698168005626

For ff8766ec873ff55cc0ac17dee7b379a4efa2a5c83dabdd9a30287c7761ad55d5, the sighashes are:
0ca51b9a67de27aa35aba665cedea31025f8d40c85669953952b8dcde4242960
46016caa2997dc453420a9af5090cd90c5109a93d525bbc3e9e12f8ec0112d58
b85c3c3b91362e3c8047120152d5d9640a850e1db6d867393ada2e13a6ec079a

+1 very thorough and well explained answer, you beat me to it ;)

The transaction I used is logically equivalent to the one you chose, it's just much shorter and can actually fit in a stackexchange answer. The JSON of the transaction you chose had too many characters.

Each input corresponds to only one previous transaction output. The addresses don't matter; all you need to look for is the previous transaction specified by the input and then the output index it specifies. Each input is done independently of other inputs, so whatever you do to one input does not carry over for the other inputs. That's why I specify that you copy the original unmodified unsigned transaction. That copy becomes a local copy for that input and is discarded after the input is signed.

Addresses are a human abstraction; they don't matter to transactions at all whatsoever. The only things that matter are previous transaction outputs.

What step is missing? I don't see any missing step.

"Then remove the two characters before the thing you just replaced". I say that right before listing the scriptSigs.

That's all you have to do. However don't carry over anything from any other inputs, so instead of taking the first input's unsigned tx and undoing the things you added, take the original unsigned which has all of the scriptsigs removed and work from there. That way you will be sure that you are not accidentally carrying over any data.

What signature confirmation thing? Does the hash you get match the one I provided?

I got those by modifying Bitcoin Core to print sighashes to my terminal as it verifies signatures. However this is not particularly user friendly and the hashes are actually printed in byte-swapped order (because endianness of internal structures). Furthermore, getting the sighashes of already confirmed transactions requires rewinding the blockchain and then replaying it in order for all of the sighashes to be printed.

The code is here: https://github.com/achow101/bitcoin/tree/give-sighashes You will have to compile it yourself. The txid, input index, and sighash for that input will be printed to stderr. You will need to run this from the terminal.

tyvm again.  Yeah, compiling it will definitely pose a significant challenge, but, just like with this whole thing, perhaps curiosity and a desire to save time will compel me to try it.


text:
What python code is necessary to convert the integers of a bitcoin public key into the proper hex version thereof?
If I get a public key of two integers, x and y values what code is necessary to convert them into their hex versions without any additional letters, or numbers?  This is half a Python programming question and half a bitcoin question though I think it is better asked here due to the familiarity with bitcoin requirements.
Pseudo code:

xpublickey = 20091690549896866803343277351761137627937393619088856147056855893222768847187
ypublickey = 69823032225116710867248379519530157435196049639426167980995931003755153241086
hexpublickey = "04" + hex(xpublickey) + hex(ypublickey)

I don't know what code is necessary to turn it into (as the above code does not work):

042C6B7E6DA7633C8F226891CC7FA8E5EC84F8EACC792A46786EFC869A408D29539A5E6F8DE3F71C0014E8EA71691C7B41F45C083A074FEF7AB5C321753BA2B3FE

y = hex(xPublicKey).rstrip("L").lstrip("0x")
z = hex(yPublicKey).rstrip("L").lstrip("0x")
hexpublickey = "04" + y + z

source: Stack Exchange

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

sort: votes


text:
Is the order of transaction inputs malleable?
I'm looking to track transactions in a non-malleable way. To achieve this I've read the recommendations in this answer, but I don't understand how the order of transaction inputs isn't malleable. It's my understanding that each separate input is signed by the private key it's address is associated with, and thus a malleability attack could just swap the order of inputs and a tracking hash dependent a specific order would be rendered useless. Am I missing something here?

The signature associated with an input doesn't just sign that input, it signs the entire transaction payload - basically every part of the transaction except the signatures themselves. (Technically, it appears to actually sign a hash of a serialized version of the transaction.)
It has to be that way. Otherwise, you could take someone else's signed transaction and modify the outputs to pay it to yourself instead of the intended recipient.
So if you modify the order of the inputs, you modify the signed payload. The signatures will no longer verify and the modified transaction will not be accepted as valid by anyone.
The malleable transaction attack worked by modifying the signature itself to a different but still valid alternate version. The payload of the transaction never changed.

Do you mind elaborating on the last paragraph?

@Pacerier: Unfortunately I am not familiar with the precise details as to how the modified signature works.  If I figure it out I will try to update my answer.

I have a feeling you are missing the index.
Each input is actually a transaction output from a previous transaction. The whole previous transaction is identified by the transaction hash, however the previous transaction can be paying to one or more addresses. Usually you control at least one of those addresses and so when you make a payment your software is

identifying the (hopefully already confirmed) transaction
identifying the index of the payment (ie your address) which you will use coins from

Point 2 is not malleable, the index is specific to the previous transaction. However you are able to compile your payment transaction in any order you choose, before it gets signed, and becomes your output.
This has nothing to do with the transaction malleability issue though.

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


text:
What happens if a Lightning channel close transaction is evicted from the mempool?
I recently had a cooperative close of a Lightning channel and the two Lightning nodes agreed a fee rate of about 1 sat/vbyte for the closing transaction. (This was fine by me; I always like to keep fees low and was/am in no rush.) The transaction was evicted from my Bitcoin node's mempool a few hours later because of the recent high volume.
The transaction subsequently reappeared in my Bitcoin node's mempool. That's good, but how did it get there? I can't see anything obvious in my Lightning node's logs about observing the transaction to have been evicted, resubmitting it or noticing that the Lightning peer had resubmitted it, but maybe I just don't know what to look for.
Is the behaviour in this situation standardised? If not, how do the different Lightning implementations (particularly lnd and Core Lightning) behave?
Out of paranoia I manually saved a copy of the transaction so I could resubmit it if it got completely lost; was there any need for me to do that?
(I've edited the question in light of Mark's comment and to make explicit whether I'm referring to Bitcoin or Lightning nodes.)

There is no "the mempool". Every node has it's own mempool and chooses its own policy.

Thanks Mark, that makes sense. The transaction did disappear from my node's mempool and reappeared later on. So one possibility is that some other node (e.g. with a much larger max mempool size) still had my transaction in its mempool, keeping it alive until it could spread across the network to nodes with the default mempool limit later on - is that right?

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


text:
Can an attacker flood the Bitcoin network with fake transactions?
We are in 2050. People show an ever-growing distrust in the global banking system and start transitioning to only using Bitcoin: most companies accept it as a form of payment, and people settle their bills with Bitcoin. Even the kid with the lemonade stand down the road accepts Bitcoin as her payment.
Banks are worried because they are losing customers and revenue. Legislation has not managed to protect banks and the smaller ones have already started to shut down or provide alternative services.
Then, the CEOs of Atlantis Bank and River Banks, who are the only healthy banks remaining come up with a plan:
A transaction's hash can easily be checked. Why not attack the Bitcoin network with an insurmountable number of fake transactions! We will produce so much noise, and the network nodes will be occupied with checking our fake transactions instead of the real ones, so much so, that a considerable fraction of the total network computing power will be devoted to checking fake hashes. Real transaction verification will come to a halt, and people won't be able to do any everyday trade. They will only be left with one option: return back to us.
Here is my thinking:

Bitcoin's blockchain is increasing in size.
More nodes are added to the Bitcoin network.
Nodes are getting faster.

I expect this to have an overall quadratic effect (in the best-case scenario) in this attack: it will be cheaper for the attacker to generate and submit fake transactions, but it will also be cheaper for the network to reject the fake transactions. BUT the blockchain is increasing in size so at some point the network will be at disadvantage.
Here are some back-of-the-envelope calculations I made, assuming a constant blockchain size of 15 GB:

SHA256 efficiency with today's processors: 45 cycles/byte;
So a chain of size 350 GB, requires 1.6e+13 cycles to be rejected as fake.
With 1 core syncing at 3.5 GHz, this will take 4500 s (1.25 hr).

Are my premises wrong? Won't there be a turning point, when the cost of the largest banks losing customers will be greater than the cost of them launching such an attack (in full secrecy)? How can the network defend itself against these attacks? Sure, one can always add more nodes to the network increasing the fee, but won't that also turn customers back to the banks (i.e. rendering the attack successful)?

Does this answer your question? How does the Bitcoin network deal with bad actors?

It does not, in my scenario, the attacker doesn't spend any time calculating the hash of the block; they just produce random blocks and hashes. This will take an extremely small amount of time while checking the hash will take some time (small but significant).

I was thinking of the answer which points out "The corrupt miner will ... find itself quickly blacklisted and ignored" - that blacklisting would apply.

This fact I didn't know of also kind of answers my question. Thanks for helping out!

Does this answer your question? Why is there no such thing as a redirected, forged, or fake transaction?

It seems like one of the basic assumptions you are making is that all transactions ("fake" or not) are added to the blockchain. But that is not the case. Only valid transactions can be included in a block and thus added to the blockchain. So even if some bad actor spams invalid transactions, these won't get added to the blockchain and force new nodes to sync them.
Furthermore, nodes will only relay blocks and transactions that are valid. If they are invalid, then they will not be forwarded on to the node's peers. Additionally, nodes have local Denial of Service protections. If a particular node is sending multiple invalid transactions and blocks, then the node will disconnect them and even refuse to accept a connection from/to that node (aka the malicious node is banned by the local node).
So a bad actor could make nodes that connect to many other nodes and try to spam them, but they will find themselves quickly peerless as everyone disconnects and bans them. Of course the way around this would be to change their IP address, but this means they constantly have to do that, just in order to get disconnected and banned. It would be essentially impossible to maintain a sustained attack on the network in this manner.
Lastly, the bad actor would only be able to do this to nodes that accept incoming connections. Nodes that only make outgoing connections would be unlikely to connect to the bad actors nodes, at least after they have changed their IP address once. This is because nodes that only make outbound connections only connect to nodes that are considered "good", which includes things like long uptime. So the bad actor would have to maintain a node for a while (so it has a long uptime) in order to get incoming connections from outbound only nodes. But once they start spamming, they get disconnected and banned as they would for nodes that accept incoming connections. From that point on, nodes will not make outbound connections to it because it has misbehaved or because it has changed IP addresses and the new IP address does not have a long uptime.

I see. This is in line with @RedGrittyBrick's comment. I guess what I was looking for was for the network to have a reliable way to turn down such an attack which is the quick denial of service so that an attack cannot be sustained. Thanks a lot! I'm accepting your answer.

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


text:
Can a mobile be protected against the "Linode problem"?
The "Linode problem" I'm referring to is where an external trusted party has administrative control over your device.
Mobile phones are essentially managed devices.  They can be fully controlled by someone other than the owner of the device.
Yes, they are managed by the carrier but possibly that carrier has people that cannot be trusted or, something just as bad, has people who don't maintain secure systems themselves such as what reportedly is what happened at Linode.
The importance is this.  Consider Safaricom's M-Pesa mobile payments system used widely by those in Kenya.
An attack that defrauds M-Pesa's users en mass means that at some point Safaricom figures out that there's a problem, halts all affected systems to prevent further losses, and in the end eats some, most or all of the customer's losses.
With a mobile app like BitcoinSpinner, or My Wallet from BlockChain.info or even a hosted service like Paytunia's online wallet, the risks are quite different from M-Pesa's.  The carrier doesn't promote the Bitcoin app nor offer any guarantees.  A similar attack through the managed services of the mobile carrier's network to steal bitcoins from mobiles would cause the finanical losses to afflict the individual mobile user alone.
Just like how Linode disavowed any responsibility to Slush, Bitcoinica, etc. for the tens of thousands of bitcoins lost, carriers such as AT&T, Vodafone and Safaricom would likely maintain the same type of position.
So, this is a fundamental question -- is the practice of storing bitcoin private keys on the mobile something that exposes it to so much risk that it shouldn't even be considered (at least, not for amounts greater than the amount of cash one might carry in a back pocket?)
Or are there ways to secure a mobile device so that even if some piece of malware is deployed by a carrier's rogue employee that the bitcoins would still be secure?

This is actually a wider concern than something affecting just mobiles.  A PC that is managed by a corporation's sysadmin could have this same "Linode problem".

Here's an example posing the risk: "I found that the company I work for is putting a backdoor into mobile phones": http://security.stackexchange.com/questions/15076

More backdooring ... Samsung Galaxy backdoor.

If your private key is compromised your coins are gone
So the short answer is that the "Linode problem" where your entire private key is at the mercy of a third-party capable of root access to your system is somewhat intractable. As others have stated you can limit your key's exposure, but malware is patient.
Off topic, but possibly of interest, is a project by the MultiBit team to use a HP50G scientific calculator as an item of trusted hardware capable of signing transactions. Not much use out in the field like a mobile would be, but handy for a small business reconciling small volumes of transactions.

Assuming you want an app which is secure, but presumes that:

the mobile is completely compromised;
the private key has a strong password;
there is a backup of the private key.

A form of two-factor authentication, perhaps through bluetooth on another device, may be able to provide enough security for most use cases and most current bitcoin demographics.  Still, that would of course bring the usual trade-off of bringing additional overhead to user experience.

The answer to that depends on the scope of what the malware can do. Assuming the whole device is compromised, exposing all of our stored data as well as everything we do on it, storing your wallet on a mobile phone will result in your coins being stolen sooner or later.
If your coins are store in an encrypted wallet, the malware just has to wait until you input your password to decrypt your keys and your money is lost. If your wallet is unencrypted, it's all the easier.
One could, however, still use an eWallet semi-securely if some additional measures are taken. If the service provider would provide one-time passwords that are not time-synchronised, the system could either allow for somewhat safe Bitcoin usage, or at least detecting that your system is compromised. This is how it would work:
Lets say you have a set of one time passwords numbered 1-10, and you alreay used numbers 1, 2 and 3. You log into your eWallet with your mobile phone, compromising your password, but every important action on the website requires one of the otps to be used. Should the malware try to change anything, it would use up password 4 attempt, and when you'd want to do something, you'd be prompted for password 5. Seeing that you haven't used number 4, you could suspect compromise.
If the malware didn't act, you could try sending a Transaction and inputting an otp, and the malware could either stop you from doing that, or perform a sort of double-spend by trying to execute a second Transaction from your eWallet in the background. If the request for a Transaction came after yours, it would not work, as it would require password 5 which you will not input, as you'd use password 4.
Depending on the sophistication of the malware, it is possible to develop a very specific malware that would execute its own transaction instead of yours, spoofing the website form for your inputs and tricking you into inputting the correct password for its use.
All in all, if your system is compromised, coins stored on it are as good as gone once you input the password to decrypt them. If they are stored online, there are measures to prevent their theft, but there are workarounds.

And as a side note, Gavin wrote awhile back on his Blog:
"If your computer is infected, then it cannot be trusted, and there is no software in the world that can keep your bitcoins safe if they are stored on it."
http://gavinthink.blogspot.com/2011/06/why-arent-bitcoin-wallets-encrypted.html

Generally, application updates do not occur automatically.  As a result protection from a wallet-stealing compromise, for instance, can come from not installing updates until after most everyone else has already upgraded.
This delay won't protect if you do installed it eventually but the likelihood would be that others would experience a problem before you've even installed the update.

Stephen, I would add to what the user linhares answered earlier to your question. Indeed, a two-devices solution would clear the air and in the same time will mitigate the wrongdoings of the staff of the mobile software manufacturer (I'd refer here only to Samsung as you did, too), or even of a possible malware infecting your smartphone. A wearable wallet, like the one suggested by Accelabyte, could be a future solution, when fully developed and released. On one hand, the part of software installed in the smartwatch, connected only by BLE, and controlled exclusively from the "watch side" of the duo, could execute the decryption of keys, issue the raw transactions and then eventually only broadcast them, signed, through bluetooth toward the other end (a smartphone connected to the internet). Each end of the BLE connection would play its separate role, as time as even the barcode requested in order to know the address of recipient can be scanned with the watch camera, too. The major drawback occurred in the process was the update of Gear from Android to Tizen, instead, which changed the established playground of Android with the less mature (and secure) one of Tizen. The second one was the update to KitKat, which affected for unsuspecting users (I would say then the majority of bitcoin users) the feature offered by App Ops application (now working only for rooted smartphones), namely the option of blocking these endless and nasty privileges asked by almost any new app installed from Google play. Both those shelved the Accela's project for a quite long time, as I've heard from someone familiar with the matter. For short, the data container created by Accela would effectively insulate the processes used in spending the coins (think of kinda Knox features, which work separately from the main "Home" apps and data flow inside the same smartphone). Ironically, the most detested version of Gear would be the most fit in order to be used as an almost perfectly secure mobile wallet (no internet, no Tizen, no sim card and also few other special advantages which better to be kept from the public). So, the answer to the question could be Yes -- for people less than paranoid :) --, but difficult to achieve, because bitcoin world is still in its infancy.

Not unless it is open source.
Check out http://replicant.us (Free / Open Source Android)

Did you mean to make two answers?


text:
If Bitcoin is ratified as a currency would its code be BTC?
At present it seems that the de facto code for bitcoins seems to be BTC. There has been some discussion of this over on the forums and an entry on Wikipedia, but I thought I'd ask the question here to arrive at an easily recognised community answer.
So, if bitcoins ever became ratified as a currency under ISO 4217 (paywall, PDF) would it be given the code BTC? If not, then what other serious contenders are there?

The normal rule is (two letter country code) + (letter), although that's arguably already been broken by the Euro having EUR instead of EUE.
BT is the country code of Bhutan, whose currency has the code BTN. If anyone will object to BTC for Bitcoin, it'll be them.
According to wikipedia, which is never wrong, multi-national currencies use the X prefix. XBC is taken by "European Unit of Account 9", but XBI is available.
http://en.wikipedia.org/wiki/ISO_4217


text:
JSON RPC: Fatal error: Uncaught exception 'Exception' with message 'Request error: Array'
I run a small exchange, and we are having a  problem with the DIMECOIN wallet. when sending amounts over 1 million coins. we get the following message when error reporting turned on. I can't for the life of me determine what the error is.
Fatal error: Uncaught exception 'Exception' with message 'Request error: Array'
stack trace: #0 ../class.wallet.php(36): jsonRPCClient-     >__call('sendtoaddress', Array)
#1 ../class.wallet.php(36): jsonRPCClient->sendtoaddress('7EFMZkPb6sHhKgk...', 69986000) #2
../withdrawalqueue.php(128): Wallet->Withdraw('7EFMZkPb6sHhKgk...', '69986000', '1', 'DIME') #3 ../index.php(334): include('..') #4 {main} thrown in ../jsonRPCClient.php on line

Here is my code:
if ($total > 1000000) {
        return $this->Client->sendtoaddress($address, (double)round($total, 2));
}
elseif($total > 10000000) {
        $amt2s = $total * .1;
        $i = 0;
        do{
            return $this->Client->sendtoaddress($address, round($amt2s));
            $i++
        }
        while($i < 10);

}else{
        return $this->Client->sendtoaddress($address, (double)sprintf("%.8f", $total));
    }

help! i'm having the problem again. i'll update the question now.

After investigating, it turns out that the problem lies with the dimecoin wallets in built max money variable, which is capped at 10 million. as you may know, this functionality only affects the maximum size of a transaction, not the actual money supply.


text:
Coin address generation for all coins
We are developing UI for coin trading. We have a plan to use  all the coins present in coinmarketcap. I am greatly confused how to generate coin address for all coins. I knew that from cryptsy.com, it is possible to generate address for all coins from bitcoin but I don't know how to implement it. Is there any easiest way to generate coin address for all coins or can anybody tell how cryptsy do this for all coins? We are doing this in Ruby. Can you please suggest some more ideas to implement this. Any help is appreciated.

Look up vanitygen and how to use it for altcoins; that should give you an idea

The following is not language specific, also a similiar process for most altcoins. Read up on it's key differences or even look at the source code of the altcoin. https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses

I Think there is some confusion here regarding the generating of new address's within a wallet and the generation of Vanity Address's. Based on

Is there any easiest way to generate coin address for all coins or can anybody tell how cryptsy do this for all coins?

I Believe what you are asking is how can you setup a system which enables users to have address's for all the different alt-coins.  This being the case you cannot do this using JUST the bitcoin software, you would need a copy of the client software for each coin you would like to generate address's for.  Then assuming you are trying to setup a Cryptocoin trading exchange similar to Cryptsy then from within the balances page (using Cryptsy as the example) when you click on a currency here and go to "Deposit / Autosell "  It then has the "Generate New Deposit Address" This will most likely be making a call to the client for the currency you have selected like:
altcoind getnewaddress $cryptsy-username
or something similar obviously altcoind would be amended forthe currency you actually wanted to generate the address for,  and the actual code to make the RPC call will be very differnt from the above, and will vary in different languages.  A good guide on implimenting RPC call's into code can be found here: https://en.bitcoin.it/wiki/API_reference_(JSON-RPC).


text:
Automatic transfer of funds between exchanges
I need to circulate money between exchanges automatically. I want to transfer cryptocurrency (BTC, LTC) between exchanges. I find that these exchanges have API calls for withdrawal options: Cryptsy, Poloniex, Bitstamp, Bittrex and Bleutrade.
Is there any other way to implement this for the exchanges which does not provide withdrawal options via API? I also want to transfer USD between exchanges. Can I implement it programmatically i.e via API?

Heya! Which exchanges do not have APIs for withdraw/deposit options (you'll need deposit too of course, if you want to circle it between exchanges).

Yeah Mathias. I need withdrawal options also

Well, if there are no API options, I think you are very limited (if it's not impossible). USD deposits are manually (afaik) because your bank probably does not support API calls.

@Mathias711 - Do you suggest any ideas to implement this?

I do not know precisely what you want, nor have I the expertise to write a full script (nor the time right now) but you can ask for a deposit address at exchange B and withdraw from exchange A to that address (all from API). That should be a very basic beginning. Then you can extent this by asking the deposit address for exchange C, and withdraw from B to C. Something like that

@Mathias711 - Incase of absence of withdrawal api call what to do? Is there any other solution to do this?

Manually? Nothing else I guess.

@Mathias711 - Yes the same also I feel

It's easy to transfer cryptocurrencies between exchanges, but there is no way to transfer USD without withdrawing to your bank account or some kind of e-wallet first. All exchanges I've seen do not allow withdrawals to third parties.

authors: Вика Николаенко


text:
Creating trade engine steps
How cryptocoin trade engine works?  I want to build a simple trade engine(trading bot) in ruby on rails for cryptocoins. Can anybody lead me through proper steps. I am a newbie to cryptocoins.

@GregHewgill - It is easy to add a comment like this but couldn't get any answer from that

Please do not ask the same questions again, rather improve the first question and vote to reopen it. Your first question was closed as it is unreasonably scoped, so is this one. Perhaps you should try to do some research first in order to be able to ask more targeted questions.


text:
Where to find cryptocoins current price
How can I find API (json data) for cryptocoins current ask/high/low/average price. Is there any website that provides that ticker information for all coins.
For example BTC/LTC ticker info is available in
https://btc-e.com/api/2/ltc_btc/ticker

I use bitcoinwisdom which in the market section has multiple exchange ratios for BTC/LTC/DOGE and for fiat money like USD/EURO/RUB.
Another option is this page in cryptocoincharts which also has many market prices for cryptocurrencies.

CoinGecko has a free and public cryptocurrency API to obtain crypto prices from exchanges. It currently covers over 7000+ coins from 400+ exchanges.
You can fetch individual ticker data for an exchange with this endpoint for example
https://api.coingecko.com/api/v3/exchanges/binance/tickers

Im not able to comment, thats why I am answering it, in addition to reiven's answer. Bitcoinwisdom is indeed a very good site to watch the BTC trend, and you can watch different markets against different currencies. However, there are even more markets you can see. For example the site for the Blackcoin vs Bitcoin market on mintpal is the following. The Dogecoin vs Bitcoin on crypsty is this one.


text:
Multisig signrawtransaction fails
I have 3 private keys (a,b,c) which belong to an address (2 of 3) from which I want to spend funds using RPC commands.
I´ve started with generating the redeemScript using createmultisig() and the pub keys which I have generated from the 3 priv Keys (using bitwasp). As the result returns the correct address this step seems to be correct.
After importing the address to my node and rescanning the blockchain I execute listunspend() to get the unspend outputs for my rawtransaction.
Now I generate the raw tx using
createrawtransaction({txid,vout,scriptPubKey,redeemScript},{address:amount})

Here the result:
020000000195b96fa7fff141564feba34cb669bdeb94953c98ae864465623def3fbe9e9fb10100000000ffffffff01e87a01000000000017a9145766fcbfc6927c0b027e4b4245fffcb1ec16f64b8700000000

Now I start with signing this raw transaction
signrawtransaction(rawtx,{txid,vout,scriptPubKey,redeemScript},privKey1)

The result of this signing process is used for the second step
signrawtransaction(signedrawtx,{txid,vout,scriptPubKey,redeemScript},privKey2)

The first signing step returns "Operation not valid with the current stack size" which, as far as I know is correct if a multisig address is involved and not enough keys have signed the tx.
The second step returns "Signature must be zero for failed CHECK(MULTI)SIG operation" which I don´t understand. What's going wrong here?
Even if I change the used priv keys and use the second or third key for the first signing step and one other for the second the error still persits. Am I missing a thing?

Can you include the scriptPubKey and redeemScript that you are providing?

sure, scriptPubKey a914b6ad52d2de8384b992531c0db16a7caa9637a07d87 and redeemScript 5241040d7670b3744902f837e96e5b1333494f2ff2d7828349c74e0c8fafc527dccf0659cd6caa275aaf104b83257e64ae69dbda9528760ca6cf74739f1f4c828a4c3e410414c9866a2302d74d7d940fa96bcc78792234d4bd1357e75e6107e461f7efe522c3909fb608b6c1e865eed7d5f66b1e41aa9a5245e5d073b0db3e41497bce19644104ab08b5953d7840128ba74db567cbd44470f7b6bd3f559eed9764d25f6c109a28c282f4322483165ea05a0a835afc8879f3aafea411d935e61b0e9d465f7c954053ae

I guess you are on bitcoin client v0.16 (version is 0200000)? createrawtransaction doesn't require scriptPubKey, see (my) post last recently here: bitcoin.stackexchange.com/questions/75931 ...and looking at the createrawtransaction line, it shows usage of previous transaction: B19F9EBE3FEF3D62654486AE983C9594EBBD69B64CA3EB4F5641F1FFA76FB995 - when I look into block explorer, I don't find it (on testnet3)... and the address behind scriptPubkey (32KNsVp616bdKoobZ3L3y4HTyWCypeCD8VrQiGt) has zero funds. Was it funded to spend from? What is the funding tx ID?

you can go "sendtoaddress 32KNsVp616bdKoobZ3L3y4HTyWCypeCD8VrQiGt", then "generate 1" to create a block, then listunspent, to verify. Check the address field, use the displayed tx ID, and create the transaction with the "createrawtransaction" command? You can show each command and result, that helps us to support.


text:
Different balance for same private key using bcoin and copay
I´ve got a copay wallet for test purpose. In there I have used a wallet for quite a while. Now I´ve started to play around with bcoin and wanted to import the wallet from copay to bcoin. therefore I´ve imported the tpriv into bcoin with /wallet/importedDemoWallet:
{
    "witness":false,
    "passphrase":"sample",
    "watchOnly": false,
    "accountKey":"tprvxxxxxxxxxxxxx[...]"
}

Here I´ve got the problem that in bcoin it only shows me a balance around 1.4 tBTC while in the copay wallet it shows 2.4 tBTC. even after a rescan the result does not change. can someone tell me whats wrong here? shouldn´t be the balance in both case the same?
UPDATE:
result from get server info:
    "result": {
        "version": "2.0.0-dev",
        "protocolversion": 70015,
        "walletversion": 0,
        "balance": 0,
        "blocks": 1722115,
        "timeoffset": 0,
        "connections": 12,
        "proxy": "",
        "difficulty": 1,
        "testnet": true,
        "keypoololdest": 0,
        "keypoolsize": 0,
        "unlocked_until": 0,
        "paytxfee": 0.0002,
        "relayfee": 0.00001,
        "errors": ""
    },
    "error": null,
    "id": null
}

There are several factors that could be causing the discrepancy.

Make sure you are running the latest version of bcoin (v2.0.0 was just released)
Make sure your node is fully synced to the testnet blockchain.
Make sure all the transactions in the Copay wallet history are confirmed.

Other possible issues:

Do you make a lot of transactions with this wallet? Like, more than 10 or so in a single block? It's possible you've exceeded the BIP44 lookahead and some manual configuration may be necessary to recover all the transactions (although this particular behavior is usually fixed with an additional rescan)
When you rescan, do you specify a block height to rescan from? Make sure that is low enough to catch your complete transaction history.

Compare the history of the two wallets (https://bcoin.io/api-docs/?shell--cli#get-wallet-tx-history). Can you determine which TXs are missing from the bcoin wallet? It might be helpful for debugging if we can identify a pattern.
If you want more interactive help debugging, you can find the developers on IRC #bcoin or on slack: https://bcoin.io/slack-signup.html

thanks for the hints. besides the history comparisson of the transaction I´ve done/checked all several times. As I use this wallet for testing purpose it might be possible that there are several transactions within the same block.

I´ve started rescans with different height. Also started one now with heigth: 1 which should get all affected addresses, right? Also is there a way to totally drop the wallet or do I have to stop bcoin and drop the wallet files manually? thanks in advance.

Yes rescanning from 0 or 1 should scan the entire blockchain. There are methods in the library to delete a wallet but they are not exposed in the API for obvious reasons. You could remove the directory ~/.bcoin/testnet/wallet and relaunch to generate a new wallet database. You can also just create a new wallet with the API and ignore the old one.

comparing the transactions showed up with some trx not known by bcoin. can those be imported by api in any way or how to update bcoin?

You could try https://bcoin.io/api-docs/#importprunedfunds but I'm more concerned with why bcoin didn't import the tx during the rescan. It could be you have large gaps in the bip44 path, and bcoin is not deriving enough addresses in advance.

I´m confused why they are not imported... here a sample (1. imported, 2. not, 3. imported, 4. not) 2019-02-13T08:39:56.000Z,,,0.01000000,BTC,c1e055df1d09fb2a57a04b60493f3874a2d48eac40cc511d744f53ec9368799c,,, 2019-02-13T08:19:48.000Z,,,0.11430071,BTC,b436c66d6d445352dcc650756656d8582bf2a7b946c2218afc669d73d44099ff,,, 2019-02-12T07:39:14.000Z,,,0.01000000,BTC,abeb2f54429f26a004162f5206d666dcc423c660f669f37225fab0b98c80f311,,, 2019-02-12T07:39:14.000Z,,,0.01000000,BTC,d23cc9771182248548b9023a9c855fdea7c3c700d2813e9d78c023f9462972f5,,,

221/305 trx unknown by bcoin.

Change this value to 1000 and rescan again: https://github.com/bcoin-org/bcoin/blob/master/lib/wallet/account.js#L54

does not bring the expected result. is there any way to check the status of the node? I´m currently using https://bcoin.io/api-docs/#get-server-info but this gives me only a limited result, and not the full dataset like in the documentation:(see OP)

Use the HTTP API getinfo (the call you actually linked to in this last comment) instead of the RPC call. But your node looks synced. Please join us on slack or IRC so we can chat and debug more, I think this is getting a little too long for SE.


text:
Allowing bitcoind startup script to access daemon commands
I'm trying to create multiple full nodes on a single machine each using a different data directory and static ip's.
My directory layout is

~/bitcoin1
~/bitcoin2
~/bitcoin3

For each direcotry I have a bash script named btc(number) with this:

!/bin/bash
~/bitcoin1/bitcoind -conf=~/bitcoin1/.bitcoin/bitcoin.conf

With the config files respectively stating the data directories and parameters.
My issue is whenever I try to run a command like "Getinfo", I have to pass the whole config file argument to the daemon like so:

~/bitcoin1/bitcoind -conf=~/bitcoin1/.bitcoin/bitcoin.conf getinfo

How can I make my start up bash script allow the daemon commands as well?
I'd like to achieve this:

~/bitcoin1/./btc1 getinfo
or btc1 stop

Thanks!
P.S. Sorry for the formatting. Never posted here before...

Add $1 to the end of the command in your script. This is more a general scripting question. Doesn't have much to do with bitcoin.
~/bitcoin1/bitcoind -conf=~/bitcoin1/.bitcoin/bitcoin.conf $1


text:
Why doesn't bitcoin place additional constraints on competing block chain forks, other than length of chain? (e.g., time and confirmation count)
In Bitcoin's proof-of-work system, consensus on which chain of blocks should be considered the "true" block chain is based only(?) on which chain is longer.
Accordingly, to quote a nicely written answer by Nate Eldredge, a typical 51% attack would look like this:

Attacker privately starts mining their own chain, which diverges from the main chain at some block N.
Attacker deposits coins to your business, sending them from address A. Call this transaction X.
Attacker inserts in his own chain a transaction X' which conflicts with X; typically X' sends the coins from address A to another address belonging to the attacker.
Attacker waits for several confirmations of transaction X, in blocks N+1, ..., N+6 (replace 6 with however many confirmations your business wants) of the main chain.
Once there have been enough confirmations to satisfy you, you deliver goods or services to attacker.
Attacker releases his own chain, which now has blocks up to, say, N+50. Being longer, this chain is accepted by the network. This chain doesn't contain the transaction X but instead X', so you don't have the coins you thought you did.

Notice that up until Step 6, everything on the network looks completely normal; only the attacker knows what is going on.

My question then is: why doesn't bitcoin specify a maximum duration of time and/or a maximum number of confirmations, after which a competing/forking block is rejected even if it's backed by a longer chain of (secretly premined) child blocks?
To summarize this idea in pseudocode:
CUTOFF_TIME = 1200 # seconds
CUTOFF_CONFIRMATIONS = 3

is_acceptable_block(new_block, parent_block):
    if not is_valid_block(new_block):
        return false

    if is_first_child(new_block, parent_block):
        return true

    old_block = get_first_child(parent_block)

    if age_difference(new_block, old_block) > CUTOFF_TIME:
        return false

    if child_chain_length(old_block) > CUTOFF_CONFIRMATIONS:
        return false

    return child_chain_length(new_block) > child_chain_length(old_block)

If this would be viable, then the 51% attack scenario described above would become much harder; and as a result, the amount of time/confirmations to wait for before a transaction can be safely believed would decrease, right?

My question then is: why doesn't bitcoin specify a maximum duration of time and/or a maximum number of confirmations, after which a competing/forking block is rejected even if it's backed by a longer chain of (secretly premined) child blocks?

Because you can't prove that to nodes that weren't on the network at the time of the attack. Which means that either:

It's possible for an attacker to create a new chain, and if enough nodes join the network while the new chain is the best one, it will lead to a situation where half of the nodes believe that one chain is the best, and half think the other chain is the best.
If you make new nodes trust old nodes when they say that the best chain isn't the real chain, you're now expanding the circle of people you trust to the people relaying the chain, in addition to the people mining it. Before, if two nodes thought different chains were best, you could download both and say with certainty that one was better than the other. If you implemented this change, you would need to decide which node was more trustworthy.

If this would be viable, then the 51% attack scenario described above would become much harder; and as a result, the amount of time/confirmations to wait for before a transaction can be safely believed would decrease, right?

A 51% attack can double-spend outputs with any number of confirmations. The oft-quoted 6 confirmations figure comes from the Bitcoin paper, where Satoshi calculates that an attacker with 10% of the network hashpower would have less than a 0.1% chance to catch up.

Your first point is a good one. A node would only be able to verify the constraints I suggested if it received block announcements in real time. However, It's not immediately apparent to me that "you're now expanding the circle of people you trust to the people relaying the chain". And by that I mean: aren't you already (in the bitcoin network as it exists today) extending trust to relaying nodes anyway? I thought that this trust issue already existed, but that it poses no problem given the incentives of nodes to keep the network as a whole in a healthy state.

Also, I'm not sure what your 2nd paragraph is supposed to refute about the sentence of mine you quoted. Either way your answer as it stands is much appreciated though. :)

@Will aren't you already extending trust to relaying nodes Very little. They can avoid telling you about blocks, but as soon as you connect to one node that isn't cooperating in the embargo, you'll download the best chain.

First, a quick clarification: assuming two chains both have valid blocks, it's the chain with the most proof of work that wins, not necessarily the chain with the most blocks.
Second, thanks for the psuedocode.  It's always nice answering a question written in clear code.
The answer is that we want nodes to be able to agree on the best block chain based entirely on the data in the block chain.  That is, there should be no external state.
Why?  Because different nodes might have different external state.  Let's say an attacker manages to partition the network so that everyone in Europe is working on one chain and everyone in North America is working on a different chain:
        /--> C  -> D  -> E  -> F  -> G  Europe Chain
A -> B -
        \--> C` -> D` -> E` -> F`       North America Chain

Because these two forks are more than 3 blocks different, even when full networking is restored, your code prevents nodes and miners in North America from switching over to the stronger European chain---meaning the network will remained forked forever.
I find it useful to always ask myself, "how will new nodes that are downloading the block chain for the first time come to consensus with currently active nodes in a trustless manner?"

Is your first statement really true?  Not how I understood it ... I understood that if there are two equal length blocks that two miners solve at the same time, then it forks, until the next block is solved, and the longest is the winner, so temporary forks are something that can happen and is expected, but the odds of the fork happening is very low, and exponentially lower chance them both co-existing for every block added.

Proof of work is calculated based on the target difficulty, not the header hash.  (Of course, the hash must be <= the target for the block to be valid.)  That means two blocks with the same parent will have the same proof of work, unless they're at a difficulty change boundary.  If we didn't have difficulty changes, it would be correct to say the longest fork wins.  As you say, accidental forks are fairly common but long accidental forks (>2 blocks) are extremely rare.

Good point about nodes only being able to verify the constraints I suggested if it received block announcements in real time (in contrast to when downloading the chain afterward). Also, good point about difficulty changes, so +1 to this answer too.

@DavidA.Harding: Wouldn't even at a difficulty change boundary two blocks of the same height with a common parent have the same target? I think you would need to have a fork of at least two blocks length to have blocks at the same height with different targets.

@Murch er, you are correct.  I guess I didn't think that one through well enough.  Thanks!

This sort of exists with checkpoints.  The Bitcoin Core source contains a list of hashes of blocks at particular heights, and the standard client will refuse any chain that doesn't contain those blocks at those heights, so it won't accept a fork that diverges before the latest checkpoint.  Periodically the Bitcoin Core maintainers will add to this list, to include some more relatively recent (but not too recent) blocks.
To get a sense for how recent, the latest checkpoint in the git repository for Bitcoin Core is at height 295000 (mined in April 2014), and the current height is 339431.  So it won't accept any fork that tries to reverse more than 44431 blocks, or about 9 months of work.  Feel better now? :-)

While what you said is true, Bitcoin Core's checkpoints are mainly an artifact of the blocks-first download method employed in the 0.9.x series and before.  With blocks-first, it's easy to feed a new node a valid-but-not-strongest chain with hundreds of gigabytes of useless transactions.  With the new Bitcoin Core 0.10.0 headers-first method, that's no longer an issue and checkpoints aren't so important.  It might even be possible to replace them with a chain-agnostic total-proof-of-work (chainwork) check.

@DavidA.Harding, The checkpoints also serve to speed up signature verification (as scripts before the last checkpoint are not checked). Even with headers-first synchronization, the checkpoints are still useful to determine when to skip signature checking.


text:
Why .bitcoin is at /root in Arch/Manjaro Linux?
I've installed bitcoin-core and downloaded the blockchain in Ubuntu. Now that I have switched to Manjaro Linux and installed bitcoin-core again, It creates the .bitcoin directory in /root/.bitcoin/ and tries to read the bitcoin.conf in that location whilst I put my .bitcoin directory backup at /home/user/.bitcoin/.
It is important for me to have the blockchain data at my /home because of the lack of free space in my /root
I also found this configuration, But I'm not sure whether it has anything to do with my problem or how to use it

And here are the commands that I used to install the bitcoin-core

And here are the first bitcoind execute messages

I use Arch linux and had a similar issue. Why bitcoin by default download blockchain to the root folder? I don't know - this is just system default setting. Many applications which require considerable disk space (like databases) usually place data to /opt, /var or /srv or other root subfolder. Taking into account that typical linux setup has 10-20 GB for root folder which is not sufficient to keep large databases, such setup with default settings does not work, so applications like bitcoind (300 GB and more for full node) require manual configuration anyway.
You can fix your problem in a following way (depending on how you start bitcoind). If you start it manually by typing command in shell (which is reasonable assumption because you seem to compile bitcoind from source, not using distro package), then you should add '-datadir' and '-conf' parameters when start bitcoind (you can write simple bash script starting bitcoind with correct parameters). Datadir parameter should point to '.bitcoind' folder in home user directory. The conf parameter should point to bitcoind configuration file which may be default /etc/bitcoin/bitcoin.conf or somewhere else. Editing this configuration file is needed to specify several bitcoind options like rpc login (for bitcoin-cli to connect to server), txindex, etc.
If you start bitcoind as a systemd service, then you should override default systemd service file settings. For example, in Arch linux systemd service file (in /usr/lib/systemd/system/) has line 'ExecStart=/usr/bin/bitcoind ... -datadir=/var/lib/bitcoind' which makes bitcoind (launched by systemd) by default read data from /var/lib. You can change this setting by writing simple 5-6 lines 'systemd drop-in override' configuration file which changes this parameter (there are lots of answered questions on other sites about this issue).
Once your start bitcoind manually you should see correct path in its ouput (lines 'Using data directory' and 'Config file').
P.S. There is no Arch/Manjaro distro. They are two different OS.
P.P.S In Arch linux default settings for bitcoind are writing data to /var/lib/ with user permissions 'bitcoin:bitcoin'. I don't know why in Manjaro bitcoind saves data to /root folder. Perhaps you have run bitcoind with sudo?


text:
Translate c++ function into python: sha256 hash mismatch
This is not related to bitcoin but it uses most of the bitcoin codebase. I would like to translate some c++ code into python but struggle really hard to get the hashes right.
This is the function I try go get. Hash is doing a double sha256
uint256 CalcKernelHash(const uint256& stakeModifier, int64_t height, int64_t coinstakeTime, const uint256& masternodeID, const Consensus::Params& params) {
        // Calculate hash
        CDataStream ss(SER_GETHASH, 0);
        ss << stakeModifier << coinstakeTime << GetMnCollateralAmount(int(height)) << masternodeID;
        std::cout << "\n--------------------------------\n";
        std::cout << "DEBUG[" << coinstakeTime << "] collateral: " << GetMnCollateralAmount(int(height)) << "\n";
        std::cout << "DEBUG[" << coinstakeTime << "] ss: " << stakeModifier.ToString() << coinstakeTime << GetMnCollateralAmount(int(height)) << masternodeID.ToString() << "\n";
        std::cout << "DEBUG[" << coinstakeTime << "] HASH: " << Hash(ss.begin(), ss.end()).ToString() << "\n";
        return Hash(ss.begin(), ss.end());
    }

And here it is called
const auto hashProofOfStake = UintToArith256(CalcKernelHash(stakeModifier, height, coinstakeTime, masternodeID, params));

std::cout << "DEBUG[" << coinstakeTime << "] coinstakeTime: " << coinstakeTime << "\n";
std::cout << "DEBUG[" << coinstakeTime << "] nbits: " << nBits << "\n";
std::cout << "DEBUG[" << coinstakeTime << "] hashProofOfStake: " << hashProofOfStake.ToString() << "\n";
std::cout << "DEBUG[" << coinstakeTime << "] stakeModifier: " << stakeModifier.ToString() << "\n";
std::cout << "DEBUG[" << coinstakeTime << "] masternodeId: " << masternodeID.ToString() << "\n";

I have added some debug statement to check the output and have a reference
--------------------------------
DEBUG[1622528110] collateral: 2000000000000
DEBUG[1622528110] ss: f541f372005beeb8952f964ea638527341c3b3a6eebb0c0309e4f092bd6c1b0e16225281102000000000000e2cfe3f576da4999ea2268224f34efdd3b0d567841d561b41b3ab67976c977d1
DEBUG[1622528110] HASH: e4b0d1b01a99d00e44d41eeb37c81d19940bf71270994fff53ea5caa1c79f663
DEBUG[1622528110] coinstakeTime: 1622528110
DEBUG[1622528110] nbits: 419654358
DEBUG[1622528110] hashProofOfStake: e4b0d1b01a99d00e44d41eeb37c81d19940bf71270994fff53ea5caa1c79f663
DEBUG[1622528110] stakeModifier: f541f372005beeb8952f964ea638527341c3b3a6eebb0c0309e4f092bd6c1b0e
DEBUG[1622528110] masternodeId: e2cfe3f576da4999ea2268224f34efdd3b0d567841d561b41b3ab67976c977d1

This is my trial in python
import binascii
import hashlib

def rotate(x):
    s2 = bytearray.fromhex(x)
    s2.reverse()
    return binascii.hexlify(s2).decode()

def padhexa(s):
    return s[2:].zfill(16)

def CalcKernelHash(stakeModifier, coinstakeTime, masternodeId):
    stakeModifier = binascii.unhexlify(stakeModifier)
    coinstakeTime = binascii.unhexlify("%x" % coinstakeTime)
    collateral = binascii.unhexlify("0%x" % 2000000000000)
    masternodeId = binascii.unhexlify(masternodeId)

    bin_s = stakeModifier[::-1] + coinstakeTime[::-1] + collateral[::-1] + masternodeId[::1]
    print(bin_s)
    return rotate(hashlib.sha256(hashlib.sha256(bin_s).digest()).hexdigest())

CalcKernelHash('f541f372005beeb8952f964ea638527341c3b3a6eebb0c0309e4f092bd6c1b0e', 1622528110, 'e2cfe3f576da4999ea2268224f34efdd3b0d567841d561b41b3ab67976c977d1')

When I execute with the parameter from the debug output I get
CalcKernelHash('f541f372005beeb8952f964ea638527341c3b3a6eebb0c0309e4f092bd6c1b0e', 1622528110, 'e2cfe3f576da4999ea2268224f34efdd3b0d567841d561b41b3ab67976c977d1')

'f01ba34ac7a897a1e37d61bac3a8ea6f0126c2ae883a2d75dab1f407d40aad0b'

Where I should get hashProofOfStake e4b0d1b01a99d00e44d41eeb37c81d19940bf71270994fff53ea5caa1c79f663
EDIT:
bin_s returns b'\x0e\x1bl\xbd\x92\xf0\xe4\t\x03\x0c\xbb\xee\xa6\xb3\xc3AsR8\xa6N\x96/\x95\xb8\xee[\x00r\xf3A\xf5n\xd0\xb5`\x00 J\xa9\xd1\x01\xe2\xcf\xe3\xf5v\xdaI\x99\xea"h"O4\xef\xdd;\rVxA\xd5a\xb4\x1b:\xb6yv\xc9w\xd1'
EDIT2:
Hash definition
/** Compute the 256-bit hash of an object. */
template<typename T1>
inline uint256 Hash(const T1 pbegin, const T1 pend)
{
    static const unsigned char pblank[1] = {};
    uint256 result;
    CHash256().Write(pbegin == pend ? pblank : (const unsigned char*)&pbegin[0], (pend - pbegin) * sizeof(pbegin[0]))
              .Finalize((unsigned char*)&result);
    return result;
}

Can you print bin_s in python? The best way to debug hash mismatches is to print full data-to-be-hashes (called preimage)

modified the answer

Hello I almost solved this but one problem: 2000000000000 the collateral value, presumable a byte array in hex, is of odd length????

I think it is the case that the preimage is not printed properly. Can you add for (auto i: ss) std::cout << std::hex << i; as a one-line debugging statement before hash calculation, and add its output here?

It only outputs garbage %�!�c#b"~�|~�tW added also the Hash definition

Ok, can you try printing ss.str()?

similar garbage output.

Can you post GetMnCollateralAmount?

Let us continue this discussion in chat.

def CalcKernelHash(stakeModifier, coinstakeTime, masternodeId):
    stakeModifier = binascii.unhexlify(stakeModifier)
    coinstakeTime = binascii.unhexlify(hex(coinstakeTime)[2:])
    collateral = binascii.unhexlify("0000000000204AA9D1010000")
    masternodeId = binascii.unhexlify(masternodeId)

    bin_s = stakeModifier[::-1] + coinstakeTime[::-1] + collateral[::1] + masternodeId[::-1]
    print(binascii.hexlify(bin_s))
    return rotate(hashlib.sha256(hashlib.sha256(bin_s).digest()).hexdigest())

that is the thing. How do you correctly serialise a string so that it gets to the same result has the uint256 type in c++? The debug output for stakeModifier is the ToString() version of it.

@Chris Can you give me the full python source code for this example with imports so that I can run it? (Full = code that can run, but not the whole source code of the software. For example I need the code that runs this python code)

edited above. All is needed is importing hashlib and binascii


text:
Why is this burn address starting to get confirmations?
Can anyone explain why the burn address
1111111111111111111114oLvT2 started receiving confirmations only on 8th June? 1st transaction is 11yrs?
I thought a burn address doesn't get any confirmations, especially all I checked are through OP_return?

Also, the same address gives an error here:
https://blockchain.com/btc/address/1111111111111111111114oLvT2
.
-I knew that addresses r case sensitive, that's why it originally gave an error, so changed L,T to upper case
-Still don't understand (not convinced with) the confirmations issue, and I think the 2016 Transaction presented in the Comment is from another address (if so, then it's out of my Q context)
-Finally, adding a more curiosity Q from comments to main:
Will all these 133,555 UTXOs (more than 2¹⁷) in this address reside in the system Merkle Tree forever? or  No because they appear in OP_Return ?
The written answer does not answer the main point of the Q:
1-it explains that confirmations are to TXs not addresses, well I know that & my Q was that none of the TXs that transferred money to this address got confirmed before 8/6/2021
2-The answer re explains the fact that this is a burn address because it's from key "0", which means yes it should not get confirmations?
3-Followed the answer is a comment showing a confirmation from 2016 to a completely different address?! which is misleading & does not give an answer?
4-The 2016 Comment was divided into 3 consecutive comments by the same person before me replying, which reached the comments limit and I had to write here with the only other option a private chat with that person????
-To be fair, I gained 2 infos from the answer:
1-Addresses r case sensitive
2-The given address is the hash of public key zero

Base58 addresses are case sensitive and you changed the capitalization: https://www.blockchain.com/btc/address/1111111111111111111114oLvT2. You also answered your own question, the address is a regular address and has nothing to do with OP_RETURN outputs.

Ok, thanks that's part of the Q;  now why the sudden confirmations?

The address is published as a burn address, https://bitcointalk.org/index.php?topic=5342023.msg57185238#msg57185238. and didn't spend anything or got any confirmations even in old TXs until this week 8/6/2021

because somebody sent  to it?

Base58 addresses are case sensitive. With the correct capitalization, the address resolves fine: https://blockchain.com/btc/address/1111111111111111111114oLvT2.
Addresses do not get any confirmations. Confirmations pertain to specific transactions not addresses. When a transaction is included in a block that constitutes the transaction's first confirmation. The transaction's confirmation count increases for every subsequent block thereafter. However, confirmation counts are independent for each transaction, even if they happen to pay to the same address.
The address 1111111111111111111114oLvT2 was first paid to 11 years ago, but has received outputs from a total 96,980 transactions altogether since, with the most recent transaction occurring this week. Your screenshot shows the times of the first and last transactions that involved the address, but the cited information does not indicate that there was no activity between those dates. Other than indicated in comments, none of the address's 133,555 outputs have been spent.

The address 1111111111111111111114oLvT2 encodes the public key hash 0. Given that it was obviously picked via that public key hash, the private key can be presumed to be unknown as it would require someone to break the pre-image resistance of RIPEMD-160 to find a corresponding public key, and then to solve the Elliptic Curve Discrete Logarithm Problem to find the corresponding private key, both of which are considered to be infeasible.

Regarding the follow-ups from the edit:

All discussed transactions involving
1111111111111111111114oLvT2 were sending funds to the address. None of the funds sent to 1111111111111111111114oLvT2 were ever spent.
Yes, all the transaction outputs sent to 1111111111111111111114oLvT2 will remain in the Unspent Transaction Output (UTXO) set forever.
The UTXO set is not a Merkle tree.
Numerous of the transactions sending funds to 1111111111111111111114oLvT2 have more than one output. Some of the other outputs are OP_RETURN outputs. Outputs cannot both be OP_RETURN and send to an address at the same time, it's one or the other.
OP_RETURN outputs are not part of the UTXO set.

Meaning it is a burn address & apparently someone succeeded in finding a private key???? Also, the UTXOs count means this address is holding 131,695 ie more than 2¹⁷ UTXOs at that time?

Huh? The address 1111111111111111111114oLvT2 has been paid to by 96,980 transactions, receiving a total of 133,555 outputs and has never been spent from.

To be honest I still don't understand why only confirmations started to appear this week & not in all the previous 11yrs. However, I got my own confirmation about the idea in here https://bitcoin.stackexchange.com/questions/106957/can-utxos-lifespan-be-predicted, with one address holding more than 2¹⁷ UTXOs that will reside in the Merkle Tree forever something has to be done https://bitcointalk.org/index.php?topic=5343748.0

I don't understand how you got the impression that "only confirmations started to appear this week & not in all the previous 11yrs", that is not an accurate description of what's happening.

Can u show me any confirmations before that?and  I said I honestly don't understand what is exactly happening, even UTXOs maybe not counted in the Merkle Tree as they're in OP_Return

Uhm, I'm a bit puzzled. Are you aware that each box on the blockexplorer address page you linked shows a different transaction? E.g. https://blockchair.com/bitcoin/transaction/a81b3301ce37f60b26aaa12bb5ea6999dc435fafe2dcd9c02685626ca348c602 was included in block 687044, https://blockchair.com/bitcoin/transaction/2c5a268f347ca3b2d39c84b10a209531d110570d5b291fd2da866cb5f2e25d91 was included in 687034.

Here's a tx from 2016: https://blockchair.com/bitcoin/transaction/da9c4273768e70227f4d5889c9281e01e34e888387a0ebfa4ee8cc66954ec3f9


text:
How are Bitcoin generated in Video Games?
There are a lot of video games out there which reward the player in Bitcoins or other cryptocurrencies for winning the game or achieving a specific objective. But from where does those crypto come from?
Do the players act as bitcoin miners while playing the game or is there any other mechanism which generates the bitcoin for the game? How does this work? Is the game itself decentralized or they embed the bitcoin blockchain in it?

These games do not actually generate any Bitcoin. No Bitcoin is being mined in these games; that's not how Bitcoin works.
The Bitcoin comes from the service running the game. They are doing something other than running the game that is earning them Bitcoin. They then use that Bitcoin to give small amounts to their users. The Bitcoin is typically earned thread advertisements that are on the website.

Have you heard of the game MyProfitLand? How does this game give money in good amounts to the players?

It looks like they use microtransactions and charge fees for withdrawal etc. That's how they earn money, and that money in turn can go back to the user. Furthermore, AFAICT, they have effectively peer-to-peer transactions so the money doesn't actually come from the service itself but from other people paying you through their service.