text:
What’s the purpose of checking for input overflow?
Everyone knows this famous fix for block 74638 which still exists in other files. But there’s something I can’t understand, why check for inputs overflow since it’s not possible to have enough utxo for such case as it’s their hash being tracked and from an attacker point of view this only decrease what he/she/they have in reality (unlike outputs where it decrease the amount to be paid).
So why making invalid something which is already impossible and would has no impacts as an inflation bug ?
Even the go implementation of bitcoin is doing it.

Which of the three checks you're linking to are you asking for?

@PieterWuille the whole check for inputs. Question edited to reflect this.

It appears to largely be just a belt-and-suspenders check. As you say, it is unnecessary to do this check. However it doesn't hurt to have this check in there. At worst, it just adds a few nanoseconds to verification time. At best, it will catch some serious bugs.
Given that this is consensus related, it does not hurt to have extra checks that are theoretically unnecessary. They will prevent errors in cases where some edge case occurs. In this case, it was possible for an input with negative value to be spent and thus this check would come into play. That would occur if someone updated their node following the block with the bad transaction, but did not rollback their blockchain. If the owner of the negative output had spent it, this check would have prevented the node from accepting the transaction.

The points is every cryptocurrencies are doing it. Even those not using Bitcoin code like Monero. So it seems to be strange that all cryptocurrencies tracking coins instead of balances are ensuring what would be an unnecessary check. Maybe there’s something I missed and an inflation attack from input overflow is possible ?

Most of those cryptocurrencies just blindly copied and forked the Bitcoin source code. The check is there because they didn't bother to remove it. The check is still in Bitcoin Core because Bitcoin Core hasn't bothered to remove it. I don't think there's really any real reason as to why it's still there other than that it was added and it does no harm.

Yes, for those who started by forking Bitcoin. But for monero (which is an example among others), I can say definitely that’s it’s not Bitcoin code.

You would have to ask the Monero developers. It is possible that they have it because a break in Monero's cryptography would allow for hidden inflation. It is also possible that during the initial implementation, they were copying code from Bitcoin even if they did not directly fork their source code from Bitcoin. After all, they have a somewhat similar transaction and blockchain model, so there's no need to rewrite everything from scratch.

the same is true for Zcash Joinspits.

While it's not valid on the Bitcoin network for inputs to add up to a negative amount, or to more that 21 million, the computer doesn't innately know that - it needs a program to instruct it. Your link is to one point in the bitcoind program where the computer is instructed how to tell the difference between valid, and invalid, transactions.
You can also think of your assertion "it’s not possible to have enough utxo" another way. One reason it is not possible is because of the IF statement you point to: remove the check, and suddenly it IS possible (later code withstanding.)

If "duplicate inputs things are deleted later" then the processing between this point and that later point is wasted because it is known /now/ that they won't pass.
What the attacker may or not believe seems irrelevant to your question "What’s the point of checking inputs overflow?". I suggest if my answer isn't what you're after, you further clarify what you're asking.

@user2284570 Both your question and this remark is actually very confusing with incomplete and grammatically incorrect sentences. The remark, to a good attempt at an answer, is very rude as well. I'm very much inclined to vote for closing this whole question if you don't improve it.

@Jannes While it's not valid on the Bitcoin network for inputs to add up to a negative amount the point is why making invalid something invalid and why would an attacker would want this as a 74638 block style attack. So know I suppose you understand the answer is like answering what will be the weather tomorrow to a question asking how the weather was yesterday, that is : an off topic answer. The answer explains why it’s impossible whereas the question is about why making it impossible. Of course, please edit the question to reflect this.

@AlistairMann the question is about why making invalid something which is already impossible whereas you’re answering how it’s done to do it.

@AlistairMann the code I’m referring to is only a security fix for an inflation bug and has no purpose for ᴅᴅᴏꜱ logic. Is it clear now ?

Seems to me this patch is about adding proper bounds checks, which must be done in all relevant places where bad data can lean in. It also makes perfect sense to do this as early as possible in the call stack. Simple input validation logic. I still don't understand your problem.

@Jannes yes and the point of the question is why doing it on inputs ? This has no sense because for inputs bad data can’t lean in for inputs. Also, only overflowing output is interesting since it allows to decrease transaction value requirement : something which has no sense for inputs.


text:
What happen when 2 transactions with one doublespending the other reachs the same block?
Let’s have 2 transactions. The second one is duplicating Input of the first one.
Both have very high fees so they are selected by miner to be included in the same block but before passing validation (because it makes no sense to validate transactions if they aren’t included in the block after because the fee is too low).
Which is the transaction is going to be rejected by not being included in the block ? The first one with a slightly lower fee than the second or as it’s the same block, the second one ?
And where is the code in Bitcoin core handling this ? I mean which source files and lines ?

So it’s the case of duplicate inputs for 2 different transactions in the same block.

Which is the transaction is going to be rejected ? The first one with a slightly lower fee than the second or as it’s the same block, the second one ?

Generally speaking, miners will choose the transaction that has the highest fee, but they are not obliged to.  In fact they don't need to mine any of your transactions if they don't want to.

Both have very high fees so they are selected by miner to be included in the same block.

No, the miner must choose 1 or zero not both, otherwise the block they create will be invalid if it contains a double-spend.  Invalid blocks will waste the miners time and money as they will be rejected by the network.

And where is the code in Bitcoin core handling this ?

Sorry, can't help with specific location.

Both have very high fees so they are selected by miner to be included in the same block. Before being validated of course. Because it makes no sense to validate inputs if they aren’t included in the block after.

@user2284570 no, a transaction is validated before it is added to a block, that is how blocks are built: From transactions that are known to be valid, as a whole. It makes no sense to only check to see if they are valid after mining a block, that would be a waste of resources.

@chytrik I’m talking about fees. Transactions are validated by the miner only if they pay enough fees to be included in next block.

@user2284570 that is incorrect. I think you're mixing up what 'validate' means. Every node on the network that hears about a new tx will validate it before relaying it to network peers. Likewise, miners will validate each transaction before the add it to a block template that they will mine one. Once the miner finds a valid block, the transactions they added to it are said to be confirmed. So there is a difference between valid and confirmed. In fact, an otherwise valid transaction may never be confirmed (perhaps it paid too low a fee, or was not seen by miners, etc).

@chytrik what I mean is miners don’t process the whole mempool and then includes transactions with the best fees in the block : they only check those which pay enough fees to be included.

@user2284570 if a transaction is in the miner’s mempool, that means they have already validated it. So yes, miners do ‘process the whole mempool’ first

@chytrik no! The mempool don t check for double spends which are in the mempool. And as the process of nodes is not serialized unlike the block generation process this wouldn t makes sense. So in the case of the mempool double spending checking is performed only against coins in the ledger not on transactions not yet mined.

@user2284570 Just repeating this claim does not make it true. As everyone is already telling you: all transactions in the mempool are already validated, or they wouldn't be in the mempool. Miners typically select from this set of valid transactions that maximizes feerate.

