text:
XAPO's flow from wallet to vault - a different wallet address used for the transfer
I have a XAPO account and I moved a bitcoin from Bittrex from XAPO. Now, XAPO has provided me with a wallet address a1.
Now when I have moved my bitcoin from my bitcoin wallet to vault and checked the transaction in the blockchain.info, I was kind of surprised that from address was different from original deposit address a1.
Also, looking into blockchain.info, I was surprised to find that my deposit address a1 was used to send bitcoin to other addresses as well which I have never initiated. So, it looks like XAPO has provided the same deposit address a1 to other users as well, which is not good. In that case, I have to be dependent on their internal ledger to claim my funds, no?
Will the withdrawal process be same as well, meaning when I withdraw from Vault to wallet, the from address will be different from what I see now as my vault address, b1? And when I finally move my fund out from wallet to let's say Bittrex, that txn will also show a different from address?
In addition to that, if XAPO regularly moves the fund around, won't it cost them a lot of fees?

Now when I have moved my bitcoin from my bitcoin wallet to vault and checked the transaction in the blockchain.info, I was kind of surprised that from address was different from original deposit address a1.
Also, looking into blockchain.info, I was surprised to find that my deposit address a1 was used to send bitcoin to other addresses as well which I have never initiated. So, it looks like XAPO has provided the same deposit address a1 to other users as well, which is not good.

Instead of thinking as the addresses being "my addresses", think of them as Xapo's or the exchange's addresses. You are not depositing into your wallet, you are depositing into Xapo's or the exchange's wallet and the addresses they give you belong to their wallet. When they receive your transaction, they just update an internal database for your account's address. The money that you deposited becomes the service's money and they promise to give you back the same amount when you ask for it. This is similar to how banks work

In that case, I have to be dependent on their internal ledger to claim my funds, no?

Yes. This is the same for basically all exchanges and all online wallet services (with a few exceptions). They are custodial, you give them money and they promise to give you back the same amount when you ask for it. In the meantime, they can do whatever they want with the coins. This model is generally easier to implement and less costly as the service can move around coins to reduce cost later.
Furthermore, instead of then having to keep everyone's coins in hot wallets (wallets that are connected to the internet), they can move most coins to cold wallets (wallets that are not connected to the internet) and keep some in hot wallets for people who wish to withdraw. Actually assigning and "spending from" addresses for each user results in perpetual hot wallets which is not secure.

Will the withdrawal process be same as well, meaning when I withdraw from Vault to wallet, the from address will be different from what I see now as my vault address, b1? And when I finally move my fund out from wallet to let's say Bittrex, that txn will also show a different from address?

Yes. The transaction will "send from" addresses that belong to other people as is convenient for the service.

In addition to that, if XAPO regularly moves the fund around, won't it cost them a lot of fees?

Xapo probably isn't actually move the coins around internally, but rather the coins that you deposited went into their hot wallet and someone requested a withdrawal so those same coins were sent to that person.

Thanks for your detailed answer Andrew. Appreciate it. One thing I have noticed in case of XAPO is that once I deposit BTC in the deposit address, XAPO moves it to its other hot/ omni wallet and that wallet is usually active and can accept a lot many BTCs. However, Coinbase limits the number of BTC in any hot/ omni wallet. Usually once the hot wallet reaches some amount of BTC, it moves them to other address, probably to reduce the amount of risk. Also, I have not done the extensive analysis..


text:
Bitcoin-cli access - how do I access it?
newbie question here. I am trying to learn to interact with the Bitcoin blockchain and I want to use the native SCRIPT language.
I already downloaded the entire node and synced on an AWS Linux Ubuntu but I did it using Bitcore.io.  I can see it's using Node.js and I can see no option of using the bitcoin CLI. The best tutorials out there are in for Bitcoin's native language.
Do I have to re-download the entire chain from bitcoin.org in order to the native command line?
I want to use all the features, not just a 'light' option like BitcoinJ.
Any suggestion appreciated.

bitcoin-cli is a completely separate binary that you may need to install. Also, you cannot just "use the native script language" with bitcoin-cli; the scripting language is for transactions.

of course you can. There is even a resource for woking with scripts.https://github.com/ChristopherA/Learning-Bitcoin-from-the-Command-Line
My question was what do I do now after I installed the node with bitcore instead of using the bitcoin.org. Is it possible to link the bitcoin-cli with my node?

That tutorial doesn't use bitcoin-cli for anything with scripts except examining them. To do anything else, you have to use other software. Anyways, to use bitcoin-cli you have to have bitcoind (aka Bitcoin Core) installed. bitcoin-cli only works with bitcoind.

Thanks a lot Andrew, I understand now. I made a confusion between the bitcoin-cli and using other software.

source: Stack Exchange

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

sort: votes


text:
How to create a P2SH address which will be the hash of a redeemScript
Suppose I have a redeemScript and I want to create a P2SH address corresponding to the hash of that redeemScript. How do I do it?
I was thinking of bitcore-lib but I'm not sure I am going in the right direction. Below is my staring point and I am not sure what to do next.
Also the scriptPubKey appears to be 0x04 and it has to be 0x05.
And how do I further generate my keys for this new address?
> var bitcore = require('bitcore-lib');
    undefined
    > var redeemScript = bitcore.Script.fromASM('OP_SHA256 001xxxxxxxxxxxxxxxxxxxx6 OP_EQUAL');
    undefined
    > var scriptPubKey = redeemScript.toScriptHashOut();
    undefined
    > scriptPubKey
    <Script: OP_HASH160 20 0x04xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx6 OP_EQUAL>
    > scriptPubKey.toAddress()
    3xxxxxxxxxxxx
    > scriptPubKey.toHex()
    a914xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx287

Another option will be to use this:
https://github.com/bitcoinjs/bitcoinjs-lib/blob/master/test/integration/addresses.js#L19
Thanks!

Do you really want to create ANYONE_CAN_SPEND address? (I can help you, but for Qt/C++, not for js)

This is for my thesis at University. Unfortunately I am still learning JS and I am afraid C++ will be too much over my head. Thank you.

Quick and dirty code for your task. Hope it helps.
1) Let us create address from secret.
static void p2sh_create ( )
{
  const MyByteArray secret ( QByteArray ( "My secret phrase" ) );
  const MyKey32 sha256 ( secret.sha256 ( ) );
  const MyByteArray redeemScript ( MyByteArray ( ).putInt8 ( OP_SHA256 ).putPush ( sha256 ).putInt8 ( OP_EQUAL ) );
  const MyKey20 hash160 ( redeemScript.hash160 ( ) );
  const QString address ( hash160.toStringP2SH ( ) );

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

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

2) Now let us fund the address 2NG482PHrj6f41UoqUHYGVkUR39oB3UvWkE. Follow the link https://testnet.coinfaucet.eu/en/ and ask for some test coins. Testnet faucet sent me 0.86978283 TBTC in transaction https://testnet.smartbit.com.au/tx/21c181c6052f6266ea6c936cf86111d6a2662a1f1e3251560b718fb8b1e6457d
3) Now create spending tx from this address.
static void p2sh_spend ( )
{
    const MyByteArray secret ( QByteArray ( "My secret phrase" ) );
    const MyKey32 sha256 ( secret.sha256 ( ) );
    const MyByteArray redeemScript ( MyByteArray ( ).putInt8 ( OP_SHA256 ).putPush ( sha256 ).putInt8 ( OP_EQUAL ) );
    const MyByteArray tx ( MyByteArray ( )
      .putInt32 ( TX_VERSION )
      .putInt8 ( 1 )
      .putArray ( MyKey32::fromHex ( "21c181c6052f6266ea6c936cf86111d6a2662a1f1e3251560b718fb8b1e6457d" ) )
      .putInt32 ( 1 )
      .putPrefixed ( MyByteArray ( ).putPush ( secret ).putPush ( redeemScript ) )
      .putInt32 ( TX_SEQUENCE )
      .putInt8 ( 1 )
      .putInt64 ( 86978283 - 200 )
      .putPrefixed ( MyByteArray ( ).putInt8 ( OP_HASH160 ).putPush ( MyKey20::of ( "2N8cj6kf3RkPHzQSCG13bvq6iXXWWPuGurZ" ) ).putInt8 ( OP_EQUAL ) )
      .putInt32 ( TX_LOCK ) );
    const MyKey32 txid ( tx.sha256d ( ) );

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

The output is:
tx   = "01000000017d45e6b1b88f710b5651321e1f2a66a2d61161f86c936cea66622f05c681c1210100000035104d79207365637265742070687261736523a82073d83ecabab6ba96a47f03d0e21ffbdfeaab5d337b7e93a0cc2e85019190fb3f87ffffffff01232e2f050000000017a914a89aec4cd53e6d74215332459b7fea3ec4aca9758700000000"
txid = "75e0904ca3f8895c6f6af45f1c7f3d1f9dcee32814ca144852bce669a5ee4421"

4) Now push the tx to the network: https://testnet.smartbit.com.au/txs/pushtx
5) Voila! https://testnet.smartbit.com.au/tx/75e0904ca3f8895c6f6af45f1c7f3d1f9dcee32814ca144852bce669a5ee4421

Thanks a lot! I will accept your answer but I wish I can reproduce this, I guess is C++? Do you have any suggestion on where to start? I remember  a while ago about Visual C++ ( I am on windows) but not sure if it's what I need to reproduce your sample.

Seconding this^.

you are welcome to ask me any additional info/sources. i am not sure that understand your task correctly. my code is just a quick example

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


text:
Why not every [x,y] coordinate on the Secp256k1 curve corresponds to a valid uncompressed publicKey?
First, some background.
1. There are some coordinates x,y satisfying y^2(mod p)=x^3+7(mod p) on the Secp256k1 curve that do not correspond to a valid Bitcoin uncompressed publicKey of the form 04[x,y].
We can prove 1 using the random_point() function in Sage with unknown generator underE=EllipticCurve(GF(modi), [0,7]). If we get lucky, after a few trials Sage returns a point such as Q.
   Q=E.random_point()

   Q
   (B8F0170E293FCC9291BEE2665E9CA9B25D3B11810ED68D9EA0CB440D7064E4DA :
    691AA44502212591132AA6F27582B78F9976998DE355C4EE5960DB05AC0A2A3 : 1)

