text:
Compiling Bitcoin Core 0.21.1 on Apple M1 architecture
I'd like to upgrade from 0.21.0 to 0.21.1 on Mac Mini (Big Sur 11.1), compiling from source. When trying to compile the dependencies by running 'make' in /depends subdirectory, I get the following error:
ERROR: Feature 'system-zlib' was enabled, but the pre-condition 'libs.zlib' failed. make: *** [/Users/xxx/bitcoin/depends/work/build/arm-apple-darwin20.2.0/qt/5.9.8-82a1b93ac0c/qtbase/.stamp_configured] Error 3
Any advice on how to solve this would be appreciated!

Core doesn't yet support building on M1, see this PR https://github.com/bitcoin/bitcoin/issues/20371. Not many testers with M1 hardware it appears so please do comment on the PR and help with testing :)

Thanks for the link; I'll hop over to github, will be happy to contribute testing! Oddly enough, I was able to build 0.21.0 (or a few commits afterwards), though boost and qt were some issues initially.

I ran into the same problem on tag v0.21.1 on my M1 macbook pro (Big Sur 11.4).
It turned out that i COULD "make /depends" on master. Then, however, even on master currently, "./configure --prefix=$(pwd)/depends/aarch64-apple-darwin20.5.0" won't finish successfuly (it can't find a specific QT lib).
To get v0.21.1 to compile on Apple silicon, I followed the build manual doc/build-osx.md.
In particular, homebrew seems to provide all relevant dependencies apple silicon compiled as of now.
BUT, "./configure" as follows:

apply jonasschnelli's getauxval fix mentioned in https://github.com/bitcoin/bitcoin/issues/20371 **
export CPPFLAGS=$(pkg-config --cflags libevent)
./configure --with-boost=$(brew --prefix boost)

A "make -j 8" should then make Bob your uncle.
** cherry-picking the proper solution from https://github.com/bitcoin/bitcoin/pull/20603 didn't work for me due to merge conflicts
Regards,
Gebert


text:
Can selfish mining work with a leaky pool?
I'm trying to work through an attack scenario (say 20 years in the future when block rewards and fees may be more comparable).  A miner with say 10% of the hashrate would like invite others to help him selfish mine.  Opening up to a pool presents a problem: If the pool is open to anyone, it becomes nearly impossible to mine blocks in secret, so you wouldn't be able to "build a lead" in secret.
However, my understanding is that you could design a pool protocol so that you are sending many templates to  many miners, in a way that only the miner who found the block knows which transactions are contained in it (This miner is quieted with a small bribe.)  Then the subsequent template which you send out contains only the hash of the block.  The other miners in the pool can see a new block is found, they are free to broadcast the hash of the block to honest miners. Now non-selfish miners are have a set of options:

Mine empty blocks including the hash of the secret block,

Try to guess what transactions have been included in the hidden blocks

Ignore the information entirely and try to build a block at the same height

Stop mining until clarity is present.

Note that 3) defaults to classic selfish mining.  In the presence a significant fees 1) can be a very stiff penalty.   (Note the miner could use his 10% "trusted" hashrate to try to stuff blocks with high value transactions, building these on an actually secret chain)
I'm thinking of working on the Markov computations with some parameters, but before I thought I would ask if there is a known analysis of this style of attack and if my technical understanding is correct.

source: Stack Exchange

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

sort: votes


text:
Child Pays for Parent transactions get stuck on testnet
I'm building a service prototype by reusing Electrum code and generated 4 consequent transactions which are CPFP type on the testnet. They are staying unconfirmed for several hours but test transaction with 10 sat/vbyte got confirmed in the nex block.
What could be a possible reason for that? Could it be testnet-specific so I should not expect the same behavior on mainnet?

Your transactions with less than 1 sat/vbyte won't propagate at all through the network, so nodes won't even see the children that pay for them.

Get it. I didn't make this mistake with my mainnet test so transactions were confirmed. Thank you very much.

The problem you're facing is that even with a high-paying child, the parent needs enough feerate on its own to get relayed on the network.
Staying below 1 sat/vB makes that hard.

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


text:
How can I find the transaction that spends a specific output via an API?
I am wondering how I can find the transaction that spends a specific output (for a large number of transactions). So for example, I have a transaction like the following: https://www.blockchain.com/btc/tx/ebd4a554faff31dd2a07135913fa073012a4495b195c1a5d5a9a7bca3e88de61. It has two outputs which are both spent. I would like to find the transaction that spends that output. Blockchain.com has a link to the spending transaction via the tx index (https://www.blockchain.com/btc/tx-index/355543195). However, they do not offer this an API endpoint and just in the GUI. I was wondering if there exists an API that offers to find the transaction via either the tx-index or other means.
Background
I just started doing research on the lightning network and I was interested in the closing of channels. In particular, I took a snapshot of the lightning network in January from https://graph.lndexplorer.com/api/graph and scan all the channel transactions to see if the channel is closed. If the channel is closed I want to know if it was a mutual close, unilateral close, or a disputed unilateral close (an old commitment tx which should have a revocation tx following the commitment tx on the chain). Since the dataset has around 16.000 channels, I need an automated way of parsing through the transactions.