Regarding double-spend checking: Bitcoin Core maintains two "views" of the UTXO set; one from just confirmed blocks, and one from blocks + everything in the mempool. New incoming transactions are fully validated against the latter (they're allowed to spend unconfirmed outputs). When a new block comes in, the mempool is reconciled with it (removing transactions that were confirmed or now conflict with the new block).

@PieterWuille but I m not merely repeateating, this is you who are wrong. But said otherwise, checktxinputs in validation.cpp uses haveInput which only read from disk cache or from disk directly not in the mempool. And for reference https://bitcoin.stackexchange.com/a/37534

@user2284570 CheckTxInputs is passed a CCoinsViewCache object in AcceptToMemoryPoolWorker, which is backed by a CCoinsViewMemPool object, which in its turn looks up transactions in the mempool.

@PieterWuille this is nonsense. Even then what happens when submitting 2 new transactions using the same inputs to 2 different unconnected nodes considering network latency ? There are several nodes, this block generation which serializes the process.

@user2284570 If you can't have a civil conversation about this, I'm done explaining. There are lots of interesting details to learn about how all of this works, but you seem to reject everything knowledgeable people try to explain.

@PieterWuille and finally an example of what I’m saying.

@user2284570 that example involves situations in which some miners would not accept certain transactions into their mempool, it does not show more than one tx in a certain miner’s mempool spending the same inputs. As people here have attempted to explain to you, such a situation is not possible. Note that each node maintains its own mempool, and that is part of how double spend txs can be published. Double spent inputs can not exist validly in a single node’s/miner’s mempool.

Every transaction included in a block must be valid in order for the block to be valid. An input can only be spent once, any attempt to spend it again would be invalid.
So in your example, the entire block would be invalid and thus rejected by the network. Nodes that hear about and attempt to validate the block would get to the second transaction, see it is invalid (because one of its inputs was already spent), and reject the entire block.
Generally, miners will choose the transaction that pays them the most. The bitcoin-core rules for relaying transactions are separate from this, so they aren’t of much consequence in the real world. A miner could easily run their own modified software that builds blocks in a way they like. Even if a transaction isn’t marked RBF, there is nothing stopping a miner from including a higher paying transaction they heard about instead.

No, I was meaning which is the block the miner will reject if he/she uses Bitcoin core. Because of course miners rejects transactions that attempt to double spend.

I added a bit to my answer, hopefully that helps.

I am going to interpret this question from a different angle: If a node were to receive a block with two transactions that spend the same input, which transaction will it return to the mempool and which will it discard?

When a node receives a block that contains two or more transactions that spend the same inputs, the block would be marked invalid and thrown away entirely. None of the transactions in that block would be considered confirmed and any transaction that was already in the mempool will remain there. A transaction was not in the mempool but was in the block will not be added to the mempool.
As such, when the node receives this invalid block and validates it, when it determines it to be invalid, it throws away the block and does nothing. It does not change the UTXO set and it does not change the mempool. This means that if any of the conflicting transactions were in the mempool when the block is received, it will remain there. If none were, none of those transactions will be added to the mempool.
So if one of the conflicting transactions paid a higher fee, but the lower fee transaction was already in the node's mempool, the lower fee transaction would stay in the mempool and the higher fee one thrown away with the block.
The code for this behavior is here. ConnectBlock takes a CCoinsViewCache which is a cache for the UTXO set. This cache only writes out the changes made to it when its Flush() function is called. ConnectBlock will return false because the block is invalid and as such, this function will return here before Flush() can be called here. So no changes will be made to the UTXO set.
Furthermore, that early return due to an invalid block means that the mempool update will not occur either. The call for the mempool update here will not be reached because of the early return and thus the the transactions that were in the mempool at the time the block was received will remain there, and the ones that weren't in the mempool will be thrown out along with the block.

I’m talking about rejection done by miner which I don’t know because if I’m correct such invalid block rejection is performed in CChainState::ConnectBlock in validation.cpp at UpdateCoin which ensure next input check will take into account coins spent by transactions in the same block.

The check for whether an input exists is done in CheckTxInputs which is called in multiple places, including ConnectBlock as well as AcceptToMemoryPoolWorker. It is not just checked when a block received; it is always checked whenever a transaction is received, whether that is in a block or over the network as an unconfirmed transaction.

source: Stack Exchange

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

sort: votes


text:
What’s the opcode sequence for doing the reverse of Multisig?
With a multisig wallet, several public keys are needed to spend an amount. But how to perform the reverse with time ?
I’m talking about this case where Alice performs a transaction where the output is sent to both Bob and Victor. With one point : Bob will be able to spend the transaction output immediately while Victor will only be able to do it after waiting some time if Bob didn’t spend it before Victor is allowed to do so.
It doesn’t matter if Bob is still able to spend the output after Victor can. However Alice can’t get the public keys from Bob and Victor but only their address.
I’m thinking about something using OP_CHECKLOCKTIMEVERIFY or CHECKSEQUENCEVERIFY or nLockTime but I definitely fail to think about what the whole Opcode sequence might looks like.

The following scriptPubKey describes the desired contract:
OP_IF
    OP_DUP OP_HASH160 <Bob's pubKeyHash>
OP_ELSE
    <now+30 days> OP_CHECKLOCKTIMEVERIFY OP_DROP
    OP_DUP OP_HASH160 <Victor's pubKeyHash>
OP_ENDIF
OP_EQUALVERIFY OP_CHECKSIG

Bob can spend the output using the scriptSig <Bob's signature> <Bob's pubKey> OP_TRUE
Victor can spend the output after 30 days using the scriptSig <Victor's signature> <Victor's pubKey> OP_FALSE.

http://bitcoin.sipa.be/miniscript/miniscript.html. Wouldn’t it rather be https://pastebin.com/pzQKN0ud ?

no I don't think you need that 1 and 2 there. In my version, Bob could pay by with   1  , and victor with   0 , but I don't doubt there is a better way

This is after https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#Escrow but which is for MultiSig in the case of Victor.

You don't need 1 and 2. Those are only required for OP_CHECKMULTISIG. This is just an OP_CHECKSIG which does not need a threshold number.

Yeah you don't need multi-sig right. Just bob can spend funds at any time, victor can spend funds after some time as long as bob hasn't already spent them. So no 1,2, multi-sig thing. Just Bob can spend, or Victor can spend after a time has past.

@AndrewChow yes, I want to avoid MultiSig. Now just a question : how can I compile this to something ? And how to test the resulting script on bitcoin testnet ?

Check out https://github.com/kallewoof/btcdeb. That project produces two tools. btcdeb lets you give a script and execute it in order to debug the script and learn how it works. btcc can take a script written out in english and compile it to the actual bytes for the script.

@AndrewChow I mean something working online. I want to see what this gives in a block explorer, so I definitely need to broadcast on testnet. Like if Bob or Victor address would be changed as result (I mean the transaction would create virtual addresses).

There is no such thing as "virtual addresses". Bitcoin does not actually use addresses, they are just abstractions for humans. Such a script does not encode addresses and block explorers would not show that a transaction is sending to two addresses with this script. All they would show is a single address corresponding to the P2SH address that has this script as its redeemScript.

@AndrewChow ok… I found out what I was really meaning… I mean is it possible to use this in a pay‑to‑public‑key‑hash instead of a pay‑to‑public‑script‑hash transaction ? I definitely need the payment to appear to be made to at least Victor address or Bob address in the block explorer instead of script hash…

No, you can't. It is a script, a script is not a key. You cannot make a script be a key.

@AndrewChow I was thinking this because checksig is performed after each address in the similar case of https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#trustless-payments-for-publishing-data. Of course, this means there’s no way Bob or Victor Balance would be changed in a block explorer.

@user2284570 so perhaps you want the output to not be a p2sh format, but rather have this script visible (when decoded from hex form) in the output? Anyway I think I answered the original question. Consider opening a new one for further refinements and mark this one as answered.

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


text:
How to search for a transaction using a specifc OPCODE?
I have several OPCODES where I need real worlds examples…
However they are rarely used. So how to search and disassemble an existing mined transaction using it ?

I can't a provide a full answer right now due to my lack of SQL skills, but maybe someone can pick it up from that: http://blockchainsql.io/Query/Template/14

I don't think this is possible. Most, if not all, block explorers and blockchain indexers do not completely disassemble scripts and index them so that they are searchable. No software or service I know of allows you to search by opcode use in a transaction. It would be pretty useless for a service to provide this as probably no one would actually use it and having such an index would be a huge resource cost.
I think the best you will be able to do is to do write a program to look through every single transaction's scriptSig and looking for the opcodes that you want. However, be careful that you don't interpret random bytes as being opcodes. You will need to have something that can disassemble scripts and check the disassembled scripts for the opcodes that you want. Furthermore, such disassemblers won't be able to disassemble a redeemScript which is the actual script where opcodes will actually be for P2SH inputs.

Instead of searching for an example of an opcode which probably hasn't been used, just try using it yourself. I recommend that you read https://en.bitcoin.it/wiki/Script to get an idea of how the opcode works. Then you can use a tool like https://github.com/kallewoof/btcdeb to execute and debug your script. This way you can learn how the opcode works through experimentation and see exactly how a script interpreter will execute the script.

What about http://blockchainsql.io which inlude Opcode searching in transactions by ɪᴅ (though I have too limited knwolwedge to write the request) ? I only need basic dissaembly, not full.For trying, I don’t know how to compile a script nor I know how to convert an address into a hash for Scripting nor I know how to broadcast a transaction on Bitcoin testnet (I’m not aware of any online services allowing that). What I need is to verify some opcodes don’t create a new virtual address in block explorer (I mean that the money appear to be received to everyone).Hence the need for a block explorer.

AFAICT blockchainsql.io does not allow searching by opcode. It has a table which has all of the opcodes, but that does not mean that you can search for a transaction containing an opcode as the fields for transactions do not contain any reference to their opcodes table. Instead of trying to do something that you do not understand, why not simply ask exactly what it is that you want to understand and people here can help you. You are asking a question that you think will help you understand something you don't, so just ask the thing that you don't understand.

Ah yes… Correct, but asking directly is something I did already.

Ok, then this exactly what I said since the beginning, I definitely need a real world example of OP_CHECKLOCKTIMEVERIFY for starting because as I understand, I need to construct signing in the transaction script manually which means there’s simply too much too do for just seeing the result in a block explorer anyway whatever happends.

BitDB is an API to access (unfortunately) Bitcoin SV transactions. You can find instructions for opcode search if you scroll down at https://docs.bitdb.network/docs/indexer#level-2-script

I don't think this deserved the downvote! I gave a +1 just now! I saw that you committed to "Bitcoin Cash". Since you've been active on Chemistry and Quantum Computing and Mathematics too, could you consider committing also to Materials Modeling which covers design of materials for solar cells, photo-voltaics, energy storage materials, new developments in batteries, and lighter or

stronger materials for cars, airplanes, spaceships, etc. It would be very lovely to have you in the Private Beta! Please commit if you don't think it would be inconvenient!


text:
How to uncompress a public key?
Simple question but I couldn’t find the answer anywhere.
What’s the 65 bytes version of those public keys ?
0229b3e0919adc41a316aad4f41444d9bf3a9b639550f2aa735676ffff25ba3898
02f15446771c5c585dd25d8d62df5195b77799aa8eac2f2196c54b73ca05f72f27

which for reference yields according to Bitcoin core getrawtransaction 5ed3694e8a4fa8d3ec5c75eb6789492c69e65511522b220e94ab51da2b6dd53f 1 "00000000000000001e76250b3725547b5887329cfe3a8bb930a70e66747384d3" :
18p4JBHP3EAKCc4jqN8XzuEJtvq8G9NAot
1Dh8oSChJWZQx5sr7ePsBNtw7uKMsNnYNC

with transaction output being :
1 04ad90e5b6bc86b3ec7fac2c5fbda7423fc8ef0d58df594c773fa05e2c281b2bfe877677c668bd13603944e34f4818ee03cadd81a88542b8b4d5431264180e2c28 0229b3e0919adc41a316aad4f41444d9bf3a9b639550f2aa735676ffff25ba3898 02f15446771c5c585dd25d8d62df5195b77799aa8eac2f2196c54b73ca05f72f27 3 OP_CHECKMULTISIG

So that while the first Public key is uncompressed, they are no version uncompressed version of the 2 others keys on the Blockchain which means Bitcoin core is recovering the 2 addresses above from the compressed public keys (the first one being not included because the Public key is uncompressed).

Points are decompressed by solving for y in the equation used for secp256k1's elliptic curve where x is the last 32 bytes of your public key. The equation is y^2 = x^3 + 7. You will get 2 possible y values, one even and one odd. The correct one is indicated by the prefix byte of your public key which indicates whether y is even or odd.
Note that all operations must be modulo p which is defined by secp256k1's spec as being 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F.
This python script will decompress the two public keys that you have posted:
#! /usr/bin/env python3

import binascii

p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F

def decompress_pubkey(pk):
    x = int.from_bytes(pk[1:33], byteorder='big')
    y_sq = (pow(x, 3, p) + 7) % p
    y = pow(y_sq, (p + 1) // 4, p)
    if y % 2 != pk[0] % 2:
        y = p - y
    y = y.to_bytes(32, byteorder='big')
    return b'\x04' + pk[1:33] + y

print(binascii.hexlify(decompress_pubkey(binascii.unhexlify('0229b3e0919adc41a316aad4f41444d9bf3a9b639550f2aa735676ffff25ba3898'))).decode())
print(binascii.hexlify(decompress_pubkey(binascii.unhexlify('02f15446771c5c585dd25d8d62df5195b77799aa8eac2f2196c54b73ca05f72f27'))).decode())

The uncompressed public keys are:
0429b3e0919adc41a316aad4f41444d9bf3a9b639550f2aa735676ffff25ba3898d6881e81d2e0163348ff07b3a9a3968401572aa79c79e7edb522f41addc8e6ce
04f15446771c5c585dd25d8d62df5195b77799aa8eac2f2196c54b73ca05f72f274d335b71c85e064f80191e1f7e2437afa676a3e2a5a5fafcf0d27940cd33e4b4

Pubkey decompression is completely different and unrelated to address generation. Addresses are generated by taking a public key as is (either compressed or uncompressed) hashing it, and then encoding it. The compression matters because the resulting serialized public will produce one hash (and thus one address) when it is compressed, and a different hash (and thus different address) when uncompressed.
Addresses are encoded by hashing the serialized public key with SHA256 and then with RIPEMD160. The resulting hash is encoded using Base58 Check encoding.
In the transaction you provided, the three public keys:
04ad90e5b6bc86b3ec7fac2c5fbda7423fc8ef0d58df594c773fa05e2c281b2bfe877677c668bd13603944e34f4818ee03cadd81a88542b8b4d5431264180e2c28
0229b3e0919adc41a316aad4f41444d9bf3a9b639550f2aa735676ffff25ba3898
02f15446771c5c585dd25d8d62df5195b77799aa8eac2f2196c54b73ca05f72f27

have the following hashes respectively:
946cb2e08075bcbaf157e47bcb67eb2b2339d242
55af2ea3c45819c6c5ae710d29fcaaced5b00cc7
8b38a8d40e08362046dee55c1c94e7991d7dec75

Encoding those as version 0 addresses with Base 58 Check encoding results in the addresses you are expecting:
1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P
18p4JBHP3EAKCc4jqN8XzuEJtvq8G9NAot
1Dh8oSChJWZQx5sr7ePsBNtw7uKMsNnYNC

The code I used for this is:
#! /usr/bin/env python3

import binascii
import hashlib

b58_digits = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'

def sha256(s):
    return hashlib.new('sha256', s).digest()

def ripemd160(s):
    return hashlib.new('ripemd160', s).digest()

def hash256(s):
    return sha256(sha256(s))

def hash160(s):
    return ripemd160(sha256(s))

def encode(b):
    # Convert big-endian bytes to integer
    n = int('0x0' + binascii.hexlify(b).decode('utf8'), 16)

    # Divide that integer into bas58
    res = []
    while n > 0:
        n, r = divmod (n, 58)
        res.append(b58_digits[r])
    res = ''.join(res[::-1])

    # Encode leading zeros as base58 zeros
    import sys
    czero = b'\x00'
    if sys.version > '3':
        # In Python3 indexing a bytes returns numbers, not characters.
        czero = 0
    pad = 0
    for c in b:
        if c == czero: pad += 1
        else: break
    return b58_digits[0] * pad + res

def to_address(b, version):
    data = version + b
    checksum = hash256(data)[0:4]
    data += checksum
    return encode(data)

pk1 = binascii.unhexlify("0229b3e0919adc41a316aad4f41444d9bf3a9b639550f2aa735676ffff25ba3898")
pk2 = binascii.unhexlify("02f15446771c5c585dd25d8d62df5195b77799aa8eac2f2196c54b73ca05f72f27")
pk3 = binascii.unhexlify("04ad90e5b6bc86b3ec7fac2c5fbda7423fc8ef0d58df594c773fa05e2c281b2bfe877677c668bd13603944e34f4818ee03cadd81a88542b8b4d5431264180e2c28")

h1 = hash160(pk1)
h2 = hash160(pk2)
h3 = hash160(pk3)

print(to_address(h3, b'\x00'))
print(to_address(h1, b'\x00'))
print(to_address(h2, b'\x00'))

(Base58 encoding function from https://github.com/bitcoin-core/HWI/blob/master/hwilib/base58.py)
As you can see, this does not do any point compression or decompression. Rather it takes the public key as it is and encodes it.

@user2284570 however care must be taken not to interchangeably use the compressed and uncompressed public keys. Addresses generated from uncompressed and compressed public keys are different.

@Andrew Chow This is not exactly right, you're implementing "03 means nonsquare Y, 02 means square Y". It should odd/even.

@AndrewChow There is a slight error in the code. You need to check the sign of the y-coordinate generated from the modular sqrt and then check if its sign is equal to the one attached to the compressed public key. That is because you do not know whether the y you have generated is odd or even. You are doing it the other way around.

It should be more like: y = y if y%2 == pk[0]%2 else p-y

Whoops. I think it's correct now.

Yes. It was easy to overlook. You got both those uncompressed public keys correct by accident.

@UgamKamat but then, how does Bitcoin core do to get addresses from compressed PubKey in bare Multisig transactions ?

@user2284570 Bitcoin Core by default uses compressed public keys. So the bare multi-sig addresses would be generated by base58encode of hash160(M...N). Note that if the public keys are uncompressed, the multi-sig address generated will be completely different than what is generated with compressed public keys.

@AndrewChow sorry : I used the wrong Public key in my question. May you update your answer ? Not only that it doesn’t work with the new Public keys since 0229b3e0919adc41a316aad4f41444d9bf3a9b639550f2aa735676ffff25ba3898  is 18p4JBHP3EAKCc4jqN8XzuEJtvq8G9NAot which isn’t the result given by 0429B3E0919ADC41A316AAD4F41444D9BF3A9B639550F2AA735676FFFF25BA3898D6881E81D2E0163348FF07B3A9A3968401572AA79C79E7EDB522F41ADDC8E6CE which gives 18EA4v85M4qiUHrs3Vs9awRm86HsStCGzi. So ʏᴏᴜʀ ᴀɴꜱᴡᴇʀ ɪꜱ ᴡʀᴏɴɢ !

@UgamKamat I mean the 3 addresses you get with in vout 4 with getrawtransaction 5ed3694e8a4fa8d3ec5c75eb6789492c69e65511522b220e94ab51da2b6dd53f 1 "00000000000000001e76250b3725547b5887329cfe3a8bb930a70e66747384d3" By testing this answer, on the compressed public keys of that transaction you can see that it’s wrong. Do you have any ideas why ?

@user2284570 As i mentioned in my first comment, addresses generated from compressed public key and uncompressed public key are different.

The answer is not wrong. You are misunderstanding how addresses are derived from public keys. The uncompressed and compressed versions of the same public key will produce two different addresses. Public keys are not compressed or uncompressed before address conversion, they are serialized as is (either compressed or not) and hashed and encoded.

@UgamKamat no, for the case I’m referring to only the first public key in uncompressed. There’s really uncompressed public keys on the ledger. Please see my last edit.

@user2284570 I have already shown you how Bitcoin Core is getting addresses for the last two public keys which are compressed. It's the same process for the uncompressed address as well. I've updated my answer to generate its address as well.

@user2284570 Can you explain what you think Bitcoin Core is doing? That way we can explain what it is that you have mistaken.

@AndrewChow ok. I simply thought uncompressing public key was required for address generation.

For anyone interested in the math: the magical line y = pow(y_sq, (p + 1) // 4, p) is due to p in the curve bitcoin uses being like p % 4 == 3 otherwise you have to use an algorithm such as Tonelli–Shanks to find y.

I don't think the second mod operation is needed for y_sq since pow(x, 3, p) + 7 will be always less than p.

If you're looking for a quick utility to compress/uncompress Secp256k1 public keys, try bitcoin-ts:
const {instantiateSecp256k1, hexToBin, binToHex} = require("bitcoin-ts")
const secp256k1 = await instantiateSecp256k1();

const compressed = hexToBin('02ad90e5b6bc86b3ec7fac2c5fbda7423fc8ef0d58df594c773fa05e2c281b2bfe');

const uncompressed = secp256k1.uncompressPublicKey(compressed);
console.log(binToHex(uncompressed));
// => 04ad90e5b6bc86b3ec7fac2c5fbda7423fc8ef0d58df594c773fa05e2c281b2bfe877677c668bd13603944e34f4818ee03cadd81a88542b8b4d5431264180e2c28

const recompressed = secp256k1.compressPublicKey(uncompressed);
console.log(binToHex(recompressed));
// => 02ad90e5b6bc86b3ec7fac2c5fbda7423fc8ef0d58df594c773fa05e2c281b2bfe

Run in the browser →


text:
What does malleable mean in "transaction malleability"?
Does malleable mean modifiable?
If you can malleate a transaction you can modify some of its parts leaving the transaction as still valid (the signatures are not broken).
If you can malleate the transaction outputs you can modify the outputs.
If you can malleate the order of inputs you can modify the order of inputs.
But the bitcoin.stackexchange.com "transaction-malleability" tag says:

A property of Bitcoin transactions that allows them to be replicated
  with another transaction id before they are included in a block.

This confuses me. Does transaction have an ID at all, and if it does ID seems totally irrelevant?

Malleability is ability to change the binary contents of transaction (that also includes its TXID) without invalidating it, by someone else after broadcast and before the confirmation in block.

Couldn't the word modifiable be used instead malleable, because this is just modifying the transaction in some way, if I understand correctly?

Hm. Let us take any txA and any txB. Can we say that txB is a modification of txA where all bytes of txA were modified to bytes of txB ? :))))