Now we have:
   Qx=B8F0170E293FCC9291BEE2665E9CA9B25D3B11810ED68D9EA0CB440D7064E4DA
   Qy=691AA44502212591132AA6F27582B78F9976998DE355C4EE5960DB05AC0A2A3

We verify that Qy^2(mod p) = Qx^3+7 (mod p) is satisfied so we confirm that Q is a point on the Secp256k1 curve.
Next, we try to validate Q as an uncompressed Bitcoin publicKey:
04B8F0170E293FCC9291BEE2665E9CA9B25D3B11810ED68D9EA0CB440D7064E4DA691AA44502212591132AA6F27582B78F9976998DE355C4EE5960DB05AC0A2A3

We get: Q is not a valid publicKey.
Yet, checking the validity of the mirrored point -Q, returns a valid publicKey:
   -Qx=B8F0170E293FCC9291BEE2665E9CA9B25D3B11810ED68D9EA0CB440D7064E4DA
   -Qy=F96E55BBAFDDEDA6EECD5590D8A7D4870668966721CAA3B11A69F24EA53F598C

Valid publicKey for -Q:
04B8F0170E293FCC9291BEE2665E9CA9B25D3B11810ED68D9EA0CB440D7064E4DAF96E55BBAFDDEDA6EECD5590D8A7D4870668966721CAA3B11A69F24EA53F598C

Valid publicKey for -Q (hashed):
1A2gaiiKy91Pmx8EUcbT4Hd6JFZ3sQvUhM
Question:
Why not every [x,y] coordinate on the Secp256k1 curve corresponds to a valid uncompressed publicKey?
Note:
In this question, by validity I mean a set of EC coordinates (x,y) that can be hashed into a bitcoin uncompressed address. I am specifying uncompressed for obvious reasons. My question is detailed enough I hope to show that it's not referring to compressed Bitcoin addresses.

Both are valid public keys just that in the first case the uncompressed public key is not represented in a valid hexadecimal format. If you look closely, your Qy has 63 hexadecimal digits (so there is a 'half-byte'). Although hashing can be done in bit boundaries, most standard implementations out there do not support it.  Just try to concatenate '0' at the start of the Qy to get Qy = 0691AA44502212591132AA6F27582B78F9976998DE355C4EE5960DB05AC0A2A3 so that you get a full byte. So now your uncompressed public key is 04B8F0170E293FCC9291BEE2665E9CA9B25D3B11810ED68D9EA0CB440D7064E4DA0691AA44502212591132AA6F27582B78F9976998DE355C4EE5960DB05AC0A2A3, which would hash to P2PKH address: 17Y1XJiC72f2kyJnzwBdkaPQEGgaD1aroR

Excellent! Thanks for your prompt answer.


text:
Bitcoinjs module missing issue
I am trying to run this code with node and bitcoinjs-lib but I keep getting missing lib.
Any idea what am I missing?
I am on a Windows Server 2016. I try to create a P2SH address by hashing a redeemScript.
// OP_HASH160 {scriptHash} OP_EQUAL
var bitcoin = require('bitcoinjs-lib')
var bscript = require('../../script')
var types = require('../../types')
var typeforce = require('typeforce')
var OPS = require('bitcoin-ops')

function check (script) {
  var buffer = bscript.compile(script)

  return buffer.length === 23 &&
    buffer[0] === OPS.OP_HASH160 &&
    buffer[1] === 0x14 &&
    buffer[22] === OPS.OP_EQUAL
}
check.toJSON = function () { return 'scriptHash output' }

function encode (scriptHash) {
  typeforce(types.Hash160bit, scriptHash)

  return bscript.compile([OPS.OP_HASH160, e216c9ev2d0drec3xxxxxxxxxxxxxxa3b5576d9176, OPS.OP_EQUAL])
}

function decode (buffer) {
  typeforce(check, buffer)

  return buffer.slice(2, 22)
}

module.exports = {
  check: check,
  decode: decode,
  encode: encode
}

Error is this below, but couldn't find this lib 'script'.
Error: Cannot find module '../../script'
    at Function.Module._resolveFilename (module.js:547:15)
    at Function.Module._load (module.js:474:25)
    at Module.require (module.js:596:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (C:\Program Files\Bitcoin\rob\hash2.js:3:15)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)

Thanks!

Your file is in the directory:
…/hash2.js

while the script module is in
…/src/script.js

The relative path between these two would be ./src/script while your file is prescribing to find it in ../../script.
Once you correct the relative path, your program should be able to find the module.

I was trying to do that, but the only 'script' I could find is a .js file under the subfolder /src.
Here are some screenshots.
https://i.imgur.com/F8PMdmH.png
https://i.imgur.com/1fgdo6U.png
Maybe I am entering the wrong path or that is not the .js file required?

And what is the location of your file?

This one: https://i.imgur.com/F8PMdmH.png
hash2.js


text:
bitcoin-cli sendrawtransaction gives odd error 16
When I submit the tx below with bitcoin-cli sendrawtransaction I get the error
16: mandatory-script-verify-flag-failed (Script evaluated without error but finished with a false/empty top stack element)
0100000002b985f8795160347be87893a47801c7bf107ad0d1ebd46c222de4f002d3d7d511020000006b4830450221008831a735a9b14c1d0b8f532237ba0832b8f829c6aa2634b48c359dcc78b45cb402200ba4fc6ed07ed970276b749fad7d5aeb7a8f80982fc2455465ca7b9c71e8a1210121037f473ce56001b7f20fe2b326196b774316d109163fa36a817c558fe0e16e3370ffffffff71f8fb5cb6ea5c24213a451e7437665ed96837c106a9c5e280245de4a4ea0c36020000006b483045022100c9ca77c70337b3cbc42c6f2d8940682e7becb756f214285904d41038a01127d402201c517a27944999d9a22d6cc8e8845af86bcd4c098a81fc8885cf57e72fa50bfb0121039975ef4f64dc31c0f33fcdb339115c7d96ccf9a8223a8fec38200862add6fd5affffffff02706f9800000000001976a9149dd0bc1927d4a65ebff0d0568aea36a22502dd1688ac80969800000000001976a914823e7e7b65b116acb6deb4ed54d8c04603c0644a88ac00000000
What's wrong with my tx?

When a scriptSig/scriptPubKey executes, it's supposed to leave an element that evaluates to true on the top of the stack. Both of these are Pay to Public Key Hash inputs, so that means that OP_CHECKSIG failed for at least one of your inputs. Check the signatures.

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


text:
Increasing the odds when solo mining with low-medium hashrates
I never saw anything concrete related to this so I dare to ask here.
First, my situation:
I'm currently mining solo, on a private pool, with roughly 350Th/s. That to be increased soon with another ~200Th/s.
I know my odds, right now, from the plenty online calculators, I should solve a block roughly once a month at this diff.
But, would either or both of these following measures increase my chances?
 - First is running the pool bitcoin daemon as a full node with port 8333 open to the world.
 - The second is lowering the relayfee which is default to 0.00001000B.

No, neither of these things will help.
The only thing that really affects your chances is your hash rate, and the measures you describe do nothing to help it.
One other thing that can make a very slight difference (< 1%) is latency: the time it takes you to receive new blocks from the Internet (or work from your pool), and to send out your own.  In the unlikely event that you find a block very close to the same time as someone else, these would slightly increase the chance that your block is received first by other miners, and thus decrease the chance that it is orphaned.  But if your pool servers are properly run, they should be doing this pretty efficiently already.  Maybe faster than your own full node would be.
The relayfee has no relevance to mining.  If anything, you'd want to increase it, so that you relay fewer transactions and thus save bandwidth for receiving and sending mining work.  But this effect would likely be negligible anyway.

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


text:
When is a new block added to the bitcoin blockchain and is it vulnerable to modifications till then?
I'm a beginner to Bitcoin and blockchain and from what I understand, one block can hold multiple transactions. Until a block is saturated with the number of transactions it will eventually hold, where are all these transactions stored?
Until a transaction is added to a block whose hash is finally computed and the block added to the blockchain, how are the transactions tamperproof?

a block is assembled by the decision of a miner. If he wants to, he cannot include transactions at all. If he includes tx, then he uses tx out of his mempool. tx are normally verified before entering into a block. If the miner decides to tamper with a tx (change its contents), then when sending the block to the network, other nodes will reject this block, cause it contains an invalid tx.

Until a transaction is added to a block ... how are the transactions tamperproof?

tx be tamperproof doesn't make sense, while the block is created. It is at the risk of the miner! If he wants to win the block reward, he better transmits correct blocks into the network.
The whole idea of bitcoin is, to better play well and get incentivized for it. If you try to play against the network, you have enormous costs to carry.


text:
Wallet's role in a double spend attack
How does my wallet allow me to double spend? As soon as I make a payment, shouldn't my wallet delete those bitcoins or does it leave them until the transaction is added into the blockchain?


text:
Easy way to accept bitcoin payments without external service
Is there a way to accept Bitcoin payments without running a full node or rely on an external service?
I'm thinking in some way to validate the transaction and then broadcast it to the network.

If you're not running a Bitcoin client of some sort, or referencing a 3rd party (rely on an external service) then your usability will suffer.
For example you can create private keys and address pairs for receiving funds using a library, so you can accept payments just fine without a node or a 3rd party. The draw back is you don't have a way to monitor the blockchain, check for UTXOs, or push transactions.
If you're looking to do those things as well with as little 3rd party as possible, I'd suggest use a library to create addresses, and build transactions, and then line up a series of open API's that allow you to check the UTXO set, and push a signed transaction. If one fails, then hit the next one, and if that fails hit the next, etc. It's a little extra work, but you won't have to sign up with a service, you don't have to run a node, and you don't have to feel like you're relying on an API service since you'll have fall backs.
Here are some push tx endpoints:
https://api.blockcypher.com/v1/btc/main/txs/push
https://chain.so/api/v2/send_tx/BTC/
https://btc.blockr.io/api/v1/tx/push
Here are some APIs to get the UTXO of an address
https://blockchain.info/unspent?active=1bitcoineateraddressdontsendf59kue
https://chain.api.btc.com/v3/address/1bitcoineateraddressdontsendf59kue/unspent
https://api.smartbit.com.au/v1/blockchain/address/1bitcoineateraddressdontsendf59kue/unspent

