What is a mechanism of providing Merkle Path?

In the Bitcoin, SPV node can query that its transaction is included specific block to full node that provides merkle path which has super fast calculation.

In terms of full nodes, they have full-ledger and merkle tree that is consist of transaction tree. so they can find some transaction queried by SPV node(light node) but my question is that how they can efficiently find it?

They may dislike compute to find transaction if they have to sequence search because they are busy to find hash value of block to earn block reward.

Sorry for my English.

Why is no security lost by using 32-byte public keys in Schnorr signatures instead of 33?

There is currently a discussion on the mailing list about truncating the 33rd byte from public keys when used in bip-schnorr.

Public keys are (x, y) coordinates and compressed public keys simply replace the y coordinate with a single byte indicating its oddness. The complete y coordinate can then be derived from the given x coordinate, and so the public key can be expressed in just 33 bytes instead of 64.

By removing the “oddness” byte, public keys will only be expressed by the x coordinate, meaning there are two potential points on the curve that could be represented. This also implies that the same single x-coordinate-only public key could actually be derived from two different private keys.

My question is, why does this not affect the security assumptions of the Schnorr signature? Is it just a subtle effect, like replacing 256 bit security with 255 bit security?

BIP0034 block height using python-bitcoinlib

I’m doing some experiments for finding coinbase height from freshly mined block which is received from ZMQ.

    tx_coinbase = CTransaction.deserialize(x('010000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff2303f90d1800fe6d8a0300fea00a04000963676d696e6572343208010000000000000000ffffffff02bc078402000000001976a914c11998cf0635b9ba940212af99447dfbdcfafe9688ac0000000000000000266a24aa21a9ed7a0ea91535f513cc527e1858a43800c2f6712d45404877f59f564a8eea88276f0120000000000000000000000000000000000000000000000000000000000000000000000000'))
    scriptSig = tx_coinbase.vin[0].scriptSig
    coinbase_script = CScript(scriptSig)
    for o in coinbase_script:
        h = int(b2lx(o), 16)

It is really weird in my opinion. The question:

Is there better solution to parse scriptSig and pull block height?

*It is also an exercise 2 from ‘Programming Bitcoin’ Chapter 9. But I really want to get block height using only raw block obtained from Core via zmq.

How does OP_CHECKSIG work

Hi I am learning bitcoin and learning how scripting works and how to use P2PKH. I was wondering how does OP_CHECKSIG work. I want to understand what is the data that the private key signs to create the digital signature itself?

Is there a simple explanation which illustrates how the digital signature is constructed for verification in OP_CHECKSIG? I understand that the Opcode uses the ECDSA algorithm for verifying the signature but I want to understand how the signature is generated for verification?

Pardon me if this is a basic question. Thanks

For how long has a channel been inactive?

I would like to close channels for which there is enough evidence that the remote node disappeared and won’t come back.
So my idea was to check for how long a channel has been inactive, and if it is > two months to close that channel.

How could I find out for how long a channel has been inactive (in LND)? Finding out which channels are inactive is easy by queryinglncli listchannels --inactive_only, but the result does not show any indicator about how long that channel has been inactive.

Why do I have a socket.timeout with python-bitcoinlib?

I am using a small script and get a timeout from python. This is my script:

import bitcoin
import bitcoin.rpc
from bitcoin.rpc import RawProxy
p = RawProxy()
hash = '0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4'
infoblock = p.getblock(hash)

This is my error:

bitcoin@raspberrypi ~/.bitcoin/BuchSkripte $ python3 49_rpc_example.py
Traceback (most recent call last):
  File "49_rpc_example.py", line 11, in <module>
    infoblock = p.getblock(hash)
  File "/usr/local/lib/python3.5/dist-packages/bitcoin/rpc.py", line 306, in <lambda>
    f = lambda *args: self._call(name, *args)
  File "/usr/local/lib/python3.5/dist-packages/bitcoin/rpc.py", line 236, in _call
    response = self._get_response()
  File "/usr/local/lib/python3.5/dist-packages/bitcoin/rpc.py", line 261, in _get_response
    http_response = self.__conn.getresponse()
  File "/usr/lib/python3.5/http/client.py", line 1198, in getresponse
  File "/usr/lib/python3.5/http/client.py", line 297, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python3.5/http/client.py", line 258, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File "/usr/lib/python3.5/socket.py", line 576, in readinto
    return self._sock.recv_into(b)
socket.timeout: timed out

When using the same method getblock via bitcoin-cli it takes 120 seconds to finish on my Raspberry. If the timeout is related to this duration, can I increase it in the script?

I read that the socket timeout can be set but I wonder if I can do this if I use a library for the connection.

Why does bitcoin-cli not know about working directory of bitcoind?

I have a /ect/systemd/system/bitcoin.service with the following content and I am wondering, why bitcoin-cli getinfo tells me about a configuration file elsewhere:

error: Could not locate RPC credentials. No authentication cookie could be found, and RPC password is not set.  See -rpcpassword and -stdinrpcpass.  Configuration file: (/home/pi/.bitcoin/bitcoin.conf)

Content of bitcoin.service, especially -conf=/home/bitcoin/.bitcoin/bitcoin.conf:

Description=Bitcoin daemon
ExecStart=/usr/local/bin/bitcoind -conf=/home/bitcoin/.bitcoin/bitcoin.conf -pid=/home/bitcoin/.bitcoin/bitcoind.pid
# Creates /run/bitcoind owned by bitcoin
# Hardening measures
# Provide a private /tmp and /var/tmp.
# Mount /usr, /boot/ and /etc read-only for the process.
# Disallow the process and all of its children to gain
# new privileges through execve().
# Use a new /dev namespace only populated with API pseudo devices
# such as /dev/null, /dev/zero and /dev/random.
# Deny the creation of writable and executable memory mappings.

Ironically, encryption is not an important part of bitcoin (?)

The above statement is taken out of a book which I’ve been reading: Mastering Bitcoin 2nd Edition.

…as its communications and transaction data are not encrypted and do
not need to be encrypted to protect the funds…

Just started about bitcoin, going through the third chapter and when I come across the above lines, I merely struck by one question, and that is, if the communication happens between (peers’ / wallet to bitcoin network) is not encrypted…then I am just thinking a scenario

X is sending BTC to Z (obviously by mentioning Z’s address in txn)

Y (bad guy) cuts in the communication which is not encrypted (as per the above reading) and tampers the transaction that X has been sent ( by Just putting his address in beneficiary )

I mean, honestly, it is a very naive scenario that anyone could think of and I know there would be something in bitcoin (which I am not aware of) could prevent this from happening, so, giving clarification on how this kind of attacks being handled or mitigated in Bitcoin would be much helpful for this post.