Than the word change (changable) instead malleate (malleable). Malleable just sounds fancy, but in fact just means change the transaction?

It's a standard term in cryptography. Malleability specifically refers to the ability to change a signature without being authorized to sign.

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


text:
Why is scriptSig filled with scriptPubKey before signing a transaction?
I'm checking the transaction signing as described here Redeeming a raw transaction step by step example required.
What is the reason for steps 5 and 6: temporarily filling scriptSig with scriptPubKey of the output we want to redeem?
Can't this just be skipped, as with txid and output index we uniquely specify the output thus scriptPubKey and we don't get any value with this filling?

There seem to be no reason: Ken Shirriff's blog explained it this way:

Then the signature is turned into code in the Script language,
  creating the scriptSig script that is embedded in the transaction. It
  appears that using the previous transaction's scriptPubKey during
  signing is for historical reasons rather than any logical reason.[17]

and the link points to a thread from 2013:
https://bitcointalk.org/index.php?topic=102487.msg1123257#msg1123257

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


text:
Why are transactions grouped into blocks? (how are new blocks-to-solve formed)
Why are transactions grouped into blocks when put onto blockchain (PART 1)?

Lets say we have just put a block on a chain and there are no blocks at the moment that users mine. At that moment how many new blocks will get created for users to mine? Will only one block-to-solve get created, or more of them?
If more blocks will get created (to be mined on), how will the miners distribute themselves on the blocks?

Why are transactions grouped into blocks when put onto blockchain?

Blocks provide a way for transactions to be committed to the blockchain. They are what allow transactions to become immutable. By grouping transactions into a block, they become protected by the Proof of Work that the miner had to do in order to create the block. This means that in order for anyone to change a transaction, they must also perform the Proof of Work to modify the block too, and all blocks that come after the block a transaction was in.

Lets say we have just put a block on a chain and there are no blocks at the moment that users mine. At that moment how many new blocks will get created for users to mine? Will only one block-to-solve get created, or more of them?

If more blocks will get created (to be mined on), how will the miners distribute themselves on the blocks?

Mining does not work like this. Blocks are not distributed to miners to be worked on.
You can think of minining more like this: each miner creates a block, hashes it, and sees if it is less than the target. If it is not, they throw away the block and make a new one that is slightly different. They do that over and over until a block is found that has a hash that is less than the target. Miners will end up making quadrillions or even quintillions of invalid blocks until they get lucky and make on that is valid. Each block is unique and constructed by the miners themselves.

Hi. I realized my question is too broad so I'll separate it in more questions and post each one separately as a new question. Can you address the edited question?

I have updated my answer.

Thx. In couple of minutes I will add related question on the site.