You can accept by having a QR code.  Where the sender will broadcast the transaction on your behalf.

but how do i check the payment has actually been done?

You could make this a better answer by explaining where the QR code comes from, and answering how to check that the transaction was broadcast.

I've downvoted this answer, because it doesn't provide sufficient explanation to address the answer fully.


text:
INPUT Script with no ScriptSig?
Anyone knows what does it mean when there is no ScriptSig under INPUT SCRIPT for a TX?
See here:
https://i.sstatic.net/Kg19o.jpg
Thanks!

It would help to see the raw transaction, then one could use „decoderawtransaction“ and analyze the details... at least on my iPad the imgur image seems to be blank... no hexcodes visible

It seems to be a witness transaction according to your screenshot (you can see the same missing scriptSig followed by witness here).
Segwit encodes the signature information slightly differently from the regular script sig, so it will not show up under that heading. A segwit transaction would still contain the information you would traditionally see in the scriptSig, but in the witness section instead.

This seems to be the case. Thanks! I also found this website where we can see details regarding segwit trx's [link]https://blockchair.com
blockchain.info is not very segwit friendly.

If it's a P2SH output and the redeem script is OP_TRUE then it's an anyone-can-spend and you don't have to provide anything in the scriptSig

This is not correct.

@eponymous could you elaborate how it is wrong so I can edit/delete it?

It's explained in the other answer, it has a witness.


text:
Where can I find examples of Node JS code for P2SH transactions (funding and spending)
I have the following example, on which I admit I am stuck:
Bob sends 0.5 BTC to Carla, who is the owner of a P2SH address of the form 3xxxxxx.
For Carla to spend the 0.5 BTC and pay Josh, who also has a 3xxxxxx P2SH address, she needs the redeemScript from Bob.
Let's say she has that from Bob and Carla sends to Josh the 0.5 BTC. Now we have a TRXO of 0.5 which can be seen on blockchain explorer under Josh's address.
To spend the TRXO, Josh also needs the redeemScript, right? Is it the same one as Bob's redeemScript?
According to Andreas's book, the redeemScript required for spending from a P2SH address is revealed after the first Output spent from the funding address.
So simply by looking at the scriptSig: under Bob's INPUT (e.g. PUSHDATA(66)[xxxxxxxxxxxxxxxxxxxxx], and taking the redeemScript from there anyone can hash that and spend the 0.5 BTC? If so, how?
The TRXO is not based on publickey as in the case of addresses of the form 1xxxx so it's not associated with Josh's address but rather with anyone who can produce a hash of the redeemScript.
This below explains a lot in previous chapters but the practical side of the article is still in draft.
https://github.com/ChristopherA/Learning-Bitcoin-from-the-Command-Line/blob/master/08_5_Spending_a_P2SH_Transaction.md
The [draft] side is what I want to understand. I think this is very important because many addresses are P2SH these days. Most are multisig, yes, very secure. But if it's not multisig, isn't it a vulnerability to access the redeemScript just by looking at a previous TRX INPUT?
I use Node JS and can access libs, on Windows + Bitcoin core.I want to test these on testnet and maybe with a small amount on Livenet.
Thanks!

In the answer for https://bitcoin.stackexchange.com/questions/105796/how-to-spend-from-a-custom-p2sh-script-using-bitcore-lib/105797#105797 I gave the instructions for bitcore-lib

bitcoinjs-lib has examples for multisig P2SH, single-key Segwit wrapped in P2SH, and multisig Segwit wrapped in P2SH.

Thanks! I think this is what I am looking for https://github.com/bitcoinjs/bitcoinjs-lib/blob/master/test/integration/transactions.js#L151. So this is how you create a P2SH address from the redeemScript hashed? Also it says 'bitcoin.ECPair.fromWIF('cMahea7zqjxrtgAbB7LSGbcQUr1uX1ojuat9jZodMN87JcbXMTcA' The WIF is the redeemScript between ''?

