text:
Why would anyone sell a Bitcoin miner instead of just mining themselves?
Every time I have asked Bitcoin experts about buying a "cloud mining" account, that is, paying fiat money to a company for them to mine Bitcoin for me, I get the response that it's a scam. "Why would they want to give you any Bitcoin when they can just mine for themselves?" is the reasoning given.
But then doesn't the same logic apply to actually buying a miner and "mining at home yourself"? Why would anyone sell such a machine when they can just hook up another one to their massive warehouse of miners and get more Bitcoin for themselves? Why bother dealing with charging fiat (or Bitcoin!) from annoying customers, having to deal with shipping and all that stuff? Why not just... mine themselves?
It seems like the very same thing to me. I just don't see any way for me to mine Bitcoin which would actually be profitable or make sense.

Why would anyone sell a house when they could just live in it themselves?

"In a gold rush, the only people getting rich are those selling shovels."

I think you might be missing the possibility that these companies don't have any interest in bitcoin.  They are just making things that people want to buy.  Kind of like how heroin manufacturers aren't really into shooting heroin.  They just want money.

@WillO That's not really a good analogy here. If I have 2 bitcoin miners they are twice as useful to me (or not as the case may be) as 1 miner. If I have 2 houses, only one of them is useful for living in, so I am forced to find a different use for the other one. A better analogy would be "why would anyone sell a house when they can just rent it out?".

@JBentley:  If what you are saying were true (and true when you replace "2" with "3", "4", etc.) then nobody would ever own a nonzero finite number of Bitcoin miners.  The fact that someone owns three miners and not a fourth tells you that the fourth miner is not as useful to that person as the third, presumably due to nonlinear costs of space, attention, energy, etc.

@WillO I'm not sure what that has to do with my explanation for why your analogy doesn't work.

'Why would anyone sell hammers when they can use them to drive nails themselves?"

The main capital cost of mining is hardware.  The main operating cost of mining is electricity.  The best place to mine is somewhere with very cheap electricity.  The best place to make mining hardware is a company full of ASIC experts.  Almost certainly the ASIC manufacturers could not mine competitively on the land they own because they did not select that land to be in a place with particularly cheap electricity.  To start mining, the ASIC manufacturer would need to invest in land somewhere where mining was profitable.  This is now a business venture and a risk.

I think there's a misunderstanding here - I assumed on reading that the question talked about used/pre-owned mining rigs. In which case the question remains valid. Someone has purchased and used the bitcoin miner. If it's no longer profitable for them, why would it be profitable for me?

@BrydonGibson It's not that it's not profitable for the seller, it's that more profitable options may now be available to them.  Upgrading a suite of mining rigs requires a large capital outlay.  This can increase the profitability of a miner's setup, but also bakes in a few years worth of risk (payback time for the capital outlay).  Buying a used, less efficient miner comes with a lower initial capital cost, giving the buyer a lower risk and shorter payback time than getting into mining with very expensive cutting edge rigs.  It's more about barrier to entry and relative risk tolerance.

@J... I think the question points out a valid fallacy still. If the seller owns a machine, and running that machine is profitable, in almost all cases, it's a shortsighted idea to sell it. If it's not profitable to run it, then there's very little reason for the buyer to buy it (short of speculating that minin will once again become profitable from a market shift). If a (used) machine is being sold, the seller is either throwing away profits for short term gain, or the buyer would be stupid for buying a money pit.

@BrydonGibson You can buy a bond with a 3% yield.  You can also buy a bond with a 5% yield.  Why would you buy a 3% bond when you can also buy a 5% bond?  A similar logic applies here.

@BrydonGibson Consider also that the buyer of the used miner may have access to even cheaper electricity than the original seller.  The seller may find investing in the newest equipment to be more profitable for them, but if the buyer has access to cheaper electricity than the seller then the equipment itself represents two very different profit equations for both parties.

All valid answers to the original question. The intent of my comment was to provide additional context as it looks like the "selling used equipment" perspective never got answered. This question (and the answers) are just helping the inexperienced heed caution when getting into mining

The difference is that with cloud mining, all you are doing is lending the company money. And you are expecting them, for no rational reason, to pay you back an interest rate higher than they would have to pay if they took out the worst loans in existence.
In the case of cloud mining, literally everything is done by the company. All they are doing is borrowing money from you and you are somehow expecting that the will pay you more than the normal amount of interest borrowers pay to lenders. That's obviously ridiculous.
In the case of buying a miner, the company just provides you a physical product that they manufacture. It is then up to you to maintain it, to provide it power and cooling, to maintain its internet connection, and to take on risk over months that the value of the cryptocurrency it produces will drop. That is nothing like just lending money to a supposed turn-key profit generator that requires you to do nothing but kick back and collect profit.
Why would companies that make miners have access to cheap power and cooling? Why would companies that make miners have facilities that can house them?

"Why would companies that make miners have access to cheap power and cooling?" Corruption?

@VargaD They could have that access. I think the point being made in the final paragraph here, though, is that they don't automatically have that access purely by virtue of manufacturing miners.

The comparison to commercial lending is way oversimplified. The reality is that your average low-interest commercial lender (a) may not lend money at all on such a business, (b) if it lends, will either lend a very small amount or will impose other onerous conditions such as security, and/or (c) will in any event be unlikely to lend 100% of the borrower's capital needs. The forces of supply and demand mean that such a borrower will have to pay higher rates if they want more favourable borrowing conditions. There's nothing "obviously ridiculous" about this.

@JBentley There are two things obviously ridiculous about this. First, the rates are even higher than the rates of such loans. Second, there are no onerous conditions. You've pointed out precisely how ridiculous it is.

@user253751 It varies. The more obvious scams claim to pay you a fixed interest rate. The less obvious scams (and legitimate, but pointless offers) don't guarantee you anything but a particular hash rate.

There's a couple of reasons I can think of:

They might not think mining is profitable and are simply looking to sell hardware and treat BTC miners as a good target market, media attention probably means there's a lot of naive users that believe they can make huge profits by mining themselves.

Once you scale up mining beyond a certain limit there can be significant capital costs. For example if you live in an apartment they'll be limits on the total power consumption the utility can provide and space constraints. Overcoming those by say setting up something in a larger / more industrial area will have a large up-front cost and the inconvenience of moving.

Also on a global scale whatever mining hardware a single individual / company might sell is pretty much a drop in the bucket, so some probably use their expertise to sell some mining hardware to make some additional profit regardless of how BTC travels. Selling the hardware involves minimal risk and can be done with minimal infrastructure.

Selling hardware is a less risky enterprise than mining bitcoin.  The manufacturer knows exactly what their profit margins and unit costs etc are and has a more or less guaranteed result.
People running miners do not.

Come to think of it, I bet it's substantially more profitable these days to sell mining hardware, than to be the owner of said hardware.  Especially today with prices hiked because of the chip shortage.  It could easily be a better business to sell hardware to people who think it prints money, than to actually believe in it and run up your power bill in blind hopes that you'll win the lottery.  And BTC is very much a virtual lottery, but compare it to a physical one...  Who gets more rich?  The average lottery player?  Or the guy that sells the paper stock used for lottery tickets?

There is great difference for large companies between earning X money now or earning X + 20% in two years' time: The former lets them invest for the next miner without waiting years, because waiting a few years to continue innovating. Waiting a few years can cause them to lag behind their competitors for many more years to come. Besides, selling miners has very low variation depending on Bitcoin's price, so they reduce the risk for themselves. Also, mining is a low-effort investment, while as a large BTC company they might have advance knowledge about many price changes, which could allow them to earn more money holding than mining.

There are quite a few oportunities (or, at least, an impression of oportunities) to be more efficient miner than the mining hardware business themselves.

You may have an access to cheaper (or free, or even stolen) electricity
You may live in favorably cooler climate
You may be one of those gambling types that just want to bet
You may have enough (spare?) manpower to run the mining setup
You may have less pressure from the shareholders for reliable and/or immediate profits
etc, etc...

That's why both you and the manufacturer may be better off in your particular roles. This makes selling/buying a mining hardware profitable for both sides.

This is an excellent question, and in fact there have been schemes around companies that did both - they used the mining hardware and sold it.
I don't recall the name of any company that used this scheme; it must have been around 2015 or so.

Advertise the sale of bitcoin mining rigs. Prepayment required.
Build the mining rigs.
Run the mining rigs themselves for testing purposes. A couple months, up to a year or so of "testing".
Ship the mining rigs after the complaints got too loud.

Customers lost out twice. First, missed a year or so of bitcoin mining opportunities.
And second, by the time they finally received the mining rigs, that was outdated technology and could no longer compete with more up-to-date miners.

tl;dr–  If you wanted to invest cash in gold-mining, would you buy a pickaxe for yourself or pay someone else to mine for you?  Or, would you buy stock in a gold-mining company?

This is why investors buy stakes in companies.
Consider three scenarios for using your cash to mine cryptocurrency:

Do all the mining yourself.Buy your own hardware, use your own space and electricity, do all the work yourself.

Hire a service to do the mining for you.Instead of doing it all yourself, outsource it to professionals.  You should enjoy huge economics-of-scale, while you pay them their cut.

Buy a stake in a mining company.Someone creates a mining-company, using their cash to buy/operate miners.  You give them 10% more cash to do the same, they give you a 10% cut.  Same economics-of-scale, while employees draw salary for working the whole thing.

Problems:

Individual miners are horribly inefficient.Everyone learning and doing small amounts of labor themselves is highly inefficient.  There's too much duplicated effort and too little expertise.

Hiring a service can have trust problems.If you're a customer, then they're trying to sell you something you want – not necessarily something that's best for you.

Owning a stake in a component mining-company would seem best.This is what companies are for: they do some work using their assets, paying laborers for their labor, while capital-owners (people who give them money) can buy/sell stock-shares, collect cash-dispersals from dividends, etc..
Ultimately should work out a lot like the prior case, except instead of being a customer that they're trying to get money from, you'd be a part-owner who the company would have fiduciary obligations to.  "Fiduciary Duties: Minority Shareholder Rights" (2015) looks helpful.  Also, the principal–agent problem.