text:
would you please tell me where is the cpp file in which immature_balance function concerned?
I am just wanting to clear up a few details of the bitcoin immature_balance.Such as how to create the immature_balance? How to increase or reduce the immature_balance? And where is the cpp file which is concerned?
I can't found the cpp file which is concerned. So would you please tell me where is the cpp file in  which immature_balance function concerned? Thank you very much.
By the way , my bitcoin version is bitcoin-0.20 and it runs in segtest mode.

Take a look at
/bitcoin/src/interfaces/wallet.h,
/bitcoin/src/qt/overviewpage.cpp,
/bitcoin/src/wallet/interfaces.cpp,
/bitcoin/src/wallet/rpcwallet.cpp

and the tests in

/bitcoin/test/functional/wallet_basic.py,
/bitcoin/test/functional/wallet_multiwallet.py

wallet.h
//! Collection of wallet balances.
struct WalletBalances
{
    CAmount balance = 0;
    CAmount unconfirmed_balance = 0;
    CAmount immature_balance = 0;
    bool have_watch_only = false;
    CAmount watch_only_balance = 0;
    CAmount unconfirmed_watch_only_balance = 0;
    CAmount immature_watch_only_balance = 0;

    bool balanceChanged(const WalletBalances& prev) const
    {
        return balance != prev.balance ||
               unconfirmed_balance != prev.unconfirmed_balance ||
               immature_balance != prev.immature_balance ||
               watch_only_balance != prev.watch_only_balance ||
               unconfirmed_watch_only_balance != prev.unconfirmed_watch_only_balance ||
               immature_watch_only_balance != prev.immature_watch_only_balance;
    }
};