Multisig addresses still require private keys. Here, you have multiple private keys in WIF, which are used to build a redeem script (a multisig redeem script is just m <pubkeys> n OP_CHECKMULTISIG for an m of n multisig, so you can derive the public keys from the private key.

I understand multisig. That's not what I meant. I am referring to TRXO looking like HASH160 PUSHDATA(20)[xxxxxxxxxxxxx] EQUAL, no multisig required.

That's the locking script for the output. When combined with the signatures and redeem script, it forms a complete script. In essence, the signatures following by the redeem script will first check that the multisig requirements are met. Then, the redeemscript is HASH160'd, which is then compared to the push(20) to ensure that the redeem script corresponds to the address

I see but my question is about non-multisigs. I am trying understand TRXO's of the "type": "scripthash" NOT type": "multyisig". How are those making use of the redeemScript?

Essentially the same way. Any P2SH address is a hash of the redeem script. Any tx spending that must supply the redeem script so that it can be hashed and OP_EQUAL'd against what's in the address. Additionally, they must supply any information required to evaluate the redeem script to true. In the case of multisig, this is signatures. You can make other P2SH addresses that require a math problem, or the preimage for another hash, or any number of other things

Thank you very much for your help. One last thing, I know it sounds silly: how exactly can I create a P2SH address from let's say a string of numbers and letters? How can I hash that string and then test it against another address to see if I can get the OP_EQUAL on the stack? My guess is that I have to use an API like Node and Bitcoinjs like you suggested.

The hash portion is simply HASH_160. Assuming your string of numbers and letters are a valid redeem script, you can pass it through HASH_160 to get the hash, and wrap it in the P2SH version code (0x05). You could technically do this with any random string, but you will never be able to spend from it unless it's a valid redeem script


text:
How to specify PrivateKey search range in HEX?
I am trying to generate random bitcoin Private_Keys in HEX format (32bit) but
I want the randomness to have a value within a specific HEX range, say between
18909BDE11F67C97A53C62F45E632EAB58EA0D73A5FAC9EB50295FAD40A57EB5

and
DD10559E1285B3EE0303B159B8D6D8D0B88E6168D1C1D6000000000000000000

The following piece of code in Python 3 is a start but it simply generates random keys for the curve's entire field which is up to
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
This is the code:
generate_private_key():
    return binascii.hexlify(os.urandom(32)).decode('utf-8').upper()

How to specify the desired search range expanding on the above code?
Thanks.

Do you need to use Python for that? Because vanitygen-plus, an unofficial version of vanitygen can be used for that easily.

Yes, I am looking for suggestions for Python 3 based on the code from the question.

may be something like this (pseudo code): const(32) + rand(8)

Use random.
Using your low and high values:
import random
def generate_private_key():
    low  = 0x18909BDE11F67C97A53C62F45E632EAB58EA0D73A5FAC9EB50295FAD40A57EB5
    high = 0xDD10559E1285B3EE0303B159B8D6D8D0B88E6168D1C1D6000000000000000000
    return str( hex( random.randrange( low, high ) ) )

And then just:
print(generate_private_key())

Note that you'll probably need to convert this hex address to wif, or extract a public key or bitcoin public address from it... If you need more easy Python code for doing this, you can check these little pieces of code.


text:
BlockNotify not working
Hi my configured jsonrpc is following
maxconnections=200
maxuploadtarget=20
rpcuser=someusername
rpcpassword=somepassword
daemon=1
keypool=10000
walletnotify=curl "https://someurl.com/walletnotify?transaction_hash=%s"
blocknotify=curl "https://someurl.com/blocknotify?transaction_hash=%s"

I am getting notified on both wallet notify and block notify but the problem is the transaction is not the same for both. For Example I get f793d590bacffce8efd37c1b1e3db254950e925dd5bbd7f3a92c1db142f4dc37
from wallet notify and
00000000000000000038ffec8f035d54558a78e94ae1138ac5bdf1470fb0863f

from block notify. Please help what have I missed or done wrong here?

-blocknotify notifies you about a block, not a transaction. The hash you see is a block hash
 You'll have to call an RPC like listtransactions or getreceivedbyaddress on payments you expect.
Alternatively, you can also call getblock with the hash you were notified about to see all the transactions in it. I don't recommend that though, as you'll need to deal with the case where your node was down or your system restarted, and you won't get notifications for things that happened during downtime.


text:
Is the Mycelium HD wallet private key stored encrypted on the device?
haven't found details on that in the net.
My concern is that I'm using a corporate (bring you own device) phone. We have to install a "security" app running with administrator rights.
IMHO this app can read EVERYTHING what is on the device. I'm pretty sure. Therefore, is the private key of the Mycelium HD wallet encrypted (with the PIN hopefully) when stored the device?
Any thoughts?

Yes, Mycelium stores an encrypted copy of your key, protected by your PIN (if applicable) on the device. This includes any individual private key accounts you import.
In general, I would advise against storing crypto keys (or any private keys or confidential information, really) on a corporate device (laptops, phones, desktops, email accounts), or even a device others can access regularly.

yes, I don't have a choice ... so I'll take the risk .. would use a Ledger Nano S but really doen't want to be dependent on a HW vendor...

Ledger and Trezor both follow BIP39/44/49, so you aren't tied into their ecosystem by using the device. You can always recover the private keys using the seed words and import them into non-ledger/non-trezor wallets if you need to. I would strongly recommend making the switch to a hardware wallet.


text:
mnemonic pass phrase generation in wallets / hardware wallets - security flaw?
Wouldn't it be saver to generate a mnemonic passphrase manually by just taking random words from a lookup table?
My thoughts:
a wallet creator can can accidentally or on purpose use deterministic seeds for creating the mnemonic pass phrase
what is your opinion about this?
I'm using mycelium - so in theory I could check the code myself - but also using ledger nano s - so there is not really a way on verifying that the threat above is not implemented on the HW wallet, correct?

Wouldn't it be saver to generate a mnemonic passphrase manually by just taking random words from a lookup table?

No, it would not be. This method may even be insecure if you are actually doing it manually.
A BIP 39 mnemonic, if generated properly, is secure. It is just as secure if you randomly choose words too. This is because both methods require a Cryptographically Secure Random Number Generator. For BIP 39, you use a CSRNG to generate a 256 bit random number and split it up in order to produce the mnemonic. There's an additional checksum that makes the mnemonic represent a 264 bit number.
In your method, you generate 24 random 11-bit numbers (because there are 2048 words in the wordlist) and use each number to choose the word to use. While this is more random, you lose the checksum. Furthermore, it's only 8 bits more random, which is not much more random. Either way, the mnemonic is sufficiently secure, not because of the method used, but because a CSRNG was used to generate the numbers.
However if you actually do it manually, then it is likely insecure. If you are generating the numbers yourself (i.e. without the help of a CSRNG), then your seed is not going to be sufficiently random enouhg. Humans are a notoriously bad source of entropy, but you want your mnemonic to have good entropy. So doing this manually is not a very good idea.
Although you could use a 6 sided die to randomly generate your numbers, but that may not necessarily be a good source of entropy either. It would also require a few hundred rolls in order to have a sufficient number of bits.

a wallet creator can can accidentally or on purpose use deterministic seeds for creating the mnemonic pass phrase

They could, but it would be noticed very quickly. The wallet is open source and people do actually audit the source code. People would notice if a change went in that modified its random number generation.

but also using ledger nano s - so there is not really a way on verifying that the threat above is not implemented on the HW wallet, correct?

Not necessarily. Most of the Ledger Nano S's firmware is open source. And the seed is generated using from the secure element which has a True RNG which is AIS-31 Class PTG.2 compliant. You can check that the firmware calls the correct functions in the Secure Element SDK to use the TRNG for seed generation.
The Secure Element's firmware is closed source unfortunately, however I don't think Ledger can modify that firmware. I believe they only get a binary blob for the firmware from the chip's manufacturer, STMicroelectronics.


text:
Is it possible to restrict where coins from a given P2SH address can be sent to?
I would like to create a checking/saving style scheme where coins from savings can only go into checking before they go anywhere else.
Is this even possible in Bitcoin?

No, Bitcoin script has no view of the output of a transaction as a design decision. This sort of behavior is called a covenant, which is usually regarded to be a fairly poor idea.


text:
Can I spend utxos from various bip32 subwallets in only one transaction?
I want to redeem bitcoin received into several bip32 subwallets in only one transaction. Is that possible?
I've tried using pycoin's ku utility to generate a tpub and a wif from a tprv. I'm using the tpub to generate the subwallets and the wif to sign the transaction, but pycoin says the signing fails.
Is that conceptually wrong, or am I just handling the keys in the wrong way?

a Bitcoin transaction can have between 1 and (realistically) several hundred inputs, each of which can redeem completely unrelated UTXOs. Whether or not the keys for those UTXOs are related through BIP32 or some other scheme is not relevant, and even not observable by the network (it is not possible to correlate different BIP32 keys unless you know their master key).

So in a transaction, each utxo is signed separately?

That's correct.

In a non bip32 situation, where all utxos point to the same wallet, that looks like a terrible waste of block space.


text:
Hash functions in Bitcoin source codes
I'm new to programming. I got into it because I wanted to learn Bitcoin.
I've downloaded the source files from Bitcoin Core. Can anyone enlighten me where the source codes related to the hash functions are located at?

I'd say in the src/crypto folder: https://github.com/bitcoin/bitcoin/tree/efb4383ef6c69e801ddca160a53e7fb4ee8b156a/src/crypto


text:
Is there any way to find out latest bitcoin transaction of a particular address in bit-cli, without knowing the txid?
I would like to find out the immediate last transaction of addressA.
But so far, I can only do this, bit-li gettransaction <txid> then bit-cli decoderawtransaction <hex>
But I want to do something like this:
bit-cli lasttransactionto <addressA>
How can I do that, without knowing the tx id??

Bitcoind doesn't index by address, but you can scan the uxto set for outpoints which are spent to the address of interest:

See scanutxoset in the documentation:
https://bitcoincore.org/en/doc/0.17.0/rpc/blockchain/scantxoutset/
However, it is not clear to how it will be supported in the future: https://bitcoincore.org/en/meetings/2018/05/24/
Also note, that the utxo set may not return any result for your address, if the last transaction output associated with that address has been spent (not member of the uxto set anymore).

Alternatively, Libbitcoin-server indexes all transactions by address per default:

See the CLI command bx fetch-history <address>: https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-fetch-history
Which makes fetch_history server request: https://github.com/libbitcoin/libbitcoin-server/wiki/Query-Service#blockchainfetch_history3
Above commands/requests will return ALL transactions in order of confirmation height related to any standard address and indicate whether the outpoint was spent or not.

Thank you, I think, I will download libbitcoin but right now, I am doing it like this, but I am not sure if it is good approach or not,
curl https://localhost/api/addr/<AddressA> | python -m json.tool | grep -A1 transactions | grep -v transactions | tr -d ',\" '
then, as usual like before
bit-cli gettransaction <lastoutput>
then,
bit-cli decoderawtransaction <hex> | grep -A1 addresses | grep -v addresses | tr -d '" -' | grep -v AddressB | tail -1

You can also import the address as watch-only into the wallet (using importaddress) in Bitcoin Core, and have the wallet rescan the chain for relevant transactions.

@PieterWuille Ah yes, as chris belchers electrum personal server does...

Rescanning the entire chain takes a long time, doesn't it? The problem I am having with my approach is that, if my address (to addr) gets exposed then spammer may flood my address with thousands of small amount of tx. Then, my code will be unable to pick up the right address(from addr). I know there are solutions out there but I dont know how to do it. haha

I have written a program in Python3 that allows you to search for any address on bitcoin core whether it belongs to your wallet or not.
Here is the github link:
https://github.com/ORP967/Bitcoin_Core_RPC_par_address
Let me know what you think or if you have any improvements you might have.


text:
HASH160 to address - What am I doing wrong?
I am running this code and nothing happens.
I am trying to hash160 a  script with OP_HASH160 {scriptHash} OP_EQUAL and get a P2SH address as output but not sure this is the right script to achieve this.
// OP_HASH160 {scriptHash} OP_EQUAL
var bitcoin = require('bitcoinjs-lib')
var bscript = require('./src/script')
var types = require('./src/types')
var typeforce = require('typeforce')
var OPS = require('bitcoin-ops')

function check (script) {
  var buffer = bscript.compile(script)

  return buffer.length === 23 &&
    buffer[0] === OPS.OP_HASH160 &&
    buffer[1] === 0x14 &&
    buffer[22] === OPS.OP_EQUAL
}
check.toJSON = function () { return 'scriptHash output' }

function encode (scriptHash) {
  typeforce(types.Hash160bit, scriptHash)

  return bscript.compile([OPS.OP_HASH160, f1b914051eaabf34c22d354053698e512b36, OPS.OP_EQUAL])
}

function decode (buffer) {
  typeforce(check, buffer)

  return buffer.slice(2, 22)
}

module.exports = {
  check: check,
  decode: decode,
  encode: encode
}

What am I doing wrong?
Thanks

You don't hash the OP_HASH160 {scriptHash} OP_EQUAL, that's just a template associated with P2SH addresses. You need to hash the redeem script, add version byte and checksum and then encode into base58.
Sample Python code:
def p2sh(script):
    scripthash = hash160(script)
    data = b'\x05' + scripthash
    checksum = sha256(sha256(data))[:4]
    address = data + checksum
    return base58.encode(address)

Thanks! I tried to run your code but nothing happens. How can I get the address and the private key from that string?  I'm new to python.
https://i.imgur.com/uPKt09A.png

try cloning this repository, it's where I got it from. From the cloned project folder open python and run the following snippet: https://bpaste.net/show/82cda4df9253 You can't get the private key from anything, it is something you must have. To get an address from a privatekey try this https://bpaste.net/show/7c224235cebe


text:
Bitcoin.org developer reference outdated?
i just can't understand if bitcoin.org developer reference is outdated or not. for example here (https://bitcoin.org/en/developer-reference#raw-transaction-format) we can see: "As of Bitcoin Core 0.9.3 (October 2014), all transactions use the version 1 format described below. (Note: transactions in the block chain are allowed to list a higher version number to permit soft forks, but they are treated as version 1 transactions by current software.)" it's right or it's an old reality?
or here (https://bitcoin.org/en/developer-reference#serialized-blocks) we can read on the first 2 line that blocks must be serialized under 1MB size or less but i know on the current version blocks can be up to 2MB so i can't understand which one is the right answer. Thanks for the help

"As of Bitcoin Core 0.9.3 (October 2014), all transactions use the version 1 format described below. (Note: transactions in the block chain are allowed to list a higher version number to permit soft forks, but they are treated as version 1 transactions by current software.)" it's right or it's an old reality?

Both. It is talking about the state of affairs in October 2014, which is old. However it also states that the information dates from back then, so it is technically correct.
Since the activation of BIP 68 in July 2016, transactions with version 2 are relevant to the network rules, so the information could clearly be updated.

or here (https://bitcoin.org/en/developer-reference#serialized-blocks) we can read on the first 2 line that blocks must be serialized under 1MB size or less but i know on the current version blocks can be up to 2MB so i can't understand which one is the right answer.

That information is clearly outdated since the introduction of Segregated Witness (SegWit) in August 2017. The concept of size of a block is no longer relevant, and replaced with block weight (which counts some bytes in a block more than others) limited to 4000000. In theory this means the total serialized size of specially constructed blocks can be up to 3.9 MB, but for blocks limited to common transactions it's closer to 2 MB.

i just can't understand if bitcoin.org developer reference is outdated or not.

Some parts are, others aren't. It's a resource maintained by a community, so I'm sure they would appreciate help to keep things up to date: https://github.com/bitcoin-dot-org/bitcoin.org

I don't think its outdated. In GetHashesPerSec section, it talked about Bitcoin 0.16.0 which is a recent release.

This doesn't really answer the question. Parts of the site may be outdated, as evidenced above. A better answer would clear the confusion between the two texts on the site.


text:
Is there a website / api where I can access historic coinbase data?
Is there a website / api where I can access historic coinbase data for Bitcoin?
I know about blockchair.com but they charge for the coinbase data.
Anywhere that supplies this for free?

For what purposes you need such data? Education or what?

You can request this data via the API.
A request could look like that
https://api.pro.coinbase.com/products/BTC-EUR/candles?granularity=60&start=2018-11-09T17:11:08Z&end=2018-11-09T18:11:08Z


text:
Can the Bitcoin halving be delayed?
Currently the next halving date is May 2020 (provisional) according to enter link description here.
I understand that every 210k blocks, the block reward is halved and this works out, roughly, to once every 4 years.
I guess I have two questions:
1) The 2012 halving took place approx. 3.8 years after genesis, and the 2016 halving took place a further 3.6 years after that. During this period hash rate increased almost continuously and at exaggerated rates due to continuous developments in mining technology from general to specific solutions (CPU -> GPU / FPGA -> ASIC). So were these 'premature' halvings due to the positive rate of change of hash rate?
2) A halving on 23 May 2020 is roughly 3.9 years from the last halving. It seems this is linked to 2018's drop in hash rate, could a hash rate collapse lead to a delayed halving event (i.e. adding the current 210,000 blocks takes longer than 4 years)?
Thank you.

So were these 'premature' halvings due to the positive rate of change of hash rate?

Bitcoin is designed to keep the block time at 10 minutes. The difficulty increases/decreases as the mining hash rate increases/decreases. At this 10 minute rate the the halving event comes every 4 years. As miners started using ASIC chips to mine blocks, the average time came down and that led to slightly lower halving time.

could a hash rate collapse lead to a delayed halving event (i.e. adding the current 210,000 blocks takes longer than 4 years)?

If hash rate declines continuously so that even after difficulty gets adjusted to account for lower hash rates, miners continue to lower their hash powers, then it could take longer than 4 years.

I can't up-vote because I don't have the rep. Otherwise thanks!

If you think it answers your question you can tick the 'correct' mark so that others know this is an accepted answer.


text:
Why wipe all BTC from an imported address?
I've read a couple blog entries and tutorials on how to spend BTC that are "stored" on a piece of paper.
They all suggested importing the private key into e.g. blockchain.info's wallet (or any equivalent)
and wipe ALL coins from that address. But why should I not continue using it?

you can continue to use it

Once your import the key, the key now exists in two places: your paper and your wallet.  Because of this, you've lost the advantage that a paper wallet has for cold storage.  What you now have is a paper backup of one of the keys stored in your hot wallet.  Any risks of a hot wallet now also apply to your paper wallet.
In addition, there is the inherent privacy issues with re-using a Bitcoin address, regardless of how that wallet is stored.  There aren't many advantages to re-using addresses, and this case is no exception.  If you still need a paper wallet after importing one, you should really create a new one.

The reason paper wallets are secure is because they aren't connected to the internet and aren't easily accessible to anyone but you because you're supposed to store a paper wallet where no one else can get it (e.g. hide it or store it in a safe if you own one anyways, for example because you own other valuables or a gun).
The very moment you enter your private key into a computer which is connected to the internet, you lose this advantage. You are willing to do this to make use of your money, that's not the topic.
However, if you do that, things are even worse than if that money was in a wallet on a computer connected to the internet or an online wallet all along because you will feel a need to dispose of the piece of paper the private key is written on. You might just throw it into the bin. And here is, where people's paranoias when it comes to large amounts of valuables comes into play.
If someone comes across the piece of paper your wrote your private key on, you can assume your money to be gone unless you transferred it to a different address. This even can happen if you burn the paper in an openly accessible fire, though that of course reduces the chance greatly. If you smear the ash by stepping onto the burned piece of paper and dragging your foot along the ground, you should be very safe, and realistically, the chance of someone stealing your private key after you burnt the piece of paper is very small, too. However, the chance of someone stealing your money if you merely throw the piece of paper away, should be regarded as very real.
It's a lot easier to tell people to transfer their money to a different address than to burn a piece of paper. A lot of people will not actually burn the piece of paper but they will transfer the money to a different address if asked to. After the transfer happened, that piece of paper can be regarded as declassified.
Furthermore, this saves creators of HD wallet software from a having to implement a feature which allows the import of a single address permanently.
To make things worse, if a HD wallet offers such a feature, it losses a major feature: The way, HD wallets are set up, they can create a virtually arbitrary number of private keys + addresses from very little data to begin with. Deterministically. That's what the "D" in "HD" is for. Such wallets can be restored using a seed which often is represented in form of a sequence of a few English words.
A HD wallet software can guarantee the user to be able to create the same private keys + addresses again on a separate installation. This way, a user only has to back up their wallet's seed and will be able to get access to their money again if their HDD fails, a crypto trojan encrypts their wallet, or their computer explodes. If a wallet software, however, allows the user to permanently import a private key which has not been created deterministically from the seed, the user won't get that private key back from the seed. They have to hold on to that key themselves.
Compelling a user to back up that one key is much harder than just telling them to transfer the money to an address the wallet generated and to keep the seed of that wallet backed up.


text:
For a bitcoin-forked complementary currency: would it be difficult / impossible to limit the mining to some agents on the market?
Am I right that by implementation everybody with a client is theoretically able to mine?
However, thinking about a Bitcoin implementation for a locally limited complementary currency:
Would it be possible (without changing half the code base) to limit the right to mine to some charitable groups and giving the other agents just the permission to do transactions?

Am I right that by implementation everybody with a client is theoretically able to mine?

Yes, it just won't be very effective without dedicated mining hardware.

Would it be possible (without changing half the code base) to limit the right to mine to some charitable groups and giving the other agents just the permission to do transactions?

Yes, you can do that. You don't have to change very much of Bitcoin to do it, either.
You change Bitcoin so that instead of a block header needing a certain amount of work to be valid, it needs a signature from a certain public key. Then, you distribute the private key to all of the organizations that should be able to mine.
You need to change the code in one other place: the mining logic. Instead of hashing continuously, the nodes that create blocks will do it by waiting a fixed amount of time after the last block, creating a new block, and signing it. (Avoid creating two blocks in two places simultaneously. There are three strategies for avoiding this: wait a random amount of time before creating a block, elect a leader who creates the block, or have a round-robin system.)

Elements Alpha implements signatures instead of mining.


text:
Unconfirmed. Sent to
Bitcoins were sent to the correct address, but did not arrive, and Bitcoin Core wallet, information is: Unconfirmed. Sent to - How do I solve this problem? Thank you?

You wait.
In the Bitcoin network, transactions are confirmed by including them into blocks, which are then permanently stored in the blockchain.
Blocks are mined, on average, every 10 minutes, but this is actually a random Poisson process, just as you can say a given piece of uranium will emit an alpha particle every 10 seconds on average. Sometimes, blocks will be found within the same minute, sometimes it may take an hour.
Blocks also have a maximum size, which is now pretty close to the transaction volume of Bitcoin at the moment. Rational miners who receive more transactions than will fit in their block, will mine higher fee transactions before lower fee transactions. If the transaction fee you paid was very small, your transaction will eventually confirm, it will just take much longer (up to a few hours).


text:
Interested to find a good resource with all active bitcoins exchanges
I am looking for recommendations for good bitcoin exchanges resource that would include info on:
- live/approximate daily trading volumes
- spreads
- and most importantly traded currencies
I found this one: https://bitcoincharts.com/markets/
But it is not up to date (no KRW for example) and I couldn't find a way to sort it by an exchange and it is a bit hard to compare traded volumes by exchange because the info is in different currencies.
Thanks,
Tagir

Cryptonator looks like a good start.
Find all exchanges for a particular trading pair.
https://api.cryptonator.com/api/full/eth-btc
Then swap out the eth with whatever currency you're looking for.
Cryptonator says this is all their supported currency pairs (https://www.cryptonator.com/api/currencies) but looks like it includes some dead coins. You could loop through that URL and for each record, input the symbol into the original https://api.cryptonator.com/api/full/eth-btc end-point.
https://api.cryptonator.com/api/full/ltc-btc
https://api.cryptonator.com/api/full/dash-btc
...and so on.
Once the loop is through you should have all pairs and all currencies, or at least all the ones cryptonator has.

Thanks for the answer. Not everyone can easily work though the JSON file from the cryptonator api. It will take me quite some time to actually get any meaningful data from there. May be there are some resources that already did the crunching? Also to clarify the questions, I am looking for BTC to FIAT pairs linked to a USD. For example https://www.okcoin.cn/marketList.do. Not looking for alt coins rates.


text:
How to increment the number of confirmation of a transaction?
Sorry for this naive question, but honestly it is going to be a great help for me.
Say I am tracking a specific bitcoin transaction('TX_1') form bitcoin core. A confirmed block had the transaction information after I decoded the block, and I updated my database as :  {transaction: 'TX_1', 'confirmation': 1}
now how do I increment the number of confirmation, assuming I am still listening to the network through ZMQ. Should I expect the same transaction ('TX_1') to be present in upcoming blocks?

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


text:
Intuitive CryptoCurrency?
How would cryptocurrencies be explained intuitively? I tried reading about bitcoin but most articles explain broad concepts ambiguously, and I want to understand the concepts so I could potentially make a cryptocurrency myself. So, here is my intuitive understanding of it. With online currencies usually there is a central service that steals some of the money when you make transactions? You don't want that so you directly do transactions from one person to the other, perhaps by passing a code that is worth value to someone else. OK, but this has problems because of double spending. A person cannot be sure if the currency has already been spent. So that's why there's databases that everyone has access to and everyone writes to that stores the amount of money everyone has. How would the databases verify that you are in fact doing the transaction and not someone saying that they are doing it? Through public and private keys, right. How that works is that each person has a private key that encrypts a specific code, and everyone has access to the public key that is paired with the private key. If that code, when decrypted by the public key, is in the correct format, then it can be verified who is making the transaction, because nobody else has the private key. But the code that needs to be decrypted must be different every time because if it's the same every time, whoever sees the code can use it to spend money. So maybe you make a rule that when you decrypt the code it has to form the current date to verify the transaction. The public key would be stored in the database with the corresponding amount of money connected to the public key. Also when you make the transaction you say which public key you want to give money to and which public key you have, and how much money you want to give. A lot of people's computers verify the transaction so it's safe. Why is mining even necessary? I might just be dumb because I don't have much cryptography experience, I do have some programming knowledge however.

Your description works well enough until you start talking about encryption. The way you've described implementing public-key cryptography isn't quite right, if you're interested, I would suggest taking a looking at at the public-key cryptography wiki page.
I think more useful than explaining how your description is wrong, I'll just give an example of how I would re-write it to be more accurate (at least insofar as it is implemented in bitcoin). My addition in bold:

How would the databases verify that you are in fact doing the transaction and not someone saying that they are doing it? Through public and private keys, right. Coins can be sent to public keys, and then spent using the corresponding private key. So you can share your 'pubkeyA' with someone, and then they can send bitcoins to that key (and thus to you). They do this by using their 'privkeyX' to sign a transaction that says "send the coins held at 'pubkeyX' to pubkeyA", and everyone else can use the pubkeyX to verify that the signature came from privkeyX, without ever knowing what privkeyX is!

Perhaps also worth mentioning, saying 'databases that everyone has access to and can write to' is sorta misleading, it makes me think of a database instance that many different people write to. In reality it is 'many instances of a database that are constantly updating according to the network's rules'.

A lot of people's computers verify the transaction so it's safe. Why is mining even necessary?

Proof-of-work mining solves the problem of needing a large network of untrusted computers to all agree upon the ordering of transactions, in order to solve the doublespend problem. Otherwise, how will the computers agree on which transactions to include, and in what order? What would make any one copy of the database more trustworthy and accurate than any other?

But can anyone who receives the signed transaction fake another transaction by sending the signed transaction again to everyone else?

@dandan no, they cannot. If you change the data being signed, then the signature will change. So if you strip the signature off a random tx, and try to add it to a tx that spends those coins to your address instead, then the signature will be invalid on your tx.

how about to the same address? without changing signature

The signature is made across all of the transaction data; changing any part of the transaction data will invalidate the signature. If this were not true, then it would be trivial for an attacker to intercept and alter transactions before they were confirmed in a block.

Mining is necessary for two big reasons.  It creates value of scarcity. Mining also provides the processing of the Bitcoin transactions.


text:
what is forking attack? and different between forking attack and selfish mining?
I am a student who studies block-chain for these days.
I have a question about forking attack and selfish mining in mining strategies
as you see picture below

I don't understand why miner should send some money to a victim to do forking attack...
what does this means to do forking attack?
is it possible to do forking attack except sending some money to a victim?
and as below picture about selfish mining

what is difference between forking attack and selfish mining if miners exclude
to do send some money to a victim in forking attack?
can anyone help me to understand what M->B and M->M'(double spending) means??
and why do need it to do forking attack??

With 51% of the network hashrate the forking attack is theoretically possible. Classically, what you have described is a double spending attack.
First, the attacker pays M->B and B releases the goods. Then, the attacker presents a longer valid chain paying M->M instead and the blocks containing M->B are orphaned.
It is not simply a matter of presenting an alternate block, it must be a valid alternate block(s) with more valid proof of work (a longer chain) which must also be based on the genesis block and any (each) checkpoint.
With 51% of the network hashpower, selfish mining is also possible, where the attacker ignores any network generated blocks and continues to extend their own chain with blocks that they have created. Because the attacker's hashpower is greater, theirs will be the longest chain with the greatest PoW.


text:
Educational sample of minimal working mining code
I would like if someone could point me to a minimal program source code that does solo minig on a CPU. (Can assume a running bitcoind/full node)
Something that in theory (obviously not in practice) would actually be able to mine a block from the live network. This is intended for educational purposes, not for profit. Good code structure is therefore more important than performance.

https://github.com/trottier/original-bitcoin/tree/master/src ?

I think that these articles are great for educational purpose:
Bitcoin mining the hard way: the algorithms, protocols, and bytes
This article explains Bitcoin mining in details, right down to the hex data and network traffic. If you've ever wondered what really happens in Bitcoin mining, you've come to the right place.
http://www.righto.com/2014/02/bitcoin-mining-hard-way-algorithms.html

Mining Bitcoin with pencil and paper: 0.67 hashes per day
I decided to see how practical it would be to mine Bitcoin with pencil and paper. It turns out that the SHA-256 algorithm used for mining is pretty simple and can in fact be done by hand. Not surprisingly, the process is extremely slow compared to hardware mining and is entirely impractical. But performing the algorithm manually is a good way to understand exactly how it works.
http://www.righto.com/2014/09/mining-bitcoin-with-pencil-and-paper.html

The first one include also small programs in python that mines a block and connect to a mining pool stratum server.


text:
Can I use Electrum seed as a paper wallet?
Based on what I've read so far I'm pretty sure that what I want to do should work, but I'd like to get some confirmation to make sure I won't be causing myself  issues by screwing something up if I'm wrong.
This is what I'd to do:
1. setup an Electrum wallet in offline mode
2. write down the seed on paper
3. send the coins I want to secure from my normal wallet to one of the generated addresses
4. delete the newly setup Electrum wallet from the hard drive
5. Voila, I should be left with a paper wallet, right? With the wallet deleted from the hard drive, the only access point to the coins is through that paper with the seed written down. And whenever I want to use them, I just open Electrum, type in the seed and it'll grant me full access.
Is my thinking correct? I want to be sure I'm not missing something silly that would result in my finding out that I can't actually access the coins further down the line...

Yes, you can create a paper wallet like that. Electrum's wallet recovery from the seed let's you recreate that same wallet later in time and as often as you wish to, even in parallel on different machines.
If you set a password for your wallet, that password will not be used to recreate your wallet. This means that you don't have to remember your password (if you set one) but it also means that your wallet won't be protected by it while on paper. If someone gets hold of your seed, they can restore your wallet no matter whether they know your password or not.

You should create your wallet from a pc that will never connect to the internet again if you want to secure your bitcoins 99.99%
If you don't have another PC, use Ubuntu Live CD/USB.

Boot from Ubuntu live cd/usb.
Install Electram, Bitcoin core, or any tools that enable you to generate wallet and create transactions.
Generate your wallet.
Write the seed (or private keys) on a paper.
Re-boot your pc.

But, in this way, you need to install Electram each time you need to sign a transaction.

If you want to be on the safe side so much that you use a live system, you should disconnect your internet connection in-between step 2 and step 3. Not much more effort, after all.

DON'T USE THE EXACT EXAMPLE BELOW FOR SECURITY REASONS.
Information synthesized below should be performed on an offline computer. Address below is an example of an address of where to deposit funds. Used source code from Monero's Electrum capabilities to write a short C++ program below called inverse_mnemonics, bitcoin-explorer, and the sed command below:
256-bit hexadecimal Private Key from 25 Electrum words:
% echo "civilian dapper fully enforce tedious deodorant lava cigar shuffled wobbly when juicy hubcaps onto thwart obliged ajar trendy safety exhale cactus pheasants upright jazz onto" | ./inverse_mnemonics
5356ac2233e3ea59af8e1c9ff3c3ce7c9f67053d128b7dd75ff6cedd8682ef86
Compressed WIF Private Key:
% echo "civilian dapper fully enforce tedious deodorant lava cigar shuffled wobbly when juicy hubcaps onto thwart obliged ajar trendy safety exhale cactus pheasants upright jazz onto" | ./inverse_mnemonics | sed 's/$/01/' | bx base58check-encode -v 128
Kz1i9EK6MTd6T9PUeYwDMj2x4Rr5N8vcVWUTTG8JLK3bScGZeyGm
Associated Public Address to deposit funds:
% echo "civilian dapper fully enforce tedious deodorant lava cigar shuffled wobbly when juicy hubcaps onto thwart obliged ajar trendy safety exhale cactus pheasants upright jazz onto" | ./inverse_mnemonics | bx ec-to-public | bx ec-to-address -v 0
186EdXhyoa7EC1X33nLhQNebbreYLrccVB
It is worth noting that https://xmr.llcoins.net/ has a JavaScript that can confirm portions of the results above offline, and may be additionally applied to create an encrypted Electrum seed words in case someone has unauthorized access to your paper wallet. This is a countermeasure that behaves analogously to a portion of the BIP 38 Standard, but instead uses Electrum technology.


text:
Is the UTXO set computed from scratch by new full nodes?
When a new full node joins the network,
does he, by default, compute the UTXO set from scratch from the blockchain so far; or does he simply trust the UTXO set he received is valid?

The UTXO set cannot be validated, except by going through all blocks in history.
The P2P protocol does not even have a way to stream the UTXO set from one node to another, so yes, full nodes will always download and verify full blocks, and rebuild the UTXO set from it.
There are various ideas (some of which are very old) to make blocks commit (= contain a hash) to the UTXO set, or a related data structure. That way one could synchronize the UTXO set for a state in the past (which  means a trust in miners), and fully verify going forward from there.

I'm not sure what exactly "synchronize blocks" means here. One interpretation I can think of is that a new full node downloads the blockchain from several places and compares

No, it just downloads them and verifies the transactions in them.

Yes, the UTXO set is generated by each node for themselves.
The UTXO set is not shared between nodes, it results from updating the node's database with the transactions included in the blocks of the blockchain.


text:
How to get the private key in hex from the output of dumpprivkey
I am trying to create raw transactions according to the excellent answer of runeks here:
How to redeem a basic Tx?
But there he starts with a private key in hex format
18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725
and I have one in base58 given by bitcoin-cli dumpprivkey:
bitcoin-cli dumpprivkey 154G5oUywHU3pESNy4oBBpkmAGqRZiYxBk
KzRVLwCuCi2tH2PpSNZnwUqPwg6gaqXAM2LWobUurzAsNdC5JesE
How do I get it in hex in the right format?

OK, I managed to do it with the excellent bitcoin-tool by matja
https://github.com/matja/bitcoin-tool
git clone https://github.com/matja/bitcoin-tool.git
cd bitcoin-tool
make test
./bitcoin-tool --input-type private-key-wif --input-format base58check --output-type private-key --output-format hex --network bitcoin  --input "KzRVLwCuCi2tH2PpSNZnwUqPwg6gaqXAM2LWobUurzAsNdC5JesE"
which gave me
5f92519eef7ec4e37cbcd25f9ba4a82e5acf9a8cd274d4d3aa3aa727fd7b6969
as a result.

https://en.bitcoin.it/wiki/Private_key
Private keys associated with compressed public keys are 52 characters and start with a capital L or K on mainnet. Your second line looks pretty much like a privkey (KzRVLwCuCi2tH2PpSNZnwUqPwg6gaqXAM2LWobUurzAsNdC5JesE), just it is 53 chars long... sure your data is not garbled?
Once you have your privkey you'd need the base58check encoding, like provided on Ken Shirriff's blog: http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
which again is explained in the wiki: https://en.bitcoin.it/wiki/Base58Check_encoding


text:
Why does segwit save space on the blockchain?
I've had a hard time finding a good source online that explains segwit.
I've read the basic idea is to store the scriptSigs separately as the scriptSig is potentially malleable, and then compute the txid without the scripSig.
But the scriptSig still needs to be somewhere on the blockchain, so how does this save space?

It doesn't. See https://bitcoin.stackexchange.com/q/52196/208

I don't get it. It sounds like you're putting the scriptSig in a separate place you're not calling a block, but still using the same amount of space. Why not just keep it in the block, and just compute the txid ignoring the scriptsig to get the non-malleability advantage?

That would not be a softfork, and thus require every node in the whole network to adopt new software before the change can be deployed. It would also break existing wallet software. The way it is done is fully backward compatible.

Is a softfork such a holy grail in itself, that anything that satisfies the definition is good? To me a natural softfork is one where the legitimate sender can get his tx unaccepted by new nodes if he doesn't upgrade his wallet to the new rules.. but here because the scriptSig is anyone_can_spend, anyone can fraudulently spend the output of the legitimate owner in the view of the old nodes. Thus, the old nodes will become completely useless almost immediately - they also cannot relay a legitimate transaction to the new nodes because they don't know they need to transfer the witness.

Softforks are not a holy grail. A softfork that freezes some specific person's coins would be a very bad thing. But what you're saying is an overstatement: old nodes indeed can't fully verify spends from segwit outputs, but they also don't care about them.

See https://segwit.org/on-the-security-of-soft-forks-2c0a00077399

Does this answer your question? Is SegWit a blocksize increase or more efficient use of blockspace?

It doesn't save space, as it still stores the witness data somewhere, but it allows the blocks (according to some canonical definition of "block") to increase in a subtle manner while being a soft-fork instead of a hard-fork (this basically means it doesn't break compatibility with previous Bitcoin clients).


text:
bitcoin coin selection algorithm
It says here https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L2458
that to choose coins for a transactions we need to solve subset sum.
But subset sum is when you're not allowed to go over a certain amount;
whereas in bitcoin you can go over the amount and give change.
So why is this necessary?

There are a few goals of coin selection.
Firstly, we want to select enough coins for the user. Secondly, we want to minimize transaction fees. Lastly we want to reduce the UTXO set.
Reducing the UTXO set requires creating less outputs than there are inputs in a transaction. By solving the subset sum problem, we can avoid making a change output and thus help to reduce the UTXO set.

For those wanting to go deeper in coin selection algorithms, I can recommend reading http://murch.one/wp-content/uploads/2016/11/erhardt2016coinselection.pdf

that may be the reason they did it. Though it doesn't make sense to me to do a much more computationally heavy procedure to maybe reduce one output.

@relG It's not just that though. The coin selection algorithm used by Bitcoin Core also results in larger change outputs. A lot of other algorithms end up breaking down the user's inputs into smaller and smaller outputs, which makes it harder and harder to spend those outputs. I highly recommend that you read the paper linked in the above comment as it explains the performance characteristics of various algorithms.

I'm reading Section 3.4 and it talks about finding the closest thing to the target value if exact solution is not found, which would result in small change.


text:
How to get money when using regtest
I want to experiment in the regtest network.
But I don't understand how I can get funds to play with.
I did:
bitcoind -regtest -daemon
bitcoin-cli -regtest sendtoaddress 2N3V4PeQXoD6TFM9ZvDMX81kzbuNtc5YPW4 1
and get:
error code: -6
error message:
Insufficient funds

Just generate some blocks.
bitcoin-cli -regtest generate 101

You will have them in your wallet and can use the funds once confirmed. 101 is the number of blocks to create.
You can use any integer that's at least 101 as the number of blocks.
You cannot use a smaller integer than 101 if you want to test transactions, because of the 100 block maturation time.

Thanks! hmm that's odd. Before I tried generating 5 blocks, and it didn't allow me to spend. But with 101 it worked. Do you understand why?

@relG: It's because of the 100 block maturation time.


text:
Does segwit solve malleability of the witness part?
I understand that after segwit the transaction ID can't be malleated,
but can't the witness part be malleated, just like the scriptSig can in a non-segwit transaction?

but can't the witness part be malleated, just like the scriptSig can in a non-segwit transaction?

Yes, absolutely.
But the witness does not contribute to the transaction id (txid), which is what subsequent transactions refer to. Because of this, malleating a witness in a given transaction does not invalidate follow-up transactions using this transaction as an input. This is important for any application where multiple parties rely on an unconfirmed transaction to keep a stable txid.

Yes, the witness can be mutated before it is in a block. Once in a block it’s committed to with a hash. This is not impactful, any modification that doesn’t change the validity doesn’t matter for the creator or receiver of the transaction.

I'm uncomfortable saying it's not impactful. It's like saying malleability doesn't matter. Also before segwit the malleable transaction was committed to with a hash. There could be potential applications depending on non-malleability of the witness.

What applications? The only application of the scriptSig is to validate a transaction, nothing can ever access it so there’s no possible reason to be using it.

I confess I don't have a great example, but malleability can have unexpected subtle attacks (otherwise people wouldn't bother to solve it). So, at the very least, I would suggest changing "This is not impactful.." to "This may not be impactful..".

