Debugging bitcoind

How do you attach a gdb to a bitcoind daemon. I wish to step through the functions. Here is what i have tried.

gdb --args bitcoind -regtest -daemon

This however exists when the daemon starts. So i tried attaching via the pid after the fork.

gdb -p 841
(gdb) file /usr/local/bin/bitcoind
Reading symbols from /usr/local/bin/bitcoind...done.
(gdb) b sendtoaddress
Breakpoint 1 at 0x4b4d34: file wallet/rpcwallet.cpp, line 379.    
r
starting program...    

This however does not work , when i invoke a transaction using the bitcoin-cli client. Is there anything i am missing. I have used –enable debug on configure.

Thanks.

How do i loop through all the related address in a given wallet address

I am using bitcoin block chain API, it is possible to get amount sent in a transaction id and the addresses it was sent to. My problem is getting the RELATED ADDRESSES to the address that sent the payment.. The only fact is that I want to be able to validate who sent the money and who it was sent to.. eg. my site involve users sending bitcoin to other users and submitting transaction ID. Each user register and input their wallet address. if User A sends to USer B and submits transaction ID, I want to be able to find out if the transaction is coming from the Sender User and is going to the Receiver Address. Validating for the receiver address is simple with my lines of code:

$requesturl='https://blockchain.info/tx-index/'.$comment.'? format=json';
$ch=curl_init($requesturl);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$cexecute=curl_exec($ch);
curl_close($ch);
$result = json_decode($cexecute,true);
for($i=0; $i<count($result['out']); $i++) {
$result['out'][$i]["addr"];
}

I can get the receiver addresses from the loop above and validate, and if want to get the sending addresses it is also possible with:

for($i=0; $i<count($result['inputs']); $i++) {
// the addr is in the input
}   

Now my problem is if the wallet Address the User A submitted on our website is not in the sending address list, how do I know his address is there in the list.?

How does Bitcoin read from/write to LevelDB

I know that Bitcoin Core uses LevelDB since 0.8 version. However, I couldn’t find detailed explanation about how Bitcoin stores and retrieves from LevelDB. E.g. If B transaction uses an output from previous transaction A as input, how does Bitcoin lookup this transaction and see if it’s spent? After transaction B is spent, how does this transaction get updated?

What are the hex and asm field values in the JSON decoded from a raw transactions?

I used the command line bitcoin-cli decoderawtransaction <hex-value> and got back a JSON output (see below). However, I noticed there are hex and asm fields that are themselves hex values (at times). I am thinking these are metadata that can further be decoded. Is that right?

Is there any more documentation on the structure and meaning of the JSON passed back for these 2 fields (or more)?

I read this SO post which referred to this out-dated article.

Also, I checked the transaction on bitcoin block explorer. They seem to have a few metadata that I don’t see in the JSON (e.g. received time, confirmations, relayed ip, etc…). Where are these values coming from?

{
  "txid": "2514161c059ac18bf2eff1e05c4628e322d846e930fd6dd4b24805ea59dc4913",
  "hash": "2514161c059ac18bf2eff1e05c4628e322d846e930fd6dd4b24805ea59dc4913",
  "size": 259,
  "vsize": 259,
  "version": 1,
  "locktime": 0,
  "vin": [
    {
      "txid": "4f40655c4ab1a029bc41bc547f79556a0dc48d22df7202778fad592791c77fcd",
      "vout": 0,
      "scriptSig": {
        "asm": "3046022100cd6795ebcd1b6b87833a4ad812733d3804065d34bafee24da181a770892272b902210088cd2484952ad2572f9bfb2874643dbb4b3c492b749e79d8177a14eb4a3bc61a[ALL] 04bbf2b84900b6f898548687aefba86cc06da6f4656a71e45fa55128b501455b5486cb09705cfa23c1899fe46d4355c9058bb2de4f1a7f1a01ff27e00b306f7356",
        "hex": "493046022100cd6795ebcd1b6b87833a4ad812733d3804065d34bafee24da181a770892272b902210088cd2484952ad2572f9bfb2874643dbb4b3c492b749e79d8177a14eb4a3bc61a014104bbf2b84900b6f898548687aefba86cc06da6f4656a71e45fa55128b501455b5486cb09705cfa23c1899fe46d4355c9058bb2de4f1a7f1a01ff27e00b306f7356"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 889.94500000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 f9d49c5cf3e120ad1be60b67d868603a8fc945d2 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914f9d49c5cf3e120ad1be60b67d868603a8fc945d288ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1PmyxDv5VvGoSAKMr1DQcWB6sHPx1ZbgWe"
        ]
      }
    }, 
    {
      "value": 10.00000000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 088465c1f0c8b3b3da06f7073a921d6b95b22f49 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914088465c1f0c8b3b3da06f7073a921d6b95b22f4988ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1n31g4rKiEeXnZEZR6VZwm3LggLicEqEC"
        ]
      }
    }
  ]
}