please note a couple deprecated calls in rpcwallet.cpp
static RPCHelpMan getwalletinfo()
{
    return RPCHelpMan{"getwalletinfo",
                "Returns an object containing various wallet state info.\n",
                {},
                RPCResult{
                    RPCResult::Type::OBJ, "", "",
                    {
                        {
                        {RPCResult::Type::STR, "walletname", "the wallet name"},
                        {RPCResult::Type::NUM, "walletversion", "the wallet version"},
                        {RPCResult::Type::STR, "format", "the database format (bdb or sqlite)"},
                        {RPCResult::Type::STR_AMOUNT, "balance", "DEPRECATED. Identical to getbalances().mine.trusted"},
                        {RPCResult::Type::STR_AMOUNT, "unconfirmed_balance", "DEPRECATED. Identical to getbalances().mine.untrusted_pending"},
                        {RPCResult::Type::STR_AMOUNT, "immature_balance", "DEPRECATED. Identical to getbalances().mine.immature"},

please review the reduce storage section in https://bitcoin.org/en/full-node#configuration-tuning if you are running in pruned mode
confirm your Berkeley db built, it stores wallet data and has a couple things to look out for in the configuration (especially if you use Ubuntu or Debian)
https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md
https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md#berkeley-db
couple notes on Segwit
https://bitcoincore.org/en/2016/01/26/segwit-benefits/


text:
old paper wallet shows missing balance after import; hacked? Bug? Confused?
I have an old (2014) paper wallet I've deposited coins into over the years.  I have another paper wallet that was generated around the same time, but wasn't used until last year.  I just finished syncing Bitcoin Core and imported the keys from the paper wallet, first the older key without rescan, then the newer key with rescan.
After a rescan, I'm not seeing the expected balance.
I've been monitoring the old wallet with the Samourai Sentinel app.  This app shows a balance of 8 BTC at the address.  When clicking through, the app takes me to: 1PMoUJpj73FUTbjMiKwJfJoo4fJaUE9bTr.  This looks about right, and like what I expect. (for some reason, the link doesn't work direct, but navigating to http://srv1.yogh.io and entering the address brings it up; cookie related probably)
But in Bitcoin Core, I don't see the balance.  I do see the balance for the newer wallet, which has 2 BTC in it here: 1LwpoTZwuS8Yw5T9EdnnHemmqQ46jCUznK.
$ bitcoin-cli listreceivedbyaddress
[
  {
    "address": "14H7dShaq6CGtyZQujckNSswac7tM5CMjE",
    "amount": 7.00850502,
    "confirmations": 388012,
    "label": "",
    "txids": [
      "d7896aa4f8bc3cb40c7abc5e388f9f505b607a57b73a0ab6594355eb6977155e",
      "ecc0149be32a31f721ed722b6788773796c627bfc6edab6dcd6242a4cd0f2a5e",
      "8a0ac886cff7af925be4df890e0fddc44929bd781716661c1706536c92d74789"
    ]
  },
  {
    "address": "1LwpoTZwuS8Yw5T9EdnnHemmqQ46jCUznK",
    "amount": 1.99645000,
    "confirmations": 33899,
    "label": "",
    "txids": [
      "783042888dc68a52379f4905260ee3e457524ce7a1738d0d1dbdf2f5a7e84016",
      "14e16a88bab62f5a40580635ed4476e0859ecf36f943488afb15f838f2c307d4"
    ]
  }
]

The second address matches my newer paper wallet, but the first address doesn't match the older wallet, and it looks like it's been completely spent.  These transactions predate those I expect and see in 1PMoUJpj73FUTbjMiKwJfJoo4fJaUE9bTr, so it's possible this was a key re-used by mistake, but my memory doesn't go that far back.
Can someone explain what's going on?  Did I mess up somewhere?

in Bitcoin Core, I don't see the balance.

Blockchain explorers do confirm that address 1PMoUJpj73FUTbjMiKwJfJoo4fJaUE9bTr still holds 8 BTC. So that suggests there has been no hacking or improper removal of money.

first the older key without rescan,

I would re-import the older key with rescan. I would also make sure the wallet has completely synchronised. I would independently confirm that the  1PMoUJpj73FUTbjMiKwJfJoo4fJaUE9bTr address can actually be generated from the keys of your original paper wallet.

The second address matches my newer paper wallet, but the first address doesn't match the older wallet

Perhaps something went wrong when you attempted to import the older key? Maybe you have a third paper wallet whose details you lost or mislaid or accidentally swapped with the original?


text:
Can I receive different cryptocurrencies on the same public key?
The main question I have is:
Can I receive different cryptocurrencies on a same public key?
For example: I instruct the person A to send me BTC on a public key X. I also instruct the person B to send me XRP (or any other crypto) on the same public key X.

If not - can you briefly explain why not, i.e. what prevents it? I've read on few places that this is impossible (not sure if true), but I don't really understand why (if true). What prevents me from doing it? Aren't the block-chains isolated from one another? Also, as far as I know, most (if not all) cryptocurrencies use the same public-private key logic under the hood.
If yes - are there any specific cons apart from obvious (one basket for all)?

Note: This question does not imply the use of online wallets that may have their own logic of aggregating multiple keys under the same online wallet.
EDIT:

Actually, I think I made a mistake in the premise of my question. We
don't use public key but address for receiving funds (see link #1). I
guess I overlooked that part in the analysis. And the addresses have
differences in prefixes among currencies (see link #2) #1 -
bitcoin.stackexchange.com/questions/80708/… #2 -
blockgeeks.com/guides/blockchain-address-101

Actually, I think I made a mistake in the premise of my question. We don't use public key but address for receiving funds (see link #1). I guess I overlooked that part in the analysis. And the addresses have differences in prefixes among currencies (see link #2) #1 - https://bitcoin.stackexchange.com/questions/80708/what-is-the-difference-between-your-address-and-your-public-keys #2 - https://blockgeeks.com/guides/blockchain-address-101/

Hi Del Pro, since there haven't been any answers on this topic yet, please feel free to edit your question to update it with your improved understanding. If you are no longer looking for an answer, please vote to close it instead.

Hello Murch. I don't see the close option from my side (I only see options Share, Edit, Delete, Flag). The question is resolved from my point of view, so please feel free to close it (if you can). Thank you!

Thank you for getting back to me, it looks like some other community members have voted to close.


text:
python - No module named 'bitcoin' on Ubuntu using WSL on Windows 10
Which version of python should I use?
When running pip3 install python-bitcoinlib I get 'Requirement already satisfied'.
I run on Ubuntu using WSL in Windows 10.
I have this error:
>>> from bitcoin.rpc import RawProxy
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\Rony\AppData\Local\Programs\Python\Python37\lib\site-packages\bitcoin\rpc.py", line 48, in <module>
    from bitcoin.wallet import CBitcoinAddress, CBitcoinSecret
  File "C:\Users\Rony\AppData\Local\Programs\Python\Python37\lib\site-packages\bitcoin\wallet.py", line 33, in <module>
    import bitcoin.core.key
  File "C:\Users\Rony\AppData\Local\Programs\Python\Python37\lib\site-packages\bitcoin\core\key.py", line 34, in <module
>
  _ssl = ctypes.cdll.LoadLibrary(ctypes.util.find_library('ssl') or 'libeay32')
  File "C:\Users\Rony\AppData\Local\Programs\Python\Python37\lib\ctypes\__init__.py", line 442, in LoadLibrary
    return self._dlltype(name)
  File "C:\Users\Rony\AppData\Local\Programs\Python\Python37\lib\ctypes\__init__.py", line 364, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: [WinError 126] The specified module could not be found

What's the exact error it is printing when failing to import?

@Mercedes >>> from bitcoin.rpc import RawProxy
Traceback (most recent call last):
File "", line 1, in
ModuleNotFoundError: No module named 'bitcoin'

Are you sure you are using Python 3?

import sys; sys.version;

@Mercedes '3.8.10 (default, Jun  2 2021, 10:49:15) \n[GCC 9.4.0]'

import bitcoin; bitcoin.__version__;, or find an equivalent one using bpython, don't use python but bpython to explore libraries you are not familiar with.

Won't work because the bitcoin module isn't there. Your pip3 must belong in somewhere else. Is there any *conda in your system?

which pip3; which python

@Mercedes I made sure both are in the same place: which pip3.exe; which python.exe
/mnt/c/Users/Rony/AppData/Local/Programs/Python/Python37/Scripts/pip3.exe
/mnt/c/Users/Rony/AppData/Local/Programs/Python/Python37/python.exe

@Mercedes I edited the post with the new error, it's too long for a comment.

Try https://stackoverflow.com/a/8846029 (via https://github.com/weex/addrgen/issues/5)

@Mercedes I need to install the C# openssl on my wsl ubuntu? If I just downloading those 2 files I get this error: ssl = ctypes.cdll.LoadLibrary(ctypes.util.find_library('ssl') or 'libeay32')
File "C:\Users\Rony\AppData\Local\Programs\Python\Python37\lib\ctypes_init.py", line 442, in LoadLibrary
return self.dlltype(name)
File "C:\Users\Rony\AppData\Local\Programs\Python\Python37\lib\ctypes_init.py", line 364, in init
self._handle = _dlopen(self._name, mode)
OSError: [WinError 193] %1 is not a valid Win32 application

@Mercedes I run on Ubuntu


text:
how to correctly port forward bitcoin in VM ubuntu
hi im getting the error message
Unable to bind to [::]:8332 if i run bitcoind on my host windows /VM virtual box ubuntu 20.04
how to correctly port forward .
there are so many faulty information topics about this on the internet .
any help will be welcome

8332 is the JSON-RPC port, not the Bitcoin port (which is 8333). What are you trying to do? What sources are you reading in order to try to do what you are trying to do? Which are the faulty topics you mention?

im trying to connect bitcoin core testnet and main to the internet via an VM virtualbox ubuntu

It should work out of the box, unless you want the Bitcoin network machines to connect to your machine as well. Do you want the Bitcoin network machines to connect to your machine? Or would you be good enough if your machine connects to the Bitcoin network machines?

it would be good enough if they connect to the bitcoin network

Maybe comment the version you are trying, maybe share your bitcoin.conf file, or the command line arguments you are using.


text:
How can I spend a mix of UTXOs (p2sh, p2wpkh, p2wsh) along with a p2tr UTXO?
I'm constructing a script to spend multiple distinct UTXOs in a single transaction. I've successfully combined all UTXOs except for two.
Succeeding in spending a P2TR with P2PKH UTXO.
I encountered a problem when attempting to spend a P2TR with one of them P2SH, P2WSH, P2WPKH.
accompanied by a 'non-mandatory-script-verify-flag (Invalid Schnorr signature).

While I managed to dispatch these transactions via an alternative node, none of them have been confirmed as of yet.
tx ids: (bitcoin-testnet)
88558b495f28ff4799a4dacf40ee5cd1666850fed4847b8315256a5ae22527f8
02429ffe2f82f587d8e7a6e925201d3e7f219ac3af3688f2bc5c2770204e5d5c
What could be the cause?
thanks
P2TR,P2WPKH to P2PKH
"hex": "02000000000102f80b4d99b2489228e23a25f1a458feefc1129b8ee030dc53d7ad0f112e278bd10000000000fffffffff80b4d99b2489228e23a25f1a458feefc1129b8ee030dc53d7ad0f112e278bd10100000000ffffffff01dc000000000000001976a91451283c275c76d14f0a1b010fa3430f0ade37781c88ac0140d7ac7111d6a732e655ebdf62fe224b1572803b47eb0c70aeb2b4f1a8f287fa20008b9145143f4cd0302ac1420f9602f5728a74d7c91b6c491ca44323d045f0af024730440220608f9ba4da7daa2d70aa24e7aabbf2c47d78ed39c331f40caf7aba7c07aa14750220467cf13de308c0633624fbcc6b41f9a1ef4f4f8568db9ac13ab7f1002e12912c01210220e57408d8f6726a81747f7507f7cdb7b86c502882d8a3bce5c62d39fddf38b100000000",
  "addresses": [
    "mnv5EAfPMTbfatz5ZbT6uUKpK7E5MftBAv",
    "tb1ps7gfq0h0hwu2cql9azz0wcf8rphr6xxeeyenrugd6yf263pxg9tq0fcjvz",
    "tb1qgt0w9wnw9wrs5qxtw7ptpfdz579889t2lcwcsy"
  ],
  "total": 220,
  "fees": 199780,
  "size": 301,
  "vsize": 170,
  "ver": 2,
  "vin_sz": 2,
  "vout_sz": 1,
  "confirmations": 0,
  "inputs": [
    {
      "prev_hash": "d18b272e110fadd753dc30e08e9b12c1effe58a4f1253ae2289248b2994d0bf8",
      "output_index": 0,
      "output_value": 100000,
      "sequence": 4294967295,
      "addresses": [
        "tb1ps7gfq0h0hwu2cql9azz0wcf8rphr6xxeeyenrugd6yf263pxg9tq0fcjvz"
      ],
      "script_type": "pay-to-taproot",
      "age": 2474244,
      "witness": [
        "d7ac7111d6a732e655ebdf62fe224b1572803b47eb0c70aeb2b4f1a8f287fa20008b9145143f4cd0302ac1420f9602f5728a74d7c91b6c491ca44323d045f0af"
      ]
    },
    {
      "prev_hash": "d18b272e110fadd753dc30e08e9b12c1effe58a4f1253ae2289248b2994d0bf8",
      "output_index": 1,
      "output_value": 100000,
      "sequence": 4294967295,
      "addresses": [
        "tb1qgt0w9wnw9wrs5qxtw7ptpfdz579889t2lcwcsy"
      ],
      "script_type": "pay-to-witness-pubkey-hash",
      "age": 2474244,
      "witness": [
        "30440220608f9ba4da7daa2d70aa24e7aabbf2c47d78ed39c331f40caf7aba7c07aa14750220467cf13de308c0633624fbcc6b41f9a1ef4f4f8568db9ac13ab7f1002e12912c01",
        "0220e57408d8f6726a81747f7507f7cdb7b86c502882d8a3bce5c62d39fddf38b1"
      ]
    }
  ],
  "outputs": [
    {
      "value": 220,
      "script": "76a91451283c275c76d14f0a1b010fa3430f0ade37781c88ac",
      "addresses": [
        "mnv5EAfPMTbfatz5ZbT6uUKpK7E5MftBAv"
      ],
      "script_type": "pay-to-pubkey-hash"
    }
  ]

I used python-bitcoin-utils Python tool to generate the following code related to the transaction ID 88558b495f28ff4799a4dacf40ee5cd1666850fed4847b8315256a5ae22527f8 which involves inputs from both P2TR and P2WPKH scripts.
def main():
    print(to_satoshis(0.0000022))

    setup('testnet')
    priv1 = PrivateKey("cV3R88re3AZSBnWhBBNdiCKTfwpMKkYYjdiR13HQzsU7zoRNX7JL")
    priv2 = PrivateKey("cSfna7riKJdNU7skpRUx17WYANNsyHTA2FmuzLpFzpp37xpytgob")
    pub1 = priv1.get_public_key()
    pub2 = priv2.get_public_key()
    fromAddress1 = pub1.get_taproot_address()
    fromAddress2 = pub2.get_address()
    # p2tr utxo
    txid1 = 'd18b272e110fadd753dc30e08e9b12c1effe58a4f1253ae2289248b2994d0bf8'
    vout1 = 0
    # P2wpkh UTXO
    txid2 = 'd18b272e110fadd753dc30e08e9b12c1effe58a4f1253ae2289248b2994d0bf8'
    vout2 = 1
    amount1 = 100000
    amount2 = 100000
    amounts = [amount1, amount2]
    script_pubkey1 = fromAddress1.to_script_pub_key()
    script_pubkey2 = fromAddress2.to_script_pub_key()
    utxos_script_pubkeys = [script_pubkey1, script_pubkey2]

    toAddress = P2pkhAddress('mnv5EAfPMTbfatz5ZbT6uUKpK7E5MftBAv')
    txin1 = TxInput(txid1, vout1)
    txin2 = TxInput(txid2, vout2)
    txOut = TxOutput(to_satoshis(0.0000022), toAddress.to_script_pub_key())

    tx = Transaction([txin1, txin2], [txOut], has_segwit=True)
    sig1 = priv1.sign_taproot_input(tx, 0, utxos_script_pubkeys, amounts)
    sig2 = priv2.sign_segwit_input(tx, 1, script=script_pubkey2, amount=amount1)

    tx.witnesses.append(TxWitnessInput([sig1]))
    tx.witnesses.append(TxWitnessInput([sig2, pub2.to_hex()]))
    print("\nRaw signed transaction:\n" + tx.serialize())

Instead of posting the one that worked, could you post the transaction that failed? My first guess would be that you forgot to add the (empty) witness stack for the non-segwit input.

@Murch I added an empty witness for the UTXO P2SH at the specified index. I didn't modify the transaction; this is the same failed transaction that got confirmed on another node provider.

Okay, cool. Could you still post the failed transaction rather than one that succeeded? It’s hard to diagnose the issue without seeing the transaction that caused the problem.

@Murch  I didn't modify the transaction; this is the same failed transaction that got confirmed on another node provider

Oh, my bad. I thought that the second input was P2PKH, instead of P2WPKH.

It looks like your signature is invalid. You said that you managed to send other transactions with P2TR inputs, right? Most likely your issue stems from incorrectly calculating the sighash for the P2TR input now that there is another input.

There is nothing special about P2TR signatures in combination with specific other types of inputs. Can you post the sighash you used, and how you computed it?

Perhaps it would be helpful if you provided more information on how you construct the transaction. What tools do you use and which steps did you implement or perform manually?

@Murch I am encountering an issue while sending a transaction with various inputs. If one of these inputs is P2TR, I have created two transactions previously. Unfortunately, neither of them has been confirmed yet. The first transaction involves a P2TR input and a P2SH input, while the second one includes P2TR and P2WPKH inputs. I updated the question

@Murch Could you perform a test transaction with (P2TR +P2WPKH) inputs? I suspect the issue might lie with the test network's node or miners. Thanks

I don’t think it’s the nodes. The error message “non-mandatory-script-verify-flag (Invalid Schnorr signature)” indicates that the node you tried to give the transaction to first found the signature to be invalid. Perhaps @karask has an idea, have you considered trying to ask him on his project in github?

@Murch Now I received this answer from him https://github.com/karask/python-bitcoin-utils/issues/47#issuecomment-1688599637

I would not be surprised is the testnet node of Blockcypher were still a pre-taproot node, but I cannot find either of your transactions on other popular testnet block explorers (e.g. Blockstream and Mempool.space).

If the error is "Invalid Schnorr signature", it is definitely a taproot node.

It has now been deleted from Blockcypher. I tested many Taproot transactions, and I only encountered a problem with inputs involving (p2tr+ (None p2pkh) ).

Since it is a segwit address you should use
fromAddress2 = pub2.get_segwit_address()

Also, while taproot (segwit v1) requires the scriptPubKey when signing, segwit v0 requires the script code; i.e. a template that corresponds to the non-segwit equivalent. For example, for p2wpkh you would use as script code the p2pkh scriptPubKey.
So when signing the segwit input you shouldn't use the scriptPubKey but the p2pkh equivalent for that address. Example https://github.com/karask/python-bitcoin-utils/blob/master/examples/spend_p2wpkh_transaction.py demonstrates this.
I haven't tried these changes to your code yet, but will do with the first opportunity.
EDIT: Just tried the suggested changes it works.
PS. In the meantime, if you try it out yourself please use testmempoolaccept to test tx validity instead of just sending the tx to a node for processing. That will test tx validity without spending the outputs. If there is still an issue I can then test using the same UTXOs.


text:
developing hd wallet using bip32 and bip 39
I'm developing a HD wallet using C#.
I want to use this wallet for multiple blockchains like bitcoin, ethereum, dogecoin etc...
I've read that I should use bip32 for my wallet. i know what's bip32 but couldn't find any effective way to use it.
can anyone help me with that?
thank you

What have you looked for? What found? What exact problems with implementing which part? Have you used stackoverflow for other C# programming problems? Can you clarify what an answer here would look like?

See: BIP 32 / 39 / 44 / 49 / 84. Note that questions related to cryptocurrencies other than bitcoin are off topic here.


text:
My Public Key on MultiBit Classic is 34 digits long
My public key, as it's displayed in MultiBit Classic, has remained unchanged in the last eight years since I bought my bitcoin in Jan 2014.  I'm now looking to move my bitcoins from MultiBit Classic to Coinbase.  But since MultiBit is deprecated, I need to extract the public key and private key from MultiBit, and send it manually from Exodus.  I have been able to extract the private keys, and confirm they are the correct length: 52 digits for a compressed public key.  My public key is 34 digits, but everywhere I read says a compressed public key should be 33 digits.  What am I missing? or not understanding correctly.
How can I confirm the correct compressed public key?
This question:
MultiBit with multiple addresses to Electrum
explains how to export a private key from MultiBit Classic.  I already have my private keys, but my public keys are 1 digit too long.

What do the public keys you're talking about look like? Are they human-readable? Hexadecimal? Base58? byte arrays starting with 0x02 or 0x03?

After you import your private keys, Exodus should be able to regenerate your public keys from that. Why do you need to export the public keys?

@PieterWuille, they're alphanumeric, no special characters, and start with "1F12RWoivL3t ....." and "1Q1UtS5veqZF ...", and are 34 digits so I concluded that the public keys are compressed.

@Murch, I believe I need the public key that is associated with each private key to manually send bitcoin from Exodus to Coinbase.

What you are describing are addresses which are stand-ins for the public keys, but not the public keys themselves.—After you import private keys, your wallet should rescan the blockchain for funds. As soon as it has rediscovered the relevant funds, it will be able to spend them in a transaction. It's not clear why you would need the address in order to send somewhere else: Coinbase should give you a unique deposit address in order to distinguish which account to credit.

If anything, you might need the address to identify which private key to exactly export to the other wallet, but you write that you have already successfully extracted the private keys.—Anyway, it sounds to me like you may be trying to do something that you don't need.


text:
How much mining activity is needed for Bitcoin to remain secure?
I'm not looking for a number, but rather for a way to make an estimate taking things like market capitalization and the fact that mining uses ASICs into account. (I assume ASICs are relevant since their usage implies that an attacker can't get very far with general-purpose hardware from a botnet or public cloud.)
My motivation for asking this question is as follows. I assume the current rate at which energy is expended on Bitcoin mining is primarily the result of high rewards. As the 21-million supply limit is approached, mining will most likely become less profitable unless transaction fees increase immensely. At the time I'm writing this question, transaction fees only account for a small fraction of miners' profits, while minting new coins is the primary driver of profits. At the supply limit all minting stops, so transaction fees are bound to increasingly become the major (and eventually only) mining reward. It seems inevitable that mining activity will decrease as a result.
Given that mining activity is likely to decrease significantly in the medium- to long-term, how much is needed for Bitcoin to remain reasonably secure?

We have a few related topics like https://bitcoin.stackexchange.com/q/3111/5406, https://bitcoin.stackexchange.com/q/876/5406, https://bitcoin.stackexchange.com/q/5406/5406. Does any of these cover your question?

Those are all relevant to this question and seem to come from similar lines of thought. I think none of them specifically tries to get at where Bitcoin would become fragile if mining activity goes down, though. https://bitcoin.stackexchange.com/q/876 comes closest (the top-and-accepted answer from 2011 seems to boil down to "Bitcoin will collapse"), but I think this question is meaningfully different.

Isn't the answer simply that the amount of mining activity in hash/sec must be greater than the additional amount a consortium of attackers could feasibly deploy without prior warning signs?

That sounds like a good start. But how much could they feasibly deploy without warning signs? Additionally, maybe an existing group of mining pools could go rogue under some circumstances. I also read that a 51% attack could potentially be dealt with (https://bitcoin.stackexchange.com/a/1062), which would make security easier.

Currently fees make up < 5% of mining revenue, but this has not always been the case, fees have ballooned to the point that they approached 20%, and some specific blocks crossed 50% in the past.  Ultimately, as the block reward decreases this chart will, of course, balloon up to 50%, 70% and eventually 100%.
Not exactly your question, but just some perspective.
https://bitinfocharts.com/comparison/fee_to_reward-btc-sma90.html#alltime


text:
Unable to `make` libbitcoin on Debian VPS
I'm trying to install the libbitcoin-rpc but I'm getting the following error when I try to install with make:
gcc -fPIC -O3 -g -Wall -Werror -Wextra -std=c99 -D VERSION=\"0.2\" -o src/bitcoinrpc_err.o -c src/bitcoinrpc_err.c
src/bitcoinrpc_err.c: In function ‘bitcoinrpc_err_set_’:
src/bitcoinrpc_err.c:39:9: error: ‘strncpy’ specified bound 1000 equals destination size [-Werror=stringop-truncation]
   39 |         strncpy(e->msg, msg, BITCOINRPC_ERRMSG_MAXLEN);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [Makefile:87: src/bitcoinrpc_err.o] Error 1

I have installed all dependencies and I have also already tried changing the Makefile and the PATH according to the README but nothing worked.
I think the issue is related to this question. Is the libbitcoin library still maintained? Last changes were in 2016 and the strncpy error exists only since 2019 I think.

Some background on this error can be found here: link. To fix it, you could either subtract 1 from the length being copied, or disable the warning.
However, this library is certainly not maintained. As you observed, the last commit was in 2016, and the highest supported version of Bitcoin Code is listed as v0.12. Bitcoin Code released v22 recently so this is very out of date and the API will have changed significantly.

Thanks! But do you have an alternative library for RPC-calls?

Perhaps take a look here: https://bitcoin.stackexchange.com/q/43937/51948


text:
Transfer blockchain from PC to Mac
I have a bitcoin wallet on my PC  but I just recently downloaded the MAC version of it.  I would like to initialize it with the blockchain from my PC so that I don't have to download it all over again.  Is that possible?

See https://en.bitcoin.it/wiki/Data_directory
Copy over your %APPDATA%\Bitcoin directory to ~/Library/Application Support/Bitcoin/
Your AppData directory should be:
C:\Documents and Settings\YourUserName\Application data\Bitcoin (XP)

C:\Users\YourUserName\Appdata\Roaming\Bitcoin (Vista and 7)

If not, you can always run explorer %APPDATA%\Bitcoin in Command Prompt (Super-R, type cmd, hit "Run") to find it.

Just to avoid people missing the key information about the wallet and blockchain - one is very private information and one is public information.  In copying as said here: How to transfer only the blockchain to a friend's computer?

"To be more specific, you need to transfer the blocks and the chainstate directory. Don't transfer the database directory as it may contain remains from wallet.dat such as private keys. – rumpus"


text:
Do electrum fully support Hierarchical Deterministic Wallets?
I'm curious if electrum fully support Hierarchical Deterministic Wallets (BIP32). I have seen in source code that some part of implementation is done. But there are also as I think some electrum specific algorithms.
So when I create new wallet in electrum will it be BIP32 compatible?

related: What is the status of hierarchical deterministic wallets (BIP32)

Of course I have seen it before asking this question. :)

BIP32 support is planned for Electrum version 2.0. The code is already there, but disabled.
You can find some features that were first planned for 2.0, but were included in a 1.9.8 release as the servers were being updated to a new important version so it was needed to apply some changes already to the client to put all in place for 2.0 https://bitcointalk.org/index.php?topic=518133.0

I have one additional question. You are saying "BIP32 (or a similar approach but not standard)" so BIP32 isn't the standard?

@Adam I've updated the answer with the latest update from devs. Electrum will use BIP32 standard for 2.0 version

@rdymac Can you update the answer as of now. It's 2017 now so probably the new visitors to the question will be grateful to get an updated answer.


text:
Should an end-user download the whole blockchain? Or is a “lightweight” client sufficient?
The average user normally doesn’t want to host a 3+GB file on his machine and wait for hours for it to download.
What are the security risks of running a lightweight client? And how does this affect my daily transactions?
What features does a “full” client offer a “lightweight” does not?

For the MultiBit client:
(disclaimer: I am the lead dev)
1) as you are not running a full node, you are not helping relay transactions nor mining nor verifying blocks.
2) if an attacker can surround your network they can feed you spurious transactions and a fake but well formed alternate fork. (I guess this is true for bitcoind too).
3) MultiBit does not keep a database of unspent transaction outputs so importing an arbitrary key is slow.
4) you ARE downloading the full blocks and parsing them (though not storing the full blocks) so you can keep up to date with blockchain reorgs and such like.
5) an unconfirmed transaction cannot be verified by checking all the inputs are unspent and thus you cannot rely on it until it is confirmed. A full node can check everything about the transaction. Only when it appears in a block (on the main chain) can you have any confidence in it.
6) not actually related to architecture but important for security: only the beta MultiBit code has encrypted wallets.
7) compared to bitcoind, the lightweight clients have less manpower working on them. If you want to use bitcoin in, say, a company environment then bitcoind would be the safer option.
In summary: there are a few limitations caused by not having access to the full block chain locally but for everyday use they should not hinder you too much. Factors more to do with what the devs have managed to implement (or not) probably make a bigger difference.