Note: This isn't financial advice nor legal advice.  And I'm definitely not suggesting anyone invest in Bitcoin.
That said, if someone did want to invest money in mining cryptocurrency, investing in a good, reputable mining-company would seem like the way to do it.  Alternatively, someone could mine for themself, though that'd seem to be mixing in a hobbyist-project rather than a strictly investment-focused strategy.

Cloud mining introduces a lower entry fee into mining as you do not need to purchase the hardware. That said, many cloud companies are considered 'scams' because contracts can end abruptly without compensation. This usually happens when the BTC price increases or decreases considerably. Although there are some reputable companies around.
Cloud contract prices are variable and follow the BTC price. And, the longer the cloud contract period, the higher the profit margin. But in order to turn a profit, a cloud miner is making a bet that the BTC price will remain stable or increase.
Cloud mining, selling hardware, and mining yourself comes with risks because the profitability of all of these businesses follows the BTC price which is volatile. Professional miners use the bull and bear cycles to their advantage, and can also move rigs to where electricity is cheaper.

One possible explanation as to why companies sell their mining hardware instead of using it themselves is given by the paper "Correct Cryptocurrency ASIC Pricing: Are Miners Overpaying?" (links to a short talk about the paper, a long talk, a medium post, and the paper itself).
The authors of the paper argue that mining hardware is overpriced, meaning that manufacturers charge a price that is higher than the correct price for their hardware. They reach this conclusion by modeling the hardware as a bundle of financial options, and then applying option-pricing theory to evaluate its correct price.
For example, when looking at the Bitmain Antminer S9, the authors concluded that Bitmain's official price was higher than the correct price for most of 2016-2019:

That's a great question; here is the thing about cloud mining and ASICS.
1. CLOUD MINING
cloud mining is an act where a company pays users to use their mining software so that customers may use their machines as a proxy. Here is what doesn't make sense about the economics, who gets the money?
1.1. customers make profit
1.2. company makes profit
1.3. miners make profit
You cannot have all 3 of these groups make money, that's just not how economics works. The companies when recruiting others to cloud mine suggest that they (the miners) will earn a higher profit than mining if they mine for the cloud mining company. How can one earn more money with a company than mining the coin directly?
How can the company make a profit as well as the customer? You can't. We did an audit of NiceHash for example, and we found if you order a hashrate that was 10% of the hash unit advertised, then your order of miners will appear for a few minutes and then approximately 25% would disappear, and then reappear again 8 minutes later. This was a repeating cycle.
scammers will use fake user accounts that:
a) try to gas light you (telling you that you either made it up or that you're confused on how it works)
b) try to discredit you so that people looking up reviews to test the service will trust the users who are doing the gas lighting and discrediting.
c) defend the company to their last breath. Hint: actual people won't die hard defend a company, especially a crypto business.
2. ASIC MANUFACTURERS
this boils down to liquidity. If you engineer an ASIC and no one else on the market has one, then do you keep them for yourself or do you sell them? You sell them. Because if you were able to make an ASIC, then you can be sure that someone else is also doing the same thing and will bring theirs to market if you don't. Now you don't have the edge on mining, and you lost out on ASIC revenue.
the second part comes to availability. What would you rather have? 1 bitcoin every day, or 40,000 units of sales within a year? ASICS are very, very cheap to manufacture, especially with the hack jobs that bitmain cranks out. Old recycled hardware or unused from Chinese manufacturers, and a design that isn't compact in the slightest. It's truly built as if someone threw scrap parts together. Nonetheless, it does what it was designed to do. At 40k units, the company manufacturing these units are most likely looking at a profit of $100+ million.
There is likely around 160k ASIC units mining Bitcoin. Most of which Bitmain is responsible for. They would not be able to get to that point if they had not sold their ASIC units. It costs a lot of money to start manufacturing, but if you're pumping out thousands, then the costs get relatively cheaper by scale.
Another point to look at is that Bitmain also owns Antpool where they can get up to 4% of all bitcoins mined. They have 0% for paid per last N shares, or 4% full paid per share, of which the latter is more desirable as it takes nearly a full day to start earning revenue with PPLNS.
Ant Pool finds approximately 14% of all Bitcoin blocks.
506.3 Bitcoins Per Day * 13.8% Block Claim = 69.86 BTC per day
let's assume 30% of the miners choose the 4% option.
69.86BTC * 30% (0.30) * 4% (0.04) = 0.8384328 BTC per day.
This means that Bitmain is also earning approximately 306.02 BTC ($10,557,965) per year, all without deploying 5000 ASIC machines, and having to pay for mass cooling, mass storage, and mass electricity.

The most obvious reason I am aware of comes to mind. If you have a cloud server farm for other standard types of cloud services that isn't being utilized heavily, renting off capacity to a new market helps keep you from being under utilized and keeps you in your line of business.
It's the most basic move all businesses make, extend your product into as many markets as possible so shifts in one market don't sink your entire business.
And before anyone brings up the wear and tear aspect of taxing server resources with crypto mining and shortening their life, in a large server operation, you already have to upgrade hardware on a schedule just to keep up with improvements in technology. Having to replace a server you've otherwise never used, is a capital loss. There are only certain circumstances where that loss is useful for tax purposes and even then you don't save it's cost in tax savings, just a small percentage. You'd only choose to keep it idle if it would lower the overall rate you are taxed on everything else.

Bitcoin mining is performed with ASICs that are custom processing units that can not perform general computing tasks.


text:
Often seeing Rewinding blocks... and Loading block index
Every so often I see these error messages in Rewinding blocks... and Loading block. What is the cause of those error messages? I am using the core wallet.

I am using the core wallet.

There are several different wallet applications with "core" in their name. This answer applies to Bitcoin Core but not to Bitcore or other wallets whose name includes the word "core".

Often seeing Rewinding blocks ...

