text:
Musig Signature Interactivity
2 Questions:

Why is Musig signing always interactive?
Let's say I have a Musig wallet where keys are stored in secure locations with no internet access. What are some methods to sign from these secure, offline locations given Musig interactivity constraints?

MuSig is interactive because each signer needs to provide a signature nonce (effectively randomness) before signing. This is not specific to MuSig, but applies to any discrete logarithm-based multisignature scheme as far as I know.
Now to understand why multiple communication rounds are necessary let's look at what happens at each of them, starting from the last, the third round:

Round 3 Every participant creates a partial signature with their secret key. The sum of the partial signatures is the final signature. In order to compute the sum the signers must send their partial signatures. That's one communication round.
Round 2 In order to create a partial signature, the signers have to compute the hash of the combined public nonce R. This is the sum of the individual signer's nonces R_i. The nonces are somewhat similar to public keys in that they are random points whose discrete logarithm is unknown to everyone else Broadcasting R_i is another round.
Round 1 The reason for the first round is the most difficult to understand. If the signature hash would just consist of the sum of R_i's then an attacker would have control over the outcome of the hash function. For example, the attacker could first collect every other signers R_i and then choose his R_j such that the hash output is odd. This specific example would not be helpful to the attacker, but what he can also do in a similar way is to mount a Wagner's attack which results in signature forgery. This is why in the first round, the signers send a commitment (for example SHA256(R_i)) of their nonces. Therefore they have to choose their nonce before seeing the other nonces, because they will only be revealed at round 2.

While this is a relatively intricate dance where quite a few things can go wrong, our implementation in libsecp256k1-zkp should be misuse resistant provided that you

Never reuse a session id. The id can be the output of a cryptographic random number generator or an atomic counter.
Never copy a signing session state. Otherwise, nonces will be reused which results in a direct leak of a secret key. Also, it allows active attacks, such as Wagner's attack.

Now it should be easy to see that offline signing is difficult with MuSig. Before shutting down the signing device you need to store active MuSig sessions on a persistent medium. That's effectively a copy of the state and very dangerous. You need to be sure that you load the correct session state when powering up again and not a corrupted or old or wrong session. For that reason, the libsecp256k1-zkp implementation does not support serializing the session state right now. However, there are some ideas for how to design a serialization format that is maximally misuse resistant.
Another aspect is that nonce commitments can be safely "pre-shared" before a message is known. That means that when setting up your offline signing devices, you start multiple sessions in parallel and exchange the nonce commitments. Then, when you want to sign a transaction, you only need to go there twice, first to get the actual nonce and then to get a partial signature. If you have only one device at a remote location you can make it so that you only go there once (by having all other decommitted nonces ready when you go there). It's important to note that as opposed to nonce commitments, nonces can not be pre-shared because that would allow yet another Wagner's attack.
There is research in progress to effectively remove the nonce commitment round and the whole session state with zero knowledge proofs. This is exciting for the offline signing case, but of course also brings increased implementation and computational complexity.