Sorry, but I can’t accept this as the answer, since it’s solely about Multibit.
By the way, you should really work on your gui, it’s a pain in the ass.

There is quite a variation on lightweight clients so it is difficult to be general. Can you be a bit more specific about what usability problems you are having ?

For the question(s): A list of the features that separate lightweight clients from a full clients in general (and maybe different approaches that lightweight clients take, best with examples) and how that affects security in general.
Short: An answer to this question every newbie who is not a nerd but afraid of losing his money can understand that is still precise. ;)

About your client: The font support sucks in a Linux environment and changing it doesn’t affect everything. I went with Electrum in the end, since you can feel the elegance in every part of that program and it has a potent command line, should one need it. Plus, restorable wallets from seeds and working encryption.


text:
How many signatures are there in one non-multisig transaction
I checked this How is a transaction's output signed?.
I need clarification for:
For each input there is one signature, so there are as many signatures as there are inputs?
Why is that so and not use just one master signature per transaction, is it because sender of transaction can use funds from more than one address he controls?
Is there also a master signature that signs entire transaction or just the per  input signatures mentioned before?

1.: For typical P2PKH/P2PK you will always need to provide one signature. If all inputs spend outpoints of this form, then each one of them must provide one signature.
2.: They must sign a "special" transaction structure, see here: Redeeming a raw transaction step by step example required

To add slightly to point 1, if the input is from a multi-signature address then more than one signature is required, but yes normally one per input is required

Sorry, my question is too broad, I will shrink to only first bullet with some subquestions, and post 2 as separate question.