I could not find the word "Rewinding" in the source of Bitcoin core v23.
Occurrences of the word "rewind" seem to me to be associated with blockchain reorganisations. Murch commented that a one-block chain-tip change might occur once every two weeks. This is routine and not a cause of any concern,
The only similar message I can find mentioning "rewind" is these:
index\base.cpp:                    FatalError("%s: Failed to rewind index %s to a previous chain tip",
index\base.cpp:            FatalError("%s: Failed to rewind index %s to a previous chain tip",

I don't work on this code, so have no real insight, but examining the source code may help clarify what this means. For example
        // Ensure block connects to an ancestor of the current best block. This should be the case
        // most of the time, but may not be immediately after the sync thread catches up and sets
        // m_synced. Consider the case where there is a reorg and the blocks on the stale branch are
        // in the ValidationInterface queue backlog even after the sync thread has caught up to the
        // new chain tip. In this unlikely event, log a warning and let the queue clear.
        if (best_block_index->GetAncestor(pindex->nHeight - 1) != pindex->pprev) {
            LogPrintf("%s: WARNING: Block %s does not connect to an ancestor of " /* Continued */
                      "known best chain (tip=%s); not updating index\n",
                      __func__, pindex->GetBlockHash().ToString(),
                      best_block_index->GetBlockHash().ToString());
            return;
        }
        if (best_block_index != pindex->pprev && !Rewind(best_block_index, pindex->pprev)) {
            FatalError("%s: Failed to rewind index %s to a previous chain tip",
                       __func__, GetName());
            return;
        }

Since failing to rewind the index is a fatal error,  I would expect Bitcoin Core to exit. Perhaps it indicates data corruption?

... and Loading block index

Every time you start Bitcoin Core, it has to first load some parts of its database and check their integrity. It does this in stages and the informational messages let you know how far it has progressed through that process. Loading the block index is  a part of that:

On my PC "Loading block index..." is quickly replaced by "Verifying blocks..."

The message "Loading block index" occurs in init.cpp and in qt/bitcoinstrings.cpp in Bitcoin Core's source code.

Loadinh block happens when opening the QT wallet.

Thats a normal informational message that reassures people who might otherwise wonder if the application was somehow stuck or hung up. See amended answer.

Two competing blocks occur about once every two weeks, we have not had a two block reorg in a few years.

source: Stack Exchange

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

sort: votes


text:
How to solo mine to my bitcore node
Currently running a full bitcore node (v23.0.0) on Ubuntu. Chain has fully downloaded and is taking to peers.
How do I point my asic (on the same network) to solo mine to my node?
I've found a how to on the. Conf for win but not ubuntu and nothing seems to happen when I try to open/ edit config thru the bitcore gui

By "bitcore" you mean "https://bitcore.io/" - right?

If you on the other hand mean Bitcoin Core, one of these two topics might already answer your question: https://bitcoin.stackexchange.com/q/110990/5406, https://bitcoin.stackexchange.com/q/36845/5406. It may be helpful if you include the make of the ASIC you are trying to get online. (Asicminer is (was?) a specific manufacturer, so you might have meant a different tag.)

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


text:
Retweaking other person's or my own taproot address
Suppose I get a taproot address=schnorr public key from an exchange that is not tweaked using mast merkle root and I wish to tweak that public key.
This will yield a potentially different public key.

Can I do this?
If I Do this, will the exchange still recognize my deposit?
In general, can I re-tweak already tweaked public keys at will?

Thanks.

to explain my motivation more in depth, it would be cool if users could be embedding additional data on chain into the tweaks, similar to how they do now with OP_RETURN just privately

Sounds like an XY-problem. You should consider asking another question, but directly about the issue you want to solve rather than an approach you are considering. :)

meh not really. it would be still cool because 1MB of pubkeys + 1MB data in tweaks > 1MB not tweaked pubkeys

It sounds like you may be looking for sign-to-contract: https://blog.eternitywall.com/2018/04/13/sign-to-contract/. That's a scheme that allows for a signature to commit to arbitrary data, without making it larger. This has the advantage that public keys are not modified, and thus it is purely a signer-side issue.

No, this would likely lead to a loss of funds. Key tweaks are created by a recipient who tweaks a key before sharing the resulting tweaked public key in the form of a destination address.
If you tweak a foreign key, the original intended recipient would have no way of recognizing independently that that their key is associated with the new address at all, and very likely would be unable to spend the funds even when informed about the tweak.

Are you sure there's a loss of funds? Even If I reveal the tweak + original pubkey + new pubkey to the exchange?

Yes. What if e.g. the recipient uses a Hardware Security Module that can only sign for addresses they generated? The recipient specifies under what circumstances they recognize a payment. The sender has no business making assumptions how they may modify that.--If your landlord tells you that they expect to be paid by check in the mail, you don't bury a bag of quarters in their frontyard and tell them where to dig, do you?

Or worse, don't tell them where to dig, and then act all confused and surprised when they ask you about the money.

BIP341 recommends tweaking even public keys which have no intended script path, with a dummy tweak. This prevents certain attacks (though none relevant in your scenario).

You can tweak an existing public key, yes, but the address will get another meaning.

Absolutely not. Only the receiver's software determines which address they accept coins on. If you pay to anything else, you should assume the coins are sent into the void. It is possible that say an exchange can still access the coins with their keys if you inform them of the tweak, but this cannot be relied upon. The private keys may be in a hardware security module or so, which has no means of signing for anything but the intended address.

In a way, yes, but that turns it into another address, with other semantics.

In theory, if someone has the ability to sign for a public point P, they can sign for a tweaked version of P, assuming they know the tweak. The tweak cannot be inferred from the tweaked point; it has to be conveyed separately. This also works recursively, because if you can sign for a tweaked version, you can also signed for a tweak of that. Again however, this is theory and cannot be relied upon in practice. Only the receiver determines which address they accept.


text:
Bitcoin's Liquid Network - Unable to Broadcast PSET P2PKH issuance transaction using go-elements
While working on go-elements I've been trying to expand on pset_test.go by implementing functions that broadcast different kinds of PSET transaction. Unfortunately I can't find many technical informations about this subject.
I'm trying to implement a test that Broadcasts a transaction created from a PSET that issues an asset, with P2PKH outputs for the asset, l-btc (for the change) and the fee.
The code I wrote is returning the error pset_test.go:324: Signature does not correspond to this input which is pretty self-explanatory but I'm not sure where I got it wrong. I would appreciate some help and also indication on technical resources that could help me understand this subject a bit better. Thank you
func TestBroadcastUnblindedIssuanceTxP2PKH(t *testing.T) {
    privkey, err := btcec.NewPrivateKey(btcec.S256())
    if err != nil {
        t.Fatal(err)
    }
    pubkey := privkey.PubKey()
    p2pkh := payment.FromPublicKey(pubkey, &network.Regtest, nil)
    address, _ := p2pkh.PubKeyHash()

    // Fund sender address.
    _, err = faucet(address)
    if err != nil {
        t.Fatal(err)
    }

    // Retrieve sender utxos.
    utxos, err := unspents(address)
    if err != nil {
        t.Fatal(err)
    }

    // The transaction will have 1 input and 3 outputs.
    txInputHash, _ := hex.DecodeString(utxos[0]["txid"].(string))
    txInputHash = bufferutil.ReverseBytes(txInputHash)
    txInputIndex := uint32(utxos[0]["vout"].(float64))
    txInput := transaction.NewTxInput(txInputHash, txInputIndex)

    lbtc, _ := hex.DecodeString(
        "5ac9f65c0efcc4775e0baec4ec03abdde22473cd3cf33c0419ca290e0751b225",
    )
    lbtc = append([]byte{0x01}, bufferutil.ReverseBytes(lbtc)...)

    changeScript := p2pkh.Script
    changeValue, _ := confidential.SatoshiToElementsValue(99999500)
    changeOutput := transaction.NewTxOutput(lbtc, changeValue[:], changeScript)

    feeScript := []byte{}
    feeValue, _ := confidential.SatoshiToElementsValue(500)
    feeOutput := transaction.NewTxOutput(lbtc, feeValue[:], feeScript)

    // Create a new pset.
    inputs := []*transaction.TxInput{txInput}
    outputs := []*transaction.TxOutput{changeOutput, feeOutput}
    p, err := New(inputs, outputs, 2, 0)
    if err != nil {
        t.Fatal(err)
    }

    updater, err := NewUpdater(p)
    if err != nil {
        t.Fatal(err)
    }

    arg := AddIssuanceArg{
        Precision: 0,
        Contract: &transaction.IssuanceContract{
            Name:      "Test",
            Ticker:    "TST",
            Version:   0,
            Precision: 0,
            Entity: transaction.IssuanceEntity{
                Domain: "test.io",
            },
        },
        AssetAmount:  1000,
        TokenAmount:  1,
        AssetAddress: address,
        TokenAddress: address,
        TokenFlag:    0,
        Net:          network.Regtest,
    }
    err = updater.AddIssuance(arg)
    if err != nil {
        t.Fatal(err)
    }

    err = updater.AddInSighashType(txscript.SigHashAll, 0)
    if err != nil {
        t.Fatal(err)
    }

    err = updater.AddInNonWitnessUtxo(updater.Data.UnsignedTx, 0)
    if err != nil {
        t.Fatal(err)
    }

    txHash := updater.Data.UnsignedTx.TxHash()
    sig, err := privkey.Sign(txHash[:])
    if err != nil {
        t.Fatal(err)
    }

    sigWithHashType := append(sig.Serialize(), byte(txscript.SigHashAll))

    // Update the pset adding the input signature script and the pubkey.
    _, err = updater.Sign(0, sigWithHashType, pubkey.SerializeCompressed(), nil, nil)
    if err != nil {
        t.Fatal(err)
    }

    valid, err := updater.Data.ValidateAllSignatures()
    if err != nil {
        t.Fatal(err)
    }
    if !valid {
        t.Fatal(errors.New("invalid signatures"))
    }

    // Finalize the partial transaction.
    p = updater.Data
    err = FinalizeAll(p)
    if err != nil {
        t.Fatal(err)
    }

    // Extract the final signed transaction from the Pset wrapper.
    finalTx, err := Extract(p)
    if err != nil {
        t.Fatal(err)
    }

    // Serialize the transaction and try to broadcast.
    txHex, err := finalTx.ToHex()
    if err != nil {
        t.Fatal(err)
    }
    _, err = broadcast(txHex)
    if err != nil {
        t.Fatal(err)
    }
}

The error hints that you're not signing the transaction correctly.
In fact, you're generating a signature with:
txHash := updater.Data.UnsignedTx.TxHash()
sig, err := privkey.Sign(txHash[:])

But the current transaction hash is not what you need to sign. Instead, you should use HashForSignature for legacy input types:
sigHash, err := updater.Data.UnsignedTx.HashForSignature(0, p2pkh.Script, txscript.SigHashAll)
if err != nil {
    t.Fatal(err)
}
sig, err := privkey.Sign(sigHash[:])

PS. Note that at the moment the Elements protocol does not allow you to use an input owned by a legacy scriptpubkey, therefore even if the transaction is well-formed it won't get accepted in mempool and included in the blockchain.


text:
What stops a wallet from stealing bitcoins?
I'm not particularly knowledgeable on the topic of cryptocurrencies so it's possible that I've missed something obvious, but I still wonder what it is that stops a wallet from stealing from you. Wallets contain your private keys and they obviously have to use them to be able to send coin. So what stops a given wallet from stealing bitcoin from a user in the background without the user's knowledge?

As @Prayank mentioned before: Nothing. As Ken Thompson said: "you can't trust code that you did not totally create yourself".
If you are paranoid, it's better that you use cold wallets and make them air-gap.

Wallets contain your private keys and they obviously have to use them to be able to send coin.

That is indeed a very valid concern; you good sir have exercised thinking well.
Others have thought the same, and created hardware wallets to tackle exactly this threat!
Those are basically USB dongles with a button — which you have to physically press before it signs any transaction. So, this:

stealing bitcoin from a user in the background without the user's knowledge

does not work anymore — even when your green shiny well-known well-reviewed Open Source wallet software has been discreetly infected (for example, to show you one destination address, but substitute another when sending funds).
Crucially, hardware wallets are designed to hold private keys within, and are supposed to never share them with the host computer / wallet program. Spending request in — signed transaction out. This also protects your funds. For another example, you can now be OK with having to use a public computer with a crappy OS on it.
Maybe check out https://bitcoin.org/en/wallets/hardware/ — I'm sure you'll manage to do your own research from there.

Oh, and don't be fooled: just because it's a secure™ hardware chip — does not mean it can't be malicious in exactly the same way. Transparency requirements (e.g. Open Source firmware, bug bounty program, etc) still apply.


text:
Identifying Closing Balances on Lightning
Is it possible given on-chain and gossip protocol data to derive closing channel balances? For example, the following channel between ACINQ and magnetron has two txouts but unsure who's balance is which. Closed Channel Example
I know from Bolt #3 that transaction outputs are sorted by value in ascending order but is there something in the script to match closing balances to nodes?

No, the ownership of the outputs of closing transactions is private. Nobody except the channel owners needs to know the final balances of the channel, so clearly it would be a privacy leak to serve this data unnecessarily.
You may be able to make an educated guess if one of the channel owners reuses the output to create another channel, or by analyzing the receiving wallets' fingerprints in order to guess per the software they might be using (e.g. the P2TR output here might be an indicator).
Note that a channel owners might not send the funds to their own wallet with the closing transaction.


text:
When chains branch, are there multiple UTXO sets?
If there are "fork" chains coming off a block, how do we keep track of the UTXOs of different public keys?
Would I just store UTXOs derived from the longest chain and recalculate if another "branch" becomes longer than this chain?

Each node considers the valid chaintip with the most-work that it knows about the canonical state of the network. Only this "best chain" matters to establish the state of the UTXO set. If another chaintip overtakes the prior best chain, the node reverts blocks until it arrives at the highest common previous block and then applies the new chain.
The nodes only need to assess the header of the block. Each block mentions its predecessor in the header, so the node can see where a block attaches to the blockchain. If a new block header is not leading to a better chaintip, nodes will not even retrieve the block. Pieter recently wrote a detailed description of how block synchronization works today, if you want to understand the process in more depth.
Of course a miner could extend whatever chaintip they want, however not only are stale chaintips easy to identify, the miners will also lose money on doing so:
The best chain is a single-file connection between Genesis block and the best chaintip. Every block has exactly one predecessor and you can only spend coinbase transaction outputs (i.e. the mining reward) when they have 100 confirmations. Stale chaintips are not part of that best chain, and therefore the block rewards are paid to outputs that don’t exist in the best chain. Mining on top of invalid blocks costs you the same effort, but nets you zero revenue.

Ah right, thanks, that makes sense. But wouldn't that mean blocks can't be published with previous blocks on invalid chaintips? Does that restrict miners to only publishing blocks on the chain that the node considers the longest?

Any miner can extend whatever chaintip they want, it’s just that if their block isn’t part of the best chain in the long run, they’ll find it hard to sell their mining reward, because the output doesn’t exist in the best chain. The best chain is single-file, every block has exactly one predecessor and you can only spend coinbase transaction outputs when they have 100 confirmations. Mining on top of invalid blocks costs you the same effort, but nets you zero.

So if miners extend a shorter length chain, would I have to search UTXOs on that "branch" to see if their block is valid instead of using the UTXO set? Since surely the UTXO set the node has stored would just be valid for the longest chain.

@Shay Your node will only download the headers of this new branch unless it actually is a (candidate) best block. Once the branch is extended long enough to potentially overtake (or at least tie with) the current best block in terms of work, it is downloaded and partially validated. The actual full validation that involves the UTXO set is only performed if it would actually be the best chain. See my answer here for more depth: https://bitcoin.stackexchange.com/a/121293/208


text:
I set up a Trust wallet do I need bitcoin in there to receive bitcoin
I set up a trust wallet put 5k in it as was told I needed this much in it to receive my investment (bitcoin)but the 5k is not accessible as now they say I need 7k more to make it accessible I am assured a payout (only the person I have been talking with)but I have sent 1000s initially

This is with bitnextradefx so if anyone can help as if they are a fraud set up please advise

Does this answer your question? Is it normal to be asked for an advance fee on a withdrawal?

Definitely a scam. All the money is gone and cannot be recovered. Contact your local police. Do not give any more money to the scammer and don't communicate with them. Do not put money into that wallet

No, you don't need any BTC funds to be able to receive BTC in your wallet.
Schemes where you have to prepare/provide some funds 'in order' to receive something else sound very much like a scam.


text:
What specific packages are required to be installed in order to create legacy wallets?
When attempting to create a legacy wallet using bitcoin-cli, I get the following error:
bitcoin-cli -named createwallet wallet_name="[...]" descriptors=false load_on_startup=true
error code: -4
error message:
Compiled without bdb support (required for legacy wallets)

I already have Berkeley 5.3 and SQLite3 installed and running Bitcoin Core 23. What else do I need?

Assuming that you're building in Linux, legacy wallet support will require Berkeley DB 4.8. You can find instructions in the corresponding section along with a helpful install script's location. There is also this comprehensive guide on how to compile bitcoind for testing by Jon Atack, which provides a few more details that might be helpful.
At the end of the mentioned install script, it prints instructions on how to configure the compilation of bitcoind. Look for something along the lines of
db4 build complete.

When compiling bitcoind, run `./configure` in the following way:

  export BDB_PREFIX='<SOME-PATH>/db4'
  ./configure BDB_LIBS="-L${BDB_PREFIX}/lib -ldb_cxx-4.8" BDB_CFLAGS="-I${BDB_PREFIX}/include" ...

Use these instructions to configure your installation after installing BDB. Run:

The export BDB_PREFIX='<SOME-PATH>/db4' from the scripts final output
./autogen.sh
Also from the script output use ./configure BDB_LIBS="-L${BDB_PREFIX}/lib -ldb_cxx-4.8" BDB_CFLAGS="-I${BDB_PREFIX}/include" ..., adding any other parameters you like
finally call, make or make install according to your intended outcome

Unfortunately, I am still getting the same error. I installed Berkeley DB 4.8 using the suggested script. It is located in /usr/local/BerkeleyDB.4.8. I have restarted the node after the install. Any suggestion?

Did you run configure… and make again afterwards? The configure step defines which bdb your install is gonna use.

Yes, I did the following: '$ tar -xzvfdb-4.8.30.NC.tar.gz' '$ cd db-4.8.30.NC/build_unix/' '$ ../dist/configure --enable-cxx' '$ make' '$ make install' which I can find in '/usr/local/BerkeleyDB.4.8'

I meant that after installing BDB 4.8, you'll need to rebuild Bitcoin, to make it use the other version of BDB

I just rebuilt Bitcoin Core 23 and I still have the same error. Is there a specific feature that needs enabling during configure?

Hi Gervais, I added more details, I hope this helps

You can also build with --with-incompatible-bdb, which allows for building with BDB up to 5.3. The resulting wallet.dat files can't be opened with lower BDB versions, but that isn't necessarily a problem.

After taking a close look at the configure messages while recompiling, I found the problem: configure: WARNING: libdb_cxx headers missing, configure: WARNING: Bitcoin Core requires this library for BDB (legacy) wallet support. Thank you all so much for your help!


text:
How much bitcoin in Canada?
How much bitcoin in Canada? Are there any sources of data or sites where it says how much bitcoin is in Canada or how many wallet addresses are Canada based?

How much bitcoin in Canada?

That's a very interesting question:

None of it.
It isn't always possible to say that an address is based in Canada. Some Canadians might use wallets on mobile phones. If the Canadian visits the USA does her Bitcoin move to the USA? Suppose the Canadian leaves a duplicate wallet with a relative in the USA and returns to Canada? Does electronic money in a globally replicated system have a physical location?

All of it.
All Bitcoin is in the blockchain. Canadian nodes hold copies of the whole blockchain.

What does it even mean?
If a Frenchman buys Bitcoin from a Canadian exchange, does the money move from Canada to France? What if he is using a custodial account? What if the Canadian exchange's servers are AWS cloud servers? What if Amazon shifts some workload to Mexico? Does the Frenchman's money move to Mexico?

You might ask how much Bitcoin is under the control of people normally resident in Canada - but how would anyone know? What is the nationality of Satoshi Nakamoto? Where does Nakmoto live? If Nakamoto is dead, where do you consider Nakamoto's money to be? What is the location of money locked in a multisig UTXO?

So if I were to ask how much Bitcoin is owned by Canadian residents, that would be something that can't be measured? I understand how it is difficult to measure and why the question may not be easily answerable. But in general, how are geographical estimates formed for bitcoin and crypto?
I came to stack exchange because I googled how much crypto is owned by Canadians, then I searched up the same for the US, and different websites gave different percentages and estimates. Why are they all different and how do they develop such estimates? Are they just educated guesses?

The coins are just numbers in a "database" (the Blockchain). Everything is distributed all around the world, none of it is in any physical location. No one can determine anything about nationality of "owners" of all the addresses. So yes any estimates are just wild guesses inferred from various players' access to transaction statistics, IP addresses etc


text:
Can a full node understand the transactions it downloads from the Bitcoin network?
I understand a full node downloads and validates the entire transaction history. Can a full node read and understand these downloaded transactions, or is it just just keeping a copy of encoded information?
I'd appreciate if you could mention your sources' links in this regard.

Can a full node read and understand these downloaded transactions, ...

Yes.

or just it's just keeping a copy of encoded information?

You write "encoded" but the context makes it seem you may have meant "encrypted"
The Bitcoin network does not encrypt any data. None of the data in the blockchain is encrypted. It is all publicly readable information in plain sight.
The answer you are reading right now is encoded. The encoding used is UTF-8.

Thank you for answering my question and sorry for the typo. So if I understand correctly, a full node can see the transaction details but not the private keys, therefore it can't figure out who are the sender and recipient, is that correct?

@zbbo It can see the receiving addresses and public keys. Information about the sender and recipient can be inferred from that information.

All info on transactions and more generally on blockchain are readable and understandable by every full node. All the info you find on a blockchain explorer are basically asked to a full node, if you want you can run your own blockchain explorer querying your node.
There is no privileged actors in Bitcoin network, all node share the same info and capabilities ... and this does not refer only to physically possessing the info but also to read and know them.

Thanks a lot for your answer; could you also check my complementary question too?
So a full node can see the transaction details but not the private keys, therefore it can't figure out who are the sender and recipient; is it so?

Not exactly, private keys give you ability to spend bitcoin on its address, they are not giving more info on transactions. If you intend sender and recipient as addresses, anyone can see them, instead if you mean people there is no association between addr and person, so the only way you can know which is owner of an addr (sender or recipient make no difference) is that the owner himself tell you.

Much appreciated, got it.


text:
How to "Autoforward" incoming BTC using Electrum
We would like to generate multiple addresses in Electrum, receive BTC to these addresses on a daily basis and auto-forward them to another address automatically.
So the flow would be this:

BTC Sent to Electrum generated address
Electrum wallet balance is inquired on a timed basis (every 1 minute)
If Electrum wallet balance is over 0.05 BTC then it will create a new broadcast transaction to a predetermined and fixed wallet

Is this possible?

Yes, you could for example create a cronjob that calls a shell or python script every minute. A corresponding script would e.g. use electrum getbalance and electrum payto <address> <amount> with some additional logic to forward the funds when enough has been accumulated.
I would suggest that you avoid address-reuse by using extended pubkeys instead of fixed addresses.


text:
Can I verify a child public key derived from its parent public key without involving any private keys and child index?
I have a extended private key, I'm creating multiple child private key / public key pair. If want to verify that the child public is derived from the parent public key. Can I do that? Thanks in advance!

If you have the parent public key and the (non hardened) index you can generate the child public key and verify that it matches. You can’t do it without the index I’m afraid since the derivation involves a one way hashing step.

Ohh okay then I'll go with the indexes itself. Thanks

To derive child keys, two conditions have to be met / satisfied:

The extended parent public key is available (public key & chain code)

The derivation path uses non-hardened indexes

(optional) know the derivation path; if you don't know it, it will take you time to iterate through the various combination (i.e. brute force), but typically they are simply incremented, so it shouldn't be costly.

Reference Public parent key → public child key in BIP-0032.


text:
Crypto exchange - what do BTCUSD SELL and LTCBTC SELL mean?
I just downloaded an app that forecasts the crypto market. The app seems to be nice but I don't understand the forecast interface. What does this mean?
BTCUSD SELL,
LTCBTC SELL

Does it mean that I can sell my bitcoin to someone that has dollars?
For the second, does it also mean that I can sell my LTC to someone that has BTC that is invariably buying BTC with LTC?

BTCUSD          sell
  |               |
Trading Pair    Advice from the Platform

So BTCUSD is a trading pair
in trading you always exchange something (BTC) for something (USD)
the last part is the advice from the platform what you  could do with the specific pair. (in this case sell the first for the second)
this is my guess because we do not know the context really, some forcast software/apps are also integrated with the ability to exchange directly if you open an account with them)
As for my interpretation (assuming it is only forecast):
If you have BTC they advice you to sell BTC for USD because the market will be favourable this way (you will profit form this trade in the future because they expect the USD to be valued higher than BTC).
If you have LTC they advice you to sell LTC for BTC because the market will be favourable this way (you will profit form this trade in the future because they expect the BTC to be valued higher than LTC)
STRONG ADVICE
Do your own research about what could happen in the future, forecasts are forecasts and nothing more, don't come crying because you lost money by trusted a forecast. They may be factually based, but they can still be completely wrong. You may lose everything, many people have and will.