Furthermore, I decoded the raw transaction using https://blockchain.info/decode-tx and got something different.

{
   "lock_time":0,
   "size":259,
   "inputs":[
      {
         "prev_out":{
            "index":0,
            "hash":"4f40655c4ab1a029bc41bc547f79556a0dc48d22df7202778fad592791c77fcd"
         },
         "script":"493046022100cd6795ebcd1b6b87833a4ad812733d3804065d34bafee24da181a770892272b902210088cd2484952ad2572f9bfb2874643dbb4b3c492b749e79d8177a14eb4a3bc61a014104bbf2b84900b6f898548687aefba86cc06da6f4656a71e45fa55128b501455b5486cb09705cfa23c1899fe46d4355c9058bb2de4f1a7f1a01ff27e00b306f7356"
      }
   ],
   "version":1,
   "vin_sz":1,
   "hash":"2514161c059ac18bf2eff1e05c4628e322d846e930fd6dd4b24805ea59dc4913",
   "vout_sz":2,
   "out":[
      {
         "script_string":"OP_DUP OP_HASH160 f9d49c5cf3e120ad1be60b67d868603a8fc945d2 OP_EQUALVERIFY OP_CHECKSIG",
         "address":"1PmyxDv5VvGoSAKMr1DQcWB6sHPx1ZbgWe",
         "value":88994500000,
         "script":"76a914f9d49c5cf3e120ad1be60b67d868603a8fc945d288ac"
      },
      {
         "script_string":"OP_DUP OP_HASH160 088465c1f0c8b3b3da06f7073a921d6b95b22f49 OP_EQUALVERIFY OP_CHECKSIG",
         "address":"1n31g4rKiEeXnZEZR6VZwm3LggLicEqEC",
         "value":1000000000,
         "script":"76a914088465c1f0c8b3b3da06f7073a921d6b95b22f4988ac"
      }
   ]
}

Why are some transactions found on some chain explorers but not on others?

This is something that has puzzled me for a while and I cannot think of a rational reason for it.
The transaction 3361d2484f0566ab13d32f2ab321319945f48eaea1ac2cc9f5a79b40528359c3 shows properly on blockchain.info and tradeblock.

However, I cannot find it either on blockr.io nor blocktrail.com.— I am also running a server to watch transactions and I cannot find this transaction either. Sometimes I can find transactions that do not appear on blockchain so it’s quite random.

All servers have many connections so I wonder what could be the issue? Slow network?

Bitcoin Volatility

I am a French student in a Business School and currently working on a Bitcoin study.

I have 2 questions to you:

  • Are there means, for companies or states, to limit or at least to curb on the volatility of Bitcoin?
  • If not, can a company adopt measures to protect itself from a drastic slump of the Bitcoin price? If so, what are those?

Quadratic hashing problem: Why not just create new OP code “CHECKSIG2” to fix?

Why can’t “we” fix the quadratic hashing problem with OP_CHECKSIG with a soft fork?

Update NO_OPx to OP_CHECKSIG2 with soft fork, where OP_CHECKSIG2 doesn’t quadratically hash (uses a single tx hash of all data for each input maybe?). Create a new transaction type for the new process like P2SH and after wide enough network adoption, soft-fork to invalidate any old OP_CHECKSIG transactions the way BIP 66 worked?

Or is there a fundamental problem with my assumption that “uses a single tx hash of all data for each input maybe” is possible at all?

Disjoint quora slices and global ledger status. [closed]

Theoretically, if all the nodes in the quorum participate only in disjoint slices, then there wouldn’t ever be a single global state of the ledger. Does Stellar help identify such scenarios in the network (main or private)?

From the Stellar Consensus Protocol article, there is a universe of nodes of which a quorum of nodes is enough to arrive at a ‘final’ ledger state.

To tolerate Byzantine failure, SCP is designed not to require
unanimous consent from the complete set of nodes for the system to
reach agreement, and to tolerate nodes that lie or send incorrect
messages.

Then, there is a quorum slice that is a collection of certain nodes within the quorum mentioned above.

Federated Byzantine agreement introduces the concept of a quorum
slice, the subset of a quorum that can convince one particular node of
agreement.

These quorum slices may or may not intersect. enter image description here