It is simply not impactful. So long as it doesn’t change the outcome of a transaction, does it matter that it’s not the way the creator of the transaction intended?


text:
How to enable device in cgminer?
I I have a GekkoScience Compac BM1384 bitcoin miner that I am trying to get working with CGMiner on my Raspberry Pi. It is really annoying though, as it doesnt detect any devices on startup. However, when I go into USB management and select I it lists my bitcoin miner and it says "inactive". But when I try to enable it it says "invalid selection'.
Any suggestions?
Thanks,
BytePhoenix

CGMiner doesn't come with support for that particular miner by default. I believe you have to get the driver for it. You can use bfgminer, which from 5.3.0 supports your miner out of the box.
Instructions from https://bitcointalk.org/index.php?topic=1173963.0

The stickminer will enumerate as an antminer U3 on cgminer (if the version of cgminer you're using supports the U3), and should run fine.  It may give warnings about "no valid hashes within 3 seconds" but this is fine, as the U3 has a higher hashrate, confusing cgminer but not noticeably affecting performance.  If your hardware errors are low you're fine.  These older version of cgminer do not allow a clock rate over 250MHz.  This is pretty good for most people as that's moderately high power but in theory the chips will run up to 500MHz.
Luke Jr added bfgminer support in bfgminer 5.3.0, so you may use that
  version of bfgminer.
I (novak) have written a cgminer driver which enumerates the compacs
  as expected, removes the error, and ramps up the clock slowly to
  prevent spikes on USB power.  My custom cgminer can be found here:
  source code: gekkoscience.com/misc/cgminer-gekko.tar.gz win32 binary:
  gekkoscience.com/misc/cgminer-gekko-win32.zip EDIT: The current
  version supports bitshopper compacs as well, and can be (and is, in
  the case of windows) compiled with icarus support.
I have not yet tested it but edonkey was nice enough to upload a
  custom minera image with cgminer-gekko enabled as a custom miner.  You
  can set the frequency under manual options as: --compac-freq 150.
  Link:
  https://dbtbmm05cubzd.cloudfront.net/cryptocurrency/mods/minera_compac_mod.zip
On the engineering sample sticks you can only use old cgminer as the
  newer drivers for both cgminer and bfgminer depend on a hexfile
  flashed to the cp2102 which the engineering samples do not have.
If you need to run cgminer on windows (either stock or mine), you'll
  need to install the zadig driver.  You can find it here:
  http://ck.kolivas.org/apps/cgminer/zadig/
Run the program and install the winusb driver for the compac(s) that
  you have plugged into your windows machine.  You may need to replug
  the compacs afterwards while cgminer is running to get them to start
  mining.
=========
=How to Run=
Old cgminer: To build use --enable-icarus flag.
./cgminer -o stratum+tcp://stratum.mining.eligius.st:3334 -u
1BURGERAXHH6Yi6LRybRJK7ybEm5m5HwTr --au3-freq 150
GekkoScience cgminer: To build use --enable-gekko flag.
./cgminer -o stratum+tcp://stratum.mining.eligius.st:3334 -u
1BURGERAXHH6Yi6LRybRJK7ybEm5m5HwTr --compac-freq 150
bfgminer:
./bfgminer -o stratum+tcp://stratum.mining.eligius.st:3334 -O
1BURGERAXHH6Yi6LRybRJK7ybEm5m5HwTr --set compac:clock=x0b83

Old thread I see.  But look up, in the early Gekko Science posts on bitcointalk.org their url for their version of cgminer.  Generic cgminer has been around for decades, but different manufacturers can customize it for their hardware, then it becomes about the only thing that will work.  You need to at least run ./configure --enable-gekko to build it.  If you don't have Gekko's version of cgminer trying to enable it will cause an error.
Try https://github.com/wareck/cgminer-gekko but that's not right.  Use the Gekko Science official directions here: https://bitcointalk.org/index.php?topic=5053833.0


text:
What can make an unconfirmed transaction (0-conf) an invalid one other than Double-spend?
It's obvious that inputs that already been spent will make the transaction invalid (pure double-spend scenario), but is there's anything else that could make a tx invalid?
Invalid inputs?
Invalid signature or other data?
For example, if I have a program that manages a wallet (keypairs are exclusively managed by it, and not by any human, and it's source is public) and it sends payments, can the recipient be insured that even 0-conf tx will be eventually valid and processes?

Next to the provided answers I’d like to point to the protocol rules, especially for transactions. I used this as a reference for my codings:
https://en.bitcoin.it/wiki/Protocol_rules#.22tx.22_messages

There are a lot of things that can make a transaction invalid. Note that an invalid transaction cannot be confirmed as the block that contains it would also be invalid, thus there is no such thing as a confirmed or unconfirmed invalid transaction.
Things that make a transaction invalid:

Spending an input spent by another transaction that is confirmed
Spending an input that does not exist
If signatures are required and must be valid, providing an invalid signature
If some data must hash to something provided (e.g. pubkey hash, scripthash), providing a piece of data that does not hash to the correct hash.
In general, any input script not validating to true
Negative output values
Sum of the output values is greater than the sum of the input values
A coinbase transaction outside of a block
A coinbase transaction that is not the first transaction of a block
A coinbase transaction where the sum of the output values exceeds the block reward

There's probably a few more that I missed, those are just a few that I can think of off of the top of my head.

can the recipient be insured that even 0-conf tx will be eventually valid and processes?

No. There is no guarantee that an unconfirmed transaction will eventually confirm, even if it is valid. Note that transactions do not become valid; they are either valid or invalid upon creation.

If a transaction attempts to spend an output that doesn't exist and later that output does exist, doesn't the transaction become valid?

@DavidSchwartz It would seem so wouldn't it but, how would the utxo be referenced in the first transaction if it did not exist?

The most obvious way -- the person making the transaction already saw the block that included the first transaction but you didn't. Also, this question doesn't seem to be bitcoin specific, so would include systems that don't require you to know specifics of the funding source. (Stellar, for example, doesn't.)

Thanks for the detailed answer. Though, I believe @pebwindkraft's answer is more correct and answers my question more directly with all rules that can make tx invalid and eventually not include into a block. So I'll mark his answer.

but is there's anything else that could make a tx invalid?

consensus rules can be changed via soft- or hard-fork while the transaction is in memory pool :)