Note that this answer only applies to MuSig and not necessarily the follow-up work that has been published since. The "research in progress" mentioned in the answer is now called "MuSig-DN" (https://eprint.iacr.org/2020/1057). MuSig2 (https://eprint.iacr.org/2020/1261) is a two round protocol that is non-interactive because the first round can be pre-processed.


text:
BIP67 + importmulti + multisig descriptors
I'm trying to setup a Bitcoin Core watch-only wallet using importmulti and a sh(multi(m,xpub1/*,...,xpubn/*)) ranged descriptor, and then use deriveaddresses to get receiving addresses.
Is it possible to import only BIP-67-compliant addresses somehow? With a ranged descriptor I can't manually order the multisig script pubkeys from my side as suggested in this abandoned PR because my client only touches the account xpubs.
I could manually inspect and skip addresses until I get ordered pubkeys, but that's really ugly and fragile.

No, the descriptors language currently doesn't support BIP67.
It would be easy to add a multi_bip67 or so to the language if there is a need for it.

There's a PR for that now: https://github.com/bitcoin/bitcoin/pull/17056

source: Stack Exchange

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

sort: votes


text:
How to import an extended public key into bitcoin core 0.16
I exported an xpub key from a HW wallet and want to import it into my own node to keep track of changes to the balance. My node is running satoshi 0.16.1
Can someone help me find the right syntax for bitcoin-cli, or make a statement about whether it is possible at all to import extended public keys?
Edit: @aantonop seems to state in this video (https://youtu.be/8mpDcBfNA7g) @ 16:55 that this is possible in bitcoin core though I may be getting it wrong and also he isn't omniscient.

It's not possible in bitcoin core right now. You can use electrum and import your xpub as a watch-only wallet.

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


text:
Do Full Nodes validate all transactions and make new blocks after all bitcoin are mined?
Do Full Nodes validate all transactions after all bitcoin are mined?
A fork of bitcoin core with all coins pre mined would be behaving in this way too I'd imagine..?
Also, would these nodes still create blocks of transactions, if so, why dont full nodes do this now? Is mining only a safety mechanism for a permissionless network?
See this quote at the link below:

Blockchain Validation vs Blockchain Consensus
It’s important to note that “validation” and “consensus” aren’t the same thing. A Blockchain Validator performs validation by verifying that transactions are legal (not malicious, double spends etc).
However, Consensus involves determining the ordering of events in the blockchain — and coming to agreement on that order.
Essentially, Consensus involves agreeing on the ordering of validated transactions.
The validation precedes the Consensus. We may very well have something that is “valid” that the network does not “agree” upon.

https://medium.com/hupayx/how-are-blockchain-transactions-validated-consensus-vs-validation-ada9c001fd0a

Please, update the web link, thanks.

was deleted by the looks of it

If you find or know any similar post, please add or replace on your question. It is hard to understand your question without some details.

Have updated, please let me know if you have any other questions about how it all works @CloudCho

Do Full Nodes validate all transactions after all bitcoin are mined?

Yes.

Also, would these nodes still create blocks of transactions

Yes

if so, why dont full nodes do this now?

Do what? Validation? If so, full nodes certainly do validate now. In fact, full nodes validating is what keeps miners in check.

Is mining only a safety mechanism for a permissionless network?

Mining is the mechanism in which the ordering of transactions is determined. It's sole purpose is to dictate which transaction came first in the event of a "double spend" and allow everyone to agree that that transaction was first. It is an integral part of achieving consensus. Mining doesn't actually validate anything; just that whatever goes into a block, and the block itself, must be valid, so miners should be validating incoming transactions before including them in a block.

Oh so MINERS are still needed and are the ones who get rewarded from transaction fees after all bitcoin are mined? So both full nodes and miners are still needed after all mining is done?

Yes. Blocks will continue to need to be mined and verified after the block subsidy ends. Mining never ends, just the supply of newly generated bitcoin.


text:
With MtGox gone, how can I know the current price of a bitcoin?
Firstly, I acknowledge that there is no official bitcoin price and it is market determined, but I have seen various websites quote the current price of bitcoin and so on.
In the past my bitcoin wallet told me the price of a coin making reference to MtGox's index.
Now that MtGox is gone, what are the most reliable resources to obtain both present and past bitcoin prices?
Or are there some credible exchanges that I can use as a reference to compare less credible sellers with?

http://bitcoincharts.com/

I think one of the most accurate is the coindesk bitcoin price index.
It is a mean volume weighted between major exchanges.
UPDATE:
It isn't volume weighted, it's a simple average. For more information read source

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


text:
transaction inputs does not have prev_out field
I found some transaction inputs does not contain prev_out field, i.e. it does not have input address. It only has an output address. Does this mean this kind of transactions records the activities of mining new coins?
e.g.
'tx': [{'hash': '2b1f06c2401d3b49a33c3f5ad5864c0bc70044c4068f9174546f3cfc1887d5ba', 'inputs': [{'script': '04ffff001d0138', 'sequence': 4294967295, 'witness': ''}], 'lock_time': 0, 'out': [{'addr': '1HwmP33SaknLYShXfjVU8KmVThU3JiuVgH', 'n': 0, 'script': '41045e071dedd1ed03721c6e9bba28fc276795421a378637fb41090192bb9f208630dcbac5862a3baeb9df3ca6e4e256b7fd2404824c20198ca1b004ee2197866433ac', 'spent': False, 'tx_index': 15066, 'type': 0, 'value': 5000000000}],

while for another transation:
{'hash': 'ee475443f1fbfff84ffba43ba092a70d291df233bd1428f3d09f7bd1a6054a1f', 'inputs': [{'prev_out': {'addr': '1CfD77hupeUvFwBPxZ2fA8iyWmVwQY22oh', 'n': 1, 'script': '76a9147fe34b97aeff4ab754770be5c8f12e2e95332fd488ac', 'spent': True, 'tx_index': 8845778, 'type': 0, 'value': 10212000000}, 'script': '483045022100e5e4749d539a163039769f52e1ebc8e6f62e39387d61e1a305bd722116cded6c022014924b745dd02194fe6b5cb8ac88ee8e9a2aede89e680dcea6169ea696e24d52012102b4b754609b46b5d09644c2161f1767b72b93847ce8154d795f95d31031a08aa2', 'sequence': 4294967295, 'witness': ''}], ...

the second one has a prev_out field while the first one does not

Transactions without prev_outs are known as coinbase transactions (not to be confused with transactions from the company named Coinbase) or coin generation transactions. They create outputs without needing any inputs to the transaction. Coinbase transactions are special transactions which are created miners and included as the first transaction in a block. They are what pays miners for their work.
There can only be one coinbase transaction per block, and it must be the first transaction of the block. The sum of the outputs must also meet certain constraints: it can be no more than the sum of the block subsidy and the sum of the transaction fees paid by all transactions in the block.

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


text:
Bitcoin-tx sign/redeem p2sh transaction (Unable to sign input, invalid stack size (possibly missing key))
I'm seeking help in redeeming a p2sh transaction using the standard tools from bitcoin core, e.g., bitcoin-cli or using directly the RPC commands via curl would also be fine.
Creating the P2SH address
locking funds in a p2sh address is not the problem I assume, e.g., I handled it that way:
intput
bitcoin-cli -regtest decodescript "935787"

output
{
  "asm": "OP_ADD 7 OP_EQUAL",
  "type": "nonstandard",
  "p2sh": "2N2Mn4F9tUVy9cRTzBQhQTiMpi2Kpwzkyn6"
}

in order to redeem that script I would need two numbers equaling 7 right, e.g.,
1 6
Locking some funding in a p2sh
so let's spend some funds into the p2sh
input
bitcoin-cli -regtest sendtoaddress 2N2Mn4F9tUVy9cRTzBQhQTiMpi2Kpwzkyn6 40

output
5589b316dc210174d988bfab333f93101cea40f5914a1ab833a9bbe56faf55ca```

here is the raw transaction
input
bitcoin-cli --regtest getrawtransaction 5589b316dc210174d988bfab333f93101cea40f5914a1ab833a9bbe56faf55ca

output
0200000001cef241d611112f7f9c98a8e825eb801dad923767126bee7c9ec190950c06ba24000000004847304402202d25bc67043c3cc2ec5fbf6b0bfe7e49b0a5f29e3891f5da005f3350188bc79502202ca014de3b60ede7f3b3bf2080ed33a06c9cb39f588178907f48b09caa0b1bca01feffffff0200286bee0000000017a91463f665a76eef10e84662c82bec9aff641edf42ec8750bb9a3b0000000017a914c12b3404c4e13900c5bfefc886533d7eb59524228766000000

or decoded it is:
{
  "txid": "5589b316dc210174d988bfab333f93101cea40f5914a1ab833a9bbe56faf55ca",
  "hash": "5589b316dc210174d988bfab333f93101cea40f5914a1ab833a9bbe56faf55ca",
  "version": 2,
  "size": 187,
  "vsize": 187,
  "locktime": 102,
  "vin": [
    {
      "txid": "24ba060c9590c19e7cee6b12673792ad1d80eb25e8a8989c7f2f1111d641f2ce",
      "vout": 0,
      "scriptSig": {
        "asm": "304402202d25bc67043c3cc2ec5fbf6b0bfe7e49b0a5f29e3891f5da005f3350188bc79502202ca014de3b60ede7f3b3bf2080ed33a06c9cb39f588178907f48b09caa0b1bca[ALL]",
        "hex": "47304402202d25bc67043c3cc2ec5fbf6b0bfe7e49b0a5f29e3891f5da005f3350188bc79502202ca014de3b60ede7f3b3bf2080ed33a06c9cb39f588178907f48b09caa0b1bca01"
      },
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 40.00000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 63f665a76eef10e84662c82bec9aff641edf42ec OP_EQUAL",
        "hex": "a91463f665a76eef10e84662c82bec9aff641edf42ec87",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "2N2Mn4F9tUVy9cRTzBQhQTiMpi2Kpwzkyn6"
        ]
      }
    },
    {
      "value": 9.99996240,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_HASH160 c12b3404c4e13900c5bfefc886533d7eb5952422 OP_EQUAL",
        "hex": "a914c12b3404c4e13900c5bfefc886533d7eb595242287",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "2NArcA7oJfBkH6ZWBfh2TaTQkvKYMoK9xhd"
        ]
      }
    }
  ]
}

Creating a new UTXO spending from that p2sh transaction
now I want to redeem that tx, so first create a raw transaction with the old tx as input
input
bitcoin-cli -regtest createrawtransaction "[{\"txid\":\"5589b316dc210174d988bfab333f93101cea40f5914a1ab833a9bbe56faf55ca\",\"vout\":0}]" "{\"2NACSKxqUhLRHTwaSN3xaJpti6BEPyDFSUJ\":39}"

output
0200000001ca55af6fe5bba933b81a4a91f540ea1c10933f33abbf88d9740121dc16b389550000000000ffffffff01004775e80000000017a914b9f330d64c88295017c651d2117785f212cb59938700000000

Signing that UTXO to redeem it
and I figure in the next step I assume I'd have to sign the transaction using the redeemScript, i.e., the redeemScript is:
515603935787
which is the hex form of:
1 6 PUSH 935787
I tried to sign the tx using:
input
bitcoin-cli -regtest signrawtransaction "0200000001ca55af6fe5bba933b81a4a91f540ea1c10933f33abbf88d9740121dc16b389550000000000ffffffff01004775e80000000017a914b9f330d64c88295017c651d2117785f212cb59938700000000" "[{\"txid\":\"5589b316dc210174d988bfab333f93101cea40f5914a1ab833a9bbe56faf55ca\",\"vout\":0,\"scriptPubKey\":\"a91463f665a76eef10e84662c82bec9aff641edf42ec87\",\"redeemscript\":\"515603935787\"}]"

Output
{
  "hex": "0200000001ca55af6fe5bba933b81a4a91f540ea1c10933f33abbf88d9740121dc16b389550000000000ffffffff01004775e80000000017a914b9f330d64c88295017c651d2117785f212cb59938700000000",
  "complete": false,
  "errors": [
    {
      "txid": "5589b316dc210174d988bfab333f93101cea40f5914a1ab833a9bbe56faf55ca",
      "vout": 0,
      "witness": [
      ],
      "scriptSig": "",
      "sequence": 4294967295,
      "error": "Unable to sign input, invalid stack size (possibly missing key)"
    }
  ]
}

and that's where I don't know any further.
I always get the error Unable to sign input, invalid stack size (possibly missing key) any idea what I am missing?
kind regards,
Jagoda
note: I already had a look at various links here on stackexchange/stackoverflow and the official developer wiki but couldn't find an easy to follow tutorial.
Tutorials I had a look at which might be useful for future references:

2 out of 3 multi sig (outdated)
p2sh step by step example
sign raw transaction

i'm in the exact same boat as you (i ended up executing the same commands you did and getting the same result). how did you end up solving for it?

You cannot use Bitcoin Core to create your transaction because it does not know what to do with non-standard inputs. There is no need to use signrawtransaction because you are not signing anything. In order to make your transaction spendable, you will need to do it manually by inserting the scriptSig that you figured out yourself.

signrawtransaction is deprecated at bitcoin core 0.21

You do not need to sign transaction because your redeemScript "OP_ADD 7 OP_EQUAL" does not contain OP_CHECKSIG* operations
Just fill the scriptSig
0200000001ca55af6fe5bba933b81a4a91f540ea1c10933f33abbf88d9740121dc16b389550000000006515603935787ffffffff01004775e80000000017a914b9f330d64c88295017c651d2117785f212cb59938700000000

that would work, but is that the preferred way of doing so, or differently asked, is there a way using bitcoin-cli to fill the scriptSig?

Bitcoin Core can't sign arbitrary scripts. You need to fill in the data yourself.

That produces scary errors and says that it's not complete. This is all correct. You can see that the signature has been partially successfully because the hex has gotten longer. Though the transaction has been partially signed, it's not done because it needs more signatures.

M-of-N vs N-of-N: Obviously, if you have an n-of-n signature (like the 2-of-2 multisignature), then everyone has to sign, but if you have a m-of-n multisignature where m < n, then the signature will be complete when only some (m) of the signers have signed.


text:
Litecoin - same transaction hash and block hash
After building litecoin v0.15.1rc1 client on Ubuntu 16.04 I wanted to build an app that uses Litecoin. But I stumbled upon something odd (at least to me).
I did the following command: ./litecoin-cli getrawtransaction 716aba3806b7737f5152af0079c73d20b924a4c1b679026feac42205e06d9f5b 1
I saw that transaction hash and block hash are absolutely the same. Can someone explain this? I can paste the whole output if requested.
Thank you in advance!
EDIT: this transaction is a testnet transaction
Full output:
{
  "txid": "716aba3806b7737f5152af0079c73d20b924a4c1b679026feac42205e06d9f5b",
  "hash": "716aba3806b7737f5152af0079c73d20b924a4c1b679026feac42205e06d9f5b",
  "version": 2,
  "size": 667,
  "vsize": 667,
  "locktime": 482836,
  "vin": [
    {
      "txid": "c7fdc7179381c001b056e2f905c5b506c79d10ae9fc3cd2a7721467a4bf05906",
      "vout": 1,
      "scriptSig": {
        "asm": "3045022100d723c11024ec3800aa87f9e20ebbd344ebcb57db5f71b2cc66155a2ea3ac167f022019f1455f1438d44e048ecf3895a5e3d041b2aca1146fc18b9c8dc4e77e40bb50[ALL] 035e23a55d8804ae49e49136a2412fb53b02f3de495622ef1e6a40f63f1ea93e44",
        "hex": "483045022100d723c11024ec3800aa87f9e20ebbd344ebcb57db5f71b2cc66155a2ea3ac167f022019f1455f1438d44e048ecf3895a5e3d041b2aca1146fc18b9c8dc4e77e40bb500121035e23a55d8804ae49e49136a2412fb53b02f3de495622ef1e6a40f63f1ea93e44"
      },
      "sequence": 4294967294
    },
    {
      "txid": "102313318e90c4c4ccb7581c90c1a8d38085106f19917544a21359067a80096a",
      "vout": 1,
      "scriptSig": {
        "asm": "30440220269bf280fd82163658da1be2f5301f851f13978937ee2c7701f654ac49ffc03602204fafb6592af7bdbedede204bd476b24fb03b50cdd75c5fbdb35e57692e870635[ALL] 0258c857eff89b9b54ccab29d4fcbadcb01c0a4cf9627fa56e4d6b96ae74f5e462",
        "hex": "4730440220269bf280fd82163658da1be2f5301f851f13978937ee2c7701f654ac49ffc03602204fafb6592af7bdbedede204bd476b24fb03b50cdd75c5fbdb35e57692e87063501210258c857eff89b9b54ccab29d4fcbadcb01c0a4cf9627fa56e4d6b96ae74f5e462"
      },
      "sequence": 4294967294
    },
    {
      "txid": "7c7c64412dfaad8bf74280748f295ae8b4fa88b469e2473b08c98198c1ba9266",
      "vout": 0,
      "scriptSig": {
        "asm": "3044022039293b68bda763f2f07ead2edd257eee35078ece91e0afdeb56b898c5e89d44502205f49dbebb0521e1cf4d74a1ec0fec0d174352e47385f773c4323e0533453e566[ALL] 035e23a55d8804ae49e49136a2412fb53b02f3de495622ef1e6a40f63f1ea93e44",
        "hex": "473044022039293b68bda763f2f07ead2edd257eee35078ece91e0afdeb56b898c5e89d44502205f49dbebb0521e1cf4d74a1ec0fec0d174352e47385f773c4323e0533453e5660121035e23a55d8804ae49e49136a2412fb53b02f3de495622ef1e6a40f63f1ea93e44"
      },
      "sequence": 4294967294
    },
    {
      "txid": "7c7c64412dfaad8bf74280748f295ae8b4fa88b469e2473b08c98198c1ba9266",
      "vout": 1,
      "scriptSig": {
        "asm": "304402200563b82f8d85ebc37f0adc106595caff6a69e5fecfda67c3003523fc195dd2a4022023f18ab2027f39b8c1e6be8cdf57d5fb6aae56c71756db4db9f123d6e88b77d3[ALL] 0209fac8d3f346aef9bf636e3d539e9c2cb0eb59bcd2898d560f0bbc9405628067",
        "hex": "47304402200563b82f8d85ebc37f0adc106595caff6a69e5fecfda67c3003523fc195dd2a4022023f18ab2027f39b8c1e6be8cdf57d5fb6aae56c71756db4db9f123d6e88b77d301210209fac8d3f346aef9bf636e3d539e9c2cb0eb59bcd2898d560f0bbc9405628067"
      },
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 0.01885081,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 6e3201e86a59653a0ea031af8f2b03615748d248 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9146e3201e86a59653a0ea031af8f2b03615748d24888ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "mqZcXjXjHBTHJwSxns2ZajLHpu3Ej33gh3"
        ]
      }
    },
    {
      "value": 0.10000000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 b3ebe3b4f7f100e00a1abfbb4ae39af4aece27f3 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914b3ebe3b4f7f100e00a1abfbb4ae39af4aece27f388ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "mwvHqHCSHqrfp7t7bnFA74JdnmaFAVXpLk"
        ]
      }
    }
  ],
  "hex": "02000000040659f04b7a4621772acdc39fae109dc706b5c505f9e256b001c0819317c7fdc7010000006b483045022100d723c11024ec3800aa87f9e20ebbd344ebcb57db5f71b2cc66155a2ea3ac167f022019f1455f1438d44e048ecf3895a5e3d041b2aca1146fc18b9c8dc4e77e40bb500121035e23a55d8804ae49e49136a2412fb53b02f3de495622ef1e6a40f63f1ea93e44feffffff6a09807a065913a2447591196f108580d3a8c1901c58b7ccc4c4908e31132310010000006a4730440220269bf280fd82163658da1be2f5301f851f13978937ee2c7701f654ac49ffc03602204fafb6592af7bdbedede204bd476b24fb03b50cdd75c5fbdb35e57692e87063501210258c857eff89b9b54ccab29d4fcbadcb01c0a4cf9627fa56e4d6b96ae74f5e462feffffff6692bac19881c9083b47e269b488fab4e85a298f748042f78badfa2d41647c7c000000006a473044022039293b68bda763f2f07ead2edd257eee35078ece91e0afdeb56b898c5e89d44502205f49dbebb0521e1cf4d74a1ec0fec0d174352e47385f773c4323e0533453e5660121035e23a55d8804ae49e49136a2412fb53b02f3de495622ef1e6a40f63f1ea93e44feffffff6692bac19881c9083b47e269b488fab4e85a298f748042f78badfa2d41647c7c010000006a47304402200563b82f8d85ebc37f0adc106595caff6a69e5fecfda67c3003523fc195dd2a4022023f18ab2027f39b8c1e6be8cdf57d5fb6aae56c71756db4db9f123d6e88b77d301210209fac8d3f346aef9bf636e3d539e9c2cb0eb59bcd2898d560f0bbc9405628067feffffff0299c31c00000000001976a9146e3201e86a59653a0ea031af8f2b03615748d24888ac80969800000000001976a914b3ebe3b4f7f100e00a1abfbb4ae39af4aece27f388ac145e0700",
  "blockhash": "bb55f8d0463ddf6b1c854286a2f1911ab590ed154ef502406f28fd0a01e52238",
  "confirmations": 6,
  "time": 1523009113,
  "blocktime": 1523009113
}

Are you sure you're on the right chain? I don't see a tx or block for 716aba3806b7737f5152af0079c73d20b924a4c1b679026feac42205e06d9f5b on the litecoin chain

@RaghavSood its on the testnet, sorry i forgot to mention that

Can you post the full output? Looking at https://chain.so/tx/LTCTEST/716aba3806b7737f5152af0079c73d20b924a4c1b679026feac42205e06d9f5b, it looks like the transaction hash and the block hash are different.

@AndrewChow i know that chain.so gives different hashes, i will paste it here asap

@AndrewChow https://pastebin.com/JHU640YT This is the output that litecoin client gives me

@Micic The txid and blockhash are clearly different: "txid": "716aba3806b7737f5152af0079c73d20b924a4c1b679026feac42205e06d9f5b", "blockhash": "bb55f8d0463ddf6b1c854286a2f1911ab590ed154ef502406f28fd0a01e52238",. Are you confusing hash for blockchash?

The txid and blockhash are clearly different. It appears that you are confusing the hash field for the blockchash field. The hash field is still just the hash of the transaction, not the hash of the block containing the transaction. Since this transaction is not a segwit transaction, the hash and txid will be the same. If this transaction were segwit (i.e. contains a segwit input), then the hash will be different from the txid.

so in conclusion, txid and hash keys are absolutely the same thing? and my pastebin is a correct output?

They are not always the same thing, but in this case they are the same thing. The output of the command is correct.

sorry for bothering you further, but shouldn't  txid represent the transaction hash, and hash represent the hash of the block?

I reread the answer and get it now, sorry for additional questions. Thank you!


text:
How does blockchain ensure that a closed loop in network is not formed?
Suppose there are 9 nodes and each node can connect to 8 other nodes. All these 9 nodes connect to the 8 others. Then when a new node comes where does it connect to in this case? All the current nodes are full (connected to 8 other nodes).

Nodes have more than 8 connection slots, by default they have 125 maximum connections. There are 8 outbound connections, but can still have incoming connections from other nodes when all 8 outbound connection slots are full. So in your example, the new node can open a connection to any of the other nodes in the network because they all have available incoming connection slots.
Furthermore, because connections are classified as incoming or outgoing (but data is still bidirectional), at least 8 of the 9 nodes will have at least one more outgoing connection slot.

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


text:
Bitcoin - Technical difference between P2PKH and P2SH address generation?
I  was convinced that the only difference between the generation of addresses starting with '1' and '3' was simply changing the prefix added to the digest from 0x00 to 0x05 after the ripemd160 part.
Although the addresses that i get do not match the addresses from Bitcoin Core wallet, when import the same private key, and also from the https://segwitaddress.org/.
Does the prefix 04 remains the same or also changes?
There's something i am missing. Could you please help? Thank you.
[EDIT]
This is the method i have at the moment and still does not work. I am surely misinterpreting something..
def getPublicAddress(self, digest):

    oSk = ecdsa.SigningKey.from_string(digest, curve=ecdsa.SECP256k1)
    oVk = oSk.get_verifying_key()

    hexlify = codecs.getencoder('hex')
    self.pubkey = str(hexlify(b'\04' + oVk.to_string())[0].decode('utf-8'))

    ripemd160 = hashlib.new('ripemd160')
    keyhash = hashlib.sha256(codecs.decode(self.pubkey, "hex")).digest()
    ripemd160.update(keyhash)

    redeem_script = hashlib.new('ripemd160')
    redeem_script.update(b'\x00\x14' + ripemd160.digest())

    prefix = b'\x05'
    m = prefix + redeem_script.digest()
    checksum = hashlib.sha256(hashlib.sha256(m).digest()).digest()[:4]

    return base58.b58encode(m + checksum)

P2PKH, P2SH, and Segwit are all different address types. Segwit and P2SH addresses are not the same.
P2PKH and P2SH addresses are generated in a similar way. P2PKH takes the hash160 of a public key (RIPMED160 of the SHA256 of the public key), appends the version byte of 0x00 to the hash160, and Base58 Check encodes it.
P2SH addresses are the Base58 Check encoding of the hash160 of a script (known as the redeemScript). It uses a version byte of 0x05 instead. The rest of the encoding is the same, just Base58 Check encoding.
For Segwit addresses, there are multiple types. There are native segwit addresses which follow the Bech32 standard. There are also P2SH wrapped segwit addresses.
For a P2WPKH (pay to witness pubkey hash) wrapped in a P2SH address, the redeemScript is 0x0014 <hash 160 of the pubkey>. That redeemScript is hashed  and encoded in the typical P2SH way.
For a P2WSH (pay to witness script hash) wrapped in a P2SH address, the witnessScript (redeemScript but for segwit addresses) is first hashed with SHA256. Then the P2SH redeemScript is 0x0020 <SHA256 of witnessScript>. The hash160 of this redeemScript is then encoded in the typical P2SH way.

As for your code, you are appending 0x04 to your public key which is simply incorrect. The 0x04 is not part of the address encoding, it is part of the public key encoding itself. Your public key generator should already be doing this for you. Note that if the public key is compressed that the prefix byte will be either 0x02 or 0x03 (depends on the Y value of the public key) instead of 0x04 which is for uncompressed public keys.

[Technical difference - Example solution]
`
    def hash160(self, v):
        r = hashlib.new('ripemd160')
        r.update(hashlib.sha256(v).digest())
        return r

    def doublehash256(self, v):
        return hashlib.sha256(hashlib.sha256(v).digest())

    def ecdsaSECP256k1(self, digest):
        # SECP256k1 - Bitcoin elliptic curve
        sk = ecdsa.SigningKey.from_string(digest, curve=ecdsa.SECP256k1)
        return sk.get_verifying_key()

   def publicaddress1(self):

        prefix_a = b'\x04'
        prefix_b = b'\x00'

        digest = self.privkeyhex.digest()

        p = prefix_a + self.ecdsaSECP256k1(digest).to_string() # 1 + 32 bytes + 32 bytes
        self.pubkey = str(binascii.hexlify(p).decode('utf-8'))

        hash160 = self.hash160(p)

        m = prefix_b + hash160.digest()
        checksum = self.doublehash256(m).digest()[:4]

        self.pubaddr1 = base58.b58encode(m + checksum)

    def publicaddress3(self):

        prefix_even = b'\x02'
        prefix_odd = b'\x03'
        prefix_a = prefix_odd
        prefix_b = b'\x05'
        prefix_redeem = b'\x00\x14'

        digest = self.privkeyhex.digest()

        ecdsa_digest = self.ecdsaSECP256k1(digest).to_string()

        x_coord = ecdsa_digest[:int(len(ecdsa_digest)/2)]
        y_coord = ecdsa_digest[int(len(ecdsa_digest)/2):]

        if (int(binascii.hexlify(y_coord),16) % 2 == 0): prefix_a = prefix_even

        p = prefix_a + x_coord

        self.pubkeycompressed = str(binascii.hexlify(p).decode('utf-8'))

        redeem_script = self.hash160(prefix_redeem + self.hash160(p).digest()).digest() # 20 bytes

        m = prefix_b + redeem_script
        checksum = self.doublehash256(m).digest()[:4]

        self.pubaddr3 = base58.b58encode(m + checksum)`

Thank you for your help. So basically i am missing the part where i need to feed a compressed wif private key and to check for the Y value after. The problem now is that the ECDSA is expecting a 32bytes input digest and if i decode base58 compressed WIF  51bytes + x01 and feed into ECDSA is gives me this error:     assert len(string) == curve.baselen, (len(string), curve.baselen) AssertionError: (38, 32) it is expecting a 32 byte size. Should i just input the digest of the private key like the classic P2PKH? I will jump into the Y value part meanwhile.. Thanks a lot.

Your WIF decoding sounds like it is wrong. You should get a 34 byte object. The first byte is the version number, and the last byte indicates compressedness, but is only relevant to WIF. You should drop those two bytes and you will have a 32 byte object that is the private key. Handling public key compression happens later, so you need to have something else remember whether the public key is compressed or not.

Thank you. What i was missing was the separation of the digest (coordinates) in 32 bytes each. The rest was easy to implement. Going to put the solution up..

Segwit inside P2SH:
redeem_script = hash160(b'\x00\x14' + hash160(public_key))

0x00 -> Witness version, 0x14 -> 20(or 32)bytes push opcode
prefix = b'\x05' -> P2SH main net
checksum = double_sha256(prefix + redeem_script)[:4]
address = base58(prefix + redeem_script + checksum)

Thanks for your help! I notice that those steps are basically what they have here https://bitcoincore.org/en/segwit_wallet_dev/ ? Not able to understand a few things. Where do you get that hash160 function? Are you refering to the ripemd160 ? Are those snipets placed after generating a x00 or in replace of? I don't really understand also what they mention by "the public key used in P2SH-P2WPKH MUST be compressed i.e. 33 bytes in size, and starting with a 0x02 or 0x03"..

@fortesp hash160(x) is ripemd160(sha256(x)). You can find more information on what a compressed public key is here https://bitcoin.stackexchange.com/questions/3059/what-is-a-compressed-bitcoin-key


text:
Inbound connection merchant risk
I was recently looking at the safest way to set up an online bitcoin service. When looking for security concerns I ran across this post on stackexchange What are the risks of running an online store via a bitcoind connection using less than the minimum of 8 connections? under the main question Stephen Gornick talks about how allowing inbound connections on 0 conf could open you up to huge double spends. I looked all over for the reason for this but was hoping someone could explain this vulnerability to me.

The attack is this simple:

You connect to both the merchant and every major mining pool.
At the same time, you send a transaction paying the merchant to the merchant and a conflicting transaction that pays yourself to every major mining pool.
The merchant sees the transaction paying them, and accepts it with zero confirmations.
The mining pools see the transaction paying yourself first, so they try to work that transaction into blocks. Eventually, one of them succeeds and the merchant will never get paid.

If you accept payments with zero confirmations, you should connect directly to multiple points in the Bitcoin network as close to major mining pools as possible and monitor for any conflicting transactions -- even if seen later. (There are other things you must do too. It's not trivial.)

I am still doing a lot of research on the matter. I do not intend to accept 0 conf but was just curious on the matter. You're the best David!


text:
Understanding Vout
I have searched around for this and found the following article In getrawtransaction, what is the vout integer in the vin list?. However I am a very visual learner and this does not make much sense mostly because the two transactions I tested don't seem to follow the rule in the post or more likely I don't get it.
For transaction 1d7f54deccb7b2646a4ba83c6884dbac953b0588c8943d0e7e8f7c8f559d5d72 I expect the vout to be 1 which is correct and I validated through use of gettxid.
However for transaction ef96555197df4397ac4fed180903ce760fe8b59b85da83baba5ecd2a0fac7ec1 I expect the vout to be 2 which is not correct per validation with gettxid. The correct number is in fact 0.
Can anyone explain this to me why vout for the second transaction would be 0?

VOUT is the index of the output within the transaction that the input is spending.  The first output in a transaction is index 0, the second is index 1, etc.  The transaction you referenced has two outputs, so it has outputs 0 and 1.  You would reference txid:0 to spend the first output and txid:1 to spend the second output.

Thank you that makes a ton of sense don't know why I was having trouble with it!


text:
Is normal ECDSA verification slower than a verification method based on Public Key Recovery?
Background info:
This post on the Cryptography stack exchange shows how to almost uniquely recover the public key from the signature, hash of the signed data, and knowledge of the curve: https://crypto.stackexchange.com/questions/18105/how-does-recovering-the-public-key-from-an-ecdsa-signature-work. I believe it basically produces two public keys for which the signature given will validate for the hash.
Main Question:
Given a public key Q, a signature S, and the hash of some data H, it seems that there are two ways that we can verify that this triple is valid.

We can run the usual ECDSA verification routine, which is somewhat time intensive.
We can run public key recovery with (S, H, Curve) and verify that one of the 2 possible returned public keys (4, really, since each can be either compressed/decompressed) is the point Q. I am not sure if this is more/less time intensive.

So,

Is verification through public key recovery more or less time intensive than the usual ECDSA verification?
If less, then couldn't bitcoin do all it's ECDSA verification through public key recovery and save time? Granted, checking a pubkey-hash would involve taking each candidate public key, OP_HASH160 hashing it and seeing if it comes out to the right 20 bytes of the address. And if none of the 4 possibilities hash to the correct value, then the signature verification failed.

My only reason for asking this is that ECDSA verification is slow, and I read somewhere that public key recovery is very fast, so just wanted to see if anyone has any insight into this.

You can simplify your proposed algorithm: calculate the public key from the signature in uncompressed form; if the public key from scriptSig is compressed, uncompress it and compare it to your two candidate public keys.

Right, when you have a public key to work with, that works fine. In 2., I was talking about the case where you only have a hash of a public key to verify a signature, so I think you'll need to hash all four possibilities (doing the 2 compressed versions first since they're probably more likely now-a-days).

Verification w/ Public key recovery is never going to be faster than normal verification however it is only marginally slower.  I benchmarked it a while back and PubKey recovery added about 5% overhead.
Changing the txn format would require a hard fork so it is unlikely that is going to happen but the advantage of pubkey recovery is that it trades storage for time.  This could be useful for Bitcoin as processor power is less of a bottleneck than WAN bandwidth especially in residential 'last mile' scenarios.
A typical 2in, 2out P2PkH transaction is 373 bytes with compressed keys and 437 bytes using uncompressed keys).  The same transaction without pubkeys would be 309 bytes resulting in a storage (bandwidth and memory) reduction of 17% to 29% in exchange for 5% increase in CPU time.
Hashing is extremely fast so performing 4 hashes vs 1 hash is negligible but a single byte can remove that overhead.  The protocol would require using a flag with the signature to indicate which form to use when recovering the PubKey.
0x02 = compressed even
0x03 = compressed odd
0x04 = uncompressed even
0x05 = uncompressed odd

This really only saves significant space in P2PkH transactions. For P2SH (i.e. multisig) the script is very likely to contain full pubkeys instead of keyhashes.
While using PubKey recovery initially would have made sense the cost in terms of needing a hardfork doesn't make that change very viable.  If putting a hardfork on the table there are a lot of more interesting things that could be done instead.  For example switching from ECDSA to Schnorr signatures would allow native thresholding signatures.  This would reduce the number of signatures from one (or more in the case of multisig) per input to just one per transaction.  As 64 bytes each that would really add up.


text:
Turing an old laptop into a bitcoin miner
So I have an old laptop that was passed down to me, and I want to turn it into a bitcoin miner, I don't have any experience with bitcoin mining; its got 2gb of ram and some pentium. it will be running all the time.
Thanks in advance
Holden

Probably a very bad idea. Not only will it be terribly inefficient at mining. It will also incur a net loss due to electricity cost!

What you could do instead is mine a coin with a PoW that's CPU friendly, such as a Cryptonote coin. You can then sell those for bitcoins on sites like Poloniex, or P2P markets like bitsquare. You may not get a lot, but I believe you can still come out ahead of electricity costs with Monero, as laptops are fairly low in electricity consumption. If you wish to try this, ask another question about it.


text:
How can we receive hashtx and hashblock from bitcoind by zmq subscribe?

install bitcoind by sudo apt install bitcoind in Ubuntu 16.04 server amd64(https://bitcoin.org/en/full-node#ubuntu-1410)
bitcoind --version show v0.13 ga402396
bitcoind -daemon -zmqpubhashblock=tcp://127.0.0.1:28332 -zmqpubhashtx=tcp://127.0.0.1:28332
after download, blocks file is 89G.
and the bitcoin.conf only have rpcuser=xxxyyy and rpcpassword=xxx123
should add server=1 to bitcoin.conf?
git clone https://github.com/bitcoin/bitcoin
cd bitcoin/contrib/zmq and pip install zmq, then do python zmq_sub.py and we can't receive anything in long wait.
How can we receive hashtx and hashblock from bitcoind? Should i install libzmq3-dev? Is libzmq3-dev only for compile bitcoind and don't need in runtime?

The PPA you have installed (https://launchpad.net/~bitcoin/+archive/ubuntu/bitcoin/+packages) is not compiled with ZMQ support (It should in future).
You need to self-compile bitcoin v0.13.0 or use one of the "official" binaries: https://bitcoin.org/bin/bitcoin-core-0.13.0/
EDIT: since 0.14, ZMQ support is available via the PPA

Note that, latest packages from ppa:bitcoin/bitcoin contain ZMQ support


text:
Stratum Server Exception "[coin] is not connected"
When i running 'twistd -ny launcher.tac' i getting the following Exception. The connection okay. Please help me to fix this issue.
2017-01-30 19:33:43,094 INFO bitcoin_rpc # Checking for submitblock
2017-01-30 19:33:43,097 DEBUG bitcoin_rpc # submitblock detected.
017-01-30 19:33:43,097 INFO mining # Found submitblock
2017-01-30 19:33:43,101 ERROR mining # Coind Error: Guncoin is not connected!

Thanks,
Your help will appreciated!

What are you doing? What is twistd? What is your expected outcome?

@Murch Based on filenames, I think it's this fork of stratum

Thanks for your reply....
     Actually i am not familiar with Python,
     I am just followed this instructions ,
      https://github.com/Crypto-Expert/stratum-mining/wiki/Getting-Started-With-Stratum,
     But, it is showing above exception

If anyone runs into this problem then check your coin daemon settings.
I got it because my client didn't find any nodes to connect to. I found a list of nodes and added them in my COIN CLIENT SETTINGS.
I.e:
addnode=xx.xx.xx.xx

Restart the client, run client-cli getinfo to make sure you're downloading blocks. If it works you should be seeing
ERROR mining __init__.setup # CoinD downloading blockchain... will check back in 30 sec

Let your client update to the latest block and everything should be just peachy.


text:
False error notifcation (double spent) 'code' => -4, 'message'
Now and than I seem to get a consistent false error notification.
Error message:

Request error: array ( 'code' => -4, 'message' => 'Error: The transaction was rejected! This might happen if some of the coins in your wallet were already spent, such as if you used a copy of the wallet and coins were spent in the copy but not marked as spent here.', ).

After the notifcation the getbalance and getbalance '' '1' are in conflict. Getbalance not showing the actual balance correct anymore.
Despite the error the bitcoin transactions gets broadcasted correctly on to the network and within a couple of days (most of the time) the transactions get processed successfully.
Info on client
{
  "version": 130000,
  "protocolversion": 70014,
  "walletversion": 130000,
  "balance": 13.56365098,
  "blocks": 455269,
  "timeoffset": 0,
  "connections": 8,
  "proxy": "",
  "difficulty": 440779902286.5892,
  "testnet": false,
  "keypoololdest": 1488349424,
  "keypoolsize": 100,
  "paytxfee": 0.00150000,
  "relayfee": 0.00010000,
  "errors": ""
}

Anyone here having the same problems lately?

Is there any possibility you could try 0.14.0rc1 or later? It has a more useful error message for that error.

The reason for this could be that you spend a long chain of unconfirmed transactions. In 0.14, Core has improved this behaviour and added an startup option called -walletrejectlongchains (needs to be enabled, default is off).
Otherwise your wallet might spend long chains of unconfirmed coins but your node/mempool won't accept them.
Also, have a look at the -limitancestorcount settings and consider reading the pull request here

Hi Jonas,
Thank you for your reply! Could it be that the clients balance gets deducted without the transaction actually reaching the mempool?
I made a transaction yesterday getting the 404 message described above. The amount was deducted from the balance. When checking if the tx was in the mempool by : getmempoolentry txid response is:
error code: -5
error message:
Transaction not in mempool
Could it be that the client assums the coins are sent despite not being broadcasted on to the network? And how to spend/send the coins again?

Just to be sure I understand you correctly. Regarding the long chain of unconfirmed transactions. Is the transaction change considered to be part of the long chain of unconfirmed transactions? Like in this example when I start with a balance of 25 BTC on a single address and start sending 100 transactions in <1 hour without any of them being confirmed.

Hi. The transaction was probably successfully added to the wallet, but could not be broadcasted. So the balance is correct, the transaction is made,... but do to your local mempool policies it could not be broadcasted. You can try to increase your -limitancestorcount (but other peers mempool could reject it) or try to "abandon" the transaction (look for abandontransaction).


text:
Persistency of Seed Nodes
A few of the guys at work have asked for me to make them a cryptocurrency (god knows why but I'm happy to oblige). I'm basing it on Cryptonote and have got it all built.
I understand that I need at least two seed nodes to get things going. However, do these seed nodes need to stay on indefinitely or can they be turned off once there's a network of miners?

I'm not familiar with the specific design of CryptoNote, but in general a cryptocurrency node must have a way of discovering its first node in the network. Once it discovers that first node, it can ask that node for all of the nodes it knows of, then ask those nodes for all of the nodes that they know of, etc. etc. until it knows about every node in the network. In most cryptocurrencies, there's no difference between a seed node and a regular node.
There aren't a lot of constraints on how you solve this problem. You could have a seed node at a fixed IP address, and distribute an update if that IP address changes. You could have the node look up a DNS record that corresponds to a handful of nodes. You can have the node request a webpage, and add all of the IP addresses on that webpage to the address list.
Bitcoin uses a combination of fixed IP's, plus DNS seeding. See peer-discovery.


text:
Colored coins implementation in Python
Is there any implementation of this Colored Coins Protocol in Python?
I have found colored coins implementations in Python but, as far I as understand, they implement different protocol specifications (for instance Chromaway's ngcccbase or Open Assets).
Thanks!

There aren't any, unfortunately.
Rolling your own shouldn't be that difficult - I'd suggest using CoinSpark's OP_RETURN library as a starting point. All the best!


text:
What is the right method to calculate Relative Strength Index (RSI) for incoming real time data?
I am working on a trading bot that computes values for several indicators including the RSI. I subscribe to real time minute-level market data from an exchanges, and as new data arrives, I get the most recent tick, and re-compute indicators.
Let's assume the RSI calculation period is 1 hour.
Average gain is computed as:
05:00 as [Prev Avg Gain x 13 + (Price at 05:00 - Price 04:00)]/14.
06:00 as [Prev Avg Gain x 13 + (Price at 06:00 - Price 05:00)]/14.
What is the right way to compute RSI at a minute level? I generate trade signals (buy/sell) every 5 minutes. What is the right way to update RSI at 05:05 i.e, at a smaller granular period (5 minutes) than the calculation period (1 hour)? I don't want to wait one until 06:00 to get the RSI for the one hour period. I have two options:
Compute Current Gain = (Price at 05:05) - (Price at 05:00).
OR
Compute Current Gain = (Price at 05:05) - (Price at 04:05).
And do this for each of the previous intervals so that average gain also follows this formula - essentially adding a 5 minute shift to each computation.
Any suggestions are welcome.

What does RSI stand for?

Are you referring to Relative Strength Index? https://en.wikipedia.org/wiki/Relative_strength_index

Yes I am! Sorry, should have been clearer.

use Current Gain = (Price at 05:05) - (Price at 05:00)
so at 05:59 it should be almost exactly as the new level at 06:00


text:
Action taken when data of a block gets tampered with
Let's say we have a Blockchain consisting of 10 blocks, indexed from 0(Genesis Block) to 9(The last block).
If the data of a block, say block 5, is changed(maliciously), the data stored on the block, as well as subsequent blocks, becomes invalid.
What happens next?
It is impractical to drop the blockchain entirely. It is also impractical to recalculate all the hashes, in case of larger chains.
So, how is data of the current block, as well as that of other blocks, preserved in the event of an attack on a single block?

Are you talking about local tampering on a specific node, or a chain-wide tampering attempt?

@RaghavSood A specific node.

I believe that if the data of one block is maliciously altered on one node, this would likely affect signatures relating to affected data.
All other nodes would ignore any blockchain data and transactions from that node which are affected by the changes made.
For example, any other nodes obtaining that block from the malicious node would either notice that it's checksums and signatures were invalid or would notice that there is a competing chain (based on an unaltered block) which is longer and more trustworthy.
Wallet software, when synchronising, does check the validity of each block received. This means it is not impractical to do this for the entire blockchain (although it does contribute to the time that initial synchronisation takes)
Some wallets don't need to check really old blocks because they have hardcoded within them, checksums for blocks at release date. They can still distinguish blocks built upon on differing earlier blocks (because changes to significant data in earlier blocks affect the checksums of blocks built on that)
The upshot is that making changes to old blocks doesn't give anyone the ability to spend bitcoins they wouldn't otherwise have had.

Useful links

https://bitcointalk.org/index.php?topic=2129247.0
What are the trust assumptions in --assumed-valid in bitcoin core 0.14?


text:
Why the receiver doesn't get any bitcoin on the balance if sendtoaddress or sendrawtransaction is used?
I want to do a transaction, but I see that the receiver doesn't get the amount sent.
The regtest node started
bitcoind -rpcuser=test -rpcpassword=test -regtest -rpcport=16591 -fallbackfee=0.000045

My service class to interact with bitcoind API
const httpClient = require('axios');

const bitcoindConfig = {
  url: 'http://localhost:16591',
  headers: { 'content-type': 'text-plain' },
  auth: {
    username: 'test',
    password: 'test'
  },
};

class BitcoinService {
  _bitcoindRpcCall({ reqMethod = 'POST', walletName, method, params = [] } = {}) {
    const options = {
      url: walletName ? bitcoindConfig.url + `/wallet/${walletName}` : bitcoindConfig.url,
      method: reqMethod,
      data: JSON.stringify({'jsonrpc': '1.0', 'id': 'curltext', 'method': method, 'params': params}),
      headers: bitcoindConfig.headers,
      auth: bitcoindConfig.auth
    };
    return httpClient(options);
  }

  listWallets() {
    return this._bitcoindRpcCall({ method: 'listwallets' });
  }

  createWallet({ walletName }) {
    return this._bitcoindRpcCall({ method: 'createwallet', params: [walletName] });
  }

  getNewAddress({ walletName }) {
    return this._bitcoindRpcCall({ method: 'getnewaddress', walletName });
  }

  getBalance({ walletName }) {
    return this._bitcoindRpcCall({ method: 'getbalance', walletName });
  }

  listUnspent({ walletName }) {
    return this._bitcoindRpcCall({ method: 'listunspent', walletName });
  }

  dumpPrivKey({ address, walletName }) {
    return this._bitcoindRpcCall({ method: 'dumpprivkey', params: [address], walletName });
  }

  listTransactions({ walletName }) {
    return this._bitcoindRpcCall({ method: 'listtransactions', walletName });
  }

  generateToAddress({ address, nBlocks, walletName }) {
    return this._bitcoindRpcCall({ method: 'generatetoaddress', params: [nBlocks, address], walletName });
  }

  getTransaction({ txId, walletName }) {
    return this._bitcoindRpcCall({ method: 'gettransaction', params: [txId], walletName });
  }

  getRawTransaction({ txId, walletName }) {
    return this._bitcoindRpcCall({ method: 'getrawtransaction', params: [txId], walletName });
  }

  decodeRawTransaction({ hexString }) {
    return this._bitcoindRpcCall({ method: 'decoderawtransaction', params: [hexString] });
  }

  // https://bitcoincore.org/en/doc/0.17.0/rpc/wallet/sendtoaddress/
  async sendToAddress({ walletName, amount, toAddress, comment = '', commentTo = '', subtractFeeFromAmount = true } = {}) {
    return this._bitcoindRpcCall({
      method: 'sendtoaddress',
      params: [toAddress, amount, comment, commentTo, subtractFeeFromAmount],
      walletName
    });
  }

  // https://bitcoincore.org/en/doc/0.17.0/rpc/rawtransactions/createrawtransaction/
  async createRawTransaction({ walletName, amount, toAddress }) {
    const { data: { result: txs } } = await this.listUnspent({ walletName });

    const inputs = [];
    let n = amount;
    let i = 0;
    while (n > 0 && i < txs.length) {
      const tx = txs[i++];
      inputs.push({ txid: tx.txid, vout: tx.vout });
      n -= tx.amount;
    }

    const outputs = [
      { [toAddress]: amount }
    ];
    console.log('inputs, outputs', inputs, outputs);

    return this._bitcoindRpcCall({ method: 'createrawtransaction', params: [inputs, outputs] });
  }

  // https://chainquery.com/bitcoin-cli/signrawtransactionwithwallet
  signRawTransactionWithWallet({ hexString, walletName }) {
    return this._bitcoindRpcCall({ method: 'signrawtransactionwithwallet', params: [hexString], walletName });
  }

  // https://bitcoincore.org/en/doc/0.17.0/rpc/rawtransactions/sendrawtransaction/
  sendRawTransaction({ hexString, allowHighFees = true } = {}) {
    return this._bitcoindRpcCall({ method: 'sendrawtransaction', params: [hexString] });
  }

  async rawTransaction({ walletName, amount, toAddress }) {
    let res = await this.createRawTransaction({ walletName, amount, toAddress });
    res = await this.signRawTransactionWithWallet({ hexString: res.data.result, walletName });
    return this.sendRawTransaction({ hexString: res.data.result.hex });
  }
}

Two wallets created: alice and bob
const btc = new BitcoinService();

res = await btc.createWallet({ walletName: 'bob' });
console.log('create bob wallet', res.data);
// { result: { name: 'bob', warning: '' }, error: null, id: 'curltext' }
res = await btc.createWallet({ walletName: 'alice' });
console.log('create alice wallet', res.data);
// { result: { name: 'alice', warning: '' }, error: null, id: 'curltext' }

Check whether the wallets exist
res = await btc.listWallets();
console.log('listwallets', res.data);
// { result: [ 'bob', 'alice' ], error: null, id: 'curltext' }

Create addresses for the wallets
let aliceAddr;
let bobAddr;

res = await btc.getNewAddress({ walletName: 'alice' });
aliceAddr = res.data.result;
console.log('alice addr', aliceAddr);
// bcrt1qn4w4futa4j0mrt6frqn9u9zg9n5s9dvaeh2mrl

res = await btc.getNewAddress({ walletName: 'bob' });
bobAddr = res.data.result;
console.log('bob addr', bobAddr);
// bcrt1qecashk27r403nkeq09gvpfnr7dgfeet9xk97m5

Generate bitcoin for alice
for (let i = 0; i < 5; i++) {
  res = await btc.generateToAddress({ address: aliceAddr, nBlocks: 101 });
  console.log('generate bitcon for alice', res.data);
  // hashes in the output
}

Check balance
// Get balance
res = await btc.getBalance({ walletName: 'alice' });
console.log('alice balance', res.data);
// { result: 126.85546875, error: null, id: 'curltext' }

res = await btc.getBalance({ walletName: 'bob' });
console.log('bob balance', res.data);
// { result: 0, error: null, id: 'curltext' }

Send bitcoin from alice to bob
res = await btc.sendToAddress({ walletName: 'alice', toAddress: bobAddr, amount: 0.1 });
console.log('alice sends to bob', res.data);
// {
//   result: '0ae84b140e3be5d4933daa4f25e3d1cd5c02b9485ede54ad4c24a91e7d0d28f2',
//   error: null,
//   id: 'curltext'
// }

Checking the balance again
res = await btc.getBalance({ walletName: 'alice' });
console.log('alice balance', res.data);
// { result: 126.75546875, error: null, id: 'curltext' }

res = await btc.getBalance({ walletName: 'bob' });
console.log('bob balance', res.data);
// { result: 0, error: null, id: 'curltext' }

The alice balance was decreased by 0.1 as expected. Why is there no amount on the bob balance?
Also, I tried the sendrawtransaction, same result, bob got no bitcoin on the balance.
res = await btc.rawTransaction({ walletName: 'alice', toAddress: bobAddr, amount: 0.1 })
console.log('alice sends raw transaction', res.data);
// {
//   result: 'e1fc8cc8bbe38bdd793ff1f87ca59a52d90c9fa1523d93d166f6a53209bc5e56',
//   error: null,
//   id: 'curltext'
// }

But I can list the transaction that bob received
res = await btc.listTransactions({ walletName: 'bob' });
console.log('bob transactions', res.data);

bob transactions {
  result: [
    {
      address: 'bcrt1qyrjp4kcar7c60842zmd38wnwjxlgjhj6550nev',
      category: 'receive',
      amount: 0.1,
      label: '',
      vout: 0,
      confirmations: 0,
      trusted: false,
      txid: 'e1fc8cc8bbe38bdd793ff1f87ca59a52d90c9fa1523d93d166f6a53209bc5e56',
      walletconflicts: [],
      time: 1637406810,
      timereceived: 1637406810,
      'bip125-replaceable': 'no'
    },
    {
      address: 'bcrt1qyrjp4kcar7c60842zmd38wnwjxlgjhj6550nev',
      category: 'receive',
      amount: 0.1,
      label: '',
      vout: 0,
      confirmations: 0,
      trusted: false,
      txid: 'd4de85ff41b0386808b60a8ec0028923c42a2bc1667e5b8a7b865cacf21abd5d',
      walletconflicts: [],
      time: 1637407520,
      timereceived: 1637407520,
      'bip125-replaceable': 'no'
    },
    {
      address: 'bcrt1qyrjp4kcar7c60842zmd38wnwjxlgjhj6550nev',
      category: 'receive',
      amount: 0.1,
      label: '',
      vout: 0,
      confirmations: 0,
      trusted: false,
      txid: '573d8ef6b72fa3e029f3207ddc8b5f03a248e88b4ae643bc66be38ae84ffa01f',
      walletconflicts: [],
      time: 1637407554,
      timereceived: 1637407554,
      'bip125-replaceable': 'no'
    },
    {
      address: 'bcrt1qyrjp4kcar7c60842zmd38wnwjxlgjhj6550nev',
      category: 'receive',
      amount: 0.1,
      label: '',
      vout: 0,
      confirmations: 0,
      trusted: false,
      txid: '4fa4efff12348f0916cec1b39e47cf19ceb1aa91b7236f7c67905b2eef34433a',
      walletconflicts: [],
      time: 1637407824,
      timereceived: 1637407824,
      'bip125-replaceable': 'no'
    }
  ],
  error: null,
  id: 'curltext'
}

I assume Bob's balance just won't be counted until it is confirmed.

@PieterWuille true, now I got it. The transactions are included in a block and it must be mined. For example bitcoin-cli -rpcport=16591 -rpcpassword=test -rpcuser=test --rpcwallet=alice -generate 1 Now I see the bob balance updated. But I can't find a way to do it via the RPC API. Is it possible? But maybe better to run the command above by the cron every 5 sec.

I don't know anything about the interface you're using here, but Bitcoin Core can give you unconfirmed balances using the getbalances RPC (note: not getbalance).

@PieterWuille thank you. It is helpful!


text:
Bitcoin and Merkle Tree - is in Bitcoin the Merkle Tree actually a List (which of course is a special form of a tree)?
When I get it right, each block in Bitcoins block chain contains a prev hash and a new block hash that includes this prev hash. So the genesis block only has itself and from there on each hash of the prev block is hashed again together with some transactions etc.
So the Merkle tree is in this case a List?
@Edit:
Found out that the Merkle Tree seems not to work globally, it seems to hash all transactions included in a block separately and use them as leaves and then build a binary tree upon them. Where each hash is created over the hash of their children.
So it seems it isn't a special kind of tree and instead a simple binary tree.
Is this all or did I miss something important?

The edit is completely correct. However, there are two known quirks you might be interested:

This quirk happens if the number of transaction is not 2^n. You can read more about it here. This was known by the creator of Bitcoin.
This attack (may) happen in the case where a transaction with length 64 bytes is an element of a Merkle tree. Details can be found here.


text:
How to determine what's mine?
I for example own 10 BTC does that mean, in some Blocks in the valid part of the blockchain is written, that I received at some point in time a certain amount of BTC? How do I prove that the Transactions in this block belong to me (without loosing ownership).
How hard is it to find all transactions in a chain which belong to me. Some how this should be possible in $\mathcal{O}(l\cdot m\cdot log(n))$ because of the merkle tree in each block for m blocks and l transactions representing my complete ownership (3 BTC + 4 BTC + 3 BTC = 10 BTC)
Could everybody check my amount of bitcoin if he knows my alias or whatever is used to mark my transactions as mine.
Could I just spend someone elses coins?
Thank you very much in advance.
PS.:
My Plain written math expression was displayed wrong so I edited as tex code but it still does not work. Anyone who can read tex will still be able to read this formula (probably better than before)
If sb knows how to fix it, plz provide a solution.

I for example own 10 BTC does that mean, in some Blocks in the valid part of the blockchain is written, that I received at some point in time a certain amount of BTC? How do I prove that the Transactions in this block belong to me (without loosing ownership).

Essentially, yes. Owning BTC simply means that one or more transaction outputs somewhere in the chain exist, that are spendable by you. In a normal case, this means that you have control of the private keys required to spend these outputs.
To prove you own them, you can sign a non-transaction message using your private key. This signature can be verified against your public key, and the public key can be verified against an address, thus proving that you own the outputs associated with that address.

How hard is it to find all transactions in a chain which belong to me

If you do not know the transaction IDs, the merkle tree will not help. The merkle tree is only useful if you want proof that a known txid is in some block. If you only know the addresses that your outputs are at, but not the txids, you must scan the entire chain and match the output scripts against your addresses. This will have a worst case of O(n).

Could everybody check my amount of bitcoin if he knows my alias or whatever is used to mark my transactions as mine.

If they know which addresses belong to you, yes.

Could I just spend someone elses coins?

If you are able to satisfy the output script requirements, then yes. For regular transactions, this would imply that you have been able to compromise the keys owned by someone else.

I am aware of asymetric key cryptography but anyway, I am not aware at which point the keys are generated and applied to the transactions. I expect that there is some kind of a signing procedure, has it to do something with the so called smart contracts (currently started reading about that, in 30min I will probably already know more)


text:
How Do Peers Choose Which Peer To Trust?

So the way I understand how the blockchain works is that each new block uses the previous block's hash, which means if my block[100].hash != someone_elses_block[100].hash that means that either I broke some rule, or the other person did; In this case, how does my client find a trusted peer? And WHERE does my client get the latest CORRECT blockchain? Is there a central server for it? If so, where did the server it from? Because the miner will have the longest chain, but what if they are not actually following the rules? Then what?
Lets say I stopped my client for 100 days, during those 100 days there was 500 new transactions, which means that if I was to compare my last block with someone elses then my client would be outdated, therefore it needs to download the extra blocks, where does it find these blocks and how does it determine which peers to sync to and to trust?
A question about the nonce, if lets say there was no nonce; If client A has a chain that followed the rules and client B was verifying transactions without actually doing all the proper checks, that means that client A at block[100].hash != client B at block[100] therefore client B is not following the rules, so the question is what is the real need for the nonce? Because in my mind it seems like it's just there to make it harder to mine for people, correct? Or does it add some sort of security? And if it does, will it have the same security if let's say the nonce was always any number between 0 and 15? Or would it have to be adjusted as mining gets faster?

Thanks!

It's worth pointing out that not all blockchains have nonces.

either I broke some rule, or the other person did; In this case, how does my client find a trusted peer

Your client does not trust any peer. It fully validates the blockchain. In the event of multiple conflicting blocks at a given block height, your node will choose to go with the first block it hears of. However it will still retain and validate all of the other blocks that it has received for that block height. Only after more blocks have been mined does it actually choose which of those conflicting blocks becomes part of its main chain. It chooses based upon which branch has the most cumulative work.
There is no trust in this process; it uses first heard initially and then will readjust if later blocks belong to a different branch. These reorganizations are why it is recommended to wait for multiple confirmations as one block reorgs are not uncommon.
Also, the blockchain with the most cumulative work (typically referred to as the longest blockchain) is not the only determination for what blockchain to use. The blockchain also has to be valid, it can't just have the most work.

2: Lets say I stopped my client for 100 days, during those 100 days there was 500 new transactions, which means that if I was to compare my last block with someone elses then my client would be outdated, therefore it needs to download the extra blocks, where does it find these blocks and how does it determine which peers to sync to and to trust?

Your node does the normal peer discovery process every time it goes online. Your node will then randomly choose one of the peers it has connected to to be the "sync node". It doesn't actually sync much off of this node, just the block headers. It downloads the block headers from this node and validates them. Then it will download the blocks for those headers from the other nodes it has connected to.
Once the headers chain of one node has been synced, it will request the headers of other nodes to get an idea of what their best headers chain is in order to determine if the sync node was dishonest.
Again, there is no trust in this process as all blocks and headers are still fully validated. Since the download involves checking against multiple nodes, it is unlikely that your node will have the incorrect blockchain as not just one node dictates what chain you download.

so the question is what is the real need for the nonce?

The nonce is completely unrelated to validity except for the fact that it is part of the block header which is hashed. The nonce's sole purpose is to have something to change when mining. It provides no security characteristics nor is it related to the consensus rules (except for the fact that it has to exist, it could be zero). Miners could very well just not do anything to the nonce and change something else to get a different hash. It exists solely as a convenience.

Assuming the network as a whole isn't broken, the only way this can fail is if every single node you connect to is malicious and none of them are willing to reveal the actual longest valid chain to you. This is called a Sybil attack and there are various defenses against them. For PoW systems, anyone who mined blocks in the longest chain wants to get them to as many people as possible to ensure they stay in the longest chain so they get to keep their reward. It's very hard for a third party to stop two people who want to exchange information from doing so.

Plus: To get started the validation started with a known good state, the blockchain software frequently (always?) has the blockchain's genesis block (block 0) built-in (or at least it's hash).  For example, here it is in Bitcoin Core.


text:
Does bitcoin core 0.18 support bip44,bip39 (HD wallet)
I am new to bitcoin. Struggling to implement HD wallet. goggled for the same but did not get satisfied answer. Can we create multiple seed in single bitcoin core server?
If yes, then how we can manage the private key of each generated seed.
   If no, then how we can create custom derivation path.
Note: I am using json-rpc protocol to communicate with bitcoin core.

You seem to have confused a couple of things.
Firstly, HD wallets is specified by BIP 32, not BIPs 39 or 44.
Secondly, being able to set your own seed is completely unrelated to setting a custom derivation path. They are two different things that have no effect on each other.
Note that BIP 39 specifies a menmonic scheme, not a seed. When I say mnemonic, I will be referring to BIP 39 mnemonics. When I say seed, I refer to BIP 32 seeds. They are two different things.

Bitcoin Core has had BIP 32 HD wallet support since 0.13. Since 0.17, it has had a sethdseed RPC which allows you to replace a wallet's BIP 32 seed with a custom one or a newly generated one. Note  that this does not allow you to have multiple active seeds in one wallet.
While you can set a HD seed with sethdseed, you cannot set a BIP 39 mnemonic. BIP 39 mnemonics and the seeds that they produce are incompatible with Bitcoin Core.
Lastly, while you can set a new HD seed, you cannot change the derivation paths that are used to derive keys. Bitcoin Core does not follow BIP 44's derivation path specification. Instead it uses m/0'/0'/i' as the derivation path for receiving addresses, and m/0'/1'/i' for change addresses.


text:
Electrum personal server rescan-script.py
when i run the rescan script i get the following output:
Traceback (most recent call last):
  File "/home/bitcoin/electrumserver/eps/rescan-script.py", line 71, in <module>
    main()
  File "/home/bitcoin/electrumserver/eps/rescan-script.py", line 67, in main
    rpc.call("rescanblockchain", [height])
  File "/home/bitcoin/electrumserver/eps/electrumpersonalserver/jsonrpc.py", line 58, in call
    raise JsonRpcError(response["error"])
electrumpersonalserver.jsonrpc.JsonRpcError: {'code': -32601, 'message': 'Method not found'}

I am very new to this, so please explain for beginners :).

What version of Bitcoin Core are you using?

Running "version": 160200

Make sure that the wallet is enabled in Bitcoin Core. Electrum Personal Server relies on the wallet. Check that you are not starting Bitcoin Core with -disablewallet or that disablewallet=1 is not in your bitcoin.conf file.


text:
Bitcoin raw transaction with manually created redeem script
I am running bitcoin in regtest mode with 2 nodes bitcoinNode1 and bitcoinNode2.I have created a redeem script by writing the opcodes and converted into hex form using btcc.
HP-ProBook-440-G4:~$ btcc OP_IF OP_SHA256 a967bf5e8ca09e059d6bb7a3efa8f62190284649d3eab773518827164ac481fb OP_EQUALVERIFY OP_DUP OP_HASH160 f5fb6147ff889a392211d0f0831a71137bedbff1 OP_ELSE OP_200 OP_CSV OP_DROP OP_DUP OP_HASH160 cac5d03956494ffc17f78ea7b71189abf7f3593d OP_ENDIF OP_EQUALVERIFY OP_CHECKSIG

O/p: 63a820a967bf5e8ca09e059d6bb7a3efa8f62190284649d3eab773518827164ac481fb8876a914f5fb6147ff889a392211d0f0831a71137bedbff167064f505f323030064f505f4353567576a914cac5d03956494ffc17f78ea7b71189abf7f3593d6888ac

Now i am trying to create a raw transaction using the redeem script.
HP-ProBook-440-G4:~$ bitcoin-cli -regtest -datadir=./bitcoinNode1 -conf=./bitcoinNode1/bitcoin.conf -rpcuser=user1 -rpcport=19001 createrawtransaction "[{\"txid\":\"818978d31bf63158612d080c4a934a78a52f52f7bc797cc1f84f6ca8cc4b2dea\",\"vout\":0}]" "[{\"63a820a967bf5e8ca09e059d6bb7a3efa8f62190284649d3eab773518827164ac481fb8876a914f5fb6147ff889a392211d0f0831a71137bedbff167064f505f323030064f505f4353567576a914cac5d03956494ffc17f78ea7b71189abf7f3593d6888ac\":0.01}]"

But i am not able to create as it says invalid bitcoin address.
Should i convert the redeem script into p2sh? If yes can you please suggest how to create p2sh and do raw transaction with that p2sh?

You can't just give Bitcoin Core the redeemScript, it won't know what to do with it. The only valid thing to give it is an address, but you have not given it an address. You need to convert your redeemScript into a P2SH address first, then you give it that address.
You can use the decodescript command to get both the p2sh and p2wsh addresses for your redeemScript:
$ bitcoin-cli decodescript 63a820a967bf5e8ca09e059d6bb7a3efa8f62190284649d3eab773518827164ac481fb8876a914f5fb6147ff889a392211d0f0831a71137bedbff167064f505f323030064f505f4353567576a914cac5d03956494ffc17f78ea7b71189abf7f3593d6888ac
{
  "asm": "OP_IF OP_SHA256 a967bf5e8ca09e059d6bb7a3efa8f62190284649d3eab773518827164ac481fb OP_EQUALVERIFY OP_DUP OP_HASH160 f5fb6147ff889a392211d0f0831a71137bedbff1 OP_ELSE 4f505f323030 4f505f435356 OP_DROP OP_DUP OP_HASH160 cac5d03956494ffc17f78ea7b71189abf7f3593d OP_ENDIF OP_EQUALVERIFY OP_CHECKSIG",
  "type": "nonstandard",
  "p2sh": "33bzAemHYJdN1XciQGqj4v48F5YFinQGcY",
  "segwit": {
    "asm": "0 6b2b3b1c6a0f8c15b5cdac185339555ec0d537304b367f73ab615d55c9719607",
    "hex": "00206b2b3b1c6a0f8c15b5cdac185339555ec0d537304b367f73ab615d55c9719607",
    "reqSigs": 1,
    "type": "witness_v0_scripthash",
    "addresses": [
      "bc1qdv4nk8r2p7xptdwd4sv9xw24tmqd2desfvm87uatv9w4tjt3jcrs2a06tv"
    ],
    "p2sh-segwit": "3Erd7hDtmrGxvyEjcaqsARh8wfBfM9m4N5"
  }
}

As you can see, you can use the address 33bzAemHYJdN1XciQGqj4v48F5YFinQGcY in your transaction. If you would like to use segwit, you can use bc1qdv4nk8r2p7xptdwd4sv9xw24tmqd2desfvm87uatv9w4tjt3jcrs2a06tv.

Thanks @Andrew. I have another question. Please guide me. After I fund the p2sh address. when i create a raw tx to redeem the fund of p2sh, i could not send to network directly. Since it needs to be signed.But how will get a private key of the p2sh address? Because when i did dumpprivkey for the p2sh , it was throwing an error "Address does not refer to a key".

For this particular script, Bitcoin Core does not know how to sign for it, so you can't use Bitcoin Core to create the spending transaction. Furthermore, Bitcoin Core doesn't know the public key for this script, nor does it even know about this script unless you imported it. While it may have the private key for a public key in this script, because this script is not one of the standard patterns that it recognizes.

Thanks @Andrew . Could you please tell me any other ways how to proceed the above one?

You will need to write some code that can make the signature and construct the final transaction. Bitcoin Core doesn't know how to sign or make the final transaction for this script, so you need to be able to do it yourself.

Thanks @Andrew . Even if i code myself , to sign such transaction how will i get private key ?

You need to figure out what public keys are involved in your script. You can then get the legacy address for them (begins with a 1) and export the private keys for those by using Bitcoin Core's dumpprivkey command.

Ok. But if I have a simple script (not involving any keys only contains hash ), in that case case how the signing take place?

Then there are no private keys. You will still need to provide the inputs to the script so that it passes validation. There is no signing in such a script, just pushing the correct items to the stack.


text:
Difficulty set by pools
Can we argue that, since the difficulty set by pools is lower than the actual one, "old" hardware remain profitable for longer and thus are used for more time. And this, indirectly, increases the actual hash rate of the entire network? (and thus difficulty as well?)

No, you see the difficulty of a pool is lower in order for the pool to be able to verify that the miners are actually working on a solution. The shares a miner obtains are mostly not valid blocks, which is what gets rewarded in Bitcoin, paid out to the pool and then paid to the miners.
The difficulty to create a block is not influenced by a pool's share difficulty, hence the total payouts the pool makes does not change, and old hardware is just as (un-)profitable.

hmm.. just posted my answer and then yours popped up. Initial reaction was to agree with you. But actually no, this is not true: as a user you are concerned with the payout. Pools actually do payout differently than solo-mining. They do payout lower difficulty work, while solo-mining with a high likelyhood doesn't. Of course the total doesn't change, but from the point of view of the individual one has to be very lucky to hit the 25 BTC jackpot and otherwise you get nothing.

Yes, indeed the reason to join a pool is to spread the income over a time. Notice I did not mention solo-mining, instead only looking at the income of the mining pool. The pool redistributes its income to its miners, since the mining pool's income depends on network difficulty that is the limiting factor. The lower share difficulty does not influence the miner's income, hence it does not influence the sum of payouts. Lower share difficulty only increases payout granularity.

Yes.
Although technically the profitability of old hardware doesn't change, it's just that the variance becomes killing if your hash rate is too low. Getting 0.1 BTC per day or having a 1 in 250 days chance of getting 25 BTC, changes the game from a lottery to a steady predictable income.
This also has the effect of allowing small miners (even with new hardware) to play along.
Yes, both those effects do increase the total hash rate of the network and thus the difficulty. And in that regard the security and decentralization of the network. Except that in most pool solutions, the pool maintainer needs to be trusted as a "centralized" party. Mixed blessing there.

Yes. Pools were invented to keep CPU miners in the game when GPU-mining begun. In the same way they are now keeping small home miners in the game, in a world now dominated by warehouse-size miners.


text:
Can exist bitcoin network with all nodes behind NAT?
If I run bitcoin client for the first time its try to make TCP connection with saved list of IPs and port 8333 -other nodes. If this nodes are behind NAT with IP 192.168.0.XX and public IP from the NAT router with changed from NAT unknown port its appears that bitcoin network is down? Or bitcoin client will try to make UDP/TCP hole punching connection? If its mandatory for some miner to have public IP address?

Can exist bitcoin network with all nodes behind NAT?

Sure. Both the Bitcoin client and many SOHO routers support UPnP. Failing that, Bitcoin users could set up port forwarding.

Or bitcoin client will try to make UDP/TCP hole punching connection?

No, it won't do that.

If its mandatory for some miner to have public IP address?

Generally, mining pools will have a public IP address. There's no reason why you couldn't set up a mining pool server behind NAT and use port forwarding to make it public, but it would be a very strange way to set things up.

If I disable UPnP on my NAT router and start bitcoint client what happened?

Outbound connection to nodes with public IP is possible but inbound connections with router UPnP disabled?

This means that I will not receive money notification if I have disabled UPnP in my router and bitcoint client not know other nodes with public IP


text:
what this parameters do end what i need put on them in blockchain ver2
/** What block version to use for new blocks (pre versionbits) */
static const int32_t VERSIONBITS_LAST_OLD_BLOCK_VERSION = 4;
/** What bits to set in version for versionbits blocks */
static const int32_t VERSIONBITS_TOP_BITS = 0x20000000UL;
/** What bitmask determines whether versionbits is in use */
static const int32_t VERSIONBITS_TOP_MASK = 0xE0000000UL;
/** Total bits available for versionbits */
static const int32_t VERSIONBITS_NUM_BITS = 29;

bip's 65 end 66 are on 3 end 4 version block's. But blockchain latest block is 2 version. What value i need put on this for upgrade when new block's be mined to ver 3 end 4.
or i need change the bip 65 end 66 to the same block ver4, end put value prev block to 2 ? How it do correctly

uh, four downvotes without explanation... could someone explain? I see that tseries is new here, trying to read and understand the code, and get involved, shouldn't this merit some understanding? Even if english seems not to be native language (same with me). @tseries: I feel the question is not precise enough, so people find it difficult to help out. You might explain a bit more, what you intend to do. BIP66 is "Strict DER signatures" and BIP65 is "OP_CHECKLOCKTIMEVERIFY" - at least for bitcoin world... difficult to see, how this relates to blockchain version code you mention.

The downvotes are likely because the question is unclear as to what the question actually is.

static const int32_t VERSIONBITS_LAST_OLD_BLOCK_VERSION = 4;

no need for change, for old blockchain need add in
consensus.BIP65Height = 4; //  Block with what start bip if it's old block chain need add block 1,2,3 next block after block chain ( for people update before the this block can be mined.
consensus.BIP66Height = 14; // this to, but + count off blocks in nMinerconfirmationwindow.

consensus.nRuleChangeActivationThreshold = 6; // 75% of 8064
consensus.nMinerConfirmationWindow = 8; //

End bip's be activated after this count of block be mined.
end you cant answer this simple question ?


text:
What value of nMinimumChainWork and powLimit should I choose for my altcoin?
// The best chain should have at least this much work.
        consensus.nMinimumChainWork = uint256S("0x000000000000000000000000000000000000000000000005c13f99f6d0b1a908");

how to calculate this parameter, i little not understand. It's not block in blockchain, how find this value if altcoin exist end i update sources with exist blockchain end for new blockchain.
consensus.powLimit = uint256S("00000fffffffffffffffffffffffffffffffffffffffffffffffffffffffffff");

end about this value , how it convert to diff xxx for understand what diff is it. example diff 1, 20, 1000 etc...

how to calculate this parameter, i little not understand. It's not block in blockchain, how find this value if altcoin exist end i update sources with exist blockchain end for new blockchain.

Because this is a new chain, the minimum should be zero.

end about this value , how it convert to diff xxx for understand what diff is it. example diff 1, 20, 1000 etc...

It is diff 1, by definition.

if it's not new , if exist 2000+ blocks , or you mean this ?
you can write example of zero ? end how calculate it in future , how this value find I do not understand. :/

You can use the getblockchaininfo RPC to find chainwork in the future.


text:
what do these values in chainparams.cpp do?
what do these values in chainparams.cpp do?
consensus.nMajorityEnforceBlockUpgrade = 2;
consensus.nMajorityRejectBlockOutdated = 3;
consensus.nMajorityWindow = 3;

and how do I find them in the existing blockchain when upgrading end for new?
first time I think it's when start diff grow up, but now think it's wrong.

Those values are part of the IsSuperMajority soft fork deployment system. This method of deploying soft forks is no longer used in Bitcoin now and have been removed. Those values are for the parameters that will activate a soft fork that uses the IsSuperMajority method; they are not relevant if you don't have any soft forks to deploy.
nMajorityEnforceBlockUpgrade is the threshold for enforcing the new consensus rules specified by the soft fork.
nMajorityRejectBlockOutdated is the threshold for rejecting all blocks that don't have the version number specified by the soft fork.
nMajorityWindow is the number of blocks in the window that are being checked.
For example, with the numbers you posted, suppose you are activating a soft fork where miners signal by setting their block version numbers to 2 or greater. If 2 (nMajorityEnforceBlockUpgrade) out of the last 3 (nMajorityWindow) blocks have a version number of 2 or greater, then you begin enforcing the new rules specified by the soft fork (e.g. block height in coinbase). If 3 (nMajorityRejectBlockOutdated) out of the last 3 (nMajorityWindow) blocks are version number 2 or greater, then any block with a version number less than 2 (i.e. 1 or 0) are now invalid and will be rejected.

what do these values in chainparams.cpp do?

If nMajorityEnforceBlockUpgrade out of the last nMajorityWindow blocks have signaled support for a softfork, enforce the softfork's rules on the blocks that have signaled support.
If nMajorityRejectBlockOutdated out of the last nMajorityWindow blocks have signaled support for a softfork, mark blocks with an old version as invalid.
These are for BIP34 style softforks.

authors: Максим Калюжный


text:
Creating secure architecture and payout process
I studied lots of valuable q&a here, but still I have some doubts.
Case - simple game (calm down - I'm not one of the rookies creating exchange as seen here), which allows to pay for a game. The character of the gameplay forces us to create virtual balance for each player and create payouts on daily basis/request.
What's done:

compiled bitcoind client is running on encrypted wallet in background
creating in advance pool of addresses
assigning free address to registered user
listen for incoming transactions/confirmations
on 6th confirmation we add transaction to user balance

Where I need guidance / pro advice:

strip my runnning bitcoind client with wallet from holding private keys (I've read about it but don't know how to achieve it properly)
many guides advice to run bitcoind client on other machine - but how to setup secure communication between two machines (vpn?), if someone gains access to game server, it doesn't matter where client is located (right?)
as private keys are stored away, how I can deal with payout requests? Are there known practices in that field? I've read https://bitcoinsecurityproject.org/SecureApplicationArchitecture/, but can't imagine real world example/process

Last but not least - if users send coins to private addresses created in one wallet, which private key should sign a transaction? As you probably see, I'm confused with some "basics" after research here :)
EDIT
I found steps to sign transaction offline (http://people.xiph.org/~greg/signdemo.txt) is it preferable way in real world apps?

You're going to  be doing some fun stuff if you need a complex system.
The Simple Way
Just use Bitcoind along with it's walletnotify and blocknotify arguments. See here. As soon as you get a walletnotify, store it in a database and make sure txid is unique. Walletnotify fires multiple times throughout a transaction's life. Check the database every block looking for unprocessed transactions that have 6 confirms. Those that do should get marked as "processed" or get deleted from the database.
The Hardcore Way
If you need the functionality like described. Consider using one of the many libraries that implement some Bitcoin features and function. Check out Bitcoinj (java), Libbitcoin (C++), Gocoin (Go), and the many python libraries that can be found through search. These libraries can make it a lot more simple to run a more finely controlled and specialized node.

Thanks for the input, we already done incoming payments. I have biggest doubts when it comes to payouts where high security is a must...

My bad, but payouts are hard to game on the Bitcoin side, once you push your transaction it's a done deal. But watch out for stuff like race conditions where a user can send you hundreds of requests in the a small time frame. Make sure your database and code process these atomically.


text:
cgminer settings "--load-balance" vs "--balance"?
http://www.amilitalia.it/github.com/ckolivas/cgminer.html
I'm looking for the best balance:
--load-balance Change multipool strategy from failover to quota based balance

and
--balance Change multipool strategy from failover to even share balance

How exactly it works?
E.g. there are 2 pool for different alt-coins with scrypt algo.

1st pool: difficulty 1.1234
2nd pool: difficulty 10.123

Is --balance set my cgminer to 90% for the second pool? Say, it will waiting for balance of ACCEPTED shares.
And --load-balance set power of cgminer to 50%/50%?

I'm afraid that one pool might go slow, will not give jobs. Will cgminer wait for this pool with --balance to keep balance of shares?

Peoples, I know that this is very old, overgrown with moss topic. Could somebody provide me with true link to the answer?

From: https://github.com/ckolivas/cgminer/blob/master/cgminer.c
/* In balanced mode, the amount of diff1 solutions per pool is monitored as a
 * rolling average per 10 minutes and if pools start getting more, it biases
 * away from them to distribute work evenly. The share count is reset to the
 * rolling average every 10 minutes to not send all work to one pool after it
 * has been disabled/out for an extended period. */

So --balance looks to the diff1 count and tries to get an even distribution.
--load-balance looks at the --quota values and distributes work in proportion to the GCD of them, counting down until remaining quotas are all 0 and the values are reset.


text:
Possible attack vector of BIP32 HD wallet
I've been reading about BIP32 HD wallet and it's implementation and came across a few questions regarding the possible known "attack" vector of leaked private child keys and known xpub parent key leading to the discovery of the parent private key.
Given the following path of an HD wallet:
m/b/p/c
Where m is the master node derived from a seed, b, p, c being indexed nodes in different depths.
Imagine that a server is watching and creating receiving c addresses from p's xpub. If one of c's node's private key gets leaked and the server gets hacked, thus revealing xpub to the attacker, the attack could now generate p's xpriv and with that, all of c's node's private and public address could be derived by the attacker (hardened c nodes included).
First question: If p was a hardened node, could the attacker still calculate its private key from it's xpub and a child's private key ?
Second question: Could the attacker "climb up" the depth (calculate parent's xpriv) from p all the way over to m after calculating p's xpriv from the leaked c key and p's xpub ? Would a hardened b or p make a difference here ?
Third question: If a private key from c's depth was leaked and the attacker knew m's xpub, could the attacker calculate m's private key or does the exploit only permits calculating the direct parent of a leaked child ?
Bonus question: Could anyone give actual use cases for using one or more hardened nodes in a path ?

First question: If p was a hardened node, could the attacker still calculate its private key from it's xpub and a child's private key ?

Yes. It doesn't matter how p was generated. What matters is how c is generated.

Second question: Could the attacker "climb up" the depth (calculate parent's xpriv) from p all the way over to m after calculating p's xpriv from the leaked c key and p's xpub ?

Only if the attacker also has b and m's xpubs. An important part of the derivation is the parent's chaincode. The chaincode is part of the xpub and if the attacker does not have the chaincode, then he cannot derive the parent's private key.

Would a hardened b or p make a difference here ?

If the attacker had b and m's chaincodes, yes, hardening would make a difference. Hardening entirely prevents this attack. However hardening does not allow someone to have an xpub and be able to generate keys without the private key.

Third question: If a private key from c's depth was leaked and the attacker knew m's xpub, could the attacker calculate m's private key or does the exploit only permits calculating the direct parent of a leaked child ?

The attack only operates on a child key and its direct parent extended public key.
However, given m's xpub and cs private key, it may still be possible to recover m's private key even though it is not c's direct parent. If b and p are derived using unhardened derivation, then m can be used to derive b and p's xpubs. From there, with all of those xpubs, the attacker can work backwards from c in order to get m.
If b and p are hardened, then it is not possible.

Bonus question: Could anyone give actual use cases for using one or more hardened nodes in a path ?

Take BIP 44 for example. It define a standard derivation path of m/44'/0'/0'/i/k. The xpub at m/44'/0'/0' is given out. But since it itself is derived with hardened derivation, if any of m, m/44' or m/44'/0''s xpubs are leaked, the user's master key is still safe since hardened derivation is used.
Additionally, Bitcoin Core derives all keys using hardened derivation. This is because it uses BIP 32 for the easier backup function (you can use an older backup and still get all of the same keys) rather than for the auditability.

Chaincodes are intended to be shared with others-- not published on the blockchain, but not secret data.  Describing BIP32 public derivation being secure against private key relations so long as the attacker doesn't know the chain code is technically correct, but might be a little dangerously misleading.

So in the above path, if any c's xpriv and p's xpub were known, only c's nodes would be exposed and the attacker couldn't do anything else to the rest of the c's parent nodes. In essence, hardening nodes is only useful in a scenario where m or b's xpubs are also known, rendering the whole tree exposed with any c private key, is that correct ?

Yes, that is correct. But as G. Maxwell points out, the chaincode is meant to be shared and sharing the chaincode will result in the entire tree be exposed.

Alright that's all I needed to know, thank you !