BTCUSD means you are selling your BTC in exchange of USD, same with LTCBTC, you are selling your LTC in exchange of BTC. That both works with spot and leverage trading settings.


text:
Why is there "Change" in Bitcoins?
I have read about a change address and wondered why there even is the concept of change?
Let's say I received 1 BTC from some person A and I want to send 0.4 BTC to another person B, afterwards. From what I have understood, I have to send the 1 BTC, as a whole and then get 0.6 BTC as change.
Is that right? And if so, why don't you just send 0.4 BTC in the beginning?

Bitcoin follows a Unspent Transaction Output (utxo) model.
Our modern banking systems follow an account model - you're assigned a bank account number (similar to an address), and send and receive money from it. Any incoming funds increase your total account balance, and any outgoing funds decrease it. The bank does not keep track of which funds came from which deposit. It's just a single balance.
Bitcoin is closer to cash - Any funds in your Bitcoin wallet are the result of a previous incoming transaction, exactly how any notes in your physical wallet are the result of previous real life transactions you've made (whether an ATM/bank withdrawal, or received as change at a store).
Bitcoin tracks the output of each individual transaction, just like real life notes. When you receive 1 BTC, you receive an output (note) of exactly 1 BTC. This must be spend in its entirety, and cannot be split. So if you'd like to send 0.4 BTC, you put in the entire 1 BTC into the transaction, and send 0.6 BTC to one of your own addresses in the outputs.
This works much the same way as buying a $5 item with a $20 note - you must put in the entire $20 note, and you will get $15 back. You can't simply tear the $20 note into four equal pieces and create 4 $5 notes.
Of course, unlike real cash, in Bitcoin there is no risk of the recipient simply taking your BTC and refusing to return the change - the change is sent back to an address owned by you as part of the transaction building process. The recipient of the rest of the funds has no control over it.
A cleaner way to think about it is using the coin (physical coins, not bitcoin) analogy mentioned by Abdussamad in the comments - You can treat each output in your wallet as a single, indivisible coin of a fixed value.
When you spend these coins, transactions act as a melting pot - you can add in multiple coins to create a pot with a value of the sum of all coins, and you can use the melted coins to mint new ones of the values you want - 1 coin for the payment you're making, and one coin for the change that you keep with you. This even accounts for transaction fees - every time you melt down some coins, the pot claims a small amount that sticks to it, resulting in a final output that is slightly lower than the input.