Invalid inputs? Invalid signature or other data?

First of all if any of the above parameter is invalid then the transaction wont be created on first place. The transaction will be discarded.
To create transaction :

1) Valid Vin and Vout that will be determined by algorithm itself
2) Creating raw transction using txid
3)Signning the transcation (which will be needing your pvt key)
4)Sending the transaction to mempool for verification.

If you manage to reach step 4 then your transaction will possibly get confirmed but for sure  it will be sent to mempool. Now its over the miner to confirm or not confirm your transaction.
If you want to make your unconformed transaction as conformed:
one can redo the same transcation with little more transaction fee. If miner is to mine your particular transaction and make it confirm than he needs to confirm all of your earlier tranasctions as well.
Now to answer your question about making your unconformed transaction as invlaid you dont need to do anything for that, after some period of time for your transaction in being in mempool, still  unconformed, get revert back to your wallet address

This is wrong. There is never a guarantee an unconfirmed transaction will make it into the chain.

Can't this be one possible attempt to make unconfirmed transaction confirmed?

I don't understand your question. You claim that if you reach step 4, the transaction will be confirmed for sure. This is not correct; you can never be sure a transaction will confirm. Also, in the next line you require that the sender address has enough balances. Bitcoin does not have any concept of address balances, but uses UTXOs.