I would parse the blockchain. There are libraries for almost any programming language. You can in a 5-liner scan through all transactions and see which input they spent. You need to do this with a local parser and not via an remote api as remote api calls would take way too much time.
If the input txid is an element of your funding txset wich you collected before it is a channel close (for now while we don't have Splicing)
On the other side 1ml.com has a history of channels with the closing tx. So you might be able to get the data you seek from them.


text:
Hierarchical Deterministic (HD) Importing Funds
I'm creating derived addresses from a HD private key.
I have all data saved, such as the; seed, HD private key and derived addresses with their private keys, plus wif formats.
I'm receiving funds in each address, but need a way to import all the funds as efficiently as possible into a SPV wallet. At the moment I import each address wif to recieve its corresponding balance.
Is there a neat way to pull in all funds that derive from a "master key". Or, have I misunderstood deterministic benefits - am I trying achieve a non existent feature?
TLDR; what's the best way to import funds from multiple addresses?

Is there a neat way to pull in all funds that derive from a "master key". Or, have I misunderstood deterministic benefits - am I trying achieve a non existent feature?

If you import your master key (which may be in the form of a mnemonic or an xprv...), any BIP44 compliant wallet should be able to locate all the funds, provided you followed BIP44 when generating and using addresses.
If not, then you will have to import each key individually.


text:
Deterministic - BIP32 Derivation Gap Limit
I'm creating many derived addresses from a xprv (HD private key).
I've been reading about the gap limit problem. The gap limit is 20 addresses ahead.
How do I get my wallet to detect funds, in addresses, that have surpassed the gap limit?
i.e. m/100 derived address transactions would not get detected, until the gap limit is filled. Are there any tricks to get around this?
If not, I plan to bulk import corresponding WIF keys for each address. Do people recommend doing this?
Ideally I would like everything controllable via 1 master key.

The BIP44 gap limit approach is a weak or even broken concept for recovering BIP32 based wallets.
It makes an assumption about the use case of a BIP44/BIP32 based wallet.
The default limit of 20 (some even use 5) will quickly lead to lost funds in recovery if the wallet was used in non-super-trivial use cases.
The missing metadata in a BIP39 mnemonic or in BIP32 xprivs tend to make recovery complex and has a moderate risk of missing funds.
The ultra-safe(est) way to recover a BIP32 seed without metadata is to derive all possible keys (impossible) and all possible scripts, then, rescan the blockchain. But yes, your guess is right,... this is infeasible.
So how to recover?
If you develop a wallet or rescan tool, use a very large gap limit. Maybe 1'000 or 10'000.
If you are just a novice user?

Well, just make sure you keep your old backup in case you detected lost funds.
Don't purely trust a BIP32/39 recovery, make sure all your funds are there
If not, consult an expert (watch out for fraud, use a trusted person), or research how to extend the gap limit and how to derive multiple script types
If you are using Electrum, read here about the gap limits and ways to extend it


text:
Can I connect to a node as read-only?
In my Electrum wallet I can open the Network Window and view Nodes I'm connected to. Here's an example: electrum4101870.fullhealth.net. I can also find public nodes at https://bitnodes.earn.com/nodes/leaderboard.
Is my wallet streaming data from these peers? If so, how?
My understanding is that in order to stay connected to a node you need to exchange messages about the chain...
Or, is there a way I can connect to a node and just read outgoing information, such as new blocks + transactions.
Thanks

It is important to note that your Electrum wallets connect to Electrum servers which speak a different protocol than the Bitcoin P2P network. Electrum servers are full nodes with additional software running which provide the data and protocol that Electrum uses.
If you want to be strictly read only, as in you never send the node any data, then no, it is not possible with either the Electrum protocol or Bitcoin P2P protocol. Both protocols have a handshake at the beginning of the protocol where both nodes (or client and server for Electrum) exchange messages before the rest of the connection can continue.
Furthermore, both protocols have ping messages which have to be responded to. If a node (or client) doesn't respond to the ping, the other side will disconnect you. So if you have no send capabilities, you will not be able to maintain the connection for very long.
However if you just mean you aren't sending any blocks or transactions, then yes. You can most definitely connect to a node and never send it any blocks or transactions.

Using Electrum still requires you to reveal to the server which addresses you're interested in, so even if you ignore protocol handshake stuff, there is no useful way to use the protocol without submitting information.


text:
Access Bitcoin Wallet with private key
3 years ago i bought a little bit of Bitcoin. Today i found the private key of my wallet. But I cant access it, I need these 12 words (backup) I dont have.
Why cant I access my Bitcoin Wallet with Private Key? (Like Myetherwallet, here you can access wallet with private key)

You just need to find some software that can import your private key.
These days, the standard for backing up wallets is defined by BIP32/39/44/49/84, and it comes in the form of a 12 or 24 word mnemonic seed phrase. This seed phrase is used to derive all keypairs and addresses in the wallet, so you just need to store it safely in order to recover your wallet later.
So most wallets accept a seed phrase, and inputting raw private keys has become less common (though it is definitely still possible). You just need some software that can accept a private key.
Note that in some cases, you may have to create a new wallet, and then import the private key to it— there may not be an option to create a new wallet by importing the private key alone.

With bitcoin core it's pretty easy to import a single private key. You just open the console (menu "Window"->"Console") and type in:
importprivkey "<the private key in WIF>" "somelabel"

WIF here means Wallet Import Format and is a standard way of encoding a private key. It should start with either K, L or 5.
Be aware that this will start a full chain rescan to look for UTXOs associated with that private key which can take up to several hours to complete depending on the speed of your disk.
If you know exactly the block where the first UTXO was in (from a block explorer perhaps), you can also do:
importprivkey "<the private key in WIF>" "somelabel"
rescanblockchain <startblockheight>


text:
Wouldn't the "malleable transaction" attack be foiled by common sense?
I'm trying to understand the malleable transaction attack, as it seems to me that only a rather careless operator would be vulnerable in the first place, as described below.

Mainly to clarify my own thoughts, let me describe the attack as I understand it.  Dramatis personae: Alice is the attacker, and Bob is a "banker" (exchange operator, web wallet; someone who is holding coins on account for Alice.)
Alice: Hi Bob, I have 1 BTC in my account and I'd like to withdraw it.  Please send it to address 1Alice1.
Bob: Okay, I've generated a transaction, its hash is 123abc.  I've just posted it to the p2p network.  It spends output 3 of prior transaction 987def and sends 1 BTC to 1Alice1.  Your account has been debited for 1 BTC and your new balance is 0.
Alice: Thanks, I see the transaction.   I'll wait for it to be confirmed.
Now Alice constructs a "mutant" transaction, with the same effect as 123abc; it still spends output 3 of 987def and sends 1 BTC to 1Alice1, and the signature still verifies, but the mutant has a different hash 456bca.  Somehow, Alice gets 456bca into the blockchain instead of 123abc.  Maybe she's just better connected on the p2p network than Bob is, or maybe she bribes Polly, a mining pool operator, to give priority to 456bca.  Since 123abc conflicts with 456bca, 123abc will never be confirmed.
Some time passes.
Alice: Hey Bob, remember that 1 BTC I was supposed to get?  The transaction never confirmed.
Bob: Let me check.  Yes, I see, there's no such transaction as 123abc in the blockchain.  Well, I guess you never got your coins; sorry about that.  I'll recredit your account; your new balance is 1 BTC.
Alice: Thanks.  Now that I have 1 BTC back in my account, I'd like to try again to withdraw it.  Send it to 1Alice2.
Bob: Okay, I've generated a transaction, its hash is 246fed.  I've just posted it to the p2p network.  It spends output 7 of prior transaction 369dbc.  Your account has been debited and has balance 0 again.
Transaction 246fed is confirmed normally.
Alice: Gotcha, Bob!  Your original transaction went through after all, just in mutant form as 456bca.  Now I have both it and the new transaction, and I've just stolen 1 BTC from you.  Mwa ha ha!
Bob: Oh, woe is me!

However, it seems to be that this attack requires some rather careless bookkeeping on Bob's part.  Even if Bob has no idea there is such a thing as a malleable transaction, he knows he generated 123abc and put it on the network, and for all he knows it is still floating around out there.  So I would think that before recrediting Alice's account, common sense should dictate that Bob ensure that 123abc cannot be confirmed at some future date, perhaps by making a new transaction (963dad) that spends the same input (trans 987def output 3) to one of his own addresses (1Bob1), and waiting for 963dad to confirm.  Of course, in the current scenario, 963dad never will confirm (because 456bca supersedes it), and Bob will eventually get tired of waiting and investigate further.
Or, alternatively, when Alice asks to withdraw 1 BTC for the second time, Bob's new transaction (678bbb) to Alice should again spend the same input (987def:3), ensuring that Alice can't somehow get 123abc confirmed later.  This foils the attack also, because 678bbb has been invalidated by 456bca.
Furthermore, since Alice's mutant transaction 456bca did in fact spend Bob's input (987def:3), shouldn't Bob's client software inform him that this input is no longer available to him, and adjust his balance accordingly?  Bob apparently believes 123abc failed and so he still controls that input, and therefore this should throw his books out of balance and alert him that something is wrong.
My understanding is that the Bobs of the world have responded to the issue by complaining that "malleable transactions" are an obscure protocol bug that they couldn't have been expected to anticipate.  Whether that's true or not, it seems to me that in order to have been vulnerable, Bob's accounting practices already had to be negligent, so he really has no defense either way.
Or, if Bob saw the red flags but failed to understand the situation, and credited Alice's account anyway in the interests of customer service, it's still hard to feel much sympathy for him.
Is this account essentially accurate, or have I missed some crucial details?
Thanks, and sorry for the length.

In essence, you've replicated the argument that nobody needs to worry about this problem, which we now know is false. It's because of that very belief that we have the mess we have now.
One crucial detail you missed is that when spending the outputs of a prior transaction, you must specify its transaction ID in your new transaction. So there are many other possible failure scenarios.
For example, say you form only transactions that spend your own outputs, so you might assume that your transactions will definitely succeed eventually and thus you can chain transactions without waiting for confirmations. Until recently, this was considered the correct way to generate high volumes of transactions.
But we now understand that you can't because the chain can break entirely if any transaction in the chain has its ID changed. The next transaction that refers to any of those outputs will never confirm since it will have the wrong transaction ID specified in one of its inputs. Later transactions that spend from that transaction will also fail and you'll have an unholy mess.

Check out this video supposedly demonstrating a malleability hack on mtgox:
https://www.youtube.com/watch?v=WfKy3DEiOwY
Looks like gox automatically recredited his account after the failed transaction - which would explain both the fiat discrepancy ( sell your hacked coins for fiat) and the coin discrepancy.
Now the real question is:
How did those idiots at Gox not notice?

I was originally going to phrase this as a comment but I'm confident enough to risk the downvotes with an answer:
What Bob should have done was spend the original inputs again (possibly by simply re-broadcasting his original txn). If the alternative txn was already in the blockchain the new txn would be correctly rejected as a double-spend, alerting Bob that the coins had in fact changed hands.
Looking forward to learning how my simple explanation is incorrect :)

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


text:
Which clients offer a way to replace unconfirmed transactions?
On this site, we see a lot of questions from people who have sent a transaction which isn't being confirmed, often because they have neglected to include an adequate fee.  The Satoshi client doesn't appear to offer a convenient way to handle this; the only advice to the user is either to wait indefinitely until the transaction is picked up by an altruistic miner, or to do some kind of elaborate hack involving replacing wallet.dat, etc, so that the client forgets the transaction ever existed.
The obvious solution from the point of view of the protocol is to produce and send a new transaction spending the same coins, but with a fee added.  Since this would technically constitute a double spend, it's perhaps not surprising that client authors don't want to include such a feature; but all the same it would be very convenient in certain situations.
Are there any clients that provide this feature?
Alternatively, has anyone produced a patch adding this functionality to some client?

Electrum Bitcoin Wallet has the feature. I've confirmed that mac client worked. It seems that Android app has the same feature.
https://electrum.org/#download

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


text:
Privacy of sending CoinJoined UTXOs from wallet with unCoinJoined UTXOs
If I use something like Wasabi to CoinJoin my UTXOs and then send the outputs to a wallet with addresses containing UTXOs that haven't been coinjoined does this present a privacy risk?

...does this present a privacy risk?

Privacy concerns can be boiled down to the following questions: what information am I giving up by engaging in this transaction? And who am I sacrificing this information to?
When you engage with some counterparty to make a payment, they will gain knowledge about your involvement in the bitcoin transaction that includes said payment. An unrelated third party can also watch over all transactions, but they will not necessarily know that you are involved in said transaction specifically. By following the history of transactions and using some (imperfect) heuristics, a third party can potentially trace your coins through time, and given information about your involvement in some prior transaction, they can thus potentially link future transactions to you as well.
A coinjoin helps to sever the ability of any party to trace your coins through time (thus providing privacy). It does this by breaking the heuristics used to track a coin’s history, by effectively creating many possible histories for each output. With enough possible histories, it becomes ineffective to attempt to track a coin’s history through time.
So to answer your question more directly, let’s assume that you spend a coinjoined UTXO to some other wallet you control, and then eventually that UTXO is combined with a non-coinjoined UTXO in order to make a payment to some counterparty.
The counterparty you are engaging with could assume that you most likely control all inputs to the transaction (this is one of the mentioned heuristics), so they will now potentially have knowledge of: your use of coinjoin transactions, and your involvement in a specific coinjoin transaction. Additionally, they will have knowledge of your involvement in the transaction that created the other UTXO you spent. The counterparty could trace this other UTXO back through time, and probabilistically (using the heuristics mentioned) unveil some amount of your financial history.
For an unrelated third party, the same sort of analysis is possible, but they may not be privy to the fact of your involvement in said transactions. They may just be able to determine (probabilistically) that some group of transactions surrounding the transaction in question likely belong to a single user/wallet.
Example: the privacy granted by coinjoin transactions can be truly broken when a third party gains knowledge of your involvement with a transaction on both sides of a coinjoin. For example, if you bought coins from a KYC’d exchange, transferred them to an external wallet, coinjoined, and then sent the coinjoin UTXO straight back to the exchange (to the same user account), then your use of a coinjoin would be useless in protecting your privacy against the exchange. Further, the anonymity set for each other participant in the coinjoin would now be reduced slightly, since the link between least one input and output in the transaction would be known.
———————
So, coinjoin transactions can be effective if used properly, and the more they are used, the more effective they become. But they are not a silver bullet against privacy snoops! Improper use can completely destroy the privacy gains, and so a user must practice careful coin control in order to maintain their privacy most effectively. In the example above, if the user never combined the coinjoin UTXO with any other UTXO that is traceable back to them, then the coinjoin would be quite effective in preserving their privacy. But by combining it with unjoined UTXOs, some privacy may be sacrificed.

Thank you @chytrik This confirmed my thoughts in an eloquent way. An excellent answer!


text:
What is the difference between BFT and PBFT
What are the differences between BFT and PBFT?
I want to know the difference between these two concepts.
If there is any improvement in the BFT's limitations, let me know.
Please answer. Thank you.

BFT is a class of problems where a group of nodes needs to find consensus, where some of the nodes may be malicious. PBFT is an algorithm that generates consensus in one of those environments (specifically with signed messages and partially sychronous network). An good writeup is here: https://medium.com/s/story/lets-take-a-crack-at-understanding-distributed-consensus-dad23d0dc95


text:
Where and how are raw transactions stored on the blockchain?
My understanding is that transactions are stored on the blockchain in double hashed format: ie SHA256(SHA256(rawtransaction)). But it is also possible to get access to the raw transaction. This means that the raw transaction data must be stored somewhere. So where is the raw transaction data stored, if it isn't stored on the blockchain? Or was my initial statement incorrect about transactions being stored in double hashed format? I don't think the raw transaction data can be extracted by reversing the double hash operation.