text:
What is the structure of bitcoin block?
If I understand correctly block consists of:

block header,
transactions counter,
list of signed transactions.

Each signed transaction consists of transaction itself and appended signature.
Each transaction consists of:

transaction version no,
number of inputs,
inputs themselves,
number of outputs,
outputs themselves and
locktime.

Each input consists of:

Reference to its outputing transaction
index of output in that transaction
scriptSig

Each output consists of:

output value
scriptPubKey

Is this structure correct?

Where did you get 81 bytes from?

Found that figure on several places for example here: http://bitexperts.com/Question/Detail/3333/what-is-bitcoin-block-header-size-in-bytes, although 80 is more commonly shown. But here https://en.bitcoin.it/wiki/Block I find now there is more to the structure.

It’s 80 bytes, not 81. They’re calling the number of transactions part of the header (and assuming its one byte), which it’s not.

So in general it is 1-9 bytes, is not part of the header and shows the actual number of transactions in this block (and not always 0)?

Right. It’s just part of the way it’s encoded though, that varint for the number of transactions isn’t included in any hash. It means you don’t know the size of the block until you’ve parsed every single transaction too.

Don't you know the size from the block size field https://chat.stackexchange.com/rooms/68577/room-for-croraf-and-eponymous

I'd like to partially answer your question on the tx structure: in general you are right, here some more detail, and yes, you can have several TX_INs and TX_OUTs:
VERSION
TX_IN COUNT
  TX_IN[0] OutPoint hash
  TX_IN[0] OutPoint index
  TX_IN[0] Script Length
  TX_IN[0] Script Sig
  TX_IN[0] Sequence

TX_OUT COUNT
  TX_OUT[0] Value/Amount in Satoshi
  TX_OUT[0] PK_Script Length
  TX_OUT[0] pk_script
 LOCK_TIME

So in general the VERSION field at the very beginning and the LOCKTIME at the end is an additional piece. For sure you find further details in the developper section of bitcoin.org, and in Andreas' book "Mastering Bitcoin" (also online available). Avery good overview of the details was also provided here: http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
I am not experienced enough to answer the part on the blocks, but it is also mentioned in the links.


text:
Lightning network explaination (bidirectional channel funded by one party)
Let's say Alice and Bob want a bidirectional lightning channel with common 2-2 multisig address C.
Alice is the only one putting funds in, say 100BTC. They agree on nLock of these funds to be 30 days (channel will be open for 30 days). This requires Bob to sign and give Alice a refund transaction with nLock 30.
Now during next 15 days Alice pays Bob 10 BTC three times, each time giving him a signed transaction with respective outputs 90Alice-10Bob (on day 5) 80Alice-20Bob (on day 10) and 70Alice-30Bob (on day 15).
If Bob wants to close the channel he needs to sign 70Alice-30Bob transaction and broadcast it. And these 3 transactions don't need to have nLock. (unidirectional channel)
But instead Bob wants to pay Alice 10 BTC (on day 20). So he makes and signs a new transaction 80Alice-20Bob and gives it to Alice. They leave the channel open for more transactions.
Which of the above transactions need to have nLock and with what value?

Related: https://bitcoin.stackexchange.com/q/63073/31712

From what I understand, Lightning does not use absolute timelocks (nLockTime) for single payment channels.
The task of implementing a bi-directional channel is equivalent to the task of invalidating old states (i.e., preventing them from being broadcast to the blockchain). In Lightning, if Alice wants to update the state, she must first sign a "Breach remedy transaction" (BRT). Moreover, the party who initiates closing the channel by broadcasting some channel state must wait before being able to withdraw their funds (implemented with a relative timelock). Putting this all together, if Alice tries to cheat and broadcasts an old state (trying to withdraw more money than she is entitled to), Bob has time to broadcast his BRT and claim all funds in the channel.
Answering your question, none of the transactions inside one channel have nLock. The paper and a wiki page provides more details.

So Alice first receives the redeem transaction for her funds and makes a funding transaction. When she wants to update the state of the channel she sends Bob the update transaction which can now be activated and along with it (or immediately after) the breach remedy transactions for previous transaction. When Bob receives the breach remedy transaction he considers update done. The same is true for opposite direction. Is this the model of the lightning network (please check every step here)?

@croraf "she sends Bob the update transaction" -- they both co-sign two symmetric update transactions with different timelocks (at least the papers describes it this way; only one of the transactions will be significant economically though). "immediately after" -- I suppose, it is "immediately before". Bob will not co-sign the update transaction until he receives the breach remedy transaction signed by Alice.

Bob does not cosign at all. He will co-sign only if he wants this to be final. Actually I think she must receive the new transaction before sending bob the BRT for old transaction. Otherwise Bob can trick her into not sending her the new transaction and Alice cannot broadcast old transaction as Bob has BRT for that.


text:
Two variants of signing transaction
When signing transaction I think the following is done (in short):
For each input

all inputs and outputs are taken
the respective input scriptSig is filled with txPrev.pubScript, other inputs's scriptSigs are left blank?
this is signed and signature is put in scriptSig

Is there any benefit for bundling all inputs prior to making each signature? Could just respective input be used when signing for that input?

this is how segwit transactions work :) read more about quadratic hashing problem and segwit solution. you are on right way

Answer provided by @Andrew Chow:

The benefit is that each signature commits to the inputs and outputs
  of the transaction so that they cannot be changed. If each input only
  commit to one input, then more inputs could be added and malleate the
  transaction. However, there is a sighash type that allows this: sighash
  ANYONECANPAY.


text:
Are there someone can explain me how to go from the first to the second? Thanks
The first: BTC/day= 24 / (D * 2^32 / (H * 10^6) / 60 / 60) * C
The second: BTC/day=  (H*B/D) * 20.11626
In the first formula that I find in a discussion, I can't understand the mathematic form. In my opinion is not clear the sequences of the fraction and how I can pass from the first to the second.
Could be helpful a legend to describe what is the significate the numbers inside the formula.
Thanks in advance.

Please add more information explaining where you got those equations from and what all the variables mean. For example, what are D, H, and B. The first equation has no B in it, so they're obviously not equivalent.

I've closed this as a duplicate because all the equations you mentioned are explained in the answers and comments of the question I linked.

Ok I understand.


text:
Is it possible to realize MitM attack between bitcoin full node and listener of this node?
I have the appication listening bitcoin full node and receiving tx messages. Is it possible to change TxOut value by man in the middle, so I don't detect this changes?
Node I connect is public node, not my own. My app just recieve and send messages. No validate. When it recieve message from node it just checks checksum. So, if I'm right, Man-In-The-Middle can change message and it's checksum while message transfering.

No, just changing the output value would invalidate the transaction's signatures, which the application can easily verify. But since the application is not a fully validating node, what the attacker can do instead is to create their own transaction signed with their private key that pretends to be spending coins that don't actually exist, and use any output values they want.
Of course, if you use a secure channel to communicate between your application and your full node, you shouldn't need to worry about man-in-the-middle attacks.


text:
Restore blockchain.com wallet(s) in case the company goes away?
So I have some funds on an blockchain.com wallet. Actually it's multiple wallets (some ETH, some BTC)
I followed the backup procedure and wrote 12 English words on a sheet of paper.
There is an answer about password recovery but it still needs the company to be existent.
Will there a way to recover the wallets from those passwords or is this just a fancy way of password recovery?
If not, what's a better way to backup the wallets?
EDIT: If found some background about how it seems to work.
It seems to work using BIP44 / BIP39. But this leads to more questions:

Is this only working for my bitcoin wallet, not for ETH?
Is also the wallet address encoded in the words or only the passphrase?

I tried it. It works independent from the company.
I downloaded the exodus client and was able to restore my wallet there.
The only risk with a web-wallet like blockchain.com is, that the company could theoretically access to funds and withdraw them from my wallet, if they go bankrupt.
So it seems a better approach for use an offline wallet and transfer the funds to a new exodus wallet or something similar.


text:
Can a wallet/exchange provider ask for transaction details
My question has two parts,

Am I obligated to share transaction details with my wallet/exchange provider for any payment I made to an individual, like a subscription to a website?
Irrespective of the above point, If I pay for a subscription using Bitcoins to someone, and the receiving party misuse the coins for something illegal unknown to me, will I be in a problem?

Thanks

Am I obligated to share transaction details with my wallet/exchange provider for any payment I made to an individual, like a subscription to a website?

A proper noncustodial wallet will impose no such restrictions.
A business that is running a wallet service might impose restrictions though. So this question really just depends on the terms of service/policy of that business. If they are holding your private keys, you will be 'obligated' to follow their rules, though I'm not sure I agree with the use of that word, maybe the word 'forced' would be a better pick. Not your keys, not your coins, and all that.

Irrespective of the above point, If I pay for a subscription using Bitcoins to someone, and the receiving party misuse the coins for something illegal unknown to me, will I be in a problem?

Most businesses (ie exchanges) that impose such restrictions do so for legal reasons: the jurisdiction they operate within requires some sort of KYC/AML procedures. So these businesses will often employ the use of a chain analysis service, which can supply the business with more info about happenings on the blockchain, thus satisfying regulators. Chain analysis services are not capable of perfectly knowing what on-chain transactions represent, but they can make guesses based on certain heuristics, and data gathered from various sources.
Some easy ways to mitigate against this risk:

Don't store coins with custodians that might restrict your access
Create another wallet, send coins to it, perform a self-send or two with that wallet, and then finally, pay the coins to your intended destination. This adds some extra steps between the address which is known to be owned by you and the person you are sending payment to, breaking the obvious link between you two.
Use a wallet that creates coinjoins to obfuscate your UTXO history, such as Wasabi, or JoinMarket
Use a wallet that has payjoin/P2EP enabled (this is currently an ongoing development)

There is a lot of nuance to bitcoin privacy, I'd recommend giving this wiki entry about Bitcoin privacy a read if you're interested.
Generally, the sort of worry you have doesn't seem to cause problems for users these days (I haven't seen many complaints of this online), but if you're worried I would simply suggest adding a new wallet and a transaction or two in between the regulated custodian, and the outgoing payment.

More broadly, for Bitcoin to be useful, users need to not worry about these sorts of risks. Bitcoin can function in a way that allows all transactions to be perfectly traceable, but it can also function in a way that provides the user with financial privacy. As a user, you can employ certain techniques and strategies to help retain your privacy, but remember also: the businesses you support are the ones that will continue to grow in this industry. If you don't like the sort of existential risk imposed on the network by KYC'd exchanges, don't use them. As they say: vote with your dollars (or in this case, your sats).

Thanks @chytrik for taking time to read and give detailed answer. It has exposed me to new things to look at. My concern is, if I already made the payment with an exchange and they ask for transaction details. I have a miniscule amount on the the exchange. So, I am not really worried about the coins I have with them. Can I just ignore them when ask for the transaction details, and be done with them?

