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 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?

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

Create Multiple Output transactions with Bitcoin Core

I am new to multiple output transactions with bitcoind and I want to learn how to implement them.

Let’s say I want to create 2-3 addresses and send 1 btc to the generated addresses. If I want to send 0.4 btc to address1, 0.4 btc to address2 and 0.2 btc to address3, should I create a raw transaction specifying each bitcoin address that will be spent?
If so, I have another doubt; if I want to create a raw transaction, I need a unspent transaction and I know that I can list unspent transaction outputs using listunspent, but what happen if I don’t have any unspent transaction on the bitcoin server? How can I get a list of unspent transactions from blockchain?

Manually checking for credited bitcoins

If I have the bitcoin address, the private key and a transaction ID from Bitcoin (regtest mode) in shell variables, what Python code do I need to run to claim the Bitcoins are indeed intended for this private key?

I have been following this excellent article – Bitcoins the hard way : Using the raw Bitcoin protocol. I hope to replicate this with Bitcoin in regtest mode as part of a larger design.

To begin with, I had to ensure that the code mentioned in the article (available here) can generate Bitcoin address with m or n as the prefix and uses 111 as the network ID. See here. I made the following code changes to generate addresses for regtest mode:

keyUtils.pubKeyToAddr


def pubKeyToAddr(s):
ripemd160 = hashlib.new('ripemd160')
ripemd160.update(hashlib.sha256(s.decode('hex')).digest())
return utils.base58CheckEncode(111, ripemd160.digest())

utils.base58CheckEncode


def base58CheckEncode(version, payload):
s = chr(version) + payload
checksum = hashlib.sha256(hashlib.sha256(s).digest()).digest()[0:4]
result = s + checksum
leadingZeros = countLeadingChars(result, '\0')
return 'm' * leadingZeros + base58encode(base256decode(result))

Then, with bitcoin-qt, I transferred some BTC to an address generated from above. The transfer goes through and is confirmed when a new block is created.

However, I am unable to see the amount credited to this new address with the getreceivedbyaddress command. I am running this command in the Debug Window console (for some reason, bitcoin-cli wouldn’t connect even after configuring bitcoind). I think, the reason could be the fact that, the private key and the bitcoin address was generated elsewhere from command line rather than the default --data-dir location that bitcoin-qt used when it was launched. I understand this.

How accessible is Bitcoin to blind people?

Is it easy or hard for blind people to trade bitcoin if they have the appropriate assistive technology? It is easy or hard for blind people to work at tasks involving bitcoin such as utilizing computers for mining, or confirming transactions on the blockchain?

What kinds of technologies would they likely find beneficial?