the coin analogy is probably better than the note analogy because of the differences cited in your last paragraph: https://en.bitcoinwiki.org/wiki/Coin_analogy

@Abdussamad Good point - I've expanded on it in an edit, thank you!

Your description of the "modern banking systems" is completely wrong. They are based on  transactions very similar to how bitcoin works. Account balances are not generally stored, they are derived by adding up incoming and outgoing transactions. Look up "double-entry bookkeeping".

@MichaelBorgwardt Sure, on an internal level - as a user, it is exposed via a single account balance. I doubt getting into banking implementation details is going to help explain bitcoin any better to folks

There are a lot of good answers, but I want to point out the most obvious answer.
Say you have 1 bitcoin and you send 0.2 bitcoin to me and the design leaves it so that you still have 0.8 bitcoin in the same place as the 1 bitcoin you had originally. What stops someone from simply processing that transaction again? You still have the funds.
Designing the system so that a transaction destroys its input totally and only creates new outputs ensures that any transaction that executes cannot be valid a second time because it destroyed something it needed in order to be valid.
There are other ways to do this. The XRP Ledger uses accounts with balances and it requires transactions to have a "sequence number" in them. An account with sequence 3 can only execute a transaction with sequence 3 and in the process, the sequence number is bumped to 4 to forever invalidate the transaction. Bitcoin's method is simple and elegant.

And if so, why don't you just send 0.4 BTC in the beginning?

Bitcoin was designed to allow single-in multi-out or multi-in multi-out payments. In Ethereum, only one address fills the whole "to" field of transactions. (This doesn't apply to contracts. Does that mean, in Ethereum, users are 2nd class citizens?)
If you were Satoshi and you were to allow transactions with multiple inputs, how would you design transactions so that a change output is not need? I honestly don't know. Plus, currently "in" fields of transactions reference txid:vout where vout 0, 1, 2, ... refers to an output of the transaction.

There are some good answers here, but I'm surprised nobody has mentioned privacy.
Having coins sent to a new change address can improve your privacy in many ways. Consider this simple example: a one-input two-output transaction. Which output is change? If the transaction is carefully constructed, it may be difficult for a third party to tell.
There are more complicated ways you can build transactions to increase privacy as well, such as 'coinjoin', 'payjoin', or 'payswap' transactions. It is an active area of research.
Compare this to the account model, where the leftover 'change' just stays in the same account, making privacy much more difficult to attain.

While true, it's also not ridiculously hard to track change outputs over a large number of transactions - in fact, the more change outputs you have in a chain, the higher chance of a single bad payment deanonymizing many of them

@RaghavSood very true, it requires careful transaction handling. But in any case, the UTXO model allows for this sort of plausible deniability, while the account model does not.

One major advantage of this Unspent Transaction Output(UTXO) is that it simplifies handling of cheating.  Consider the case where I have $20, and then cheat to buy two things for $11 each with the same money.  The system has to reconcile this, figuring out who gets paid and who does not.  Now amplify this to a scale where I might make a thousand purchases, some intentionally fraudulent, and some not.  The untangling could be a nightmare.
If you consider how you and I usually resolve this, its a first-come-first-serve approach.  The first retailer gets their money, and the rest don't.  This lines up well with what would have happened if we used physical money.  It would have been impossible to give $11 to the second guy in the first place!
However, timing is a tricky subject for Bitcoin because it is a distributed network.  There is not a single node that can timestamp all money spent to resolve this issue.  If you happen to get one purchase into the block chain, it's easy, but you may have multiple pending purchases outstanding before a new block gets minted.
The solution is the UTXO approach.  By forcing all money from a bitcoin account to be spent all at once, returning the remainder as "change" into a new account, you create an ordering for these purchases.  The extra accounts automatically construct that ordering.
And, as such, we can untangle nasty situations where I may have made 4 valid purchases, then 2 fraudulent ones, and then 2 transactions on each of those fraudulent chains on top of that:

Purchases A, B, C, and D
Double spent purchases E1 and E2
Normal purchases E1-F and E1-G (valid if E1 is valid)
Normal purchases E2-F and E2-G (valid if E2 is valid)

This sort of thing could be a snarl.  It's the kind of thing which leads credit card companies to have humans do the arbitration. But thanks to the UTXO model, these transactions are very clearly ordered.  The system will tie-break between E1 and E2 based on which one gets into the blockchain first.  The result will be that either A, B, C, D, E1, E1-F, and E1-G are valid, or A, B, C, D, E2, E2-F, E2-G are valid.
Try to construct such a system without a centralized node to timestamp purchases, and without a human to arbitrate, and you quickly appreciate the choice.  Are there other ways to do this?  Certainly.  But one has to appreciate the simplicity and clarity.

How this would be solved by a real bank is that your balance is $-2 and you get a phone call or an angry letter

Also the blockchain already constructs an ordering regardless of whether you use the UTXO model or the account model.

@user253751 Yes, an angry phone call.  And then legal action if need be.  Lots of people are involved in the resolution of that case with a real bank.  If you want to see how it really happens, look at the process of bankruptcy, and how humans have to sort out which creditors get what.

@user253751 And the block chain orders things to within 10 minutes.  However, you can spend bitcoins faster than once every 10 minutes.  To avoid needing humans in the loop, we order these rapidly spent coins as well.

The UTXO model does not order rapidly unspent coins in case of attempted fraud. You can create two transactions with the same UTXO. Only one will be accepted into the blockchain, but you have to wait for several blocks to know that.

@user253751 And, as I stated in my answer, it will properly order the transactions around it, and will resolve disputes in a very clear algorithmic manner.  A given transaction is valid if and only if all transactions which preceeded it in order are valid.

If you have 1 bitcoin in an account, double spend 1 satoshi out of it, and then try to buy something from me for 1 bitcoin in the same block, I can look at the transaction history, build up the partial order of transactions I am dependent on and ask questions about how likely I am to get paid my 1 bitcoin, but I am certain I will either be paid or not paid.  There wont be a mediation (like might happen in a real bank), where I get 0.99999BtC.

More like: I create two transactions which spend the same 1 bitcoin and send them both simultaneously to different peers. 40% of the network sees the second transaction first and rejects the first one and 60% of the network sees the first transaction first and rejects the second one. Because you stupidly didn't wait for confirmation, you gave me real goods after seeing the first transaction (which pays out to you), didn't see the second one because your node rejected it, and by a 40% chance, the second one got into a block.

@user253751 You seem to be approaching it from a human point of view, where "stupidly" plays a part.  From an algorithmic point of view, this algorithm defines a very exacting rule for how transactions will be sorted out in the less-than-ideal cases which would otherwise be more ambiguous.

Yes and the algorithm is "wait for a certain number of blocks". Your algorithm is "wait for no blocks" and it's broken.

@user253751 That is a usage policy, not an algorithm.  The algorithm does not state how many blocks to wait.  The algorithm is responsible for keeping the ledger functioning and self-consistent.

@user253751 I am not referring to a service.  You may freely read about the algorithm I am referring to in this paper

@user253751 And how does it decide which transactions get into the block chain and which ones do not?

Is that right?

Yes.

why don't you just send 0.4 BTC in the beginning?

Because you need to consume the last transaction (called "input" of your second transaction, in your example the 1 BTC) entirely (*), or the delta will end up paid in fees.
The amount paid in fees to the miner including your transaction is the amount of the input(s) you unlock, minus the amount of the output(s) you lock back ("send").
Since you generally really don't want to pay 0.6BTC in fees, you add another output locking funds back to you.

(*) Simplified so you get the idea but technically the input of your transaction is any unspent-yet output (there can be several) of a precedent transaction.


text:
Is there a simple-to-use Windows-10 client for Lightning Network?
I'm having trouble finding a Windows 10 client for Lightning Network which is simple to use and which can be installed without needing to learn a lot about the underlying technical concepts.
Is there any reason why such an application program is not possible?

If you want to use lightning in a non-custodial way, there's 2 clients I find very easy to use: Electrum, Zap. If you're comfortable using it in a custodial way, then Muun wallet has by far the easiest user experience of any wallet I've ever used. Download BlueStacks, install Muun

Edit: Apparently Muun is non-custodial as well, which is amazing considering the UX it has

@hydrabeast Sorry, I have no use for any "phone apps".

I've rewritten this to focus on the core of the question. If you disagree with the change, please click the "edited..." link and select "rollback". However note that questions asking for product reviews tend to get answers based on opinions and which tend to become out of date quickly. Therefore the question may get closed if many people take that view.

I mean, Sybil has been told this before, but LND has a Windows binary…


text:
Bitcoin address gap limit
I know there are a lot of posts on this issue but the majority of them are quite old.
Is there a more modern and "simple" solution for the address gap limit problem? For what I've read, the best one is to use Electrum and set the gap limit to something like 5000. Is there the possibility to set it up to infinity?
If instead of generating new addresses each time, would importing external private keys to my wallet, without scanning, and generating a single address per private key solve the gap limit dilema (in a Bitcoin Core wallet, for example)?
Thanks a lot for any input!

The gap limit is used because there are practically infinite addresses you can generate via Hierarchical Deterministic generation. If you didn't have a limit, the wallet would have to generate all of them, just in case, to see if any where used in transactions. That is impossible, there are just way, way too many possible child addresses.

Is there the possibility to set it up to infinity?

This is the same as having no limit, and it's impossible, as above.

would importing external private keys to my wallet, without scanning, and generating a single address per private key solve the gap limit dilema (in a Bitcoin Core wallet, for example)?

The gap limit is specific to Hierarchical Deterministic wallets, where you can deterministically generate many addresses from a single short seed. This makes backups super easy - backing up the seed means you've backed up all past and future addresses your wallet will generate. The seed is short so you can even write it down by hand. And HD has other benefits like being able to generate child public keys without access to the secret keys (useful for security, to avoid having secret keys "hot" on internet-connected devices).
If you just imported a few individual keys, you wouldn't need a gap limit, but you'd lose all the benefits of HD wallets. That's how Bitcoin Core's wallet used to work - colloquially known as the "bag of keys" model. HD is definitely the better way to manage keys.

Thanks for the answer! The thing is the PK management that I need is very basic: no scanning for past txs, just listening to ones since each address' creation, and I need to not have a limit on the amount of addresses and/or PKs managed by my wallet (or a very big limit). I have two following questions, if I may:

Can I import infinite PKs to a Bitcoin Core wallet?
If the gap limit is an issue of HD wallets only, can I create n addresses within a Bitcoin Core wallet without losing the ability to listen to when each address receive a new deposit? @meshcollider

The gap limit only applies when restoring a backup. If you are just creating addresses, then of course all the keys will be tracked by the wallet. Specifically, the answer to both 1) and 2) is yes.