Continuing the previous comment, since I don't have substantial coins with them, will they have any legal means (apart from freezing my account) to force me to share transaction details?

@digitalnomad30 I think the question/clarification in your comments falls outside the scope of this site. It isn't really a question about bitcoin persay, but about your relationship with that exchange. For all I know you could be operating a completely anonymous account and it may be fine, or on the other hand it could a fully KYC'd account in your legal name, and your local laws may force compliance when being asked such questions about transaction details. If you have legal questions, you need to talk to a lawyer, not random strangers on the internet.

thanks for clarifying on my comment


text:
Bitcoin sent to a defunct address - what happens to it?
I got the address for my account on a site and wrote it down. As I had had a huge hassle buying my bitcoin that morning due to problems with the vendor's site (and which they denied was at their end for 3 or more hours, nearly drove me spare) I was flusterred quite badly.
Anyway, for some reason that is still not apparent to me I clicked on a button saying "generate new account". However, as the site kicked me out due to poor connectivity and it flagged me that "your request could not be processed", I sent the bitcoin off to the address I had written down.
Some hours later I went to the site to check my balance...my funds were not there. There was A NEW ADDRESS for sending bitcoin to in my account details.
So, it would appear that I have sent my bitcoin to a valid address that is now redundant.
What will happen to my bitcoins? Will they bounce around for a few days before coming back or will they just disappear into the ether?

Contact the vendor, they most likely have the private key and should be able to recover the funds from the previous address.

Thank you Roy, I have contacted them with the details of the account where the money was sent but no reply so far.

It is recommended that services which provide an e-Wallet account for customer funds will provide a new address for each payment.   When this advice is followed, each time an address for "add funds" is shown it will be different.  So usually, this means each account can have multiple bitcoin addresses for adding funds.

If the address is valid then the bitcoins will stay there until spent.  If you don't have the private key for that address they are now unspendable.
However, in general Bitcoin uses addresses in a different way to that which might be considered immediately obvious.  An address is generally considered a single-use item and as such it is entirely possible that your wallet contains the private key for the address to which you sent these coins, as well as any other addresses which you might have created.  Take a look at your wallet to see if it is present.

I definitely have the address to where I sent the bitcoin. I have checked out the tracking...it has had 56 confirms at last count and the bitcoin HAS NOT been redeemed.

All the transaction details are in my wallet. What is the "private key"? I assumed it is a series of numbers, would they be the first block of numbers in the "Raw Transaction" field, or in some other place? If and when I find the private key for the receiver's address, what do I do next?

Bitcoin is a bit confusing in how it talks about keys and addresses.  Public keys are translated in to addresses, which are the long strings you see starting with "1".  Think of this as the equivalent of a postal box.  Private keys are the actual keys to the postal box, and required to use the funds sent to the address.  The private key will not be visible anywhere public but might be in your wallet.  If you can find the private key you can import it in to your wallet and access the funds that way.

Thanks jgm. OK, so the private key may be in my wallet. How do I find it? It wouldn't be the "Hash 160" string of characters as shown on the blockchain.info page for the account in question would it?

If you are using blockchain.info as your wallet provider then open up your wallet and go to the "Receive Money" tab.  Look for the address in either 'Active' or 'Archived' tabs.  If it's there, and doesn't say "Watch Only", then you have the private key.  Otherwise I'm afraid you are out of luck.


text:
How do you tell if witness data has been tampered with?
If you receive a block, how can you tell whether the witness data has been tampered with between when it was mined and when you received it?
Where in the block is the wtxid root, and how do you compute the merkle root of the witness data?

Quoting from BIP141:

The commitment is recorded in a scriptPubKey of the coinbase transaction.

and

A witness root hash is calculated with all those wtxid as leaves, in a way similar to the hashMerkleRoot in the block header.

Indeed, the witness merkle root seems to be computed in a similar way than the hash merkle root, since it calls the same function.
I guess you can just check if the witness data has been tampered with by just computing the witness root hash yourself and checking that it matches the stored one.


text:
How can an encrypted wallet spend coins without asking for decryption password?
It is possible for some encrypted wallet to spend coins (e.g. this one) without requesting a decryption password or any other form a authentication. Of course, a password is requested when first importing the wallet file, but nothing after that. This seemingly means that a simple user process has access to my private keys. What prevents another process from replicating the same code and reading the same files so as to spend my coins? There appears to be a major vulnerability, which I am guessing is not real. What cryptographic trick is in play here, to allow such wallet behavior without exposing the user's private keys?
EDIT The answer to the paradox stems from the fact that access to the file system on Android does not work in the same way as on a typical Linux distribution. A file owned by an app cannot be accessed by another app (unless the other app is root). This allows the Android wallet to decrypt the private keys (with password) when restoring a backup file, and save the unencrypted keys to a new file without compromising security. So it is possible for the wallet to spend coins without referring to the backup file again (which would require a password) and simply look for the private keys in the newly created file (which requires no password). (The Answer is due to Nick ODell and Andreas Schildbach, as can be seen from the comments of this thread).

As far as I know Bitcoin Wallet for Android does not have an encrypted wallet, only an encrypted backup.

@PieterWuille Thank you Pieter, yes in fact I had the Android wallet in mind when asking the question, and yes I was wrong to assume the wallet was encrypted (the backup certainly is). So really the question should have been "How can a wallet with encrypted backup spend coins without asking decryption password?" and the answer is (most likely), "It does so by decrypting the keys (with password) when restoring the wallet and keeping those keys without encyption in a separate file". This behavior is possible on Android, as files for a given app are not accessible by another app, unless root.


text:
Cannot build secp256k1 C library on Debian stretch
I was hoping that someone would be able to suggest something about this
(the same process works perfectly fine on my Debian Jessy machine)
$ uname -a
Linux front 4.8.0-1-amd64 #1 SMP Debian 4.8.7-1 (2016-11-13) x86_64 GNU/Linux

$ git config --get remote.origin.url
https://github.com/bitcoin-core/secp256k1

$ git pull
Already up-to-date.

$ ./autogen.sh
...

$ ./configure
...

$ make
gcc -I. -g -O2 -Wall -Wextra -Wno-unused-function -c src/gen_context.c -o gen_context.o
gcc gen_context.o -o gen_context
./gen_context
  CC       src/libsecp256k1_la-secp256k1.lo
  CCLD     libsecp256k1.la
/usr/bin/ar: `u' modifier ignored since `D' is the default (see `U')
  CC       src/tests-tests.o
src/tests.c: In function ‘test_ecdsa_der_parse’:
src/tests.c:3702:52: error: dereferencing pointer to incomplete type ‘ECDSA_SIG {aka struct ECDSA_SIG_st}’
valid_openssl = !BN_is_negative(sig_openssl->r) &&
!BN_is_negative(sig_openssl->s) && BN_num_bits(sig_openssl->r) > 0 &&
BN_num_bits(sig_openssl->r) <= 256 && BN_num_bits(sig_openssl->s) > 0 &&
 BN_num_bits(sig_openssl->s) <= 256;
                                                ^~
Makefile:1050: recipe for target 'src/tests-tests.o' failed
make: *** [src/tests-tests.o] Error 1

EDIT: replacing ./configure by ./configure --enable-tests=no leads to a successful build. The command make check is also successful.
EDIT2: As indicated by Andrew, the answer is to use ./configure --enable-openssl-tests=no
EDIT3: This issue has been resolved on master branch, as far as I can tell

Looks like OpenSSL has changed something out from under us ... for now you can compile with --enable-openssl-tests=no to still get the tests, OpenSSL is only used in the test jig and only in a small way. Can you open an issue on the libsecp github?

Hi Andrew, thank you. I can confirm that --enable-openssl-tests=no solves the issue while giving access to tests. Yes I will open an issue on libsecp github

Andrew I am guessing you don't care, but if you were to write a quick answer, I would obviously validate it since your comment closes this thread

@AndrewPoelstra: yes, OpenSSL 1.1.0 makes some structs 'opaque' including ECDSA_SIG. You are now supposed to use ECDSA_SIG_{set,get}0 to access the fields.


text:
Failing to build bitcoin-core v0.13.1
I have done quite a few upgrades in the past and this has never happened before:
$ uname -a
Linux back 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux

$ git checkout v0.13.1
$ git fetch --all
$ ./autogen.sh
...
$ ./configure LDFLAGS="-L/home/me/bitcoin/db4/lib/" CPPFLAGS="-I/home/me/bitcoin/db4/include/"
...
$ make clean  # I have had issues in the past, always solved with clean target
...
$ make
...
AR       leveldb/libmemenv.a
CXXLD    bitcoind
libbitcoin_util.a(libbitcoin_util_a-util.o): In function `GetNumCores()':
/home/me/bitcoin/src/util.cpp:796: undefined reference to `boost::thread::physical_concurrency()'
collect2: error: ld returned 1 exit status
Makefile:3336: recipe for target 'bitcoind' failed
make[2]: *** [bitcoind] Error 1
make[2]: Leaving directory '/home/me/bitcoin/src'
Makefile:8357: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/me/bitcoin/src'
Makefile:668: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

Does anyone have any suggestion of anything I could try out to resolve this?
EDIT: I can't even rebuild v0.13.0, so I have most likely messed up my system in relation to boost. Looking into that
EDIT2 (RESOLVED): cleaning up the boost install resolves the problem (make check passes all tests). Any Bitcoin enthusiast who still doesn't quite know what he is doing (like myself) will easily attempt to install various Bitcoin libraries and utilities (e.g. libbitcoin bx for C++) with boost dependencies and end up with various bits and pieces of the library everywhere (both /usr and /usr/local hierarchy as well as boost distribution packages on top of existing stuff in /usr/lib/x86_64-linux-gnu/). So I removed the distribution packages, cleaned up /usr/include/boost and /usr/lib/libboost_* (and the equivalent on /usr/local), left the gnu folder alone (libreoffice will break otherwise), and installed a clean copy of boost (on /usr/local hierarchy). One thing to remember, if anyone tries to experiment by moving around library files, you need to run ldconfig to update the cache for the linker I think. Things started to make sense after I did that.
EDIT3: for the sake of completeness, if I decide to install boost in the /usr/ hierarchy rather than /usr/local/, then the above build will also fail for some reason. However, replacing the line:
$ ./configure LDFLAGS="-L/home/me/bitcoin/db4/lib/" \
              CPPFLAGS="-I/home/me/bitcoin/db4/include/"

by:
$ ./configure LDFLAGS="-L/home/me/bitcoin/db4/lib/ -L/usr/lib" \
              CPPFLAGS="-I/home/me/bitcoin/db4/include/ -I/usr/include"

leads to a succesful build.

Try git clean -dfx (this will remove all build results and files not checked in, so you can start fresh). Also, what version of Boost do you have?

Thank you very much ! I tried that. I retried after reinstalling boost 1.61. Same errors. Will keep looking. Thanks anyway !!