This is a question of definition.
The blockchain doesn't store anything, it's an abstract data structure that's collectively maintained by nodes in a network. Those nodes are the ones that store things. That may or may not include the actual transaction data - it doesn't matter.
The Bitcoin blockchain consists of hash-linked block headers. Every block header contains the hash of the previous block header. Every block header also contains a hash of all the transaction hashes in it (through a Merkle tree). Those transaction hashes obviously are hashes of the transaction data itself.
That's a definition of the structure all nodes need to agree on, because it involves hashes, and those hashes need to match. But what they actually store of that is their own business. Full nodes with unpruned history will store all transactions and all blocks. Pruned nodes may store all transactions and blocks down to a particular point in history. More lightweight nodes may only store the block headers plus transactions the user is interested in.

So the raw transaction is indeed stored in the nodes (full nodes at least, and possibly pruned ones) and each transaction stores a double hashed representation of its input transactions: https://bitcoin.stackexchange.com/questions/8443/where-is-double-hashing-performed-in-bitcoin

Yes, transactions are typically serialized and stored that way, but again: they don't have to be. How things are stored is up to the individual node software. E.g. some software uses a compressed representation that can omit repeated input hashes. The only thing that matters is how a txid is defined, which is a double-SH256 of the transaction data in "network serialization" which indeed includes the txids of the previous tx that created the UTXOs being spent. If somewhere can store things differently, but still agree on that hash, everything is ok.

double hashed format: ie SHA256(SHA256(rawtransaction))

Your understanding of this is very, very wrong.
The data structure stored in a blockchain is not double hashed. Instead there are two hashes stored in the data structure.
Instead of SHA256(SHA256(rawtransaction)). You should visualize the blockchain data structure as:
struct Block {
    Transactions[] transactions;
    int256 nonce;
    int256 previousHash; // SHA256(previous.transactions + previous.nonce + previous.previousHash)
    int256 hash;         // SHA256(this.transactions + this.nonce + this.previousHash)
}

You can see, the data structure is linked to the previous block by including the hash of the previous block as part of its own data. This is the "chain" part of blockchain. The definition of the entire set of blocks is recursive because to calculate the hash of the previous block you need to calculate the hash of the block before that and so on until you get to the genesis block.
The raw committed transactions are part of the block.

Um, no. Double hashing is indeed used in blockchain. I can give you lots of references, e.g. https://bitcoin.stackexchange.com/questions/8443/where-is-double-hashing-performed-in-bitcoin. I know how the chain part of the blockchain works. The real answer is that in (for example) links in current transaction to input transactions, the current transaction stores the double hash of the previous transaction. Double hashing is used elsewhere too.

Note: the example of the block structure given in this answer works to give a basic understanding, but it is not truly accurate. See: https://en.bitcoin.it/wiki/Protocol_documentation#Block_Headers


text:
what happens to low-fee or forgotten transactions
If a transaction has a fee that is too low then it is possible for the transaction to either age out of the mempool (14 days) or get removed because the mempool reaches its max size. So what happens to that transaction? At some point the transaction is "forgotten" so the sender has the funds available to him again. But how does this happen? Since each miner has its own version of the mempool, is it possible for the transaction to still be in one miner's mempool but not other miners' mempools? How does the network of miners "decide" that the transaction is forgotten so that the sender now has the funds available to him again? And could that person resend that same transaction or does the sender have to create and send a new transaction?

Likely the transaction will be kicked out of the pool - purging it from the node's "memory". Its hard to imagine that there would be a transaction that would qualify for that treatment with one node, but not for others.
But anything is possible.
If that were the case, then that transaction would just remain hanging in the mempool for that particular node that decided to keep it (for whatever reason). For this portion of the protocol though, its more important to take into consideration which action the network would take overall.
How That Specific Node May Handle Things

There's a chance you may attempt to send a duplicate transaction (from the perspective of that node), unwittingly.