Awesome! Thanks again for help. @meshcollider


text:
What are the constraints on Bitcoin Core's wallet passphrase?
I know I can't send coin without my passphrase, but I have forgotten it. All I would like to know is, is the passphrase a phrase I come up with? Or does Bitcoin Core provide the phrase? Many thanks.
Also is it just one word or a sequence of words?

is the passphrase a phrase I come up with?

Yes.
It is used to encrypt the wallet so that only you can use it.

is it just one word or a sequence of words?

It is up to you what characters to type and whether it includes spaces.
The program suggests "Please use a passphrase of ten or more random characters, or eight or more words"  So, if you are the sort of person to heed advice, you probably chose a passphrase following one or the other of those forms.

I have forgotten it.

See Are there Bitcoin password crackers I can use to recover forgotten passwords?
Don't use any online tools.


text:
How can I get all transactions into and out of a bitcoin address in JSON format?
For example if I use https://blockchain.info/rawaddr/$bitcoin_address,  it shows only the first 100 txs. How can I get all transactions if the number of txs is greater than 100?

Their API documentation tells you:

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)

So use the offset parameter and repeat until all data retrieved.


text:
How do I set up my S9 and full node for solo mining?
I keep seeming to get round about answers about this. I want to begin mining to my local general-use machine which acts as a node as it hosts the blockchain (aka.BTC-core). I HAVE an ASIC S9. I need a bit of a walk-through generating the blocks and having my machine take cracks at them locally without a pool. Inspired by some of the low hashes of found blocks recently, I think my s9 has a chance with a gigabit+ connection.

https://www.asicminervalue.com/miners/bitmain/antminer-s9-13-5th

Does this answer your question? Solo Mine with an AntMiner

I think I meant this related question: https://bitcoin.stackexchange.com/a/110992/5406


text:
Mempool not accepting transactions: 'reject-reason': 'insufficient fee'
I'm using Bitcoin Core, and for some reason, it doesn't want to accept transactions when I already have other transactions in the mempool, even if those transactions are using different UTxOs and they have different non-witness data. I have enough to pay for the transaction and fees. I also make sure that the fees are greater than the vsize which means that the problem is not with the fee.
Can someone provide an insight about this specific reject-reason?

By default Bitcoin Core’s mempool data structure is limited to using no more than 300 MiB of RAM. If your node has been consistently online, it would currently be full of transactions that pay about 4.6 s/vB or more. It seems to me that the transaction you were trying to send paid less than your own mempool’s minimum feerate and thus was rejected with the reason "insufficient fee".

Is there a way to estimate the current "mempool's feerate" ? I thought it was 1s/vB. If the answer is yes, would that mean that the minimum ferrate is dynamic and depends on the state of the mempool?

I conducted such experiment: After one successful tx, I multiplied the fee by 5 and it works. In order for it to work on the 3rd time, I had to multiply the same fee by 10. Otherwise, I got the same error. I'm not sure I understand why since getmempoolinfo got me mempoolminfee and minrelaytxfee to be equal to 1e-05.

Is it possible that it was 10e5, instead of 10e-5? Otherwise, this related topic might be of interest: https://bitcoin.stackexchange.com/q/96068/5406