text:
Can I get the same stats as are on blockchain.info and btc.com by running a full node?
There seem to be some discrepancies between blockchain.info and btc.com, specifically I am looking to extract the following info:

"Relayed By", there was a block that was listed as unknown on blockchain.info and showed as "relayed by" by specific mining pool on btc.com
Is there a way to figure out hash rate of specific mining pool as a % of total in the real time.

"Relayed By"

Bitcoin Core doesn't track which node relayed a transaction, and I doubt most other nodes do either.  In addition, this information is likely to be different for different nodes as each one may first receive a transaction from a different peer.

figure out hash rate of specific mining pool as a % of total in the real time

Full nodes don't have the information necessary to determine anything about mining in real time as they only receive information about blocks when those blocks are distributed (on average every 10 minutes, but with high variance).  Because block finding is so variable, it's additionally necessary to average results over large numbers of blocks to get reasonably accurate numbers, meaning the statistics you typically see are either trailing actual block production by several days or are probably quite inaccurate.
In addition, miners don't have to identify themselves in the blocks they create, and the way they do optionally identify themselves is not standardized, so no stock full node provides any method for telling you which miner created which block.

Are you referring to solo miners?                                                               I was inquiring regarding mining pool?                                            How does blockchain.infor or similar sites figure out which mining pool mined specific block?