Unless you had the RBF flagged ticked for your TX (which there's a good chance that you may have since this is default Electrum behavior along with many other wallets), the node will reject that new transaction attempt since its likely coming a million years after you sent the initial one

Assuming most of the network purged that TX though (they probably did), however that node decides to handle your re-broadcasted TX (if you do that), is neither here nor there


text:
Is it possible to capture network events without going full-node?
You might find my question rather quixotic or nonsense. But I have to ask it here.
I want to capture all the transactions propagated over the main network and detect if a new block mined. I don't want to become a full-node or spv-node. Technically, I know this is exactly the way all the full/spv nodes do every now and then. However, I could not found a good reference to teach me how.
Is it a way to do so? Any technical resources would be appreciated.

@Prayank Sounds good. Would you please elaborate on this?

want to capture all the transactions propagated over the main network and detect if a new block mined. I don't want to become a full-node or spv-node. Technically, I know this is exactly the way all the full/spv nodes do every now and then. However, I could not found a good reference to teach me how.

Clearly, full nodes and SPV nodes must get their information from somewhere. And that somewhere is simply other nodes on the P2P network.
The P2P protocol is what nodes use to communicate with each other. There is some documentation on https://developer.bitcoin.org/devguide/p2p_network.html, some older but more detailed documentation on https://en.bitcoin.it/wiki/Protocol_documentation). Modern changes to it are proposed as BIPs (https://github.com/bitcoin/bips), which are usually backward compatible changes, only used between clients that support it.
Specifically, transactions are relayed by first announcing their hash using an "inv" message. The receiver then chooses which peer to fetch the full transaction data from, and sends a "getdata' message. The selected peer then responds with a "tx" message. There are other mechanisms available such as the old (and largely abandoned) BIP37 transaction filtering, and the newer BIP157 client-side filtering.
For blocks, it is a bit more complicated. The sequence there is first requesting block information using "getblocks", then responding with "inv"s for the blocks, "getdata" to request the full data, and "block" for the full blocks themselves. BIP152 compact blocks provides a far more efficient mechanism that allows the receiver to avoid receiving transactions in blocks they already have. BIP130 sendheaders enables an alternative where blocks are announced using "header" messages instead of "inv" messages.
So what distinguishes a full node from an SPV node or other nodes? The level of validation they perform. A full node will fully validate all blocks and transactions it receives. If you don't want to do that, just don't - if you're ok with trusting whomever you're connecting to. You can implement the P2P protocol yourself, or use existing implementations (there exist ones in many languages), connect to whatever peers you like, and if you do it right they'll start giving you a stream of blocks and transactions.


text:
BlockUntilSyncedToCurrentChain: txindex is catching up on block notifications
The message "BlockUntilSyncedToCurrentChain: txindex is catching up on block notifications" is appearing regularly in my debug.log. When these messages appear, I can be sure that lnd will not be able to complete syncing to the chain and thus unable to fully start.
This message occurs after the "txindex thread exit" message, and can be triggered with a "bitcoin-cli getrawtransaction xxx" call. I don't know how to resolve this, or even to determine what state the txindex is in. Restarting bitcoind does not help.
I am running Bitcoin Core version v0.18.0 (release build).

One way to solve this seems to be to disable and then reenable txindex. In other words, stop bitcoind, set txindex=0 in bitcoin.conf, start bitcoind, wait until fully started, stop bitcoind, set txindex=1, start bitcoind, wait until message "txindex is enabled at height xxx".
Unsure why this is necessary though.

I would be cautious of this advise. Restarting a txindex-synced node without txindex will essentially abandon txindex and you will need to re-index from scratch, should you want to enable txindex again

and yes, it "helps" because there's no txindex anymore, so no warnings about it :) Maybe you did not notice this because you did not need txindex at the first place

For me it turned out that I had mempool.space running on my machine before bitcoind was done syncing the blockchain. I assume that mempool sends RPC calls to bitcoind in regular intervals, which then somehow causes this message to appear in the debug.log and often it seems that this message stops the blockchain syncing process and you have to restart bitcoind.
Simply shutting down mempool.space allowed bitcoind to then download the rest of the blockchain without any hickups, for me.

The warning message simply means that your node is indexing new block(s) at the moment, and thus RPC calls are blocked temporarily. Blocked here means they are waiting in the RPC request queue, not rejected or something. So once the indexing is done, they will be processed normally.
From the client side it may look like those requests take more time to execute. That is until there are too many requests in the RPC queue and further requests are rejected. then you would see different messages in the log explicitly stating this, which is a bigger concern (that's when your RPC clients will actually receive an error). Queue depth can be adjusted (default is 15, IIRC)
If you see a lot of messages like this - it may mean your node lacks resources to promptly index incoming blocks, check the node performance (disk IO / memory / CPU usage).


text:
How does the miner efficiently check that an address has required amount of data?
I've read this question.
As the answer said, the miner "looks up the outputs that a transaction is spending from and makes sure that no other transaction has spent those outputs already."
So the miner has to look up all the blocks form block 1 to the end, which has over 500,000 blocks (and will grow even bigger), for each transaction. And a block contains thousand of transactions. This sounds impossible to me.
"A node maintains a list of all unspent transaction outputs." This request each node to maintain billions of address and their unspent transaction outputs. Is this even possible? If yes, what about the future?

So the miner has to look up all the blocks form block 1 to the end, which has over 500,000 blocks (and will grow even bigger), for each transaction. And a block contains thousand of transactions. This sounds impossible to me.

No, it just maintains a set of all unspent outputs. For each output in each transaction in a block, an entry is added to that set. For every input, one is removed.
It doesn't need to go through the entirety of history for each input; it just looks it up in the database.
Also, this is not restricted to miners. Every node performs this operation. Miners are only kept honest by the rest of the ecosystem verifying that the blocks they produce are valid.

"A node maintains a list of all unspent transaction outputs." This request each node to maintain billions of address and their unspent transaction outputs. Is this even possible

No, addresses aren't relevant here. The UTXO set is just a set of UTXOs. Each UTXO has an address (or more precisely a scriptPubKey or locking script), but they are identified by the transaction that created them and the position within that transaction.
Every transaction refers to actual UTXOs being spent (by listing the txid and index of the transaction that created them). They're not looked up by address.
The address (script) is only involved in determining whether a particular spend was authorized, by runni g the script with the signatures provided in the input, and checking it evaluates to True.
At the time of writing (July 2018) there are about 49 million entries in the UTXO set. For many systems the entire set easily fits in memory.
You are correct in being concerned about the future though. There are no real incentives in the system to keep this set small, and its growth is effectively unbounded.
There is research into moving to models where nodes don't actually maintain this set themselves anymore, but transactions instead contain proofs that the UTXOs being spent exist and aren't spent yet. Useful search keywords are Bram Cohen's bitset model or Peter Todd's Merkle mountain ranges.


text:
can one account have more than one address?
Bitcoin core support the methods :

getnewaddress [account]
getBalance [account] [minconf=1]

All of them are base on account concept. So I wonder that if one account can contains more than one address?
When I call the getnewaddress with the same account name many times, what does happen? The account will associate with all addresses that the method created, right?

First of all, do not use the accounts feature. It is both broken and going to be removed. It is important to note that accounts are not part of Bitcoin at all and are just a part of Bitcoin Core.
You can associate multiple accounts with the same address. It just means that the account's balance will update with each amount sent to an address associated with the account. However, sending Bitcoin from an account in your wallet WILL NOT necessarily "send from" the addresses associated with the account. It will just decrease the balance of that account.


text:
Send to bech32 segwit address from Bitcoin Core 17.1
I have a non-HD wallet in Bitcoin Core v17.1.  I have never used SegWit before.
I need to send some coins to a bech32 address from bitcoin-qt GUI.  The problem is after selecting the specific coin inputs to use (originally received into P2PKH address), and then entering the bc1... bech32 send to address, then the Send button does nothing.  I usually after pressing Send button get a passphrase prompt to unlock the wallet and confirm sending the transaction.
How do I send to a bech32 address from qt GUI?

This sounds like a bug that's unrelated to bech32 addresses.

Maybe it's a bug related to the selected inputs.  I'll upgrade to 18.0 soon and try again.  I'm also running on some older Linux qt libraries.

When I upgraded bitcoin-qt, the problem was fixed.  Bug in 17.1


text:
How do I backup wallet for first time
I tried to send Crypto to my brand new digital wallet.  I was informed I must backup wallet first.  How do I back up my digital wallet for first use?

The method can depend on which wallet you use. Are you using Bitcoin-core, Electrum, Bread or something else? Are you using an account with a web based service? If so which?

Just write down the 12 words and put them back in and its done.  never give out them words because that your passphrase or in other words your Backup


text:
Why use the master key to encrypt private key? And why just store unencrypted master key in memory?
When encrypt wallet, using a master key to encrypt private key.The master key is encrypted by the key derived based the wallet's passphrase.
When unlock wallet, the unencrypted master key is stored in memory, but not private keys.
1、Why not directly use the key derived based the wallet's passphrase?
2、Why the unencrypted master key is stored in memory, why not private keys?

1、Why not directly use the key derived based the wallet's passphrase?

Encrypting a master key which is then used to encrypt the actual keys is a fairly standard practice for encrypting data. Doing this allows the master key to remain the same so that changing the password does not result in having to decrypt and then re-encrypt all of the encrypted data. It only requires decrypting and re-encrypting the encryption key.

2、Why the unencrypted master key is stored in memory, why not private keys?

A wallet can contain thousands of keys (or tens of thousdands, or even hundreds of thousands). Keeping all of these keys in memory will use memory and possibly take up so much memory that the system is unable to keep running bitcoind. A master key is fixed size though, and fairly small, so keeping that in memory is not a burden.


text:
Building a small block explorer for fun, stuck with node
Im trying to build a small btc block explorer for fun.
The problem where i am stuck is that im trying to setup a node.
I got a Ubuntu VPS running and i have bitcoind installed, but what now?
Can someone help me with this? I have read that you need to run the node in txindex mode or something.
Thanks in advance!

Search for RPC protocol that gives you an interface for the data on the node once it's running.

Thats the problem, i cant get the node configured.

Got it, let me know if that answer helps.

You want to use the RPC Protocol to get blockchain info. RPC is usually disabled by default, so you need to enable it. You can do this in the bitcoin.conf file in .bitcoin folder where you've installed the daemon.  Alternatively, you can run the daemon with the -server flag, see  command line arguments. Now, you will also need to set RPC authentication in the conf file as well. The -txindex flag will allow you to search for any tx by hash using getrawtransaction command, which may be useful depending on how you utilizar the RPC protocol.
Example bitcoin.conf
The line to add is:
server=1

How to use:
RPC documentation

Huge thanks! Is it also possible to retrieve an accounts balance using bitcoin-cli? And data about blocks such as timestamp, amount of transactions and total block value (in btc).

getbalance only retrieves balance for addresses you own. I think you have to query all transactions for an address and sum them up. You probably have to do the same for total block value, have a look at the RPC docs in the link above for all possible commands.


text:
Why does Bitcoin Core support a transaction index but not an address index?
Bitcoin Core has the CLI option -txindex to maintain a full transaction index for RPC calls. That sounds useful for some use cases, like for a blockchain explorer. It seems perfectly logical then that there should also be an option to enable an address index, which would allow looking up address balances and transaction histories, but there isn't one. Why is that? And why exactly was -txindex included in the first place?

The transaction index exists because it is leftover from how Bitcoin Core used to work for validating new blocks and transactions. Prior to 0.8.0, Bitcoin Core maintained the transaction index, and when validating transactions, would look up outputs by going into the transaction index, finding the transaction being spent, then finding its output. The transaction index was integral in validating transaction.
0.8.0 introduced a feature called ultraprune which gave us the validation model that we have today. What ultraprune did was that it got rid of the reliance on the transaction index and instead UTXOs were stored in a separate database. New transactions would be validated by looking up the UTXO in this other database, and when the UTXO is spent, it is removed from the database. This was introduced because it is much faster and it allowed for the transaction index to not be built and thus "prune" the database.
But instead of deleting all of the transaction index code, it was decided to put that feature behind the -txindex option. This is because there were already users relying on the ability to look up arbitrary transactions, so it would not be good if Bitcoin Core just removed this feature out from under them. This is how we have the transaction index today - it wasn't a feature that was implemented because people wanted it, but rather it is a leftover from how Bitcoin originally worked.
(Side note: I think that if Bitcoin Core had used ultraprune originally and not needed a transaction index in the past, there would not be a transaction index feature.)

An address index doesn't have the benefit of existing previously, so it would have to be something that is completely new. And there have been several attempts to implement an address index, by my count, 4 attempts. None of them have been merged.
The main objection is really one of the scope of the Bitcoin Core project. Is it really in the scope of Bitcoin Core to provide a blockchain explorer to every user? Is that really necessary, and if so, is it worth it to maintain that feature? Because once the feature is added, it will basically have to be maintained in perpetuity.
To understand why many contributors have not been favorable towards adding an address index, we need to understand what the use case is.
As you mention, it is allow looking up address balances, but that can already be done without an address index. It's completely unnecessary to build an index of all addresses and their transaction histories to calculate their balance; a balance calculation can be done with the UTXO set itself (which every node must maintain anyways). In fact, Bitcoin Core already implements this via the scantxoutset RPC. So this use case doesn't actually need an address index.
As you mention, it would allow looking up the transaction history for an address. But so far no one has really came up with a compelling reason for why this is useful. Sure it's cool to be able to look at an addresses transaction history, but is it so cool that it's necessary to implement it into Bitcoin Core and now burden the Core developers to maintain it in perpetuity?
For many of the use cases of address indexes I have seen proposed, it seems like each one need slightly different data, or data formatted in slightly different ways. For example, Electrum servers require an address index. Currently they have their own (multiple) software that builds the address index and speaks the Electrum protocol. But because of some quirks of the Electrum protocol, everything is provided as hashes (not addresses). So in order for an address index in Bitcoin Core to be useful to Electrum, it would also have to index by script hashes. Otherwise, Electrum will still have to write their own software to build their own address indexes.
For building these kind of services on top of an address index, it seems like it is more reasonable for people making those services to just build an address index themselves. That way they can store the data in exactly the way that they need it rather than hoping that the developers of an upstream project will store the data in a way that they can use it.
So it really comes down to the fact that no one has come up with a compelling reason for Bitcoin Core to implement an address index. For all of the things that need an address index, they can build their own address index and tailor it to their needs.

It’s worth noting that many implementations of an address index have been added to forks of bitcoin core and they tend to have absurdly poor performance. Very very good answer.

The compelling reason is for wallet apps. It's missing features like this that have held bitcoin development back.


text:
33 byte private key?
I have read that private key is 256 bits or 32 byte. see here
I generated a key on bitcoin-test network.
WIF:

cVe4tA6QHduboeSiQD6Y6nzV1QjaVpDVG2YHbqbtJiSCxsNDYYUF

HEX:

f06e4a9c228dafff48e6a44eb9527a14374a203a5750de01c0cf39e7280ce45501

if you notice above hex is 33 bytes!
I went  on to sign a transaction :

01000000015760c907060ca47bbf97a964a435387c38fd86c307e920c1d29ce1a3d0d4d56b010000001976a914ca560954433f0fd1bda9bb566607d1724559b0db88acffffffff02d0070000000000001976a914f9ad22432bb6eb5e4262f9e4bcfb09fda2f5167b88ace068be07000000001976a914ca560954433f0fd1bda9bb566607d1724559b0db88ac0000000001000000

generated the following tx hash:

01000000015760c907060ca47bbf97a964a435387c38fd86c307e920c1d29ce1a3d0d4d56b010000006b483045022100f2224f424a63675682f062fbf6699028727e13d26dc382af6dca57dfb21e9910022011b485e63f8f0045c40f8df41bcab13040bc554da4c176a380c81d18c615b210012103b9dc990c2b8a999ba68bf80cbff94fd85d62a01c7dc48252156f78c813b0aa67ffffffff02d0070000000000001976a914f9ad22432bb6eb5e4262f9e4bcfb09fda2f5167b88ace068be07000000001976a914ca560954433f0fd1bda9bb566607d1724559b0db88ac00000000

and when i broadcasted it got accepted!
Now my question is, how can 33 byte private key be valid signing key?
P.S. please don't take out the coins, they are worthless and i need for testing. thanks!

Got it: the last byte 01 stands for compression and has to be dropped

cool, you found it - here was last recently a discussion on it: https://bitcoin.stackexchange.com/questions/69315/how-are-compressed-pubkeys-generated/69322?noredirect=1#comment80498_69322


text:
Which block explorer indexes the keys used in mutisig scripts?
Consider transaction 0846e91bc3afdf2275db14bcbb10e19f141069d77f17dae6bcbd907fd28f4747, which takes money out of the script address 3PJQGGnBQr8DJBdPYowd6Mp2kSWvFFo7Gk. As we can see in the input scripts, this script address references script 51210261afd7a2796e9bb83896089293f11edd2987ebbd67ed2075f5e45b7c4bb7edcb51ae, which, according to the decodescript command, is
    "asm": "1 0261afd7a2796e9bb83896089293f11edd2987ebbd67ed2075f5e45b7c4bb7edcb 1 OP_CHECKMULTISIG",
    "reqSigs": 1,
    "type": "multisig",
    "addresses": [
        "1xW3APNVG6Ro1HY8hysmnKq8mvgVk6oPU"
    ],
    "p2sh": "3PJQGGnBQr8DJBdPYowd6Mp2kSWvFFo7Gk"

So this payment was made to anyone who has access to the key with the address 1xW3APNVG6Ro1HY8hysmnKq8mvgVk6oPU.
But none of the common block explorer websites seem to index this; when I ask them about the address 1xW3APNVG6Ro1HY8hysmnKq8mvgVk6oPU, they list no transactions.
Is there a block explorer that maintains a mapping from key address to the script addresses the key is mentioned in?

You must not see the address in the blockchain as a receiving address. It is a P2SH tx, which means, that the spending condition is sha256’d. This is the type 3address above. The 1-of-1 multisig condition inside defines, that anyone who has the private key to the “1xW3APN...” address can spend this tx, which happened on 2014-07-28 to the target address “1UxOYSY...”
I highly recommend reading Andreas’ book mastering bitcoin (online available), which explains in nice detail the reasons and insights of those multisig adddresses.
Blockexplorer blockchain.info obviously doesn’t show the decoded script, cause it is not an address used to receive funds.

I understand that. But still, when I want to find “everything on the blockchain related to ” 1xW3APN, can’t I reasonably expect to be shown the 3address above? (Of course only once that address has been used once, so that the actual script is publicly known)

I see, then maybe this: https://webbtc.com/script/0846e91bc3afdf2275db14bcbb10e19f141069d77f17dae6bcbd907fd28f4747:0 - it would decode the "Inner P2SH Script" ...

That’s a cool resource, thanks! It even turns 1xW3APNVG6Ro1HY8hysmnKq8mvgVk6oPU into a link. But then there is no back link.
Obviously the data is there, and it could link back to that transaction, but it seems that is not done. I guess nobody else wanted this before :-)

On blockchain.info you can look it up by 3PJQGGnBQr8DJBdPYowd6Mp2kSWvFFo7Gk which is the keyed address that was used (p2sh).


text:
Why i can still use the 'generatetoaddress' RPC with custom signet?
I have set up my custom signet, with my own challenge.
I expected to fail to generate blocks using the 'generatetoaddress' API before importing the private key related to the challenge script in the node wallet, but using bitcoincore 0.21.1 the blocks generation works with just the PoW.
Why?

generatetoaddress doesn't actually have a restriction on which networks it operates on. You can use it on mainnet, it will just not find any blocks. The way that it is implemented is that it just tries the nonce range for a single block, and if none of those block proposals are valid, then it exits. So if the difficulty is low enough that it is possible to find a block with just the nonce range (rather than needing to change block templates or increment an extra nonce), then generatetoaddress will find blocks.

Hello Andrew. So signet blocks are not strictly committed to the challenge script? At this point, I don't know how it works.

Signet blocks need to be mined using a separate utility so that the challenge script is valid. Instructions for mining signet blocks can be found at https://github.com/bitcoin/bitcoin/blob/master/contrib/signet/README.md#miner

Thanks again for your answer. I have already checked the signet documentation on how to mine blocks (unluckily the current miner on master is broken, using the 0.21.1, but this is another story).
What I don't get is why the generatetoaddress API is still used to produce blocks in a custom signet, I expected to see it fail due to lack of signature.

It would only fail if you have set up the mining utility to require a block signer and not provided a valid block signature. By default a custom signet doesn't require a block signature, you have to set that up if you want that.


text:
Regtest at height 120k took 600ms to generate a block
Just doing
while :
do
 time bitcoin-cli generatetoaddress 1 <non_local_wallet_address>
 bitcoin-cli getblockcount
done

brings regtest blockgen times up to 600ms when generating a block at the height 120k, even with all empty blocks.
I have noted down the following numbers:
height, gen-time
800 -> 7ms
5500 -> 18ms
11000 -> 31ms
22000 -> 65ms
37000 -> 110ms

and so on.
This makes my test suite slowing down a lot, over time.
Is this something we can deal with?
Thanks!

I can confirm this behavior. The difficulty is the same in regtest, so I don't think this should be happening.
Unfortunately, I cannot provide any more help apart from suggesting to restructure your suite so that it does use 120k blocks.

This is probably not related to block height. Because running invalidate and mining again from genesis does not help.

Why do you need 120k blocks for a test?

If you add -debug=bench to your bitcoind command, then the debug.log file will contain log lines with benchmarks for some part of the block generation process. That may help inform where the slow down is.

Hi Andrew, infrastructures developers may have infinite reasons for having a private, permanent, regtest network.
The debug (=all) doesn't highlight where bitcoincore is spending time to generate blocks. I'll try with bench.

Hey @JonSnow, have you had any luck with the benchmark tests? I am experiencing the same issue and before I start investigating on my own, I would like to hear if you found something! Thank you in advance!


text:
Is it possible to announce several IP addresses for a single lightning node according to Lightning protocol specs?
Is it possible to announce several IP addresses for a single lightning node?
The idea is to run a node that is connected to different ISPs to increase its uptime. LND seems to able to run in a cluster using etcd as its database backend. So a multi-homed front-end seems to be the next logical step.


text:
Broadcasting a raw transactions on bitcoin network
I have made a raw transaction (based on Bitcoin rules) for my own for sending on Bitcoin network. I would like to submit it on the Bitcoin network. How can I do it ? (preferably command line based).

Using Bitcoin Core (bitcoin-cli), the standard sequence of commands to create and broadcast a transaction would be:
createrawtransaction
signrawtransactionwithkey
sendrawtransaction

You can find information on the commands by executing bitcoin-cli help
You might also want to see this question:
https://stackoverflow.com/q/38493893

Do you know how can I use bitcoin-cli locally and not as a full node? if it is possible.

bitcoin-cli simply alllows you to interact with a running instance of bitcoind via RPC.
if you want to perform tests on a local network you need to use Regtest (add -regtest to both bitcoind and bitcoin-cli)

If you don’t want to run a node you can use a third party service that will broadcast your transaction for you, for example https://www.blockchain.com/btc/pushtx

Thanks both. My question actually is can I use bitcoin-cli or bitcoind as a SPV to send transactions on the network or I have to installed whole of around 500 G for running it?

There's no SPV mode in Core, but you can use pruning to limit the amount of memory used to store the blockchain. Note that however you will still need to download each block at first. See this question: https://bitcoin.stackexchange.com/q/48882/35577


text:
Transaction fees for multiple outputs
I received a transaction from an exchange. It has 30 outputs, the fee was - according to blockchain.com - roughly 18k sats. Is this the fee per output or for the entire transaction? Is it cheaper - and if so why - to send transactions with multiple outputs?

Related: https://bitcoin.stackexchange.com/q/69088/5406, https://bitcointechtalk.com/saving-up-to-80-on-bitcoin-transaction-fees-by-batching-payments-4147ab7009fb

Is this the fee per output or for the entire transaction?

The fee is per transaction not per output. In the network data it is simply sum of input amounts - sum of output amounts.

Is it cheaper - and if so why - to send transactions with multiple outputs?

The creator of a transaction is using the fee to bid in an auction of space in the next block. Therefore the fee is based on the size of the transaction in bytes (or in vbytes for segwit transactions). This is sometimes called the weight.
Since every transaction needs a header and at least one input and usually a change output, you save on repeating the byte sizes of these by combining many commercial transactions into one Bitcoin transaction.
HIOOOOOOC "weighs" less than HIOC+HIOC+HIOC+HIOC+HIOC+HIOC. Therefore it costs less.


text:
Bitcoin-cli getbalance returning negative value
I am running: bitcoin-cli getbalance username 1
It is returning -37.01
How is it possible for an account to be negative? Is this a bug or do I need to add stricter security when performing a send to prevent accounts from going negative?
I am running this in daemon mode on debian.

It is possible to an account balance to be negative.
Accounts do not correspond to on-chain transactions 1:1. They are a separate layer within Bitcoin Core. Non-obvious functionality like allowing accounts to go into negative is why they entire account system has been deprecated and will soon be removed.
You should either track separate accounts at an application layer, or use the new multiple wallet system in Bitcoin Core 0.17.0 to create a separate wallet for each account.


text:
Debug Bitcoin Core Mining
I'm running the generate command on a bitcoin core fork (with difficulty = 1) and bitcoind running in another window and outputting the best/vs. hashes as it should when generate is running.
However, nothing has been mined yet; generate keeps returning empty brackets. A similar command worked on this machine so I know its powerful enough to mine at this low difficulty.
How do I check what's going wrong? Perhaps a verbose option for generate or something other than debug.log (this just outputs keypool return/keypool reserve throughout. I have also tried to mine in the debug console of QT client but with no luck either.

If you mean the generate function, which creates blocks on demand, it is only available for the Regtest mode. Use the -regtest option to run in Regtest mode.
If you mean the setgenerate mining function, it has been disable since the 0.13 version of Bitcoin Core, due to the fact that mining difficulty became too high for doing it with CPUs.
If you want to restore that functionality you will need to restore the mining functionality code from a previous version and try to integrate it again in the source code (you will need to recompile it).
debug.log is the reference log file. You can refine the log output through the command line options. See https://en.bitcoin.it/wiki/Running_Bitcoin

You can also use external mining software such as cpuminer.


text:
Can two signed transactions be merged into one?
I'm in a situation where I have a presigned transaction, which, due to a bug in software that generated it, has a fee lower than minimal relay fee. I have that transaction's hex, but it can't be broadcast in a way that'd get it mined, so that's no use. Thus, the question: is it possible to merge it with another transaction which I could arbitary create and sign with my wallet, so that that transaction would unlock enough bitcoin to cover the fee for the resulting transaction? If so, how could I do this?

The term to search is "child-pays-for-parent." All it takes is one miner to pick up the parent-child pair for confirmation. Put a nice fat fee on the child transaction. You may be able to contact a miner directly, too.

@RichApodaca You can't do a child pays for parent if your parent transaction fee is below minrelay. A node won't accept the child if it doesn't know about the parent, and nodes will not relay the parent, so they won't know about it

Nodes set their own relay polices. Bitcoin Core adds parentless transactions to an orphan pool. It only takes one miner to pick up the parent-child pair. True, it may not work depending on peers. But these aren't consensus rules.

Potentially. It depends on how the transaction was signed.
If it was signed with a SIGHASH_ALL flag, you cannot combine it since the signature checks to make sure the inputs and outputs have not been changed.
If it was signed with an ANYONE_CAN_PAY flag, you can add additional inputs, and potentially more outputs depending on the rest of the signature.
All consumer wallets I'm aware of default to SIGHASH_ALL, so you're likely out of luck.
Your best bet would be to either send more BTC to that address and sign a new tx, or to import your private key into another wallet with more BTC, and create a tx spending from more than one address.


text:
How easily can asics be ported over to other sha algorithms?
Let's say I want to rewrite the software behind the hardware of current asics. Would it still mine, for example, sha1 algorithms orders of magnitude faster than a normal cpu would?

What do you mean by "the software behind the hardware"? The hardware cannot be changed, it is designed specifically for SHA256

Application Specific Integrated Circuits are hard set to only do one thing, and in the case of bitcoin ASICs, that's SHA256 hashes. You cannot re-write the software, you would need a new circuit built that only does SHA1 or whichever hash you're looking for.
https://en.wikipedia.org/wiki/Application-specific_integrated_circuit


text:
LND seems to ignore CSV delay settings when opening a channel
LND v0.15.5-beta
In my lnd.conf file I have the following lines:
bitcoin.maxlocaldelay=144
bitcoin.defaultremotedelay=144

When I try to open a channel using lncli, I get the following error message:
$ lncli --sat_per_vbyte=1 --remote_csv_delay=144 --node_key=XXXXXXXX --local_amt=1500000 --push_amt=750000
[lncli] rpc error: code = Unknown desc = CSV delay too large: 180, max is 144

Apparently, it bases its CSV delay value on the size of the channel. Is there any way to override that default? None of the settings or parameters I have tried has worked.

It is difficult to answer this without more information about your setup and your channel partner, but I suspect this is because your channel partner wants a delay of 180, but you've set a maxlocaldelay of 144.
Per the sample conf file from LND:
; The maximum number of blocks we will limit the wait that our own funds are
; encumbered by in the case when our node unilaterally closes. If a remote peer
; proposes a channel with a delay above this amount, lnd will reject the
; channel.
; bitcoin.maxlocaldelay=2016


text:
Protocol version message is ignored by node
I'm trying to send a protocol version message to my node on port 8333. I found this site that explains how to send a version message from the command line. I have a C++ app that is creating the message, but I thought I would try sending it from the command line before trying to do it in my C++ application.
I'm on a local network sending the message from 192.168.1.44 to the node at 192.168.1.47. The node is running Bitcoin Core 23.0.
According to the site linked above, the following command can be used to send a version message and print the verack that it receives. Instead, it pauses for a few seconds and prints nothing.
echo -en "f9beb4d976657273696f6e00000000005a000000365c501771110100010000000000000091211e6300000000010000000000000000000000000000000000ffffc0a8012f208d010000000000000000000000000000000000ffffc0a8012c208daabbccddeeff11350454657374d87f0b0000" | xxd -r -p | nc 192.168.1.47 8333 -i 2 | xxd

Here is a breakdown of the most recent message I've tried to send:
f9beb4d9
76657273696f6e0000000000
5a000000
365c5017

71110100
0100000000000000
91211e6300000000
010000000000000000000000000000000000ffffc0a8012f208d

010000000000000000000000000000000000ffffc0a8012c208d
aabbccddeeff1135
0454657374
d87f0b00

00

Here is what each of the above lines is supposed to be:
Mainnet byte sequence
"version" padded with zeroes
Length of payload (little endian)
Payload checksum (1st 4 bytes of double SHA256 converted to little endian)

Version 70001 (little endian)
NODE_NETWORK service
Timestamp (little endian)
Recipient address/port = 192.168.1.47:8333

Sender address/port = 192.168.1.44:8333
Nonce (random)
User agent = "Test"
Last block received = 753624 (little endian)

Relay = false

My bitcoin.conf file contains:
txindex=1
server=1
rpcbind=192.168.1.47:8901
rpcallowip=192.168.1.44
rpcuser=username
rpcpassword=xxxxxxxx

Is there something that needs to be added to bitcoin.conf?
Is there something wrong with the version message I am trying to send?
What else could the problem be?

Try adding "debug=net" to your bitcoin.conf, restart bitcoind, try your command again, and see if anything relevant appears in the debug.log file.

It added a line in debug.log that looks like this: 76890:2022-09-11T19:16:25Z connection from 192.168.1.44:36780 accepted. However, it did not return a verack to the command I ran on the command line. I also noticed that while the command was waiting, an Unroutable Inbound peer with the same ip address appeared in bitcoin-qt and disappeared when the command finally finished.

Looking at some line in debug.log that came after that, I see a Wrong checksum message that shows the same 4-byte checksum that I sent. Going to look at it more carefully in a bit, but that's a big clue.

FWIW, the phrase "1st 4 bytes of double SHA256 converted to little endian" is meaningless. SHA256 outputs 32 bytes, the first 4 of those are the checksum. Bitcoin does in some places interpret the SHA256 output bytes as numbers (in particular, in block hashes when determining PoW), but there are no numbers involved here - just bytes.

And that was my incorrect assumption, that those 4-bytes was interpreted as a number and needed to be converted to little endian. Commenting those lines out fixed the problem.


text:
What does Wasabi Wallet connect to when it starts up, and why does it seem to ignore my settings?
Wasabi Wallet 2.0.2.1
My goal is to connect the Wasabi Wallet to my Bitcoin Core node running on a different machine on my local network over IPv4. But it seems like Wasabi Wallet connects to its own set of nodes and ignores my settings.
In the Bitcoin tab of the Settings window, there is a field called Bitcoin P2P Endpoint. The documentation says:

If you have a Bitcoin full node already on a remote computer, then
Wasabi Wallet can use this too. In the Bitcoin settings, specify the
local IP address and port or the Tor onion service of your full node.

I assume, since they are talking about connecting to a remote computer, that they are referring to the local network when they say I should specify the local IP address. However, the example they show is this:

The documentation also says:

Wasabi will show up as one of the connected peers while it is
downloading a block.

But I never see it in my peer list.
When I enter my node's IP address and port 192.168.1.27:8333 into this field, the wallet appears to start up just fine, with a message saying Downloading and processing Bitcoin network data.
However, I can change that field to something like 192.168.1.23:1111, an address that does not even exist on my network, and when I restart the wallet I see exactly the same message.
There is a small white circle with a checkmark in it in the lower right corner of the main window, and when I hover over that circle, it says:
Tor is turned off
Backend is connected
Peers 11 connected

Where are those 11 connected peers coming from? How can I know if one of them is mine when I don't see it as a connected peer? Is there a way to control which peers the wallet connects to?

From the Wasabi docs:

There are two ways to confirm that your Wasabi client is connected to
your own full node.
First, in the Wasabi logs. Once you receive a transaction Wasabi
downloads the block containing that transaction from your node, and in
the logs you should see: Block acquired from local P2P connection.
Second, by checking the connected peers inside your full node. Wasabi
will show up as one of the connected peers while it is downloading a
block. You can check this in the Bitcoin Core / Knots GUI by clicking
on Window -> Peers. During the period when Wasabi is fetching a
block, it will show up in the User Agent column. Alternatively, you
can use the Bitcoin RPC call bitcoin-cli getpeerinfo and see the
Wasabi client listed.

Do you see Block acquired from local P2P connection in your Wasabi logs when you receive a transaction?
Note that the message is logged only when a block was fetched, and blocks are fetched only when needed, which means that you have to have a transaction in a new block if you want wasabi to get the block from somewhere.
Also make sure that you don't have any whitebind rule in bitcoin.conf that prevents inbound connections.

Where are those 11 connected peers coming from? How can I know if one of them is mine when I don't see it as a connected peer? Is there a way to control which peers the wallet connects to?

AFAIK the peers are used to broadcast your transactions when you send.
No there is no way to control which peers the wallet connects to.


text:
Simple Address check via API
So I have a wallet with thousands of addresses, I want to know how can I check the blockchain whether or not a transaction has been made to one(or another) of the addresses?

There are several API services that allow bulk address queries.
For example smartbit's API takes up to 1,000 addresses with their v1/blockchain/addresses endpoint which will return details about each address sorting by the highest balance first.
Example GET request:
https://api.smartbit.com.au/v1/blockchain/addresses/1DuMuchPBGNoi5b9JmpreZ2L5EpuMiJdyc,1N75aWck3TFPorTvSgdzLUttY8uddqTAFZ,161UqtBktXJMzcg2zxBGMiHgnVrtH78Amx,19eK34996XoXPgpranrUVSPLmkxzowt8ox
Link to API docs: https://www.smartbit.com.au/api
EDIT: Smartbit API is permanently offline
EDIT 2: Blockcypher offers a similar API service.
https://www.blockcypher.com/dev/bitcoin/#address-balance-endpoint

I think you mean .../address/<addr1>,<addr2> since .../addresses/ just returns the richest people no matter any parameters.

You have two options :

Request on one of block explorer platforms which will let you query on blockchain on their server. Check : https://blockexplorer.com/api-ref

Example request :
$ curl https://blockexplorer.com/api/addr/19SokJG7fgk8iTjemJ2obfMj14FM16nqzj
{"addrStr":"19SokJG7fgk8iTjemJ2obfMj14FM16nqzj","balance":0,"balanceSat":0,"totalReceived":112.91089695,"totalReceivedSat":11291089695,"totalSent":112.91089695,"totalSentSat":11291089695,"unconfirmedBalance":0,"unconfirmedBalanceSat":0,"unconfirmedTxApperances":0,"txApperances":364,"transactions":["a2afb522edeba67ae593c683154da45b231d59ffccd18806cec38ecd21994a2d","28ccc7fe617451a4d15b8cea64a6ac222600e2877073ba543d83225a354975ac","950239654cd47d2b53f98bdf250cfbf516e1a9eaf87944ee8afac603a9cb61fc","4daa82997cb86b6f75089ad19eddf518b77a4d88a72920efbab6439914a2183b","27b6dc933a9eee548d5b40574c16e9e29a907e9a85a51c2545a60a0833a0f441","cacc6ded99959ff8310b18e1052e05a4aa9fe8c4c7f9651318fbbe3fcd5a16ab",...}

If you dont want to rely on any 3rd party services; install bitcoind (or similar bitcoin client), import your addresses in watch-only mode and query using provided RPC calls. http://chainquery.com/bitcoin-api/listtransactions

First option is simpler as you dont need to download GBytes of chain data. Second option is better as you dont rely on some platform.

1: are block explorers free to use?

Can you point me to one that meets my needs?

yes. mosty such services charge you when you want to make transaction. i've updated my answer.


text:
Electrum console commands?
I need 2 commands for electrum
To create X amount of addresses
to export those addresses to word or just be able to copy them

x=10

for thing in range(0,x): wallet.create_new_address()

listaddresses(True,False,False,False,True)

A guide about console commands is here. Thanks to @RichApodaca for pointing that out.
Another resource is the code itself. For example you can see the function declaration for listaddresses here which tells you what all those boolean args are for. In the above case it only outputs unused addresses in the external (receive) chain.

Can you add some explanation/links to official documentation? The code alone, while possibly correct, is not a helpful answer

@RaghavSood This page talks about how to use the console, and documents built-in functions: https://bitzuma.com/posts/an-introduction-to-the-electrum-python-console/ You can enter the code into the console.


text:
Bitcoind walletnotify
Does wallet notify performs actions also on old transactions? In case that my node went offline for some reason, Once its back online I will get notifications from wallet notify for the transactions that I missed when it was offline or not?
Tnx in advance!

Yes, It will send a notification once a transaction added to your bitcoin core wallet. so, when you start your node again any transactions belongs to your wallet you should get a notification for.
-walletnotify=<cmd> Execute command when a wallet transaction changes (%s in cmd is replaced by TxID)


text:
Import private key ripple
Is there a way to import private key with rippled?
Same as bitcoin core impoertprivkey with RPC calls?
Tnx

Looking through the rippled API documentation it would seem that there is no import private key call - https://developers.ripple.com/rippled-api.html
However other ripple clients can do this task.  I know of the https://toastwallet.com/ as a stand alone Ripple wallet but it seems some people have had issues importing private keys.
https://gatehub.net/ is another alternative for a desktop ripple client and in here you can import the private keys and import addresses into your wallet.
Your private key is your account. You can access your account from any wallet that is a portal to the xrp ledger.
Gatehub will easily let you restore your private key. People have issuings restoring with toast cause the toast backup requirement.


text:
How to get Coinbase Text for newly found block
Websites like blockchain.info and btc.com give Relayed By information to find who found the block. I can see coinbase text in the website https://coin.dance/blocks. Is it possible to get that information using bitcoin-cli ?

Certainly. Use bitcoin-cli getblock <hash> 2 to get the full details of a block (you may want to pipe the output to less as there will be a lot of output). The first transaction in the block (the first transaction in the array tx) is the coinbase transaction. In there, there is a field labeled coinbase. That contains the hex of the bytes of whatever data miners are putting there in the transaction. Drop the hex into whatever Hex to Ascii converter you want and you will get text. Note that some miners may not include readable text in their coinbases.


text:
Bitcoin New Block Event Trigger
I want to know when a new block is discovered, I am watching debug.log to see if it has changed, I know there is a new block if the line contains "UpdateTip: new best". Is there a better way to do this?

bitcoind offers a zmq hook which you can use to receive notifications on new blocks and transactions.

You can use blocknotify option, Execute command when the best block changes, read more here https://en.bitcoin.it/wiki/Running_Bitcoin


text:
how to get bitcoind to launch on startup/reboot? ubuntu 16.04
Is there an easy way to ensure that bitcoind restarts on system reboot? I tried placing the systemd service file in /etc/systemd/system but that didn't seem to work... thanks in advance

Try https://askubuntu.com/ if you're facing issues with the systemd script, it's not bitcoin specific, and those guys are a lot better at the whole linux side of things

After putting the systemd file in /etc/systemd/system, make sure that your systemd file is set up to work with your installation (binary path, datadir path, etc. are correct). Then run sudo systemctl enable bitcoind.
Alternatively you can do edit your crontab with crontab -e and add the line
@reboot bitcoind

do you really need to put the executable in the system folder? Update path and add the root folder for the daemon so it can be updated easier and not forget to copy everything over...


text:
Find all transactions for a bitcoin address
I'm looking for a way to query all transactions related to a particular bitcoin address - I periodically need to find all transactions for numerous addresses.
I've seen info about bitcoind searchrawtransactions, although it looks like this may no longer be supported?
Any recommendations?

To use getrawtransaction to lookup any transaction, you have to have the -txindex flag set, so that all transactions are indexed. But, you have to know the txid.
getrawtransaction "txid" ( verbose "blockhash" )

NOTE: By default this function only works for mempool transactions. If the -txindex option is
enabled, it also works for blockchain transactions. If the block which contains the transaction
is known, its hash can be provided even for nodes without -txindex. Note that if a blockhash is
provided, only that block will be searched and if the transaction is in the mempool or other
blocks, or if this node does not have the given block available, the transaction will not be found.

I would recommend using an api such as blockchain.info
Single Address

https://blockchain.info/rawaddr/$bitcoin_address
Address can be base58 or hash160
Optional limit parameter to show n transactions e.g. &limit=50 (Default: 50, Max: 50)
Optional offset parameter to skip the first n transactions e.g. &offset=100 (Page 2 for limit 50)

{
    "hash160":"660d4ef3a743e3e696ad990364e555c271ad504b",
    "address":"1AJbsFZ64EpEfS5UAjAfcUG8pH8Jn3rn1F",
    "n_tx":17,
    "n_unredeemed":2,
    "total_received":1031350000,
    "total_sent":931250000,
    "final_balance":100100000,
    "txs":[--Array of Transactions--]
}
What you want is in the txs property of the returned json object.

Thanks for the info, but i’d prefer not to rely on a third party, i’m looking to do this in-house. Also, I will have not have the txids, I’ll need to query with the address as the parameter

Then I think you'll have to write your own block parsing scripts to search the entire blockchain.

This API works for me: https://chain.so/api/v2/address/BTC/1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
Here is c++ code to get all utxos for an address:
https://github.com/SatoshiFantasy/--skillSale/blob/c2d31bda47f4e0223572343b54f9fd0d3211f66e/share/fantasybit-core/bitcoinapi.h#L63
https://github.com/SatoshiFantasy/--skillSale/blob/f32b482c35667109755a538a889e7307f405fc3d/share/fantasybit-core/RestfullService.h#L69

This (like other APIs) is limited to 50 per address. Can you share how to get all of them?


text:
Whats the difference between "txid" and "hash" - getrawtransaction bitcoind
Sometimes the txid key is the same as the hash key in the return of getrawtransaction, sometimes different. I'm trying to understand more about these...
What are the differences, and why are they sometimes identical and sometimes different?
Example - identical in this testnet tx:
bitcoin-cli -testnet getrawtransaction c3f11d1708ac20eff9137d4eadd62dd99d71ce22dc51bc51d4e5b83958d9596d 1
Example - different in this livenet tx:
bitcoin-cli getrawtransaction df2fd78e42590f301b5174e7d6665887380ad1f49a4688a0f8adffa0829855cc 1

Summary: The difference is when the tx is a segwit tx, the calculation of hash does not include the witness data, whereas the txid does.
The definition of transaction hash remains the same as txid for non-witness transactions (non Segwit). The reason the mainnet tx has a different hash than the txid is because it is a witness transaction. If you run bitcoin-cli help getrawtransaction it will show you:
Result (if verbose is set to true):
{
  ...
  "txid" : "id",        (string) The transaction id (same as provided)
  "hash" : "id",        (string) The transaction hash (differs from txid for witness transactions)
  ...

Segregated Witness
The following is from BIP 141.
Note that the BIP states, "signature data is no longer part of the transaction hash."
Transaction ID
A new data structure, witness, is defined. Each transaction will have 2 IDs.
Definition of txid remains unchanged: the double SHA256 of the traditional serialization format:
[nVersion][txins][txouts][nLockTime]

A new wtxid is defined: the double SHA256 of the new serialization with witness data:
[nVersion][marker][flag][txins][txouts][witness][nLockTime]

Format of nVersion, txins, txouts, and nLockTime are same as traditional serialization.
The marker MUST be a 1-byte zero value: 0x00.
The flag MUST be a 1-byte non-zero value. Currently, 0x01 MUST be used.
The witness is a serialization of all witness data of the transaction. Each txin is associated with a witness field. A witness field starts with a var_int to indicate the number of stack items for the txin. It is followed by stack items, with each item starts with a var_int to indicate the length. Witness data is NOT script.
A non-witness program (defined hereinafter) txin MUST be associated with an empty witness field, represented by a 0x00. If all txins are not witness program, a transaction's wtxid is equal to its txid.


text:
Bitcoin-cli how to createrawtransaction without spending entire input?
Is there any possible way to create a raw transaction using Bitcoin-cli createrawtransaction API that doesn't require spending the entire input?
What I'm doing now is consuming that entire input sending 0.01 to the address specified and sending the change back to the address I'm withdrawing from.
If I deposit 0.5 BTC to my wallet and withdraw 0.01 is there any method to be able to work with my 0.49 BTC I have remaining without having it consumed entirely and being sent to the change address because then I'm stuck waiting for it to confirm and it gives off the impression my wallet balance is 0 when it's really 0.49 BTC.

Is there any possible way to create a raw transaction using Bitcoin-cli createrawtransaction API that doesn't require spending the entire input?

No.  It's an inherent feature of the Bitcoin protocol that inputs must be spent entirely or not at all.  It's a binary state: spent or unspent.  There is no "partially spent".

What I'm doing now is consuming that entire input sending 0.01 to the address specified and sending the change back to the address I'm withdrawing from.

Yes, that's what you have to do (though for privacy reasons it is better to send the change to a freshly generated address instead).

If I deposit 0.5 BTC to my wallet and withdraw 0.01 is there any method to be able to work with my 0.49 BTC I have remaining without having it consumed entirely and being sent to the change address

Nope.

because then I'm stuck waiting for it to confirm and it gives off the impression my wallet balance is 0 when it's really 0.49 BTC.

Yes, that's something you just have to live with.  However, you don't necessarily have to wait for the transaction to confirm before spending the change.  But the second transaction won't confirm until after the first one does.


text:
Why are the inputs of Bitcoin transactions signed?
This is my understanding of what a transaction looks like:
inputs:
  input0:
    txid: <funding tx0 TXID>
    outputID: <output ID of UTXO in the funding tx0>
    scriptSig: <pkhash_redeemer> <sig0_redeemer>
  input1:
    txid: <funding tx1 TXID>
    outputID: <output ID of UTXO in the funding tx1>
    scriptSig: <pkhash_redeemer> <sig1_redeemer>
  ...
outputs:
  output0:
    scriptPK: <scriptPK for new UTXO>
    amount: <amount for new UTXO>

Where the signature <sig_redeemer0> is over:

<funding tx0 TXID>
<output ID of UTXO in the funding tx0>
funding transaction's Pub Key Script
<scriptPK for new UTXO>
<amount for new UTXO>

I've read much that states things along the lines of: "the signature is over the entire transaction" or "the signature signs all the inputs and outputs". However, there are a few points of confusion I have:

Do multiple inputs necessitate multiple signatures? Or is my example wrong?
Why do we need to sign the inputs of the transaction?

If the inputs aren't signed, that means the following are left unsigned:

txid of funding transaction
<output ID of UTXO in the funding tx>
sequence number (?)

If all outputs are signed, the amounts and scriptPubKeys of all UTXOs from funding transactions are fixed. An attacker might be able to change the inputs to the redeeming tx, but they are only unlockable if the inputs remain the same, so an attacker can't use an arbitrary input.
Any help would be appreciated! Thanks

There may be multiple utxos that the same script would unlock.  The most common example is two transactions that both pay the same address.  If inputs weren't signed, an attacker could replace one input utxo by a different utxo that pays the same address, and this would be bad.

So if I understand correctly, if A creates a tx that pays B 1BTC (UTXO 1) and returns 1BTC of change back to A (UTXO 2), B could: (1) Redeem the 1BTC locked by UTXO1, (2) Redeem the 1BTC locked by UTXO1 again, since there's no explicit mapping between inputs and outputs in the tx. If A attempts to redeem UTXO2, they won't be able to, since all the inputs are already redeemed.

That particular example won't work; since the transaction in question has outputs totaling 2BTC, if B edits it to use UTXO 2 as the input (whose value is 1BTC), it won't be valid.  I'll add an answer explaining what I have in mind.

There may be multiple utxos that the same script would unlock. The most common example is two transactions that both pay the same address. If inputs weren't signed, an attacker could replace one input utxo by a different utxo that pays the same address, and this would be bad.
Consider the following scenario.  Alice has received two payments to her address 1Alice, both in the amount of 1 BTC: one with txid 234abc in the amount of 1 BTC, and another with txid 567def.  She wishes to pay 0.5 BTC to Bob, so she creates and signs a transaction using the 234abc utxo as input, with the following outputs: 0.5 BTC to the address 1Bob, and 0.4999 BTC to some "change" address, 1AliceChange.  (This leaves a transaction fee of 0.0001 BTC.)
After this transaction is broadcast and confirmed, Bob modifies the transaction so that the input is 567def instead.  The scriptSig works equally well for every transaction that pays 1Alice (they all have the same scriptPubKey), so this new transaction is also valid.  Bob broadcasts it and effectively steals an additional 0.5 BTC from Alice, which she never intended to give him.
This only works as long as 567def has the same value, or greater, than 234abc, but that's not much of a restriction.  (If 567def has a greater value, say 10 BTC, then Bob's new transaction still only returns BTC 0.4999 to 1AliceChange, so it effectively has a transaction fee of BTC 9.0001.  Any miner would be extremely happy to confirm this transaction; indeed, maybe a miner will perform this attack even if Bob doesn't care to.)

Thanks! That clarifies things a lot. I'm not sure if this is better left to another question but: Why then, are the outputs signed? I think I understand how a miner could exploit this, but not necessarily Bob. If outputs are not signed, then  the scriptPK and amount of each output can be changed by a malicious actor. A miner could: (1) whenever they receive a tx, arbitrarily add/remove scriptPKs (so censor redeemers and collect larger fees) and (2) change outputs to be addresses they control. How could Bob exploit this?

Actually, I think I understand how Bob could take advantage of this. For any posted transaction tx0, Bob could redeem from it with a new tx1 by changing the scriptPK that locks the outputs of tx0 such that the scriptSig  can give Bob the UTXO. Is this understanding correct?

@acnalb: Yes, that's right.  If outputs are unsigned, then any attacker (Charlie) can modify any transaction to pay Charlie's address instead of the address that was originally intended.  This would make the whole system entirely unusable.

So what exactly the scriptSig signs? A complete single 'prev_out'?


text:
Checking signature only vs. P2PKH
It is clear to me why it's potentially unsafe to only use a check on == in scriptPubKey. For one, not verifying a signature in the redeem script means that someone could impersonate the redeemer. From the Bitcoin developer guide:

This lets the pubkey script verify that Bob owns the private key which created the public key.
Bob’s secp256k1 signature doesn’t just prove Bob controls his private key; it also makes the non-signature-script parts of his transaction tamper-proof so Bob can safely broadcast them over the peer-to-peer network.

Why would it be unsafe to only use a check on V(sigA, pkA, m={txprev_txid, txprev_outid, txprev_scriptPK, tx_scriptPubKey, tx_amount}_skA) == 1? It seems like this is what we're doing in multisig. I.e., have a ScriptSig that consists only of (a) signature(s) instead of sig and pk like in P2PKH.
Why don't we just check signatures instead of checking both pkhash and a signature?

Let's start from the beginning.
p2pk
If you look at the initial blocks on the chain, you'll notice that the coinbase transaction output goes to a pay-to-pubkey lockscript (also known as output or encumberment)
A p2pk locking script is simply PUSH <pubkey> OP_CHECKSIG. To spend this output, one simply needs to provide a valid signature. The scriptsig would contains PUSH sig, which when combined with the locking script produces PUSH sig PUSH <pubkey> OP_CHECKSIG. If the signature provided is valid for the given pubkey, you can prove both ownership of coins and intent to spend in a single move.
p2pkh
p2pk was superseded (perhaps not the correct term, since Bitcoin 0.1 contained support for both p2pk and p2pkh) by pay-to-pubkey-hash. This has a couple of advantages over the vanilla p2pk. For one, it reduced the size of the locking script. Since the utxo set must contain the locking script for validation purposes, this results in direct space savings. For another, hashing the public key adds a layer of protection against any future ecdsa key recovery attacks that may be developed, as you would also need to break the HASH160 operation to recover the public key first.
Using p2pkh comes with some additional complexity. The locking script now takes the form of OP_DUP OP_HASH160 PUSH <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG. Since we no longer have the actual public key in the script, an unlocking script must prove two things:

That it holds the correct private key
That it intends to spend the coins

For 1, we must prove that the public key hash in the script corresponds to the public key hash of the key used to perform the signature. For 2, we must verify that the signature is valid against that public key.
To achieve this, the unlocking script takes the form PUSH sig PUSH pubkey. When combined with the locking script, this yields PUSH sig PUSH pubkey OP_DUP OP_HASH160 PUSH <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG
Now, during evaluation, the pubkey is duplicated. The duplicate is hashed and compared against the hash stored in the locking script. If the hash is valid, the signature is validated against the provided public key. This flow ensures that the same public key is used signature verification and the comparison against the hash in the locking script, thus fulfilling both requirements.
p2sh
pay-to-script-hash was developed to provide a standardized way of using more advanced bitcoin scripts. For this example, let us focus on the multisig p2sh. A typical, 1 of 2 multisig p2sh output's locking script will be similar to OP_HASH160 PUSH <hash> OP_EQUAL. This doesn't contain any public keys, or even a signature checking op code, so what's going on here?
The secret lies in the redeem script. Each p2sh address is backed by a redeem script, and the hash value in the locking script is a hash of this redeem script.
When spending from a p2sh address, you must provide an unlocking script that validates against the redeem script, and the redeem script itself. For our 1of2 multisig address, a redeem script looks like OP_1 PUSH pubkey1 PUSH pubkey2 OP_2 OP_CHECKMULTISIG. This entire script is hashed for the locking script. Note that since the pubkeys contained in this script are already hashed as part of the entire redeem script, we do not need to hash them separately, as we do with p2pkh.
When spending the output, we would then provide: OP_0 PUSH sig PUSH redeemscript. This results in a final script of  OP_0 PUSH sig PUSH redeemscript OP_HASH160 PUSH <hash> OP_EQUAL. During evaluation:

The unlocking script and locking script are combined. This results in the signatures and the serialized redeemscript being pushed to the stack. Note that since PUSH redeemscript treats the redeemscript as normal data, the op codes inside the redeem script are not interpreted as op codes in this step.
The serialized redeem script is hashed and validated against the locking script
The signatures are validated against the popped stack, which contains the serialized redeem script without its push op code, and thus interprets it correctly as a bitcoin script.

Following this order of operations provides the same guarantee as the p2pkh output - That the transaction intends to spend the coins, and that the keys involved are the same keys that were committed to during the coins' locking.

In an input spending a P2PKH output, if you were to only check that the signature is a valid signature with the public key in the input, then an attacker could use their own public key and produce a valid signature and thus a valid transaction under this model. The public key is not retrieved from the output script nor is it provided by the output; rather it is provided in the input. Thus you must ensure that the provided public key is indeed the correct public key, hence the check that it's hash matches the hash provided in the output.
In multisig, the public keys are provided in the input, in addition to the signatures. They are in the redeemScript. To avoid the same issues (of the attacker providing their own public keys), the redeemScript is hashed and the hash is in the output script. There is a comparison there to ensure that the redeemScript is the correct script.
There is an output type where you do just provide a signature. This output type is a script where the public key is in the output so there is no need to provide the public key in the input. Only the signature is needed. This is known as a Pay to Pubkey (P2PK) output. These are not widely used because public keys are large and this makes it harder to give them out.

I see. I think I was confused by the Bitcoin Developer Guide. I understand that P2SH multisig has the pk's in the redeemScript input. I was confused by this section, which makes it look like the scriptSig only contains signatures: Pubkey script:   [B pubkey] [C pubkey...]  OP_CHECKMULTISIG; Signature script: OP_0  [B sig] [C sig...]. Does this mean that this scriptPK and scriptSig are not actually used in practice? But rather the P2SH multisig?

In practice P2SH multisig is used. Having the multisig in the output (known as bare multisig) has almost never been used.