1e-5 BTC/kvb is 1sat/vb so seems plausible, especially if the node was recently restarted. (If the tx pays to bare multisig outputs, it could have a high sigop count leading to a lower effective feerate than you'd get by just looking at the tx size and fee directly)


text:
Broadcast transactions through bitcoind without importing private key
My question has already been asked before, and some answers were also already given
the question, however, it's not clear to me why I get some behaviour when implementing it. Here are the details:
I created my transaction and signed it offline, without interacting with bitcoind. But, when I broadcast it to the network (or test acceptability by mempool), it doesn't work unless I import the private key to bitcoind through the rpc command importprivkey.
I inspected the bitcoin code to understand why it does behave like that, but unfortunately, I don't quite understand where it does verify for the private key or check that it was imported. As I understand, the transaction's broadcast happens here sendrawtransaction.
Please, can someone explain why it does happen and/or provide a way to just broadcast raw transactions to the network without importing private keys into bitcoind?

This is very strange; sendrawtransaction is a node RPC and importprivkey is a wallet RPC; the two should be completely unrelated, and there is absolutely no requirement that a transaction's private key(s) are imported in order to broadcast a transaction or get it accepted to the mempool. Can you update your post with detailed steps to reproduce the problem?

I think you are right. It didn't work because I was checking that the utxos were spendable before adding them to the transactions. After reading you, I realise that you should be right.

The described behavior does not make sense to me. The sendrawtransaction is a node RPC that takes a raw transaction and submits it to the local node’s mempool. If the transaction makes it into the local node’s mempool, the node will relay it to its peers. To that end, the transaction must already be complete. The RPC will work for any valid transaction and does not even require a wallet to be active on the node. Since you could even rebroadcast foreign transactions that way, it seems implausible that the sendrawtransaction call would interact with private keys in any way whatsoever.

Yes, in fact, I got this behaviour because I was only considering the utxos that were spendable. Something like if utxo['spendable'] then add it to outputs.
It follows that it was the wrong thing to do since the outputs will be empty if the wallet doesn't have the private keys.


text:
The QT wallet does not start
The QT wallet does not start:
./bitcoin-qt в ubuntu 20.04?  qt.qpa.plugin: Could not find the Qt platform plugin "offscreen" in ""

This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform pl

tell me how to solve the problem? I installed dependencies with githab bitcoin core.

If the "offscreen" plugin is missing, you may need to rebuild Qt with the necessary platform plugins. First, ensure you have the Qt source code:
 ```bash
 git clone https://code.qt.io/qt/qt5.git
 cd qt5
 git checkout <qt_version_tag>  # Replace <qt_version_tag> with the desired version tag, e.g., 5.15.2
 ```

Then configure and build Qt with the necessary platform plugins:
./configure -prefix /path/to/qt -opensource -confirm-license -nomake examples -nomake tests
make
make install

Replace /path/to/qt with the desired installation path.

After rebuilding Qt, you can follow the previous steps to rebuild Bitcoin Core and run it. This should ensure that the required Qt platform plugins, including "offscreen," are available.
Remember to replace <qt_version_tag> with the actual version tag of the Qt version you want to build.


text:
How can I fix that transactions of my old wallet show up as unconfirmed upon loading the wallet?
I am trying to load my old Bitcoin Qt 0.8.6 wallet and I am left with old transactions as unconfirmed. How do I fix this problem? The balance in the wallet is not confirmed by the network.

This question is similar to: How do I securely update Bitcoin Core?. If you believe it’s different, please [edit] the question, make it clear how it’s different and/or how the answers on that question are not helpful for your problem. You should backup wallet.dat first and you will have to wait for the wallet software to synchronise with the network

Can you describe in more detail how you went about recovering your old wallet? What software did you use to import the wallet? If it is a fresh install of Bitcoin Core, has it finished synchronizing?


text:
Retrieving a WIF bits private key
Suppose I have a Wif private key from Electrum 4.0.9:
L2pt3eVopnxfBBvMwrJV2saZeAyQfF77UQSH5WGj5q9LBS6WWBmN ( this one or the other generated from the seed is non used of course )
with a corresponding public key:
14k8mYFC1LBWiBN8WSxpJN48jQYX1FZ6kz
I am using the code from the book "programming bitcoin" and the way we create private key is by converting the bits of a secret phrase like this:
secret = little_endian_to_int(hash256(b'dat_test_private_key'))

So I was thinking I just had to put the private key derived from L2pt3eVopnxfBBvMwrJV2saZeAyQfF77UQSH5WGj5q9LBS6WWBmN instead of "dat_test_private_key"
then we do more step to get our private key here:

https://github.com/jimmysong/programmingbitcoin/blob/master/code-ch13/ecc.py

Then to get our public key:

public_key = print(private_key.point.address(testnet=False))

But no mater what I tried I dont have the same public key as electrum, so I guess I must be off something or they use a different WIF format or the way they derive public key

What do you mean by "original bits"?

I have updated my post, but I guess I am gonna go for the bitcoin libraries and dont go too deep for my project, I have even had a reply from Jimmy song for my problem, but it hadnt fixed it

There are tons of ways for converting passwords/phrases/seeds into keys. Presumably Electrum is using a very different one. That doesn't mean any is right or wrong.

So I was thinking I just had to put the private key derived from L2pt3eVopnxfBBvMwrJV2saZeAyQfF77UQSH5WGj5q9LBS6WWBmN instead of "dat_test_private_key"
Blockquote

Are you trying to hash the private key and use it as the
secret?
You could try something like this instead:
secret = int(derived_private_key_hex, 16)


text:
Can anyone initiate a Blockchain transaction into the mining pool?
Let's say user A has public key P and corresponding private key P'. Can someone else initiate a transaction for public key P with some wrong private key, let's say P''? Once this goes to the memory pool, miners will see that it is not signed with correct private key P' and will reject the transaction. Does it happen this way? Or is it that I can't initiate a transaction at all with wrong key?

Nodes store a mempool of valid transactions. An invalid transaction can never be in a block, so invalid transactions never make sense to store or relay around the network. You can make invalid transactions with invalid signatures, but it won’t be accepted by anything.

You can initiate a transaction with the wrong key, but it will actually get stopped before the transaction gets to the miners.
All Bitcoin transactions are reviewed by the Nodes, to make sure they are sending valid amounts of Bitcoin and were signed by the correct private key. If there is anything wrong with the transaction (wrong signature, not enough BTC), the network will reject it and probably ban you for 24 hours.
This is a fairly confusing topic because most crypto content focuses on explaining the miners, and very little focus is spent explaining the nodes.

Just to clarify, when you say the "network" would ban someone, it's each node that would unilaterally ban a peer when that peer sends them invalid data.


text:
Can we cancel a Bitcoin transaction like an Ethereum transaction with same nonce but higher gas fee?
I need to use BTC transactions to buy some shares. If the shares are full (eg. it only counts on first 100BTC), can my unconfirmed transactions be cancelled? Because even if they are mined later, they are invalid transactions. Can I use RBF or other methods to send a transaction with same input to myself with higher fee rate (but less total transaction fees) just like we do in Ethereum?
I have tried with Electrum to cancel the transaction, but the result was that the new transaction's total fee is higher than the old transaction's total fee, not only the fee_rate is higher.
For example, the origin transaction was 100 fee_rate and cost 10000 sats, the new transaction I use to cancel the original one is set to 120 fee_rate and total cost is 6000 sats, but the transaction sent by Electrum is set to 220 fee_rate and total cost is 11000 sats.
So I can't save money to cancel the transaction, which is the purpose I want to cancel.

Can I use RBF or other methods to send a transaction with same input to myself with higher fee rate (but less total transaction fees) just like we do in Ethereum?

No, you can't. RBF transactions must pay higher total (absolute) transaction fees, and there's no other method.
According to BIP125’s implementation details,

The replacement transaction pays an absolute fee of at least the sum paid by the original transactions.

Therefore, both a higher fee rate (BTC/vbyte) and a higher absolute fee (total BTC) are required.

Thanks! That's what I am looking for.


text:
What's the "weight" meaning in fundrawtransaction cmd's input_weights parameter
I am trying to use bitcoin-cli fundrawtransaction to add inputs to a transaction with only outputs generated from other program. I need to use the specific inputs from my wallet. But I only find the input_weights parameter to do it. (there is no "inputs" parameter). I don't know how to set the weight in the input_weights and don't know what's their effects.
There seems to be a min(165) and max(400000) value of weight which I find it in the code. If I send a value between min and max, the difference seems to be the fee I pay in the transaction. The problem is what weight should I set? Is there any different between different input weight?
I know the concept of size/weight of transaction. But I don't know the meaning of input weight and don't know how to set it correctly. Thanks!

I think I have figure it out. The input's weight is used to calculate the fee used in the transaction before signing the transaction.
If you want to know the exact weight to used, you can use this:
(signed_tx_weight - unsigned_tx_weight) + 41*4.
However, If you set the weight higher or lower than the real weight of input, your fee_rate options will behave higher or lower than the one you set. Because you calculate more or less weight of your transaction, and the real fee_rate is: fee you paied / real weight after sign. If the real weight is higher or slower, than the real fee_rate will be lower or higher.

Also, the fee calculated is something like : fee_rate * ((input_weight - (41 * 4) + unsigned_tx_weight) / 4 )


text:
Is commenting on github as reviewer good place to ask questions about source code?
I'm not sure even this question is off-topic or not. But bear with me.
Currently I have a good knowledge of bitcoin protocol and network but know very little about its source code and implementation but want to contribute to the project.
So I started reading bitcoin-core source code and learning about it. One of the first steps is reviewing other pull requests. I want to know is it okay to ask my very basic questions about source code as comments in reviewing these pull requests? Or these basic questions may be better to asked in another place? (such as IRC chat rooms)

I think you'll get different perspectives on this from different people depending on how "basic" we are talking, the PR author and whether the PR is high priority and already obtaining a lot of review from others. I'd recommend asking questions about any PR on Libera IRC (#bitcoin-core-pr-reviews) and attending the weekly Bitcoin Core PR review club sessions first. This will help you gauge which questions should be submitted as comments on a PR to help move the review of that PR forward and which questions should be asked on IRC for your own personal understanding. Certainly general questions on source code not being changed by any particular PR should be asked about on IRC rather than on a random PR.
Generally if you submit a review comment on the PR explaining what you've looked at or tested the PR author will appreciate the effort and answer a question or two. Obviously taken to extremes lots of basic questions on the PR aren't going to help move the review of that PR forward and should be taken to IRC or here on Bitcoin StackExchange.
For additional guidance on reviewing PRs see this doc from Jon Atack.

I would not ask general questions about source code on random PR :) but I meant asking related question to the PR, but at a very basic level. Although, I have a background in c++ so try to first investigate my self before posting a comment. But thanks for your answer.

This is good advice. We use the [tag:bitcoin-core-development] tag to collect questions about the Bitcoin Core source code, so you may find some interesting topics labelled such already.

@Murch Thanks, that is so useful for me.


text:
Is it practical to prevent a 51%-attack by having a second mining algorithm?
While miners use special hardware designed to perform only one job (e.g. calculating sha256) changing that job would make all that hardware useless. So, can the bitcoin community use this vulnerability to protect against a 51-percent attack? For example by changing the hash algorithm from sha256 to sha384 or sha512?
By this, I don't mean something like randomX. As far as I know randomX changes the mining algorithm frequently. But what I mean is to have a second algorithm for the day that a 51%-attack is taking place.

A 51% attack is a breakdown of the security assumptions underlying proof-of-work, namely that it incentivizes actors strongly enough to behave cooperatively.
If an attack happens, it means those assumptions were wrong, and PoW should be discarded entirely. Switching to another hash function doesn't change anything. If the economic reality allows an actor to gain a hashrate majority with one function, there is no reason to assume it couldn't do the same with another hash function.
Of course, the community - at the social level - obviously has the possibility to jointly decide to make any changes to the consensus rules. Whether that is switching to another hash function, or a more narrow change such as deciding that a particular chain by a particular party is invalid. And the existence of that ability is something a would-be 51% attacker should take into account when weighing their odds. I feel this is mostly a mutually assured destruction like scenario; the impact of such a dramatic measure is likely very devastating even if it is successful.

Thanks, but why you think if any attack happens to PoW it should be discarded entirely? imagine after a long period of time (e.g. 10 years) some party be able to attack the network and break it down, why not change the rules to survive another 10 years? I mean we can look more flexible. PoW is great but we may need some protections against its weaknesses.

The fact that the attack is possible at all implies PoW doesn't work. Its purpose it removing the need for coordination. If it needs coordination to add "protections" on top of it, then what is the point? There is no reason to assume it would take as long a second time as a first time to break down again.


text:
Sparrow with Keystone Pro and Bitcoin Core
I originally set up Sparrow with a Keystone 3 Pro, and have been using public endpoints. Recently, I set up a Bitcoin Core node in my house. I can successfully connect Sparrow to the node, but all transaction history for my Keystone wallet is missing. Any ideas?

Any ideas?

Ideas yes, but based more on guesswork than on actual experience with Sparrow.
Bitcoin core normally does not maintain an index of all transactions for performance and storage reasons.
It would maintain an index for transactions involving addresses for which it knows the keys, including watch-only/non-spendable addresses for which it already knows only the public key. When you add keys/addresses generated externally I believe you have to tell Bitcoin core to rebuild its transaction indexes by scanning its blockchain records from the genesis block onwards. This is obviously more involved if you have pruning enabled.
Perhaps some essential step was omitted when preparing the connection from Sparrow to Bitcoin core. Consequently none of the transactions of interest to Sparrow are in Bitcoin Core's index.

Yes, I had to go back and index the wallet in bitcoin core. This involved updating my bitcoin.conf file to add server=1 and txindex=1 and also make sure I had wallet= specificed.
Then I had to ultimately perform the bitcoin-cli importdescriptors command. This involved specifying the descriptors in a JSON file. Hope this helps anyone else who gets stuck on it.


text:
if my wallet is sufficiently secure, can I ever lose my coins?
I've made an offline address and only have the key stored on 2 encrypted flash drives stored in different locations with the private key written physically on paper and stored in 2 locations. Do I ever have to worry about my coins? That is, could theyever be lost in software changes or is that as big of a never-going-to-happen as the 21 million limit being lifted? I'm pretty sure I'm not touching that wallet for a long time. Is there any benefit to repeating this process for a more "fresh" address ever or does that not make sense?

I'll go through your question clause by clause:

I've made an offline address

You're doing good.

and only have the key stored on 2 encrypted flash drives stored in different locations

As long as only you know the password and the password is sufficiently strong, this is probably secure.

with the private key written physically on paper and stored in 2 locations.

If either of these two locations are accessible by anyone other than you, then they are vulnerable. If someone else found either paper, and your keys are in plain text, then you could consider them compromised.

Do I ever have to worry about my coins?

Yes.

That is, could they ever be lost in software changes

Extremely unlikely, as the whole of Bitcoin depends on the safety of balances through upgrades. There are people who have very vested in ensuring that this never happens. Even a bug in the protocol could not erase history in an unrecoverable way, as a single offline client copied online or bootstrap.dat would refresh anyone affected.

or is that as big of a never-going-to-happen as the 21 million limit being lifted?

Pretty much.

I'm pretty sure I'm not touching that wallet for a long time. Is there any benefit to repeating this process for a more "fresh" address ever or does that not make sense?

Theoretically, you would never need to regenerate keys unless some kind of vulnerability was found in the software that generated your key, ala the Android random number generator flaw.
An unlikely occurrence would be some kind of change to the way private keys are imported, and your private key generated in 2013 cannot be securely converted to whatever format is expected in 2063, or whenever. I wouldn't get too paranoid about this.

They could be lost in a few rare scenarios. For example:

If substantial weaknesses are found in Bitcoin's crypto, or if quantum computing becomes usable on a large scale, your coins could be stolen. Most likely, the crypto will simply be weakened and attacks will still be very slow, so you'll have some time to send your coins to new addresses that use improved crypto.
When you go to redeem your coins, your CPU may err in a way that causes Bitcoin to send your coins into oblivion. There are no known cases of this actually happening, but CPUs are not perfect, and it is possible.
If Bitcoin develops critical scalability problems, and nothing else solves it, one "nuclear option" for improving things would be to require everyone to "renew" their coins every few months (or whatever). Old coins that that aren't renewed would be destroyed. If this policy is implemented, you will have to follow it. You'd have plenty of warning if something like this was approaching.

To protect yourself against these things and other possibilities, you should:

Not store too much in any one address.
Not send huge amounts at once.
Never send from any high-value address more than once. The best way to do this is to only pay to an address once.
Make sure that you're able to access your wallet with only a few days of notice.

There isn't any value in moving coins before you need to.

Sounds to me like you are taking good care of your Bitcoins, so you should be able to sleep easy at night.
Of course, there is always a risk that your account could be hacked through a scam.
Bitcoin is the realm of technophiles, so always be careful when conducting transactions. The sad truth is that there are some scammers out there looking to hack into accounts. And as they are often very bright, there is always a risk that you could be tricked.

Your answer misses the point here: Since he created his key offline there is no risk that the funds could be accessed through hacking/scam since they are literally not accessible from his day-to-day computing equipment.

Hey boss, my assumption is that he will still be conducting some trading and activities online. Correct me if I am wrong, but he will have to reload the bitcoins no? Also, if he used a flash drive, then he used his fingers to type, and there are spyware programs out there that can and will read what you type.

The asker wrote "I'm pretty sure I'm not touching that wallet for a long time." as in, he will not be conducting trades and activities with this particular wallet. Of course some point in the far future he will re-import his private key to access his funds, but before then, the situation is such as he described in detail: He keeps his private key offline in two different usb sticks and two paper copies. While these types of storage pose their own security risks, they definitely cannot be attacked by hacking or scam.

Also he wrote that he created the wallet offline: If he went about that in a sensible manner, he did that as follows or similarly: He disconnected his machine from the internet, booted it with a clean live cd, created and backed-up a new wallet, then shut down the computer again. That way only a hardware spy-tool that stores information through shut-downs could have sniffed out anything, which I find implausible.

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


text:
Consensus Question
With all the recent developments of the spammers and those who want to filter them. I have a few things I don't get. They mention the bug that wasn't fixed (CVE-2023-50428). As I understand, this "bug" is that Bitcoin Core developers did not implement a filter for the jpegs on the policy side of things after the taproot has merged, and if they would, like Bitcoin Knots did, it could still get into the block with a help of a miner because it still would be within the consensus. That's the first one. Another one is about op_cat and other covenant proposals. For example the bip 420 is for the reintroduction of op_cat. As Satoshi removed it, is it forbidden on the consensus side or on the policy side. If it was removed from the consensus, if it will be merged, how will it be backwards compatible? But if it is a policy, op_cat can appear today with a help of a miner?
Thanks

there is too many questions in one there. Could you try and ask each question separately? Mind subjective questions aren't a good fit for this site so try to phrase it so it's more focused on some objective technical aspects of it.

You might be thinking of valid yet non-standard transactions. From the point of view of the node software:
Standardness is what type of transactions should be included.
Validity is what type of transactions could be included.
If a node sees a prospective transaction as non-standard it will not share it on the P2P network and will not include it in candidate blocks for mining, even if it is valid. However, if it sees non-standard yet valid transaction has been confirmed on the chain, it will accept it.
Bitcoin Core and and Bitcoin Knots have a slightly different point of view (policy) on standardness, but agree on validity. If nodes were to disagree on validity, there would likely be a fork.

...how will it be backwards compatible?

It might be worth looking at OP_CHECKSIGADD for an example opcode only used in Tapscript.
case OP_CHECKSIGADD:
    {
        // OP_CHECKSIGADD is only available in Tapscript
        if (sigversion == SigVersion::BASE || sigversion == SigVersion::WITNESS_V0) return set_error(serror, SCRIPT_ERR_BAD_OPCODE);

But if it is a policy, op_cat can appear today with a help of a miner?

No, the script would be invalid. Such a transaction, and its block, would be rejected as invalid by all nodes running a Bitcoin Core version, or derivation, released since OP_CAT was removed (i.e. ~all of them).

Thanks for the answer, how are they planning on adding the op_cat then, if it will be rejected by for example core 27.0?

I found out, they are adding it as a new opcode in tapscript, not reenabling the old one


text:
Cannot connect Sparrow wallet to node using username and password
I'm trying to connect my node to Sparrow wallet on two computers on the same network. As I understand it, I have to authenticate using username/password option on Sparrow. This is the same computer I have the node running on. I have the bitcoin.conf file set up with
server=1
rpcuser=user
rpcpassword=pass

However when I test the connection, I get this error message on Sparrow
Could not connect:

User/pass authentication failed

I've checked many times and the user and password match, so I'm not sure what is the issue here.
If I don't use the authentication option, Sparrow connects to the node with no issue. Any help will be greatly appreciated.

What error do you get when using curl to test Bitcoin RPC


text:
Why doesn't my bitcoin testnet address work on testnet faucets?
I have created a bitcoin testnet address but it shows invalid address.
I have created it using this way
passphrase = b'blah'
secret = little_endian_to_int(hash256(passphrase))
print(PrivateKey(secret).point.address(testnet=True))

def little_endian_to_int(b):
    ans = int.from_bytes(b, 'little')
    return ans
def hash256(s):
    '''two rounds of sha256'''
    return hashlib.sha256(hashlib.sha256(s).digest()).digest()

G = S256Point(
    0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798,
    0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8)

class PrivateKey:

    def __init__(self, secret):
        self.secret = secret
        self.point = secret * G
def address(self, compressed=True, testnet=False):
        '''Returns the address string'''
        h160 = self.hash160(compressed)
        if testnet:
            prefix = b'\x6f'
        else:
            prefix = b'\x00'
        return encode_base58_checksum(prefix + h160)
def hash160(self, compressed=True):
        return hash160(self.sec(compressed))

My address generated was n1tS4gT4ksDvRUgQwpPDFR56GjbVrYb2Tw
It even starts with n, which it should, but still it shows invalid address.

It's a valid address, where specifically does it show as invalid?

@VojtěchStrnad https://bitcoinfaucet.uo1.net/send.php, here its showing invalid

It appears this faucet doesn't accept legacy addresses. There's nothing we can do about that.

Got it, Thanks @VojtěchStrnad