The details apply to both solo miners and mining pools.  Most mining pools add some text to a special field in blocks (called the "coinbase field", not directly related to the company); block explorers like Blockchain.info look at this text and guess which pool created the block.  However, pools don't just put their names there, so you need to guess which pool uses which text, and anyone can put any text they want, so there's no guarantee a particular pool created a block attributed to it.

Block explorer websites will run full node(s) of their own, and then use data obtained by their node(s) to calculate and present much of the info shown on their website. Not all info shown on the block explorer sites is explicitly present in the block data, some may be calculated or inferred by the block explorer website.

Relayed By", there was a block that was listed as unknown on blockchain.info and showed as "relayed by" by specific mining pool on btc.com

This information is not present in the block, so block explorer websites must use another method to determine it. Note that the peer you hear about a new block from is not necessarily the peer that mined that block.

Is there a way to figure out hash rate of specific mining pool as a % of total in the real time.

This information is also not included in a block.
The total amount of hashing power pointed at the network cannot be measured directly, rather it can be calculated by considering the current difficulty, and the rate of block generation. Knowing the total, you can count how many blocks (of the last x blocks) were generated by a certain pool, to estimate that pool's share of the total hashing power over that time frame.
Note that there is no requirement for a miner to put their name on a mined block, but historically many miners have elected to do so.
For these reasons, it is not possible to make a real time measurement of the hashpower controlled by a certain pool, and even the method described above is not guaranteed to be accurate.


text:
Can I win some money mining bitcoin with an old computer
I went to nicehash.com, a website that allows users to mine bitcoins.
I have my old computer on the side, it still work perfectly, but it's pretty slow. I could use it just for the fun of trying, if I win 50$/month I'm happy.
So I'm wondering, if I try to mine bitcoins, will I win a little money or will I lose some ??
I see 2 ways of actually losing money:
-if my computer is up all day, it will use electricity. If I never get paid, then I lose money in global.
-if my computer dies, I have to buy a new one.
So the two questions are: will I ever get paid, and how much ?
For the first question, I read somewhere that for each new transaction, several computers are ask to do so calculus, and the fastest computer often wins. The computer that wins get paid, the other are not. Is it exact ?
Thank you guys !

The short answer: No, you cannot. Sorry.
The longer answer can be found here: https://en.bitcoinwiki.org/wiki/Difficulty_in_Mining#How_soon_might_I_expect_to_generate_a_block.3F
Applying some common sense: If an old computer could mine for 50 USD / EUR / GBP per month, what do you think how many old computers would your neighbor have bought already and was running in his garage?
Bitcoin mining is only possible on specialized hardware these days. Your milage may vary on very, very recent high end GPUs, but this is far from an old unused PCs CPU power.


text:
Accepting Bitcoin for Services Rendered with Legal Verbiage on Set Coin Price
I accept Bitcoin and Ethereum for consulting work, but would like some feedback for Service Type Agreements that span upwards of a 1-year in an enterprise setting. What's the best method for approaching set coin prices in a legal service agreement where the markets can fluctuate?

If you want to go all in on cryptocurrency, you can make an agreement stating the payment method as BTC or ETH and then the amount. The value of these currencies may vary with time and hence no one really signs such an agreement, yet.
The best you can do is sign an agreement stating the USD value of your services payable in equivalent Bitcoin or Ethereum considering the conversion rate at the time of payment (excluding the transaction fee!) for every payment processed.


text:
How is the balance checked by miners when new addresses are generated?
How is it even possible to check all the transactions for balance when there are constantly new addresses being generated?

Bitcoin itself only needs to track the current set of spendable bitcoins.  It doesn't need to track bitcoins that have already been spent nor any information about who may receive bitcoins in the future (e.g. a new address).
When you create a new address, you don't have to register it anywhere (indeed, you can create the address completely offline), so there is no global tracking of new addresses.  By default, only your wallet tracks information related to a new address.  When someone spends money to that address, then Bitcoin full verification nodes begin to store the address, as it now controls spendable bitcoins.  When you spend those bitcoins, full nodes stop storing the address.  If you later receive more bitcoins to the same address, full nodes will start storing it again.
Some websites continue to store information about historic transactions so they can show every transaction that affected an address.  This is an interesting feature, but it's not directly related to what full nodes do.  Full nodes only store the information related to the current set of spendable bitcoins (plus some additional unindexed information necessary in case they need to recover from a problem).


text:
Sync bitcoin transaction status to local database
I am sending bitcoin transaction in node js via bitcore-lib and bitcore-explorers.
I realized that when i call the function .broadcast to send the transaction to network and returns value, it means that the transaction is broadcasted but not completed.
What I want to ensure that when the transaction is in bitcoin network , I will need to write the status into local database (pending, success or fail).
I am thinking of looping and keep calling the transaction detail by txid until it is completed only it write to database. But thinking that bitcoin network transaction will take up to 30 minutes it might not be a good approach because the node server might take up a lot of resources in keep querying the transaction detail.
Any idea on what's the best practice to ensure that local database transaction detail and status in sync with the bitcoin network?
And what function should i use to get transaction detail? I seems to not able to find query of transaction detail in bitcore library.

Since you aren't running your own node, the best way would be to simply check each new block for your transaction. Since transactions can only be mined if a new block is generated, you don't need to poll for a status chain between blocks.

Not really understand it ... especially on poll for a status chain between blocks. can you further explain about that.

You don't need to do that. You simply need to check each new block. A transaction will not be mined unless there is a new block from when you last checked, so there is no need to do anything in between blocks

I see. But a new block only guaranteed a transaction is mined, does not guarantee a transaction is success right? It still could be a success or fail transaction. Between which function i can call to check new block / new transaction. I can't find it in bitcore librarly